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.
In my understanding, Dan's claim is that the server is unable to detect
that an authenticator is claiming an incorrect identity and by virtue of
that, if the authenticator claims the false identity to both the peer
and the server, a key will be provided to the authenticator and that
will match the key that the peer derives, even if the identity was part
of the key derivation. This is the problem that I have detailed in my
earlier email and I belive that can be resolved with the text I
proposed.
Regards,
Vidya
-----Original Message-----
From: Lakshminath Dondeti [mailto:ldondeti(_at_)qualcomm(_dot_)com]
Sent: Saturday, February 17, 2007 9:36 AM
To: Sam Hartman
Cc: Narayanan, Vidya; bernarda(_at_)microsoft(_dot_)com; Dan Harkins;
ietf(_at_)ietf(_dot_)org
Subject: Re: comments on draft-houseley-aaa-key-mgmt-07.txt
Sam,
The problem of an entity in the middle giving disparate
information to the peer and the server is in fact easier to
solve than the problem Vidya summarized. The disparate
information problem has been described in the EAP Keying
Framework document and elsewhere too.
To my understanding, we are beyond that point in the
discussion in HOKEY and considering the new case of the
entity in the middle lying to both sides and attempting to
get a key that another entity in the middle is supposed to get.
Let me put it this way, both issues are considered problems
to address/solve in this case.
regards,
Lakshminath
Sam Hartman wrote:
Vidya, I found the model you proposed didn't fit what Dan
was talking
about very well. In particular, Dan wants to focus on problems
resulting from the fact that the name of the authenticator used
between the peer and the authenticator may be different
than the name
of the authenticator used between the authenticator and the AAA
server. That distinction did not figure prominently enough in your
argument that I could tell whether you and Dan are talking
about the
same thing nor whether I could even tell if I agreed with you. I'd
recommend refocusing your model on this distinction; I
think once you
do we may well make significant progress on discussing a
long-standing
issue.
--Sam
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf