Subject: [dhcwg] Use case for client authentication...

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Jul 2014 07:35:01 -0400

I don't know if this is a use case that would actually get used, but in l'esprit d'escalier, I will repeat it, since it's one that crossed my mind at some point in the past when I was discussing this with Sheng.

The use case is that you run a Wifi hotspot network.   Subscribers have registered devices, which present keys known to the infrastructure.   When such a key is presented, the subscriber gets immediate access without having to authenticate to the captive portal.   The flow is like this:

<non-subscriber client sends Solicit>
<DHCP server indicates that client authentication is desired, and provides its own credentials>
<non-subscriber client declines to authenticate, because it doesn't recognize server credentials>
<server provides client access to captive portal>
<client registers, pays through captive portal>
<client indicates somehow that this server is legit, and credentials should be offered when requested>

<client goes away, comes back>
<client sends Solicit>
<server indicates client authentication is desired, provides credentials>
<client recognizes server, sends credentials>
<client gets immediate access with no dialog>

This flow would require additional work: the current spec does not provide everything that's required, and some of what's required probably isn't DHCP stuff.   But this is the sort of thing you can do with client authentication, at least in principle.

Why not just use 802.1X?   Because 802.1X requires a pre-established trust relationship, which hasn't been established in the first phase.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 24 Jul 2014 11:15:53 -0700

At Thu, 24 Jul 2014 07:35:01 -0400,

> <client gets immediate access with no dialog>

Do you mean, for example, the client/server public key used in
SeDHCPv6 by "credentials"?  And, in the above example, would the
client send the Solicit without a public key or certificate option?

I thought SeDHCPv6 intended to start a DHCPv6 session from a Solicit
with one of these options.  Section 6.1 of sedhcpv6-03 says:

   A Secure DHCPv6 message, except for Relay-forward and Relay-reply
   messages, MUST contain either a Public Key or a Certificate option,
   which MUST be constructed as explained in Section 5.1 or Section 5.2.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Jul 2014 14:32:09 -0400

> client send the Solicit without a public key or certificate option?

I think from a privacy perspective it can be argued that sending the client certificate in the Solicit isn't a good idea.   As for the server cert, I think it's useful to be able to have a single organizational signing key that signs multiple infrastructure keys, so I think there does need to be a cert; I'm agnostic as to how that would be done.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 25 Jul 2014 09:49:30 -0700

At Thu, 24 Jul 2014 14:32:09 -0400,
Ted Lemon <[email-masked]> wrote:

> I think from a privacy perspective it can be argued that sending the client certificate in the Solicit isn't a good idea.

Hmm, then I suspect it will require a substantial protocol change to
sedhcpv6 (which is not necessarily bad, depending on how we should
consider the possible privacy concern to be critical).

--
JINMEI, Tatuya