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

From: Qin Wu <[email-masked]>
Date: Wed, 04 May 2011 09:52:52 +0800

FYI.
----- Original Message ----- 
From: "Qin Wu" <[email-masked]>
To: "Yoav Nir" <[email-masked]>; "Yaron Sheffer" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 04, 2011 9:50 AM
Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00

>>> - 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]. 
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> "
> 
>> 
>>> - Does this draft coexist with certificate-less mutual EAP 
>>> authentication, as per RFC5998?
>> 
>> I think the handed-over keying material is cryptographic proof enough and that certificates will usually be unnecessary, so I think yes.
> 
> [Qin]: Correct.
> 
>>> 
>>> Thanks,
>>>     Yaron
>> 
>> _______________________________________________
>> IPsec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Glen Zorn <[email-masked]>
Date: Wed, 04 May 2011 09:55:50 +0700

> FYI.

Instead of just forwarding selected messages, how about adding the hokey
list to this conversation?

> HOKEY mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hokey
> 
>

---

From: Qin Wu <[email-masked]>
Date: Wed, 04 May 2011 11:43:33 +0800

----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; "Yoav Nir" <[email-masked]>; "Yaron Sheffer" <[email-masked]>
Sent: Wednesday, May 04, 2011 10:55 AM
Subject: Re: [HOKEY] Fw: [IPsec] New I-D: draft-nir-ipsecme-erx-00

> list to this conversation?

[Qin]: Okay.

---

From: Glen Zorn <[email-masked]>
Date: Wed, 04 May 2011 14:56:41 +0700

>> list to this conversation?

Thanks!

...