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

From: Yoav Nir <[email-masked]>
Date: Mon, 2 May 2011 14:31:04 +0300

Hi.

Qin and I have just posted the subject draft.  The title is "An IKEv2 Extension for Supporting ERP", although it has nothing to do with enterprise resource planning.

This draft brings the ERP extension for EAP, which is developed by the Hokey group into the IKEv2 authentication exchange, allowing a client ("peer" or "initiator") to authenticate to a VPN gateway ("Authenticator" or "responder") in only three round-trips, and without user intervention, provided that this client has unexpired keys from a previous run of EAP. It doesn't matter whether the previous run was done in the context of another IKE exchange, attachment to a 802.1x LAN or over PPP.

We would like this draft to be accepted as a working-group item in IPsecME, although serious review in hokey will also be needed.

I'd like to use this one-time cross-posted mail message to explain some of the design decisions in this -00 version of the draft.

The EAP-Initiate/Re-auth-Start message is missing from the protocol. Instead, a notification payload carries the domain name. This was done because an EAP payload in the IKE_SA_INIT response would be weird, whereas unknown Notifications are common. We are not sure whether placing the domain name is necessary, because in IKE, the client usually connects to a pre-configured gateway, rather than attaching to any network available as in 802.1x.

We do not run two EAP protocols in parallel (re-auth and something else) as in RFC 5296 and the bis document, because IKEv2 ususally doesn't have identity requests (they identity protocol is replaced by the user identity in the IDi payload), and running a real EAP protocol would put us in a weird state with the backend EAP server. Instead, we send the domain name in the notification payload, and the client may either send the EAP-Initiate/Re-auth message or the IDi payload (but not both).

Alternatively we could have the client indicate support in the IKE_SA_INIT request, and then have a proper EAP-Initiate/Re-auth-Start message in the IKE_SA_INIT response. I don't see much advantage in this, so in version -00 we did not do this.

We would very much appreciate feedback from both groups.

Qin & Yoav

---

From: Qin Wu <[email-masked]>
Date: Wed, 04 May 2011 14:18:22 +0800

Hi,
----- Original Message ----- 
From: "Yoav Nir" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 04, 2011 1:30 PM
Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00

> 
> On May 4, 2011, at 4:50 AM, Qin Wu wrote:
> 
>>>> - I am missing the "authenticated peer identity", which I would assume 
>>>> should arrive from the AAA server. This should be the basis of RFC4301 
>>>> policy decisions on the IKE gateway. Does ERP provide this identity?
>>> 
>>> The EAP-Initiate/Re-auth packet carries a keyName-NAI TLV, but that is sent from the client (or "peer") to the authentication server through the gateway. (section 5.3.2 of the bis document)
>>> The EAP-Finish/Re-auth packet also carries a keyName-NAI TLV, and that is sent from the authentication server through the gateway to the client.
>>> But these don't really help, because the username part of NAI is the 64-bit EMSKname, which is not directly related to user name.
>>> However, these messages come within an Access-Accept packet from the RADIUS server, and those include a proper user name.
>> 
>> [Qin]: If you are talking about the second identity specified in section 6.4 of RFC5998, I think, unlike EAP, ERP does not provide such identity.
>> ERP only define two types: one is Re-auth-Start, the other is Re-Auth.
>> 
>> KeyName-NAI TLV defined in RFC5296 and RFC5296bis more looks like the first idenity described in section 6.4 of RFC5998.
>> As decribed in section 5.1 of RFC5296,
>> "
>>     When an ERP-capable authenticator receives the EAP-Initiate/
>>      Re-auth message from a peer, it copies the contents of the
>>                                                       ^^^^^^^^^^^^^^^^^^^^
>>      keyName-NAI into the User-Name attribute of RADIUS [13]. 
>>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> "
> 
> But what does the RADIUS send in the User-Name attribute of Access-Accept?  How does the Authenticator know who the user is?  The Authenticator needs the true identity to make policy decisions.

[Qin]: I assume username part of KeyName-NAI will be regarded by RADIUS server as User-Name during authentication.
Also I think it is not necessarily to couple  authorization with authentication.

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Wed, 4 May 2011 10:00:54 +0300

> [Qin]: I assume username part of KeyName-NAI will be regarded by RADIUS server as User-Name during authentication.

RFC 3579 says:
                        "The User-Name attribute within the Access-
   Accept packet need not be the same as the User-Name attribute in the
   Access-Request."

