On 11 Nov 2009, at 14:53, Yoav Nir wrote:
>
> On Nov 11, 2009, at 3:39 PM, Srinivasu S R S Dhulipala (srinid) wrote:
>>
>>> 2) If not same, what purpose should each of the above identities serve
>>
>> 1) mainly used as a hint for the gateway as to which AAA server to
>> choose
>> 2) It's the AAA server that may request the identity, and it's
>> internal to AAA. It doesn't play in IKE
>>
>> [SRINI] Does this imply that gateway SHOULD not send EAP identity
>> request to the client,
>> we see that one 3rd party IKEv2 client is sending IP address
>> as IDi, from which we can't
>> take any hints. Moreover, the same client is expecting an
>> EAP-ID request to be sent,
>> else EAP is failing.
>> I've started another thread about why did we demote "SHOULD"
>> to "should" if the gateway is
>> Not supposed to send EAP-identity request to the client. I
>> think we should promote it back.
>
> The gateway never sends any EAP identity requests at all. If such a request
> exists, it is sent by the AAA server. The gateway serves only as a
> pass-through.
>
> For that reason, there is typically no reason for the gateway to inspect the
> contents of the EAP payload.
This is the gist of the question. It is tempting for the client implementation
to send just a dummy IDi (like an IP address) that prevents proper selection of
the AAA server for subsequent authentication. The client rationale being that
the proper ID will be passed during EAP. As such inspecting the ID_request is
also tempting to circumvent the client's behavior.
It would be a good idea to recommend IDi to be meaningful for AAA selection and
avoid drama's. Something like:
--8<--
IDi SHOULD be meaningful enough for the responder to select an adequate
authentication and authorization profile. The IDi SHOULD be unique in the
authentication domain, constant over time and structured. ID_FQDN,
ID_DER_ASN1_DN, ID_RFC822_ADDR are good candidates for an IDi. Other ID types
are good if they match the above criteria.
--8<--
This is something that is not immediately obvious to the client developers and
will help server developers to convey their point.
fred
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
