Subject: [dhcwg] Moving SeDHCPv6 forward

From: Sheng Jiang <[email-masked]>
Date: Thu, 12 Mar 2015 04:58:07 +0000

Hi, Jim and all,

The intense discussion regarding to the use case of SeDHCPv6 seems settle down for silent now. Do we reach a conclusion on how to move the draft forward? We can now work on an update version and submit it when reopen on next Sunday.

Best regards,

Sheng

---

From: 神明達哉 <[email-masked]>
Date: Fri, 13 Mar 2015 18:35:00 -0700

At Thu, 12 Mar 2015 04:58:07 +0000,

> The intense discussion regarding to the use case of SeDHCPv6 seems settle down for silent now. Do we reach a conclusion on how to move the draft forward? We can now work on an update version and su…

Sorry for the long delay, I've been unexpectedly busy for these
several days...

Regarding the discussion, I don't think it settles down, but at least
I've failed in my attempt of understanding why sedhcpv6-like approach
is essentially needed for authenticating clients at the server other
than for preventing a session hijack using a weak form of TOFU.

At this point I'm not sure if I can contribute to the document in a
constructive way.  I'd first like to know if the wg in general thinks
it's okay to ship without clarify the above "why", either because they
simply don't see the need for it, or because it's only me who can't
understand it.

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Mar 2015 16:54:32 +0000

Hi,

I want to use SeDHCPv6 to allow servers to authenticate clients. Please
tell me that the document will move ahead with that capability included.

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: dhcwg [mailto:[email-masked]] On Behalf Of ????
> Sent: Friday, March 13, 2015 6:35 PM
> To: Sheng Jiang
> Cc: [email-masked]
> Subject: Re: [dhcwg] Moving SeDHCPv6 forward
> 
> > The intense discussion regarding to the use case of SeDHCPv6 seems settle down for silent now. Do we reach a conclusion on how
> to move the draft forward? We can now work on an update version and submit it when reopen on next Sunday.
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: 神明達哉 <[email-masked]>
Date: Wed, 18 Mar 2015 09:36:54 -0700

At Tue, 17 Mar 2015 16:54:32 +0000,

> tell me that the document will move ahead with that capability included.

In my understanding of the discussions so far, that will be the most
likely scenario.

Just out of curiosity, how exactly would you use SeDHCPv6 to
authenticate clients?  Is the fact that it's based on public key based
mechanism essential for your purpose?

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 18 Mar 2015 17:50:03 +0000

Hi Jinmei-san,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
> Sent: Wednesday, March 18, 2015 9:37 AM
> To: Templin, Fred L
> Cc: Sheng Jiang; [email-masked]

OK.

> authenticate clients?

When the client and server have no security association, I still
want the server to authenticate the client's messages. Reason
is so that no other client can impersonate the authentic client.

> Is the fact that it's based on public key based

When the client and server have no security association, I
think public key is the way to go, right?

Thanks - Fred

---

From: 神明達哉 <[email-masked]>
Date: Wed, 18 Mar 2015 11:47:01 -0700

At Wed, 18 Mar 2015 17:50:03 +0000,

> is so that no other client can impersonate the authentic client.

Is this to prevent a malicious client from hijacking an existing
DHCPv6 session for some other, legitimate client, by having the server
remember the client's public key at the initial message exchange of
the DHCPv6 session (i.e., using a weak form of TOFU)?  If so, I see
that.  Otherwise...

> think public key is the way to go, right?

(At the risk of repeating the essentially same question of the long
thread a few days ago...) ...how does the server know the client's
public keys in your intended usage?

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 18 Mar 2015 19:06:23 +0000

Hi,

> Sent: Wednesday, March 18, 2015 11:47 AM
> To: Templin, Fred L
> Cc: [email-masked]

What I was expecting was that clients would be pre-provisioned with
certificates that are issued by the same administrative authority that
operates the server. So, the server already knows the public key of
the client before the client even enters into service for the first time.

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Mar 2015 15:13:50 -0400

On Mar 18, 2015, at 3:06 PM, Templin, Fred L <[email-masked]> wrote:
> operates the server.

If clients are pre-provisioned with certificates that are known to the server, then the client and server have a security association.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 18 Mar 2015 19:22:19 +0000

Hi Ted,

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Wednesday, March 18, 2015 12:14 PM
> To: Templin, Fred L
> Cc: 神明達哉; [email-masked]

