FYI, I just rejected the DEVICE_IDENTITY configuration payload
attribute request for IKEv2 because of following reasons.
--- Begin Message ---
Michelle Cotton via RT writes:
> I'm sending this request to you for expert review.
> If you could reply back before or by 23 November 2015 that would be
> most appreciated.\
Sorry for being late for this reply, but I have been quite busy last
few months.
> On Thu Nov 05 09:32:49 2015, [email protected] wrote:
> >
> > Contact Name:
> > Frederic Firmin
> >
> > Contact Email:
> > [email protected]
> >
> > Type of Assignment:
> > New item in the "IKEv2 Configuration Payload Attribute Types" of the
> > "Internet Key Exchange Version 2 (IKEv2) Parameters" as shown at
> > http://www.iana.org/assignments/ikev2-parameters/ikev2-
> > parameters.xhtml#ikev2-parameters-21 and as specified in IETF RFC 4306
> > and updated by IETF RFC 5996 and IETF RFC 7296.
> >
> > Registry:
> > The "IKEv2 Configuration Payload Attribute Types" of the "Internet Key
> > Exchange Version 2 (IKEv2) Parameters" as shown at
> > http://www.iana.org/assignments/ikev2-parameters/ikev2-
> > parameters.xhtml#ikev2-parameters-21 and as specified in IETF RFC 4306
> > and updated by IETF RFC 5996 and IETF RFC 7296.
> >
> > Description:
> > This IKEv2 attribute is used to provide device identity.
> >
> > Additional Info:
> > IETF RFC 4306 defines the registry for the "IKEv2 Configuration
> > Payload Attribute Types". IETF RFC 7296 and IETF RFC 5996 refer to
> > IETF RFC 4306 for the definition of the registry.
> >
> > The following attribute is requested to be registered:
> > - value: (number to be assigned by IANA)
> > - attribute type: DEVICE_IDENTITY
> > - multi-valued: no
> > - length: 1 or more octets
> > - reference: 24.302 13.3.0 http://www.3gpp.org/ftp/Specs/html-
> > info/24302.htm
This assignment is problematic.
If I have understood correclty this will use configuration payloads in
non-standard way, i.e. in way where it has not been used before.
Normally client requests parameters by sending CFG_REQUEST, and server
replies values back using CFG_REPLY.
In this case if I have understood correctly the server sends CFG_REPLY
back asking for client provide the DEVICE_IDENTITY. The RFC7296 says
that "In variations of the protocol where there are multiple IKE_AUTH
exchanges, the CP payloads MUST be inserted in the messages containing
the SA payloads." (RFC7296 section 2.19). This means that
CP(CFG_REPLY) is in the last IKE_AUTH, i.e. after the EAP
authentication is finished.
The 24302-d30 section 7.2 seems to indicate that we send CFG_REPLY
back during the EAP and IKE_AUTH exchanges, and then do second
CFG_REQEST after that. This is against the RFC7296, as the first
CFG_REQUEST already contains the IP-address assingment request, and
its CFG_REPLY MUST be in the last IKE_AUTH.
Also the DEVICE_IDENTITY is attribute that is flowing in wrong
direction. I.e. the CFG_REQUEST/CFG_REPLY is meant to be working so
that CFG_REQUEST is used by the initiator to request something and
CFG_REPLY is used by responder to reply those configuration
parameters. In this case the responder is requesting the initiator to
provide some information.
Also DEVICE_IDENTITY has nothing to do with the configurations of the
devices, and is not needed by the IKE or the networks stack to create
the IKEv2 tunnel. It does not belong to the configuration payloads.
As this is also completely untrusted, and provided just for the
information for the server side, I think it would be better to use
Notify payloads to send this information. I.e. allocate status
notification payload for IMEI and another one for IMEISV, and require
that clients send those notifications during the IKE_AUTH exchange.
--
[email protected]
--- End Message ---
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
