ietf
[Top] [All Lists]

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

2007-02-19 00:23:33
Hi Yoshi, 

-----Original Message-----
From: Yoshihiro Ohba [mailto:yohba(_at_)tari(_dot_)toshiba(_dot_)com] 
Sent: Sunday, February 18, 2007 7:26 PM
To: Narayanan, Vidya
Cc: Dondeti, Lakshminath; Sam Hartman; 
bernarda(_at_)microsoft(_dot_)com; Dan Harkins; ietf(_at_)ietf(_dot_)org
Subject: Re: comments on draft-houseley-aaa-key-mgmt-07.txt

On Sat, Feb 17, 2007 at 11:43:38PM -0800, 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.

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.

Yes, this is a problem that should not happen.  If this 
happens, the peer may send out data that is specific to ISP2 
to the lying authenticator (which is actually an ISP1 entity 
but claiming itself to be an ISP2 entity) that is not 
supposed to see the ISP2-specific data.

Going back to your proposed text: 

  "It is RECOMMENDED that the key transport protocol be able to detect
  impersonation. When it is not feasible to guarantee that, every key
  handed out from the server to an entity for a given peer MUST be
  different from every other key handed out for a given peer."

I think that detection of impersonation is part of the 
"Authenticate all parties" *requirement* (not a recommendation).


I don't think it is a "requirement" - and the reason I believe that is
due to the second sentence in that text above. This is what I tried to
explain in much greater detail in my first response to Sam on this
thread. As long as no two keys distributed from the server are the same,
even to the same perceived identity, there is nothing that a lying
entity can do to sessions with other entities. So, as long as a solution
satisfies that criteria, it is not a MUST to detect impersonation. But,
I do agree that it would be much better if the detection was done by the
key transport mechanism - hence, I think "RECOMMENDED" is appropriate :)



By the way, recent discussion on 3-party key distribution 
over HOKEY mailing list made me think more about the 
following text in Section 5 (I don't know whether this is 
part of Dan's comment as I did not see his original comment 
on this mailing list):

"
   The authenticator is also a trusted party.  The authenticator is
   trusted not to distribute keying material provided by the 
AAA server
   to any other parties.  If the authenticator uses a key derivation
   function to derive additional keying material, the authenticator is
   trusted to distribute the derived keying material only to the
   appropriate party that is known to the peer, and no other party.
   When this approach is used, care must be taken to ensure that the
   resulting key management system meets all of the principles in this
   document, confirming that keys used to protect data are to be known
   only by the peer and authenticator.
"

I understand that the authenticator is a trusted party for 
the EAP/AAA server.  On the other hand, I don't think we can 
say that it is a trusted party for the peer before running 
EAP, unless the link between the peer and the authenticator 
is already secured or the peer and the authenticator have 
already a shared key to believe before running EAP.


I agree. In my understanding, the text above is talking about the fact
that the authenticator is a trusted party to the server and because the
peer trusts the server, it trusts the authenticator after it has proven
possession of the right key. So, in that sense, the text seems fine to
me. 

Vidya


Regards,
Yoshihiro Ohba




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




_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf