Re: comments on draft-houseley-aaa-key-mgmt-07.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on draft-houseley-aaa-key-mgmt-07.txt



Dan,

We are discussing the case of the authenticator providing a different identity to the peer and the server here. Sam raised that issue.

Earlier Vidya described the problem you raise below: that of an authenticator (or an entity in the middle) providing the wrong identity, but the same wrong identity, to the peer and the server and proposed a key distribution requirement that would address the problem. See http://www1.ietf.org/mail-archive/web/ietf/current/msg45291.html.

Please provide your thoughts on whether her proposed text covers the issue adequately. Otherwise, please provide text.

thanks,
Lakshminath

Dan Harkins wrote:
  Hi Vidya,

On Sat, February 17, 2007 11:43 pm, Narayanan, Vidya wrote:
Yes, the problem of an authenticator providing different identities to
the peer and the server is the typical channel binding problem and can
be detected by simply doing a protected exchange of the identity between
the peer and server. When such a discrepancy is detected, then, keys
won't be handed out or if the identity is part of the key derivation,
then, it will result in a key mismatch anyway. Hence, there is no
problem there.

No, there is a problem even if the identity is part of the key derivation. The reason is that this is a _symmetric_ key that is used by the client to gain network access. If it is possible for some entity to lie about its identity to obtain one of these keys, then that key can be used to impersonate the client to the authenticator whose identity was lied about and/or attack a connection the client makes to the authenticator whose identity was lied about.

  Any security properties you're trying to assign to this key have been
thrown out the window.

Dan.

_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.