Subject: Re: [IPsec] Issue #32 Demoted SHOULD: EAP Identity Request

From: <[email-masked]>
Date: Tue, 14 Oct 2008 13:41:39 +0300

Tero Kivinen wrote:

> I.e. the valid reason for not skipping identity request would have
> been that it is impossible because the EAP library does them
> automatically and they cannot be disabled. The bad thing about doing
> EAP identity request is that the policy lookups for the entity are NOT
> done based on them, but based on the ID payloads in the IKEv2. If the
> identity payloads mismatch (i.e. EAP payloads claim I am
> [email-masked], but the ID payload claims I am [email-masked]),
> the authentication might still succeed as EAP library just uses the
> EAP identity payload to verify the credentials, but IKE library uses
> the ID sent in the IKE, and nobody matches that those two matches.
> 
> BTW, I think we need to add some text that says those identities must
> match or at least you MUST use the EAP identity for access control and
> policy lookups, and also add some text to security considerations
> section.

When using e.g. EAP method that provides identity privacy using
temporary pseudonyms, the identity carried in IDi and the identity
authenticated by EAP won't typically match. RFC 4718 Section 3.5 has
text about this:

   When the initiator authentication uses EAP, it is possible that the
   contents of the IDi payload is used only for AAA routing purposes and
   selecting which EAP method to use.  This value may be different from
   the identity authenticated by the EAP method (see [EAP], Sections 5.1
   and 7.3).

   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 using, e.g., RADIUS [RADEAP].  In this case, the
   authenticated identity has to be sent from the AAA server to the
   IKEv2 responder.

This made its way to draft-ietf-ipsecme-ikev2bis-00, end of Section 2.16:

   {{ Clarif-3.5 }} When the initiator authentication uses EAP, it is
   possible that the contents of the IDi payload is used only for 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 has to be sent
   from the AAA server to the IKEv2 responder.

Do you think we need more text about this?

Best regards,
Pasi
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 14 Oct 2008 15:47:26 +0300

> Do you think we need more text about this?

Ah, missed that text. Would have mostly assumed it to be in the
security considerations section, but I think the EAP section is ok
too.

Perhaps add another pointer to that section in the section 3.16 where
it tells that "responder SHOULD NOT send EAP identity requests", and
point implementors to that Clarif-3.5 text if the that SHOULD NOT is
not followed.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 14 Oct 2008 11:04:06 -0700 (PDT)

Hi Pasi,

On Tue, October 14, 2008 3:41 am, [email-masked] wrote:
[snip]
> Do you think we need more text about this?

  What AAA attribute is supposed to be used by the AAA server to communicate
this information back to the IKEv2 responder?

  And it's a little more complicated too. Not only is the EAP server often
implemented in a separate AAA server, in some EAP methods that server won't
even me the one doing the actual client authentication! In a tunneled EAP
method like PEAP or TTLS the "inner method" may be done by yet another AAA
server.

  Dan.

---

From: "balaji raghavan" <[email-masked]>
Date: Wed, 15 Oct 2008 14:40:26 +0200

Hi,

> method like PEAP or TTLS the "inner method" may be done by yet another AAA

The AAA server can communicate the authenticated identity to the IKEv2
responder if required,  for example in the case of RADIUS using the
User-Name attribute in an Access-Accept response..

However it is not mandatory for the RADIUS server to do so.
Identifiers are used to match responses to requests(rfc 2865).

Perhaps it was meant to be interpreted as this:

The RADIUS server not only authenticates the EAP identity,  but also
communicates to the IKEv2 responder as to  what is acceptable in the
IDi payload ? However wouldn't that be stretching the use of the
'User-Name' attribute in rfc 2865 ?

But the bottom line is that the identity in the IDi payload is used to
determine the policy lookup, access control etc and maybe if needed to
select the EAP method.

-Best Regards
Balaji Raghavan

---

From: <[email-masked]>
Date: Thu, 16 Oct 2008 13:16:54 +0300

Dan Harkins wrote:

> What AAA attribute is supposed to be used by the AAA server to
> communicate this information back to the IKEv2 responder?
> 
> And it's a little more complicated too. Not only is the EAP server
> often implemented in a separate AAA server, in some EAP methods that
> server won't even me the one doing the actual client authentication!
> In a tunneled EAP method like PEAP or TTLS the "inner method" may be
> done by yet another AAA server.

Currently, there's no RFC or Internet-Draft that describes AAA
attributes for IKEv2 at all -- but e.g. RFC 4072, Section 2.8.1, 
talks about using the User-Name AVP for similar purpose. 

Best regards,
Pasi

---

From: "balaji raghavan" <[email-masked]>
Date: Mon, 27 Oct 2008 14:25:25 +0100

Hi Pasi,

Although we have answered the question of how to communicate the EAP
identity back to the IKEv2 responder , there is one question that
hasn't been addressed.

As Tero pointed out earlier, there is no way to match identities used
in EAP to those used in IKEv2 ID payloads( i.e if they are different).
There should be some explicit configuration on the IKEv2 responder
about the EAP & IKEv2 identities, to be able to be sure that the
authenticated identity is used by IKEv2, for policy selection etc.

I ran into this ambiguity in the MIPv6-IKEv2 specs too.. (RFC 4877)

---------
8.  The Use of EAP Authentication
---------
  carried inside EAP, invisible to the home agent.  While IKEv2 does
   not allow an EAP Identity Request/Response message exchange, EAP
   methods may exchange identities within themselves.  In this case, the
   home agent MUST acquire the mobile node's identity from the
   corresponding AAA server.  How the home agent acquires the mobile
   node's identity is out of scope for this document.
------------

I agree that no one(=> no WG)  wants to get into the nitty-gritty of
specifying how to communicate with all possible AAA servers due to
scoping issues..

But no where it's clarified on what is to be done by the responder
after it obtains the EAP identity from the AAA server.

For PKI Authentication type the MIPv6 spec (RFC 4877) explicitly
requires the identity within the IDi payload and identity in the
certificate to match. In that particular case the requirement that the
authenticated identity is used for policy lookup, access control etc
is satisfied.

Atleast the security considerations section should be updated with
this info, as Tero pointed out earlier, as the authenticated identity
cannot be used to govern policy lookups etc, if the responder is
unable to "match" the EAP identity to the one indicated by IDi.

-Best Regards
Balaji

---

From: <[email-masked]>
Date: Thu, 30 Oct 2008 12:59:19 +0200

> unable to "match" the EAP identity to the one indicated by IDi.

There's no requirement that IDi and the authenticated EAP identity
have to match, and I don't think we should have one. I agree that
adding a sentence or two to the security considerations text (giving 
a pointer to the last paragraph of Section 2.16) would be a good idea.

Best regards,
Pasi