Do current implementations copy the KeyName-NAI to the Access-Accept?  

> Also I think it is not necessarily to couple  authorization with authentication.

They may not be coupled in other EAP contexts, but IPsec requires policy decisions based on authenticated identity. One way or another, the IKE implementation needs to get the real user identity for policy decisions.

Yoav

---

From: Qin Wu <[email-masked]>
Date: Wed, 04 May 2011 15:27:19 +0800

Hi,
----- Original Message ----- 
From: "Yoav Nir" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, May 04, 2011 3:00 PM
Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00

>   Accept packet need not be the same as the User-Name attribute in the

[Qin]: RFC5296 does not specify how UserName is copied into Access-Accept. The reason this part is about authorization which is beyond scope of ERP document.
But I agree the different user name can be used. 
One way in my mind is 
Radius Server could use KeyName-NAI to look up real user name and add it into the Accss-Request.

> Do current implementations copy the KeyName-NAI to the Access-Accept?  

[Qin]: I am not aware of it. But it could be.

> They may not be coupled in other EAP contexts, but IPsec requires policy decisions based on authenticated identity. One way or another, the IKE implementation needs to get the real user identity fo…

[Qin]: Okay. the authenticated identity you mentioned is user identity, right?
I think we should be careful to differentiate these identities. becos it seems there are lots of identities:
e.g., EAP identity, IKEv2 identity and User identity.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 4 May 2011 22:11:53 +0300

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. "[email-masked]" is good enough for policy lookups and policy decisions, as well as for generating meaningful logs. "[email-masked]", where the part before the at-sign is a hex representation of an ephemeral key is not.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 4 May 2011 13:45:01 -0700 (PDT)

On Wed, May 4, 2011 12:11 pm, Yoav Nir wrote:
> 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. "[email-masked]" is good enough for policy
> lookups and policy decisions, as well as for generating meaningful logs.
> "[email-masked]", 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.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 5 May 2011 08:45:05 +0300

On May 4, 2011, at 11:45 PM, Dan Harkins wrote:

<snip />

> way that might not get you what you need.

OK. I see what you mean. Certificates are not necessarily better. She might have a certificate with a subject like "UID=alice,OU=people,O=intranet,DC=example,DC=com", or the AAA server might call her "emp715".  Either can serve. The VPN gateway needs the identity for two thing:
 - For policy lookup. As long as the policy database uses the same name, we're fine.
 - For generating logs. There should be a way to map the name in the logs to the real person, but I guess this re-conciliation of usernames and real names can be done either in generating the logs or in viewing the logs.

Any implementation using EAP has users that are either satisfied with "emp715" or use a directory to convert that in the logs to a more meaningful names.

In ERP the value used in KeyName-NAI is the EMSKName (as defined in section 3.2 or RFC 5295), or actually a hex representation of this value. The value is 64-bit, so the username part of the KeyName-NAI is just 16 hex digits, and they change each time the user does a full authentication. This value is later copied to the UserName attribute in the RADIUS AccessRequest, and probably also returned in the AccessAccept, although we're not sure that's what really happens.

This ephemeral value is much harder to map to either policy or to a meaningful name or to policy. Even if such a mapping can be done in real-time, it cannot be done later after the EMSK expires and is deleted. Even for real-time, it requires either the AAA server to store the policy and transmit it in the AccessAccept, or else to have the directory closely working with the RADIUS server to immediately map the EMSKName to a user record.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 4 May 2011 23:17:58 -0700 (PDT)

Hello,

On Wed, May 4, 2011 10:45 pm, Yoav Nir wrote:
> OK. I see what you mean. Certificates are not necessarily better. She
> might have a certificate with a subject like
> "UID=alice,OU=people,O=intranet,DC=example,DC=com", or the AAA server
> might call her "emp715".  Either can serve. The VPN gateway needs the
> identity for two thing:
>  - For generating logs. There should be a way to map the name in the logs
> to the real person, but I guess this re-conciliation of usernames and
> real names can be done either in generating the logs or in viewing the
> logs.

  Assuming the CA is trustworthy and the peer authenticated with that
