Yoav Nir writes:
> I realise you are not the one to ask about this, but why not use
> CFG_SET?
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”
> type.
Yep. I.e. it is whatever the client software or user decided to
configure there.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