My mistake for using a term out of context for what I was trying to say.
What I mean to say is that there is no symmetric key-based security
session between the client and server (like IPsec).

What I want is for clients to sign their DHCPv6 messages using their
public keys so that servers can tell that the messages came from an
authentic source.

Thanks - Fred

---

From: 神明達哉 <[email-masked]>
Date: Thu, 19 Mar 2015 09:58:24 -0700

At Wed, 18 Mar 2015 19:06:23 +0000,

> the client before the client even enters into service for the first time.

If I understand the usage model correctly, the clients could also be
pre-provisioned with a secret by the same administrative authority
that operates the server, and use it for the existing (shared secret
based) authentication mechanism as described in Section 21 of RFC3315.
So I don't see why you *essentially* need SeDHCPv6.

This is something I've been trying (and failing) to understand.  If
you can answer why your purpose can't be met with the existing
mechanism, I'd be delighted.  But I promise I will not continue this
particular discussion in this thread as I previously bored others on
this point:-)

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 19 Mar 2015 23:51:10 +0000

Hi,

> Sent: Thursday, March 19, 2015 9:58 AM
> To: Templin, Fred L
> Cc: [email-masked]

My general impression of DHCPv6 AUTH per Section 21 of RFC3315 is that it
wasn't thought out all that well from a security standpoint. For example, it
is using HMAC-MD5 which is pretty outdated, isn't it?  I also asked a long
time ago whether anyone was using DHCPv6 AUTH, and got absolutely
no responses. I think I even asked on NANOG is I remember correctly.
Some even suggested that the lack of responses were  indication enough 
that the mechanism is essentially deprecated.

I want the client to be able to assert a public key to the server along
with a certificate. The certificate then provides a piece of identifying
material by which the server identifies the client - I don't know if
this means that the certificate needs to be somehow coded in a
DUID, but that is what I am looking for. I want better than DHCPv6
AUTH, and my understanding is that Secure DHCPv6 is essentially
that. Am I wrong?

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Mar 2015 21:04:17 -0400

> public keys so that servers can tell that the messages came from an

Right, but you have, essentially, a pre-shared key in this case, so you could actually use RFC 3315 DHCP security for this.   The problem with RFC 3315 DHCP security is that in most cases a pre-shared key is not practical; this is why it has not seen widespread implementation or deployment.   But I think it actually would work in your scenario.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 20 Mar 2015 17:35:23 +0000

Hi Ted,

> Sent: Thursday, March 19, 2015 6:04 PM
> To: Templin, Fred L
> Cc: [email-masked]; 神明達哉
> Right, but you have, essentially, a pre-shared key in this case, so you could actually use RFC 3315 DHCP security for this.   The problem
> with RFC 3315 DHCP security is that in most cases a pre-shared key is not practical; this is why it has not seen widespread
> implementation or deployment.   But I think it actually would work in your scenario.

I want for the client to get a certificate that it can present to the server.
Certificates would presumably be distributed the same way certificates
are distributed to mail clients for signing and encrypting their emails.
So, what I am looking for is a certificate-based system with modern
security algorithms, and it just seems to me that Secure DHCPv6 is
bringing DHCPv6 security into the 21st century - am I wrong?

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Mar 2015 14:29:05 -0400

> bringing DHCPv6 security into the 21st century - am I wrong?

There's nothing inherently bad about shared secret in comparison to public key.  Shared secret is a lot faster.   If your goal is to have the client generate a key that is shared with the server, one advantage of public key which I guess I'd forgotten since I haven't used kerberos in a long time is that there's no need to have a special process for delivering the shared secret without revealing it to the world.   With shared secret systems like Kerberos the initial keying has to be done out of band to solve this problem.

With public key encryption, you can have an initial key establishment process that relies on some kind of approval process, automatic or manual, without the client ever having to share its private key.   So if that's what you're going for, I guess it's true that SeDHCPv6 would be easier to make work.

However, if you were planning to pre-share the key out of band anyway, then there's no real advantage.

---

From: Robert Elz <[email-masked]>
Date: Sat, 21 Mar 2015 02:41:21 +0700

Date:        Fri, 20 Mar 2015 14:29:05 -0400
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | However, if you were planning to pre-share the key out of band anyway,
  | then there's no real advantage.

If you're using symmetric key shared keys, the server needs to store (online)
the keys of every possible legitimate client, in order to be able to verify
the things - meaning a logistic nightmare if the server is ever compromised
(or if it is even thought that it might have been - such as if it ever runs
any code that is discovered to have a vulnerability that might have been
exploited.)

