Re: [saag] New Version Notification for draft-cui-dhc-dhcpv6-encryption-02.txt

[Alan DeKok <[e-mail]>]

On Aug 2, 2015, at 3:27 AM, Bernard Aboba <[e-mail]> wrote:
> [BA] Authenticating a DHCP packet with a unicast key derived between the station and the AP would not prove authorization to act as a DHCP server, so IMHO it would not add any value beyond what is already provided by 802.11 security.

  That's true.  All it would do was signal that the DHCP packet came from the AP.  Which we already know.

>  Similarly, authenticating a multicast DHCP packet with a key derived from the 802.11 group key would also not demonstrate authorization to act as a DHCP server so that also adds no value. 

  Sure, but that's not what I meant.

  I was thinking of the MSK / EMSK, which are derived from the EAP session, and typically the TLS session.  The EAPOL Key is in turn derived from that.

  It should be possible to derive a DHCP session key from the MSK.  The authentication server can send the DHCP session key to the DHCP server, which can then use it to sign DHCP packets.  The supplicant can do the same thing, and validate the incoming DHCP packet.  The key would be unique to each session.  It would also be possible to use the MSK to derive a unique MAC address for the device, which would signal to the DHCP server that the device had previously been authenticated via 802.1X.  And that identity derivation would solve most of the issues around privacy of identifiers.

  This is imperfect, of course.  It presumes that 802.1X is used, which isn't always the case.  Other methods will be needed in other circumstances.

  Alan DeKok.