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.
And for some EAP libraries getting rid of the EAP Identity
request/reply is almost impossible.
Exactly.
at is the reason there is SHOULD
NOT vs MUST NOT.
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.
No it does not try to specify what EAP does, it specifis what IKEv2
does. I.e. initiator MAY respond to such query, or abort the whole
negotiation, as the other end is not following the SHOULD NOT
specified in the IKEv2 specification.
As you pointed out earlier in this message that it is EAP library,
not IKEv2, that makes this Identity Request on Responder.
And it is EAP library on the Initiator that this request is passed to.
Actually, at this point EAP protocol has already been started, so why IKE
need to interfere with EAP and make any decisions to which
EAP request should EAP library answer and to which not?
If the initiator is not able to extract the identities from the EAP
messages, it really should abort the negotiation, as this would mean
that different identity is used for policy decision (the one in ID
payload), and different one is used for authentication (the one inside
EAP). If implementation does not have ability to verify those two
match (with suitable definition of match, i.e. it might use mapping
table etc to map EAP identity to identity to be used in the policy
checking) it should abort the exchange.
What is the point of this check? For many EAP methods
the EAP Identity in Identity Response message is not authenticated
and just plays the same minor role of AAA server routing.
The real authenticated identity is often hidden inside
the EAP protocol and cannot be obtained by parsing EAP messages.
For example, RFC5216, Section 2.2 (EAP-TLS):
Since the identity presented in the EAP-Response/Identity need not be
related to the identity presented in the peer certificate, EAP-TLS
implementations SHOULD NOT require that they be identical. However,
if they are not identical, the identity presented in the EAP-
Response/Identity is unauthenticated information, and SHOULD NOT be
used for access control or accounting purposes.
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.
They do not need to be equal. They are talking about different things.
EAP talks what EAP SHOULD do. IKEv2 talks what IKEv2 MAY do in that
case. IKEv2 could also say MUST NOT respond, and that would still be
ok. Actually as EAP only says SHOULD not MUST, it is actually valid
for the IKEv2 implementation to continue exchange and not respond to
identity request, but I would expect most EAP methods would fail in
that case. Or IKEv2 might take the ID payload and use that to
construct the EAP Identity response.
Why at all should IKEv2 do something at this point?
EAP has been already started and it is EAP's responsibility
to response to Identity Request.
> 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).
ID payload is the one which is used to do policy lookups in the PAD,
and the PAD is linked to the SPD, which specifies what kind of Child
SAs can be specified. Because of this the ID is the really important
also in the EAP case.
I disagree. In case of EAP IDi must not be used for PAD lookup,
and the RFC is absolutely clear about it.
The text above in the RFC7296 is there because
some implementations uses ID payloads which do not follow this rule,
and because of this special code is needed to make sure that the
correct PAD entry is located using the authenticated identity, and
that might be the EAP identity instead of ID payload.
The text clearly says that IDi is not used for policy lookup and control
decisions.
In normal case the authenticated identity is ID payload, in some
special EAP cases it might be EAP identity. The implementation needs
to be able to handle this special case if it wants to support such
implementations, but it is ok acceptable for it to ignore this case,
and use ID payload for all policy lookups, and forbid EAP identity
exchanges completely. Usually this is not a problem as EAP identity
requests are done by the server, which is also tied to the AAA-server,
and server implementation will know whether it supports getting EAP
authenticated identity from the AAA-server, and whether it knows how
to use it for policy lookups, and in that case it also knows that
AAA-server might do EAP identity requests. On the other hand server
EAP may also be configured so it never does EAP identity requests, or
even fakes them inside the server code. I.e. when AAA-server sends EAP
identity request, that request is NOT sent to the client, but instead
the server creates suitable EAP identity response based on the ID
payload sent by the client. Now EAP is happy, and client and server
are happy as they didn't waste one extra roundtrip to do EAP identity
request from the client at all.
You completely ignore the fact, that some EAP methods
exchange identities themselves and don't use identity,
received in response to EAP Identity request.
And that inner identity is the only authenticated identity.
Even if you manage to save extra roundtrip with all
these complications, it doesn't make IDi an authenticated
EAP identity in this case, even if it matches the EAP identity
in EAP Identity response.
The text in RFC7296 specifically does not limit the uses of EAP
identities more than that "SHOULD NOT" just because we wanted to leave
things open so different implementations can do whatever is suitable
for them.
That's why I think that ID_NULL can be used as IDi
in case of EAP - this usage doesn't contradict to IKEv2 spec.
Valery.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
