Subject: Re: [dhcwg] on use case discussion for draft-ietf-dhc-sedhcpv6

From: 神明達哉 <[email-masked]>
Date: Mon, 2 Mar 2015 17:57:48 -0800

At Fri, 27 Feb 2015 19:46:21 -0500,
Ted Lemon <[email-masked]> wrote:

> > no one has a specific idea of how a public-key based DHCPv6
> > authentication is better than shared secret based one, beyond the
> > general principle that public key based things are generally better
> > than shared secret things.  Is this correct?
>
> No, it is not correct.   Public key authentication in the case of
> the radius or captive portal flow is better because DHCP doesn't
> need a shared secret.  Essentially you just do DHCP with the
> identity that you have, and either you are already known, or you
> aren't.   If you are already known, then you are just automatically
> online, with no additional transaction.   If you are not already
> known then you have to map the key to some kind of identity, which
> may indeed be password protected, but could also be a credit card or
> something.

Is this the case for this example?

> - client sends public key, server does not recognize key, server
>   sends client to captive portal, client makes arrangements for
>   access, server records key and associates it with that arrangement

> This process is completely orthogonal to DHCP; indeed,
> it isn't even the case that it is necessary.   As we've discussed
> elsewhere in this conversation, it could be that the DHCP server
> just uses public keys to positively differentiate between clients,
> without requiring registration.

Like the case of using (a weaker form of) TOFU to prevent an attacker
from stealing/breaking an existing DHCP session?  As I already agreed
I see a public key-based mechanism is better in this case (I was
probably not clear but I intended to ask for other cases than this one
in the above question).

> - client sends public key, server associates resources with that
>   public key, other clients can't spoof the first client because
>   they don't have its private key

Same here.

> - client sends public key, server recognizes the key, server grants client access to network according to some pre-existing arrangement

This is fine, my question was more about how to establish such
pre-existing arrangement, and whether it makes a public key-based
mechanism more advantageous in terms of deployability or security.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Mar 2015 21:25:19 -0500

> mechanism more advantageous in terms of deployability or security.

With the public key mechanism, deployability is decoupled from whatever you are using on the back-end.   With shared secrets, what you are using on the back end has to be tightly coupled to the DHCP transaction.   If you want to use kerberos, you will need a special protocol for that.   If you want to use RADIUS, you will need a special protocol.   Same for EAP.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 2 Mar 2015 18:42:52 -0800

At Mon, 2 Mar 2015 21:25:19 -0500,
Ted Lemon <[email-masked]> wrote:

> With the public key mechanism, deployability is decoupled from
> whatever you are using on the back-end.   With shared secrets, what
> you are using on the back end has to be tightly coupled to the DHCP
> transaction.   If you want to use kerberos, you will need a special
> protocol for that.   If you want to use RADIUS, you will need a
> special protocol.   Same for EAP.

After reading this several times, I still don't get it, as it sounds
too abstract to me.  I don't get what "tightly coupled to the DHCP
transaction" or "a special protocol" means.  Perhaps could you provide
a specific example flow in the case of shared secret to illustrate how
it's "coupled to the DHCP transaction" and what kind of special
protocol is needed?

Thanks for your patience...

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Mar 2015 21:54:53 -0500

On Mar 2, 2015, at 9:42 PM, 神明達哉 <[email-masked]> wrote:
> transaction" or "a special protocol" means.

Jinmei-san, how would you use Kerberos with DHCP?   Think about it.   We used to see a new presentation every year in the DHC working group to work with some shared-secret protocol.

> Perhaps could you provide

Kerberos: client sends Solicit.   Server responds with kerberos domain.   Client has a key in that domain, so it sends a new solicit with a service ticket request.   DHCP server relays this to kerberos server, which issues a service ticket encrypted using the client's secret.   DHCP server responds in an advertise with the new ticket.   Client decrypts the ticket.   Client sends a new solicit authenticated using the ticket.   DHCP server contacts kerberos server to validate the ticket.   DHCP server checks access list to see if the client is authorized to receive the resources it has requested.   Once client has network access, it must renew the service ticket by communicating directly with the kerberos server.

