>> - 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 protected]
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
