Subject: [IPsec] FWD from Tero Kivinen: [IANA #879113] General Request for Assignment (ikev2-parameters)

From: Tero Kivinen <[email-masked]>
Date: Tue, 15 Dec 2015 14:18:07 +0200

FYI, I just rejected the DEVICE_IDENTITY configuration payload
attribute request for IKEv2 because of following reasons.

Subject: [IANA #879113] General Request for Assignment (ikev2-parameters)
From: Tero Kivinen <[email-masked]>
To: [email-masked]
Date: Tue, 15 Dec 2015 14:15:38 +0200

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-masked] wrote:
> > 
> > Contact Name:
> > Frederic Firmin
> > 
> > Contact Email:
> > [email-masked]
> > 
> > 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-masked]

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Dec 2015 15:55:39 +0200

Hi, Tero

I realise you are not the one to ask about this, but why not use CFG_SET?  

This IMEI information is about as trustworthy as the “APPLICATION_VERSION” type.

Yoav

> On 15 Dec 2015, at 2:18 PM, Tero Kivinen <[email-masked]> wrote:
> 
> Date: 15 December 2015 at 2:15:38 PM GMT+2
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 15 Dec 2015 17:55:07 +0200

> I realise you are not the one to ask about this, but why not use

Mostly, because it is not a configuration information, and what would
be the meaning when the server does not ACK your DEVICE_IDENTITY. Also
I do not know any implementations that actually supports CFG_SET /
CFG_ACK. And I think they want to get that during the IKE_AUTH, and
they are already using CFG_REQUEST and CFG_REPLY to get the
IP-address etc, so mixing two configuration payloads inside IKE_AUTH
during EAP authentication would be quite confusing. 

I.e. what they propose doing now is:

   HDR, SAi1, KEi, Ni  -->
                                <--  HDR, SAr1, KEr, Nr, [CERTREQ]
   HDR, SK {IDi, [CERT,]
       [CERTREQ,] [IDr,] AUTH,
       CP(CFG_REQUEST), SAi2,
       TSi, TSr}  -->
			        <-- HDR, SK {IDr, [CERT+,] AUTH,
   				    	 CP(CFG_REPLY), EAP }
   HDR, SK { EAP } ->
				<-- HDR, SK { EAP }

   HDR, CP(CFG_REPLY), AUTH -->
   		       	        <-- HDR, SK { AUTH,
                           	    	 CP(CFG_REPLY),
					 SA, TSi, TSr }

or something like that, i.e. the first CFG_REPLY says that return
DEVICE_IDENTITY, and then there probably needs to be second CP to get
the actual IP address or something. The text in their documentation
does not really tell how it is supposed to work. 

> This IMEI information is about as trustworthy as the “APPLICATION_VERSION”

Yep. I.e. it is whatever the client software or user decided to
configure there. 
-- 
[email-masked]