On the other hand, certificate based authentication of clients doesn't
require the server to have (online) anything secret at all - clients need
their private key available, to sign the message, but just one of them.

Shared symmetric key for anything other than pure one to one uses is just
insane.

kre

---

From: 神明達哉 <[email-masked]>
Date: Fri, 20 Mar 2015 15:44:07 -0700

At Sat, 21 Mar 2015 02:41:21 +0700,

> any code that is discovered to have a vulnerability that might have been

Is this the case where the server is (or might have been) compromised
in a way the attacker quietly stole the secret keys to use them to
pretend to be legitimate clients subsequently?  For this kind of
threat, public key based mechanisms are certainly and obviously
better.

I have had a feeling that other people say the public key-based client
authentication has other clearer advantages, and tried (and failed) to
understand them.  I personally think that the mitigation against the
"quite steal" threat is not particularly attractive unless we also
have a deployable way where the server can get the public keys or
certificates of arbitrary number of clients.  But if people want to
have sedhcpv6 if only for minimizing the risk of stolen keys, I
understand that.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Mar 2015 21:19:41 -0400

On Mar 20, 2015, at 6:44 PM, 神明達哉 <[email-masked]> wrote:
> pretend to be legitimate clients subsequently? 

No.   This is the case where you want to use the server, and so you need to share a secret with it, and that secret has to be shared with it in such a way that nobody else can capture it in transit.   Sharing the secret involves two things: actually sharing the secret, and securely associating an identity with the secret that was shared.

---

From: Robert Elz <[email-masked]>
Date: Sat, 21 Mar 2015 09:40:24 +0700

Date:        Fri, 20 Mar 2015 15:44:07 -0700
    From:        =?UTF-8?B?56We5piO6YGU5ZOJ?= <[email-masked]>
    Message-ID:  <[email-masked]>

  | I personally think that the mitigation against the
  | "quite steal" threat is not particularly attractive unless we also
  | have a deployable way where the server can get the public keys or
  | certificates of arbitrary number of clients.

Agreed, except the server doesn't need to be able to get the keys - the
clients will send them (or I assume that is how this would work, I do not
normally actively follow this group).  What's needed is a way for the
server to verify the key - which (at least normally) is done by having the
client send a certificate, not a raw public key, where the certificate is
signed by someone the server trusts for the purpose (perhaps itself, or
perhaps using a mechanism similar to that used for verifying routers in SEND.)
There does not need to be only one blessed method.

What's left then is getting the certificate to the client - that one I
don't think needs a single defined method either.  For the scenario that Fred
described, I'd assume the client verifies its identity (perhaps in person)
to the server, which (off line) signs the clients public key with a
"permission to use DHCP" annotation to make a certificate for the client,
and passes it over (the data exchange between client & server does not need any
particular protection, but the question of how the server knows which clients
to trust is totally unspecified here.)    Or someone can invent a new
protocol, perhaps related to AAA work, or link layer authentication, or
whatever works for the situation - DHCP doesnt need to care how this is done,
just wants to be assured that there is at least some way it can be.

I will leave you all now to consider just what relevance any of this has to
the actual subject of this thread, a question on which I have no idea at all.

kre

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Mar 2015 22:50:14 -0400

The problem with the cert model for clients is that you have to have a copy of the key as well anyway, so then what's the advantage to having a cert?   It's different when the entity issuing the cert and the entity consuming it are different, but that probably wouldn't be the case here.

---

From: 神明達哉 <[email-masked]>
Date: Sat, 21 Mar 2015 10:36:53 -0700

At Sat, 21 Mar 2015 09:40:24 +0700,

> don't think needs a single defined method either.  For the scenario that Fred

I don't think so either, I've just been trying to understand one such
specific example.

> just wants to be assured that there is at least some way it can be.

Right, and since the goal of sedhcpv6 is to "make it easier to deploy
DHCPv6 authentication" (from Section 4 of the 08 version), this
process will have to be (able to be) done with less or ideally no
human intervention, and it will have to be scalable for arbitrary
number of individual clients (or their users).  Again, I didn't mean
we need to specify one single way to do that, but the feasibility of
the idea will depend on the details of how specifically we do so.  So
I've been trying to understand at least one specific example of such a
"new protocol (or something) and understand how it's specific to
public key (or certificate) mechanism.  Unfortunately I've been
failing to understand it, and I think I have to accept I can probably
never understand it.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Sat, 21 Mar 2015 10:37:19 -0700