The flow is probably slightly simpler for RADIUS, but once again is a custom flow.   There is no flow for arbitrary captive portal authentication.

So what I mean by "tightly coupled" is that there has to be special way for the DHCP client to use the secret it shares with some non-DHCP service in order to authenticate the DHCP transaction using a proxy.

With the public key model, the DHCP server just populates a list of known keys using DHCP.   If there is an external database to query, that is separate from the DHCP transaction: no special external-database-specific stuff needs to flow between DHCP client and server.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 3 Mar 2015 11:34:56 -0800

At Mon, 2 Mar 2015 21:54:53 -0500,
Ted Lemon <[email-masked]> wrote:

> Kerberos: client sends Solicit.   Server responds with kerberos
> domain.   Client has a key in that domain, so it sends a new solicit
> with a service ticket request.   DHCP server relays this to kerberos
> server, which issues a service ticket encrypted using the client's
> secret.   DHCP server responds in an advertise with the new ticket.
> Client decrypts the ticket.   Client sends a new solicit
> authenticated using the ticket.   DHCP server contacts kerberos
> server to validate the ticket.   DHCP server checks access list to
> see if the client is authorized to receive the resources it has
> requested.   Once client has network access, it must renew the
> service ticket by communicating directly with the kerberos server.

Okay, thanks for the detailed example.  I see this is "tightly
coupled to the DHCP transaction" and not good.  And...

> With the public key model, the DHCP server just populates a list of
> known keys using DHCP.   If there is an external database to query,
> that is separate from the DHCP transaction: no special
> external-database-specific stuff needs to flow between DHCP client
> and server.

...to understand that's an inherent disadvantage with a shared
secret-based mechanism, let me compare this to the above Kerberos
flow:

Client sends Solicit with its public key.  The server doesn't know the
public key for the client identifier (DUID or something?), and it
consults the arbitrary captive portal database.  It still doesn't
find the public key for the client.  ...and, then what?

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Mar 2015 14:47:33 -0500

> find the public key for the client.  ...and, then what?

The way I would expect the flow to go is that the DHCP server would keep an externally queryable database that maps assigned IP addresses or assigned prefixes to public keys.   This could be as simple as storying the public key on the client record, as Nominum's server does, or it could involve scraping the lease database as it's written and populating an external SQL database, which is how I'd do it if I were running the ISC server.

So if the DHCP server encounters a new key for a new client, it creates a new client record and sends the client the appropriate information to send it to a captive portal to log in.   The captive portal uses some kind of back-end database to authenticate the login--could be RADIUS, could be LDAP, could be Kerberos, could be /etc/passwd.   Once this has happened, the captive portal would update the DHCP server with a mapping for the client.

You could do this flow in a variety of different ways, but the point is that because the DHCP and captive portal processes are decoupled, there is no special per-database requirement placed on the DHCP protocol.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 3 Mar 2015 18:31:59 -0800

At Tue, 3 Mar 2015 14:47:33 -0500,
Ted Lemon <[email-masked]> wrote:

> The way I would expect the flow to go is that the DHCP server would
> keep an externally queryable database that maps assigned IP
> addresses or assigned prefixes to public keys.   This could be as
> simple as storying the public key on the client record, as Nominum's
> server does, or it could involve scraping the lease database as it's
> written and populating an external SQL database, which is how I'd do
> it if I were running the ISC server.

Okay.

> So if the DHCP server encounters a new key for a new client, it
> creates a new client record and sends the client the appropriate
> information to send it to a captive portal to log in.

I'm not sure if I understand this part.  Is this mean something like
this?

- The server responds to the Solicit (followed by a Request-Reply
  exchange) to assign some (maybe ephemeral?) address to the client
  with a URL or something of the captive portal in some new DHCPv6
  option.
