Re: [HOKEY] [IPsec] New I-D: draft-nir-ipsecme-erx-00

["Dan Harkins" <[e-mail]>]

On Wed, May 4, 2011 12:11 pm, Yoav Nir wrote:
> Hi Dan,
>
> On May 4, 2011, at 9:47 PM, Dan Harkins wrote:
>
>>
>> On Tue, May 3, 2011 10:30 pm, Yoav Nir wrote:
>> [snip]
>>> The Authenticator needs the true identity to make policy decisions.
>>
>>  Well then DO NOT use EAP for authentication.
>>
>>  Dan.
>
> I'm sure I don't understand your point. The IKE responder does not need to
> know whether the user's true identity in the sense of whether she is a cat
> person or a dog person. "[e-mail]" is good enough for policy
> lookups and policy decisions, as well as for generating meaningful logs.
> "[e-mail]".com", where the part before the at-sign is a hex
> representation of an ephemeral key is not.

  Well my comment certainly wasn't a flippant one (cat person versus dog
person?). So let me expand on it a bit.

 RFC 5996 says in section 2.16:

  "When the initiator authentication uses EAP, it is possible that the
   contents of the IDi payload is used only for Authentication,
   Authorization, and Accounting (AAA) routing purposes and selecting
   which EAP method to use.  This value may be different from the
   identity authenticated by the EAP method.  It is important that
   policy lookups and access control decisions use the actual
   authenticated identity.  Often the EAP server is implemented in a
   separate AAA server that communicates with the IKEv2 responder.  In
   this case, the authenticated identity, if different from that in the
   IDi payload, has to be sent from the AAA server to the IKEv2
   responder."

  When sending EAP traffic over a AAA connection, the IKEv2 responder has
no guarantee that the EAP conversation will be terminating on the AAA
server he is passing the EAP traffic to. IDi might be an obfuscated
identity used solely for AAA routing purposes and that routing might send
it via a few proxies somewhere to a AAA server who has no idea what IKEv2
is, and even if it knew what IKEv2 is it might not know if IKEv2 was
being used in this particular case. While proxies shouldn't be mucking
with the EAP identity in the forwarded packet (the obfuscated and
non-"true identity" one that isn't useful to the IKEv2 responder) they
certainly can modify the Username attribute in the RADIUS packet that
encapsulates it. That means that the identity a particular AAA
server/proxy might get to see might not be what was originally put into
the initial Access-Request by the IKEv2 responder and it might be
different than the one, ultimately, obtained by the AAA server that
actually speaks EAP. Furthermore, one or more of those proxies along the
way might not even know what EAP is!

  Even if one assumes that the AAA server that terminated EAP will
include the identity it authenticated as the Username attribute in the
Access-Accept it sends back (and that it's included in all proxied
Access-Accepts and ultimately reaches the IKEv2 responder) there is
nothing that says that identity has any relevance or significance to
the IKEv2 responder. It could be a SIM identity from EAP-SIM. It could
be "emp12876" used in EAP-MD5 (yea, I know it's not supposed to be
used, so tunnel it in PEAP and then you have a nice, compliant, key
generating EAP method for IKEv2). Which means the IKEv2 responder has
an obfuscated identity that is not useful for authentication purposes
and, maybe, just maybe, it also has some identifier that was useful for
a method it does not know in a realm/domain/whatever it also does not
know.

  To sum, while the identity "has to be sent" (note the non-normative
nature of that statement) there is no guarantee that it will. And even
if it is sent, there is no guarantee that it will be useful in the way
you need to use it.

  Therefore, if the authenticator needs to know the true identity (as you
suggest it must) then don't use try to authenticate the IKEv2 peer in a
way that might not get you what you need.

  regards,

  Dan.