At Fri, 20 Mar 2015 21:19:41 -0400,

> No.   This is the case where you want to use the server, and so you need to share a secret with it, and that secret has to be shared with it in such a way that nobody else can capture it in transit…

Hmm, from the fact that kre responded to my message without saying
anything about this part, I guess at least my interpretation matched
what he tried to say...

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Sat, 21 Mar 2015 13:37:50 -0400

On Mar 21, 2015, at 1:36 PM, 神明達哉 <[email-masked]> wrote:
> since the goal of sedhcpv6 is to "make it easier to deploy
> number of individual clients (or their users).

OK, but deploying shared secrets with no human intervention is hard.   Deploying public keys is easier.

---

From: 神明達哉 <[email-masked]>
Date: Sat, 21 Mar 2015 10:38:16 -0700

At Thu, 12 Mar 2015 04:58:07 +0000,
Sheng Jiang <[email-masked]> wrote:

> The intense discussion regarding to the use case of SeDHCPv6 seems
> settle down for silent now. Do we reach a conclusion on how to move
> the draft forward? We can now work on an update version and submit
> it when reopen on next Sunday.

I'm still not sure about the general sense of the wg (perhaps many
others are simply not interested?), but I'm going to give one another
proposal a try.  It will be something like this:

A. Revise a paragraph or two to Section 4 to explain example cases of
  TOFU:
  1. to authenticate the server using TOFU (at the risk of allowing an
     attack window at the very initial exchange)
  2. to authenticate clients to prevent a malicious client from
     breaking existing DHCPv6 session (and also note that in this case
     the server doesn't even have to record the client's public key;
     it just needs to remember the key for the lifetime of the DHCPv6
     session)
  With some explanation of why these can be easily deployable (it can
  be completely free from manual configuration or pre-establishing
  trust between the client and server)
B. Add a note somewhere to clarify whether non-TOFU cases can make the
  deployment easier depends on details of PKI or some similar
  infrastructure.  It would also note that its feasibility is
  currently unknown but such details are beyond the scope of this
  spec.
C. Revise Section 6.2 (Processing Rules of Recipient) a bit to clarify
  that the server policy can allow the weak form of TOFU (in cases
  like #2 above).
D. Remove Section 7 (Deployment Consideration)

If we do change A, it will at least answer my own question.  I also
think change B is necessary for us to be responsible for what we're
producing in that we clarify what's open (if we can be more specific
on this point I'd be happier, but my attempts to do that through
discussions have just failed).  Change C is not a big deal, but I
think it's helpful to clarify that in case someone actually wants to
use this protocol for purposes as described in change A.  Section 7
has been a blocker issue, but if we can agree to making change A (and
B) I'm personally fine just removing it.

The rest of the draft will be largely intact.

Can this be a feasible option, if only as a kind of compromise?

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Sat, 21 Mar 2015 16:43:59 -0400

I would be really happy to see some more detail about the use cases that we've talked about and understand.   The reason I pushed back earlier is that the use cases that were described in the draft that was submitted for publication were theoretical and didn't make sense to me.   So I certainly don't object to some concrete use cases that we can describe clearly and that would actually be useful, and I think the cases you're talking about in your point A qualify.

I think your point B is worth pursuing if it can be done, but should be considered optional. We should not document anything that we don't clearly understand how to use.   But I agree that in principle this is worth doing, and would be happy to help try to do it.

To your point C, I think this is not a bad idea, but it may be better to talk about general processing rules separately from processing rules for specific use cases that we've identified.

I agree with point D, obviously. :)

---

From: Robert Elz <[email-masked]>
Date: Sun, 22 Mar 2015 03:44:36 +0700

Date:        Fri, 20 Mar 2015 21:19:41 -0400
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

One last message...

  | This is the case where you want to use the server,
  | and so you need to share a secret with it,

No, you don't - the whole point of public key crypto is that the only
(security) thing(s) shared is/are the public key(s), and they're not secret.

If confidentiality was needed, public key is too costly to use to actually
encrypt data, so a symmetric key alg is also needed, and a key for that, but
sharing that is easy, if you have the public key stuff to use.