- (A human user of) the client logs in to the captive portal maybe by
  notified by the DHCP client in some way, enters the password (or
  some secret), and uploads the client's public key to the portal.  In
  this phase all traffic from that address is blocked or redirect
  to the portal.
- Once this is done, the client starts a DHCPv6 session from a Solicit
  again.  The server doesn't know the public key (except that it saw
  it before), and it consults the captive portal to confirm that's a
  valid public key for the client.  It now succeeds, and the server
  stores that public key in its SQL database (or something) with the
  client's DUID (or something) and uses it for subsequent DHCPv6
  session.

p.s. I've googled and found draft-hornstein-dhc-kerbauth-06.txt, and
I think I'm now getting where you came from:-)

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Mar 2015 22:14:42 -0500

>  client's DUID (or something) and uses it for subsequent DHCPv6

Yes, that's one way it could work.

> I think I'm now getting where you came from:-)

Wow, that's been quite a while ago.   :)

---

From: 神明達哉 <[email-masked]>
Date: Wed, 4 Mar 2015 10:26:56 -0800

At Tue, 3 Mar 2015 22:14:42 -0500,

> Yes, that's one way it could work.

Okay, then, going back to my novice's question, what's the difference
in terms of deployability and/or security between the above one and
the following one?

- (The implementation of) client generates some random value from some
  good entropy source.
- Client sends a Solicit using the RFC3315 delayed authentication
  protocol, whose key is the generated random value.
- The server doesn't know its key ID for the client identifier (DUID
  or something?), and it consults the arbitrary captive portal
  database.  It still doesn't find the key for the client.
- The server responds to the Solicit (followed by a Request-Reply
  exchange) to assign some (maybe ephemeral?) address to the client
  with a URL or something of the captive portal in some new DHCPv6
  option.
- (A human user of) the client logs in to the captive portal maybe by
  notified by the DHCP client in some way, enters the password (or
  some secret), and uploads the previously-generated random value to
  the portal.  In this phase all traffic from that address is blocked
  or redirect to the portal.
- Once this is done, the client starts a DHCPv6 session from a Solicit
  again.  The server doesn't know the key ID (except that it saw
  it before), and it consults the captive portal to confirm that's a
  valid secret for the client.  It now succeeds, and the server
  stores it in its SQL database (or something) with the client's DUID
  (or something) and uses it for subsequent DHCPv6 session.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Mar 2015 13:36:48 -0500

> in terms of deployability and/or security between the above one and

Your proposed example requires that the user somehow convey the randomly-generated secret-to-be-shared to the authentication database through the registration process.   Since the client device has no way of anticipating what back-end registration process will be used, this cannot be automated.

It also requires that the authentication database share that secret with the DHCP server.

So this would only work in contexts where it's okay for the DHCP server to be able to know the contents of the shared secret database, and it would only work in cases where the shared secret registration process works as you have described it.   E.g., it would not work with Kerberos.   I do not know whether it could be made to work with RADIUS or LDAP.   Perhaps it could, but you are now mashing together several different services with different security constraints, which is likely to result in a much less secure solution than the public key solution would offer, since the public key solution does not require widespread dissemination of the secret.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 4 Mar 2015 14:57:35 -0800

At Wed, 4 Mar 2015 13:36:48 -0500,
Ted Lemon <[email-masked]> wrote:

> Your proposed example requires that the user somehow convey the
> randomly-generated secret-to-be-shared to the authentication
> database through the registration process.   Since the client device
> has no way of anticipating what back-end registration process will
> be used, this cannot be automated.

Correct, but isn't it the same for the client to convey the public key
to the authentication database through the registration process?

> It also requires that the authentication database share that secret

Correct, but what kind of threat would we worry about in that case?
Whether it's shared secret or client's public key, if either the
authentication database or the DHCP server itself is compromised, then
the attacker can successfully pretend to be a valid client, right?

