I changed a subject field.
Valery Smyslov writes:
Hi Tero,
> On the other hand same section says that ID_NULL SHOULD only be used
> with NULL authentication method. In which scenarios do you think
> ID_NULL can be used when using normal authentication? I.e. which is
> the exception for the SHOULD?
It could be used, for example, in the first IKE_AUTH message sent from
the client when EAP authentication is requested. If SGW is acting
as pass-through between client and backend authentication server
(e.g. RADIUS), that server will typically start EAP session from
requesting EAP Identity anyway, so the ID Payload received
from the client becomes useless.
Nope. The IKE ID payloads needs to be used, and the EAP identity
reqeuest and respond SHOULD NOT be used (from RFC7296 section 3.16):
Note that since IKE passes an indication of initiator identity in the
first message in the IKE_AUTH exchange, the responder SHOULD NOT send
EAP Identity requests. The initiator MAY, however, respond to such
requests if it receives them.
First, "SHOULD NOT" is not equal to "MUST NOT".
It is fully legal for NAS to sent EAP Identity request and
not use IKE Identity. Then, many modern EAP methods
(like EAP-TLS) have their own means to exchange Identities
within the method, and in this case the initial IKE Identity becomes
almost useless.
What about the sentence "The initiator MAY, however,
respond to such requests if it receives them.", - I think that
it is a mistake and the sentence must not be in the RFC.
It tries to mandates EAP behaviour within IKEv2 spec.
Moreover, it contradicts to the EAP specification (RFC3748),
which states (Section 5.1):
The Identity Type is used to query the identity of the peer.
Generally, the authenticator will issue this as the initial
Request. An optional displayable message MAY be included to
prompt the peer in the case where there is an expectation of
interaction with a user. A Response of Type 1 (Identity) SHOULD
be sent in Response to a Request with a Type of 1 (Identity).
It is clear that SHOULD is not equal to MAY. It's unfortunate
we didn't cach this contradiction while preparing RFC7296.
Also section 2.16 warns that if EAP Identity is used, there might be
mismatch with the ID payloads, and correct one needs to be used for
policy lookups:
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.
This para only supports my idea, that initiator's identity IDi in case
of EAP plays no important role. It's sole purpose is for Authentication,
Authorization, and Accounting (AAA) routing purposes and selecting
which EAP method to use. And it may be ID_NULL, in which case
the default AAA server will be selected and EAP method will be negotiated
within EAP (in most natural way).
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
