Session key derivation for draft-ietf-krb-wg-anon and channel definition

[Sam Hartman]

In version 10 of the anonymous draft, we introduced the requirement that
the session key needs to have contributions both from the client and
KDC.  This is designed to help the use of anonymous in conjunction with
FAST.

An armor key in FAST needs to form a channel.  In particular, we want to
detect man-in-the-middle attacks.  This is especially true if the
replace reply key facility is used.  With that facility, a fast factor
can replace the reply key used for the AS response.  Potentially if the
armor key does not form a channel then the new reply key may be
disclosed to the attacker.  We've reduced the impacts of these attacks
by using strengthening of reply keys rather than replacing reply keys.
I think the original attack that made making the armor key a channel
critical is no longer possible even if the armor key does not form a
channel.  However the security analysis of FAST is made easier and
certain uses of FAST (including aspects of the OTP draft) are enabled if
the armor key is a channel.
So, I think making the armor key a channel is still important.

Without anonymous, we know that the session key in the ticket is chosen
by a trusted KDC.  The client can trust that it is learning the key from
the KDC not an attacker because it has an authenticated relationship
with the KDC and because the reply key in the AS request is integrity
protected by this relationship.

In the anonymous case, this breaks down when the client does not have a
path-validated certificate for the KDC.  Because of the DH exchange, the
client trusts that it has established a key with some party initially
known only to the client and that party.  However that party could be an
attacker.

The attacker can perform a DH exchange with the real KDC using anonymous
authentication.  It receives a ticket including a session key.  Then,
when the client contacts the attacker, the attacker performs a DH
exchange with the client and issues a ticket with the same session key
to the client.  If the client later uses this ticket as an armor ticket
for FAST, then the attacker will know the armor key.  This defeats the
definition of a channel because an attacker can construct a channel with
a name of the attacker's choosing

Larry and I proposed to fix this by binding the session key of the
issued ticket to the DH exchange key.  The client can verify the form of
the session key and thus show that the session key is produced by the
same party with whom the DH exchange is made.  In particular, we want to
guarantee that the party acting as client and party acting as KDC both
contribute to the session key when anonymous pkinit is used.  This is
only important in the case where the client is not verifying the
certificate of the KDC, although we propose to verify this all the time
so that all KDCs will support the case where the client cannot verify
the certificate.

In draft 10, Larry introduced a new padata type to accomplish this.
Love complained that introduced unneeded complexity.  At the time, I
agreed, although was ambivilent on whether the issue should be fixed; we
could do better but draft 10 seemed good enough.  I've been thinking
about this for a while and at least for my implementation, implementing
the text in draft 10 than something without a kdc contribution key
padata item.

I think it is sufficient to provide a one-way transformation of the
reply key to form the session key.  At IETF 76, we conferenced Love into
the meeting in order to discuss this issue.  At that point, we discussed
whether it is necessary to implement client and server DH nonces as
proposed by RFC 4556.  Love's comment was that without the nonce, you
could not guarantee that some party wasn't reusing a DH key in a manner
not recommended by RFC 4556.  I think he's right: I think a significant
potential attack is opened if you don't permit the KDC to guarantee that
the session key is fresh.  Authorization elements such as ad-kdc-issued
and the MS PAC depend on a client not knowing the session key before a
ticket is issued.

I agree with Love that if you can depend on an implementation supporting
DH nonces and if you have a function to transform one RFC 3961 protocol
key into another,then you can provide a mechanism simpler than the KDC
contribution key proposed in draft 10.

However as an someone implementing today, I will find the draft 10 text
much easier to implement, so I propose we stick with that text.  This is
very much a preference based on what it is easy to do with the pkinit
implementation in MIT Kerberos.  I think implementation simplicity is a
valid concern for the WG to consider, but I want to stress that is
entirely the justification for my position at this point.

The advantages of draft 10's text for the implementation I'm working on
include:

* I don't need to implement DH nonces


* I can key session key verification and generation separate from the
   pkinit code.  The draft 10 text can be expressed entirely in terms of
   the reply key and the KDC contribution key and does not involve any
   pkinit specific details.