> So this would only work in contexts where it's okay for the DHCP
> server to be able to know the contents of the shared secret
> database, and it would only work in cases where the shared secret
> registration process works as you have described it.

But isn't it the same for a public-key based mechanism?  "this would
only work in contexts where it's okay for the DHCP server to be able
to know the contents of the public key database, and it would only
work in cases where the public key registration process works in some
way".  And, it looked to me that any specific flow for a public-key
based scenario can have a shared secret-based variant at a comparable
deployability cost and security level (regarding the latter, it would
certainly be better if we don't have to store a "secret" in multiple
places in general, but in our scenario if the key database or the DHCP
server is compromised it seems to be equally fragile for a public
key-based system as I asked in the second "Correct, but") - or I
misunderstand something fundamental, which is probably the case, so
I'd like to know an example flow where public key-based mechanism
works perfectly but a shared secret-based one doesn't.  And, in that
sense, I'm not sure how I interpret this:

> E.g., it would not work with Kerberos.

Do you mean it doesn't work as Kerberos itself being the shared secret
mechanism (like draft-hornstein-dhc-kerbauth), or do you mean some
public key based mechanism will somehow work well with Kerberos?  If
it's the former, I already agreed in my previous sense, but this
doesn't answer my question.  If it's the latter, which specific flow
do you have in your mind?

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Mar 2015 18:06:18 -0500

> to the authentication database through the registration process?

No, because the DHCP server can do this automatically.   The DHCP server and the registration database are presumably under the control of the same admin, and can be set up by the admin to share this information, without involving the user or requiring custom behavior on the client node.

> the attacker can successfully pretend to be a valid client, right?

I really encourage you to study Kerberos sometime.   This is all explained in a great deal of detail there, and Kerberos is _very_ careful to isolate master shared secrets and per-server shared secrets.   It's true that you can just cross your fingers and hope for the best, but from an operational perspective this isn't always the right thing to do.   It may be fine in some cases, but it's not a general approach.

> way".

Yes, but public keys aren't secret.

> do you have in your mind?

I mean that the Kerberos key is a secret shared between the end user and the kerberos server, and is never shared with other services.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 4 Mar 2015 16:06:50 -0800

At Wed, 4 Mar 2015 18:06:18 -0500,
Ted Lemon <[email-masked]> wrote:

> No, because the DHCP server can do this automatically.   The DHCP
> server and the registration database are presumably under the
> control of the same admin, and can be set up by the admin to share
> this information, without involving the user or requiring custom
> behavior on the client node.

So, in the previous example flow, instead of doing this:

> >  some secret), and uploads the client's public key to the portal.

You mean the client's public key is somehow registered without
involving the user or requiring custom behavior on the client node?
My assumption was that the private/public key pair was initial created
by the client, and if it's correct, specifically how is it registered
in the database?

> I really encourage you to study Kerberos sometime.   This is all
> explained in a great deal of detail there, and Kerberos is _very_
> careful to isolate master shared secrets and per-server shared
> secrets.   It's true that you can just cross your fingers and hope
> for the best, but from an operational perspective this isn't always
> the right thing to do.   It may be fine in some cases, but it's not
> a general approach.

Hmm, I'm certainly not familiar with details of Kerberos (although I
at least understand that Kerberos separates per-server secrets), but I
don't even understand why we are talking about such details in this

>> It also requires that the authentication database share that secret

What I tried to ask is what I just responded to Francis:

: True, but if the purpose of the authentication is to determine whether
: the DHCP server should provide specific clients with DHCP server
: (assigning an address, etc), compromising the server can defeat it
: anyway; the attacker doesn't have to know clients' private keys.

In other words, my question was what kind of security advantage we
have from the fact that the authentication DB and the server don't
have the client's secret, if our purpose is to determine whether
the DHCP server should provide specific clients with DHCP server.  Is
some detail of Kerberos related to this question?

--
JINMEI, Tatuya