However, I would guess that most DHCP probably doesn't much care about
secrecy, and just wants authentication - if that's true, all that's needed is
signatures, and for that public key (and a hash algo) is all that's needed.

  | Sharing the secret involves two things: actually sharing the secret,
  | and securely associating an identity with the secret that was shared.

While some servers might want an actual client identity (which a client
certificate could provide), I'd expect that most servers just want to
know that the client is an authorised user, and not really care who it
actually is.  But in either case (including where the server needs a
verified mac addr, or uid) a properly constructed certificate can provide it.

I'd also note that the issue of how certificates are generated, how the
issuer verifies the identity of the applicant, (et al) are of much wider
interest than specific to dhcp, and should not really be considered here.
There are many possible answers, with varying cost/benefits.  All that is
really required is to be assured that there exists at least one method by which 
certificates could be allocated, which does not take much imagination to find.

In another message [email-masked] said:

  | The problem with the cert model for clients is that you have to have a copy
  | of the key as well anyway,

I'm not exactly sure what you're trying to say there - obviously there needs
to be copies of the public key, but that's trivial, they just get put in the
packet (which is then signed to guarantee that the owner of the key is who
put it there, and that the packet has not later been tampered with).

And, for signing, there has to be a private key somewhere, but it doesn't
need to be accessible - there are hardware signing boxes that keep the keys
locked up where they cannot be retrieved, just used (the box does encrypt &
decrypt when requested, key generation, and exports just the public key of
the key pair - and while now they're a little expensive for your average 
client to consider (and perhaps even most dhcp servers) if the need for mass
use of client signing appears (perhaps, as one example, if dhcp servers were
to largely start demanding client authentication) I would not be surprised
to see cheap add-ons (PCI, or one of its variants, or USB) that, while perhaps
not quite as secure, could offer similar services - perhaps those even
already exist.

But in any case, each system has just one key, if it is compromised, that
one key (pair) just needs to be changed (and appropriate certificates
obtained again).

 | so then what's the advantage to having a cert?

It does all you (correctly) say is needed - when used as designed, they
provide both proof of identity or authorisation, and a mechanism to allow
safe establishment of a shared symmetric key when that is required.

  | It's different when the entity issuing the cert and the entity consuming it
  | are different, but that probably wouldn't be the case here. 

While for the scenario Fred described, it probably wouldn't be, in other
cases (of dhcp) it easily could - for example, there's some agreement among
a large number of universities that allows staff from any to use the
network at any of the others, without anything more required than being
registered at the home institution, and then just appearing at the remote
network and using it.   I haven't bothered to find out what they use for
authentication (I guess it is all based upon link level access controls,
and that once that's established, plain old boring unauthenticated dhcp 
happens) but they certainly could have certificates generated by the
home institution (approved by the consortium) allocated to each client for
use at the dhcp server at each destination visited.

But in any case, using public key (with or without certificates) allows
safe, easy, eschange of all authentication, not requiring any magic 
installation via usb stick, or floppy, or however people set up shared
symmetric keys without relying on a public key infrastructure - that's
just as true for the simple case of a server just approving its own clients
as it is for the case of distributed certificate generation.

And (I hope) finally from me - I'm a little surprised that there aren't any
real security experts speaking up on this topic (I certainly do not qualify).
If you're considering anything that is principally a security operation
(which the name "SeDHCPv6" suggests to me) I'd have thought that was a
fundamental requirement even before getting a requirements doc done, and
certainly before inventing mechanisms.

kre

ps:  this message is only intended to address general principles,
and not to comment on any specific draft, in any way at all.

---

From: "Niall O'Reilly" <[email-masked]>
Date: Sat, 21 Mar 2015 22:45:49 +0000

On Sat, 21 Mar 2015 20:44:36 +0000,
Robert Elz wrote:
> 
> [...] - for example, there's some agreement among
> happens) [...]

  Guess confirmed.

  Best regards,
  Niall O'Reilly

---

From: 神明達哉 <[email-masked]>
Date: Sun, 22 Mar 2015 07:43:16 -0700

At Sat, 21 Mar 2015 16:43:59 -0400,
Ted Lemon <[email-masked]> wrote:

> I would be really happy to see some more detail about the use cases that we've talked about and understand.  [...] I think the cases you're talking about in your point A qualify.
>

Okay, so, overall it seems worth trying to revise the draft along with
proposal.  We can then discuss how we finalize it.  As for point B,
I'm okay with skipping it if it becomes too controversial.  But for
now I'll try to include the point and see how it goes.

--
JINMEI, Tatuya