certificate then you know that the identity named by the subject name
in the certificate is who that peer is. You can make a definitive
statement about it (although I'm not sure what attributes UID or DC are).

  "emp715" returned in an Access-Accept means nothing because it's
meaningful when used with an EAP method of X inside a realm/domain of Y
and you don't know what either X or Y are. So you can't make any
definitive statement about "emp715".

> Any implementation using EAP has users that are either satisfied with
> "emp715" or use a directory to convert that in the logs to a more
> meaningful names.

  Not to belabor the point, but a user could have an authenticated
identity of "emp715" in one realm/domain (that you don't know) and
a completely different user could have an authenticated identity of
"emp715" in a completely different realm/domain (that you also don't
know). Treating them the same is probably not a wise thing to do from
a policy enforcement standpoint.

  (There's a guy named "Dan Harkins" that owns a chain of theaters in
the state of Arizona in the US. I am not that man and I don't live in
Arizona, but I have received phone calls expressing outrage over the kind
of films that "I" show in "my" family theater, and asking why "I" stopped
giving out free popcorn to patrons on their birthday. I receive these
calls because people take a name, stripped of all context, and assume
something about it. And that is a mistake).

  regards,

  Dan.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 5 May 2011 09:59:08 +0300

> definitive statement about "emp715".

Depending on how large your federation is, "emp715" may be unique. In the simplest setup - one RADIUS server that holds records for all employees, it probably is unique. Otherwise, it should probably be in the form of [email-masked]. In both cases it should be enough to later map to a real person. If it's not, then the AAA setup has not been done right.

> a policy enforcement standpoint.

I think it's up to administrators to make sure that names are unique and traceable. If RADIUS has a record for Alice, with identifier "emp715", and when the VPN gateway looks up this string it gets an entry for Bob, it's a deployment error.

Besides, I think we're derailing the conversation. We have to assume that EAP works somehow, otherwise we're not going to do ERP. The question is how to get around the ephemeral identities transmitted in ERP.

> something about it. And that is a mistake).

Strange. I never get calls from people asking for diaper advice.
http://www.yoavnir.com

Yoav (not a diaper consultant)

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 05 May 2011 23:41:12 +0300

Hi,

I think we are going down a rathole on the issue of "authenticated
identity". Most IKE gateways, like many other security devices,
normally make policy decisions based on groups. I will provide
secure connectivity to [email-masked], but not to
[email-masked]. But I don't want to differentiate [email-masked]
from [email-masked].

It seems to me RFC 4306/5996 took the concept a bit further than RFC
4301 ever intended (in fact I believe the text is new to RFC 5996).
Presumably, when we talk about identity-based policy decisions, we
refer to http://tools.ietf.org/html/rfc4301#section-4.4.3.
This text (and the following section) explicitly allows for "bulk"
policies that apply to "@example.com", i.e. anybody at that domain.
And such coarse granularity may be sufficient in practice for
inter-ISP traffic: ISP1 may be happy to provide secure connectivity
to ISP2's customers and take a cut of the business, even if it
doesn't know the exact identity of each customer and cannot contact
them, bill them or log their names.

So I would suggest that the draft should mention that no individual
authenticated identity is available in the typical case (and this is
unfortunately in conflict with RFC 5996), but the obscured identity
provided in RADIUS Access-Accept can be used to make legitimate
policy decisions.

Thanks,

Yaron

---

From: Yoav Nir <[email-masked]>
Date: Fri, 6 May 2011 21:02:27 +0300

On May 5, 2011, at 11:41 PM, Yaron Sheffer wrote:

Hi,

I think we are going down a rathole on the issue of "authenticated identity". Most IKE gateways, like many other security devices, normally make policy decisions based on groups. I will provide secure connectivity to [email-masked]<mailto:[email-masked]>, but not to [email-masked]<mailto:[email-masked]>. But I don't want to differentiate [email-masked]<mailto:[email-masked]> from [email-masked]<mailto:[email-masked]>.

True, but often we cut the groups finer than that. If John works in sales and Jane works in R&D, they may have different authorizations (John does not go near the source control, Jane does not get to see the financial statement to be published next week). To negotiate the appropriate selectors, the gateway needs some group information. This can be done by abusing some RADIUS attribute to convey policy information, or else by querying a directory with the username received in EAP.

With ephemeral identities I don't see how this could work, unless we assume that there is a way for the gateway to query the AAA about some attributes of the user behind the EMSKNAme.

It seems to me RFC 4306/5996 took the concept a bit further than RFC 4301 ever intended (in fact I believe the text is new to RFC 5996). Presumably, when we talk about identity-based policy decisions, we refer to http://tools.ietf.org/html/rfc4301#section-4.4.3. This text (and the following section) explicitly allows for "bulk" policies that apply to "@example.com", i.e. anybody at that domain. And such coarse granularity may be sufficient in practice for inter-ISP traffic: ISP1 may be happy to provide secure connectivity to ISP2's customers and take a cut of the business, even if it doesn't know the exact identity of each customer and cannot contact them, bill them or log their names.

So I would suggest that the draft should mention that no individual authenticated identity is available in the typical case (and this is unfortunately in conflict with RFC 5996), but the obscured identity provided in RADIUS Access-Accept can be used to make legitimate policy decisions.

I'm not even sure of that. Qin, does ERP give us the domain name of the original authenticating server?  Do we even know if the user came from this-isp or that-isp?

Thanks,
    Yaron

---

From: Qin Wu <[email-masked]>
Date: Sat, 07 May 2011 08:42:53 +0800

Thanks,
        Yaron

  [Qin]: Sure.

  The domain name of the original authenticating server you are talking about is actually home domain name.
  The peer bootstraps from the home domain at the first time and should know home domain name or home ER server name wherever it moves around.
  The peer learns local domain name through ERP message or other lower layer mechanism. Therefore the peer can identify which domain it move to.
  The local ER server and ER  authenticator can know domain name through realm part of KeyName-NAI TLV carried in the ERP message sent from the peer.
  Comparing realm part of KeyName-NAI and the domain which they belong to, they also can identify if the user come from home domain or local domain.

------------------------------------------------------------------------------

---

From: Yoav Nir <[email-masked]>
Date: Wed, 11 May 2011 17:19:10 +0300

> Comparing realm part of KeyName-NAI and the domain which they belong to, they also can identify if the user come from home domain or local domain.

I wonder if local domain is ever distinct from home domain with IKE.

IKE/IPsec is usually used for site-to-site and for remote access VPNs. There is also some use for host-to-host, but I don't know what they use for authentication.

In the case of remote-access, the client connects to some home gateway. Unless there's some complex federation going with a single gateway answering for multiple domains, everyone connects to a gateway that is connected directly to the home RADIUS server. Even phones with an Internet (not 3G/4G) connection will connect to their "home" operator network rather than to a local operator network.

So I don't think there's a case where the AAA server is not the home server. And in that case, the AAA server has the real user name. So if we're using re-authentication, the VPN gateway has the domain (it is the same domain) and an ephemeral identity generated by the original EAP, which may have been done with another authenticator (such as a 802.1x access point)

This reduces the problem to getting the real ID from the ephemeral ID, assuming that you are talking to the real RADIUS server, or else being able to fetch policy from such a server or from an LDAP server. I guess vendors could have proprietary solutions, but I'm wondering if there's a standardized way to do this.

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 May 2011 15:11:14 +0800

Hi,
----- Original Message ----- 
From: "Yoav Nir" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; "Dan Harkins" <[email-masked]>; <[email-masked]>
Sent: Wednesday, May 11, 2011 10:19 PM
Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00

> I wonder if local domain is ever distinct from home domain with IKE.

[Qin]: From AAA perspective, local domain or visited domain should be distinct from home domain.
>From IKE perspective, I am not sure.

> So I don't think there's a case where the AAA server is not the home server. And in that case, the AAA server has the real user name. So if we're using re-authentication, the VPN gateway has the do…

[Qin]: It depdents on the scenario you are talking about.
When you are doing authorization, you should go back to home domain to talk with home
 AAA server since Home AAA server maintain user profile. When you are doing authentication, 
it is not necessary to go back to talk with home server each time since keying materails can be
transported to the domain which the client currectly connected to.

If you assume authorization and authentication are doing together each time, Fine, ERP described in RFC5296 allows this case.
In such case, there is no local ER server deployed in the visited domain, therefore each time the client or the peer should
go back to talk with home server.

Also I should point out EAP server or ER server may be separated from AAA server.

> This reduces the problem to getting the real ID from the ephemeral ID, assuming that you are talking to the real RADIUS server, or else being able to fetch policy from such a server or from an LDAP…

[Qin] We can go to do authorization in home domain each time. In this way, we can be easy to get real ID.

BTW:I remember this similar issue had been discussed in DIME and Hokey Working group.