Anonymous pkinit, KDC issued, and generation of session key

[Sam Hartman]

The anonymous pkinit project is getting to be a bit messy.
I've found another complication.

For background, it's important that both the client and KDC contribute
to the session key when anonymous pkinit is used.  The reason is that
we want to make sure that a man in the middle cannot splice together
two KDC conversations so they both have the same session key.  One
consequence of that happening would be that an attacker could glue
together a FAST conversation from the client to the attacker and
another from the attacker to the remote KDC.  Especially if the
replace reply key facility were used, the attacker could compromise
the authentication.  Regardless, the attacker could violate the
security assumptions of the FAST channel.

The proposal on the table is to generate the session key by deriving
it from the reply key, which is a result of a DH exchange between the
client and KDC.  That should meet the requirement that both the client
and KDC contribute to the session key.

In our code, the session key is generated before any
pre-authentication plugins are called.

In addition, our code allows a pre-authentication plugin to insert
authorization data into the resulting ticket.  Pkinit uses this in
order to include ad-initial-verified-cas into the ticket.

Unfortunately, sometimes you need the session key in order to generate
authorization data. Two examples include ad-kdc-issued and the MS PAC.

Long term, it seems that ad-initial-verified-cas will need to be
included in an ad-kdc-issued element.

An additional complexity is the trimming of authorization data
mandated by the anonymous draft.  The anonymous draft rightly points
out that authorization data can give away the identity of the client.
The PAC definitely does this.  So, as a general rule, you trim
authorization data from a request in anonymous mode.

I think I can make this work as follows.  I'll overwrite the session
key in the pkinit plugin if anonymous is in use.  If the anonymous KDC
option is set, we will throw away all authorization data generated by
preauth plugins.  In addition, we will require authorization data
plugins explicitly indicate support for anonymous to be called.
In 1.8 I think the only thing we should support is copying authorization data from the request into the ticket.

This is ugly.In particular it means that we're going to treat
anonymous pkinit as special in more places than I'd originally
thought.  It means that we will have to handle cases where a preauth
plugin needs to generate KDC-ISSUED authdata differently if it needs
to work with anonymous than if it does not.  It means that the
mechanism I'm introducing for a preauth plugin to change the
session key is not general.

However this seems reasonable.  Perhaps we will clean it up, although
I don't think any of the above restrictions will tend to hurt us in
practice in the future.

Thoughts?

--Sam