Valery Smyslov writes: > > 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".
Yes, as I pointed out in my reply. > 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. That 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. 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. > 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. > > 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. 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. 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. 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. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
