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

From: 神明達哉 <[email-masked]>
Date: Thu, 19 Feb 2015 10:18:46 -0800

This is my attempt of addressing the AD review comments on the
"Deployment Consideration" section of draft-ietf-dhc-sedhcpv6.

I begin with my own message in a previous thread on this topic:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg16211.html

Quoting Ted:

> In my mind, the answer to this is that at present no mechanism
> exists for security DHCP messages between servers and clients that
> does not have a serious key distribution problem.

I see this is a valid problem statement.

> By using public-key-based authentication, we provide a mechanism for
> securing such messages that can be reasonably deployed without the
> key distribution problems inherent in the shared-secret-based
> authentication mechanism specified in RFC 3315, either using some
> form of PKI or else Trust-on-first-use (TOFU).

I also see sedhcpv6 would be a reasonable solution for that problem in
the case of authenticating the server and messages from the server at
a client.  I can personally accept the solution without a specific use
case for this pair of problem-solution.  But I guess we could also
provide some feasible use case if we want to address a previous
inquiry from Ralph:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg15528.html

I think most of the controversy exists in authenticating clients at a
server.  First off, it's not clear whether this is a valid solution to
the stated problem: "a mechanism for DHCP security that does not have
a serious key distribution problem".  Unlike the case of
authenticating a server, clients are generally more arbitrary, and
it's not clear (to me) whether/how we can manage certificates of these
clients without "a key distribution problem"; we could install each
client's public key or certificate by hand, but that's actually a "key
distribution problem" itself, not a solution.  And, depending on the
expected use case (which is also not clear and we can only provide
speculation), TOFU is not feasible in this case.

If the protocol can be completely independent from these issues, it
might make sense to publish the protocol part first.  But I suspect
that if and when we figure out these points the result will affect
protocol details.  Or we might even find that this kind of security
mechanism is not a viable solution to the stated problem in the end.
That's why I requested we first clarify exactly what kind of problem
this mechanism can solve and how it does so.  The section that
explains possible use cases is an attempt to address that concern.
But, according to the review feedback and the followup thread, that
attempt seemed to fail, at least for the case of authenticating
clients.

So my question to the wg would be: "whether it's okay to publish a
mechanism with details of the case of authenticating clients without
knowing specially how it's used or whether it really solves 'key
distribution problems'".  If the answer is "Yes", our next step would
be remove the use case section and move it forward.

My personal answer is "no, it's not okay", and I have a proposal that
might address my own concern and can still publish something useful
without much delay.  But to keep the discussion more focused I'll
defer it to a separate message.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Feb 2015 13:58:46 -0500

On Feb 19, 2015, at 1:18 PM, 神明達哉 <[email-masked]> wrote:
>  Unlike the case of
> distribution problem" itself, not a solution.

The client generates the key, so there's no distribution problem.   The server gets the public key with the message, and can retain it for future use.   Establishing a trust relationship for that key is out of scope.   Likely it would be done using some kind of HTTP-based registration process using a captive portal.

The one concern I have with the protocol as currently proposed and as it relates to this flow is that the client may wish to present different keys to different servers, and may wish to defer presenting any key at all until it has seen and validated the server's identity.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 20 Feb 2015 00:20:51 +0100

In your previous mail you wrote:

>>  JINMEI wrote:
>> Unlike the case of authenticating a server, clients are generally
>> more arbitrary, and it's not clear (to me) whether/how we can manage
>> certificates of these clients without "a key distribution problem";
>> we could install each client's public key or certificate by hand,
>> but that's actually a "key distribution problem" itself, not a
>> solution.

> The client generates the key, so there's no distribution problem.
> The server gets the public key with the message, and can retain it
> for future use.  Establishing a trust relationship for that key is
> out of scope.  Likely it would be done using some kind of HTTP-based
> registration process using a captive portal.

=> as far as I know the proposed client->server authentication uses
(X.509 public key) certificates, and TOFU is only one of the possible
options. Nevertheless I agree the idea to put the "key distribution
problem" out of scope as it is simply the only option if we want to
get the document adopted one day. Note in many DHCPv6 deployments
clients are already registered in the server config(s) so there is
no issue with associating each client entry with a short list of
certificates in this config.

> The one concern I have with the protocol as currently proposed and
> as it relates to this flow is that the client may wish to present
> different keys to different servers, and may wish to defer
> presenting any key at all until it has seen and validated the
> server's identity.

=> this can lead to a chicken and egg issue, in particular if someone
adds privacy consideration. I suggest to target first easy cases, even
they have little technical incentive...

Regards

[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Feb 2015 21:23:09 -0500

On Feb 19, 2015, at 6:20 PM, Francis Dupont <[email-masked]> wrote:
> as far as I know the proposed client->server authentication uses
> options.

Right, but I think there is almost no chance that this would be deployed in practice, which was one of my objections to the proposal.   What value does it add to have a PKI-authenticated key on the client?

> they have little technical incentive...

What's the chicken/egg issue?   Do you mean because the server is allocating a scarce resource, and would want the client to authenticate first?

---

From: Francis Dupont <[email-masked]>
Date: Fri, 20 Feb 2015 16:22:51 +0100

In your previous mail you wrote:

>  Right, but I think there is almost no chance that this would be deployed
>  in practice, which was one of my objections to the proposal.

=> I can't remember if your objection is about public key vs. certificate.
If it is the case they are in fact equivalent as a certificate embeds
a public key. Note in the server->client way a certificate has a little
added value because a bootstrapping client has by definition no access to
a PKI.
If your objection is about the whole proposal then there is no required
PKI in all cases. For instance you can add to a static config (a server
config with a dedicated entry per client, clients with static identity)
the keying material. I agree DHCP doesn't bring a lot but I know
many places where DHCPv6 is used just because DHCPv4 was and there
is no good reason to change something which proved to work well.

>  What value does it add to have a PKI-authenticated key on the client?

=> IMHO none for the "PKI-authenticated" but there is one for
the "authenticated" by TOFU or static config.

>  What's the chicken/egg issue?

=> the server discards packets sent by the client without authentication
options, the client doesn't know which authentication to use so uses none.

> Do you mean because the server is allocating a scarce resource, and
> would want the client to authenticate first?

=> yes with any kind of reasons/policies for the server.
The privacy point is from the fact authentication, in particular
a certificate, can reveal a lot about the client. But someone has
to do the first step.

Thanks

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Feb 2015 11:41:39 -0500

> added value because a bootstrapping client has by definition no access to

What you are saying seems to represent a fundamental misunderstanding of how PKI works and how it would make sense to use it.   Let me try to explain:

A cert from client to server makes no sense because certs are signed by CAs, and there's (at least at present) no way to automate that.   I'm not saying such a thing could never make sense, but I don't see how it adds value.   The use model for such a cert that I can imagine would be that a provider signs clients certs with a provider key during some initial registration process, and then the DHCP server just trusts all keys signed by the provider key.

But that doesn't make sense.   What most providers want is a one-to-one accounting model, and you don't need a cert for that--you just need to collect the client-generated key at registration time and mark it as allowed in a key database.   This means that later if the client doesn't pay the bill, you can mark it in the database as no longer allowed.   The DHCP server just checks in the database to see how the key is marked, and replies accordingly, directing non-allowed keys to a captive portal, and immediately allowing access for allowed keys.

And in the reverse direction, it _does_ make sense for the server's key to be signed by a PKI, for two reasons.   First, because of the way PKI works.   The x.509 PKI that is used by web browsers relies on the browser having a list of known roots, and if a cert's signature chain leads back to a known root, the cert is considered valid.   You need connectivity to check for revoked certs, but not otherwise.

The second reason this makes sense is that providers have infrastructure, and you don't want to have one key known to the client where the private key is stored on every piece of infrastructure in the provider network, because this means that the compromise of any one infrastructure node will compromise the entire network.   No, what you want is for the provider to have a key that it uses to sign infrastructure keys, and then you want each piece of infrastructure to have its own key signed with the provider key.   You want the provider key to be long-lived, and you want the infrastructure keys to be very short-lived, like maybe a week at most.   This way stealing an infrastructure key has limited value, and yet the client can reliably identify infrastructure keys as belonging to the provider.

So the use model that seems plausible to me is the exact opposite of what's currently described in the draft, and what you are describing here, Francis.

> the "authenticated" by TOFU or static config.

Right, and so there's no need for the client to send a cert in this case.

> options, the client doesn't know which authentication to use so uses none.

This is easily fixed: have the server discard packets that allocate resources, but not discard solicit packets or information request packets.   The client then sends an unauthenticated solicit, and if it recognizes the server in the advertise, it sends an authenticated request.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 20 Feb 2015 10:37:36 -0800

At Fri, 20 Feb 2015 00:20:51 +0100,
Francis Dupont <[email-masked]> wrote:

> get the document adopted one day.

In case I wasn't clear, I didn't intend to insist the "key
distribution problem" should be fully solved before or in this
document.  But if we totally ignore it, we could end up publishing
something that doesn't soleve any new problem.  For example, if our
expected operation is to manually configure clients' public keys on a
server or via some imaginary "portal", the underlying security
mechanism doesn't have to be sedhcpv6; the plain-old RFC3315 security
protocol using a shared secret should suffice.  So, IMO, in order to
show this mechanism provides some new value we'll at least need to
provide some level of consideration on how the keys are securely
distributed and explain how the proposed security protocol (sedhcpv6)
along with the intended key distribution solves a new problem that
can't be solved with existing tools.

Aside from whether to add such consideration in the document, I've not
seen an argument in the case of authenticating "client->server" that
can answer this question of mine.  And, at least to me, it's
irresponsible to publish the result without even understanding it.

--
JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Fri, 20 Feb 2015 21:58:45 +0100

In your previous mail you wrote:

>  On Feb 20, 2015, at 10:22 AM, Francis Dupont <[email-masked]> =
>  wrote:
>  > => I can't remember if your objection is about public key
>  > vs. certificate.  If it is the case they are in fact equivalent
>  > as a certificate embeds a public key. Note in the server->client
>  > way a certificate has a little added value because a
>  > bootstrapping client has by definition no access to a PKI.
>  
>  What you are saying seems to represent a fundamental misunderstanding of
>  how PKI works and how it would make sense to use it.   Let me try to
>  explain:
>  
>  A cert from client to server makes no sense because certs are
>  signed by CAs, and there's (at least at present) no way to automate
>  that.  I'm not saying such a thing could never make sense, but I
>  don't see how it adds value.  The use model for such a cert that I
>  can imagine would be that a provider signs clients certs with a
>  provider key during some initial registration process, and then the
>  DHCP server just trusts all keys signed by the provider key.

=> I have to disagree:
 - first you have to bind a short list of keys (or certificates)
  to each client. Without this a client can too easily impersonate
  any other client.

 - a supposed benefit of certificate vs. a raw public key is to be
  able to associate the public key to identity, to provide revocation
  list, validity dates, etc. I believe most of these benefits are
  illusion but at least on the paper a PKI is supposed to be easier
  to manage.

 - the computing power, permanent/high bandwidth network access,
  management facilities, etc, are clearly by default on the server
  side.

So I am not against a certificate on the client->server way,
at the important condition it is not required, i.e., one can use
a raw public key. Note it is what I have said from the beginning.

>  But that doesn't make sense.  What most providers want is a
>  one-to-one accounting model, and you don't need a cert for
>  that--you just need to collect the client-generated key at
>  registration time and mark it as allowed in a key database.

=> at the exception of the key/client binding I have no concern
about this.

>  This means that later if the client doesn't pay the bill, you can
>  mark it in the database as no longer allowed.  The DHCP server just
>  checks in the database to see how the key is marked, and replies
>  accordingly, directing non-allowed keys to a captive portal, and
>  immediately allowing access for allowed keys.

=> the portal idea is more for an AAA system and if you want to
plug the DHCPv6 server to an AAA agent perhaps you will need
more than a certificate?

>  And in the reverse direction, it _does_ make sense for the server's
>  key to be signed by a PKI, for two reasons.  First, because of the
>  way PKI works.  The x.509 PKI that is used by web browsers relies
>  on the browser having a list of known roots, and if a cert's
>  signature chain leads back to a known root, the cert is considered
>  valid.  You need connectivity to check for revoked certs, but not
>  otherwise.

=> I am afraid this illusion of security is exactly what we don't
want... Adn network connectivity is required for validity dates too.

>  The second reason this makes sense is that providers have
>  infrastructure, and you don't want to have one key known to the
>  client where the private key is stored on every piece of
>  infrastructure in the provider network, because this means that the
>  compromise of any one infrastructure node will compromise the
>  entire network.

=> so you believe in the ease of management provided by PKIs
but only in this way?

>  No, what you want is for the provider to have a key that it uses to
>  sign infrastructure keys, and then you want each piece of
>  infrastructure to have its own key signed with the provider key.
>  You want the provider key to be long-lived, and you want the
>  infrastructure keys to be very short-lived, like maybe a week at
>  most.

=> short-lived public keys don't bring an important security advantage
but surely they raise clear operational issues.

>  This way stealing an infrastructure key has limited value, and yet
>  the client can reliably identify infrastructure keys as belonging
>  to the provider.

=> the client can detect an obsolete or revoked key only a posteriori
so likely too late. More, this model requires a lot of resources
on the client: when you ask for crypto support on smartphones
you get answers saying it is too expensive, etc, even 3D video
doesn't seem to be (:-). BTW I am afraid it is easier to mount
an attack using bad certificates (i.e., your use model) to drain
the battery than with raw keys (i.e., the use model of previous drafts).
 A last point: your use model will work better if the server provides
a certificate chain. As far as I know it is not supported and
it is not easy with UDP (cf. SeND which is my reference for
what we can (should?) do).

>  So the use model that seems plausible to me is the exact opposite of
>  what's currently described in the draft, and what you are describing
>  here, Francis.

=> perhaps it doesn't matter as the current direction is to allow
raw public keys or certificates in both ways, so independent of
use models...

>  Right, and so there's no need for the client to send a cert in this case.

=> one point we agree.

>  > => the server discards packets sent by the client without
>  > authentication options, the client doesn't know which
>  > authentication to use so uses none.
>
>  This is easily fixed: have the server discard packets that allocate
>  resources, but not discard solicit packets or information request
>  packets.  The client then sends an unauthenticated solicit, and if
>  it recognizes the server in the advertise, it sends an
>  authenticated request.

=> I didn't say it was a hard problem: just add complexity, have
corner cases (e.g., rapid commit), etc.

Regards

PS: I prepared the code to support Secure DHCPv6 on the server side.
I provided a way to use per client certificates or raw public keys,
with certificate validation at any time, including before packet
receive, and simple compare between the received option and the
config. BTW I use Botan and OpenSSL backends and for both the
certificate comparison is not the bit to bit one could expect (:-).

---

From: Francis Dupont <[email-masked]>
Date: Fri, 20 Feb 2015 22:19:36 +0100

I have to disagree: private/public key mechanisms are strictly more
secure than shared secret mechanisms. So you can't say the RFC3315
security is enough.

Now about the use model it seems there is no possible concensus for
one in a reasonable timeframe so the idea to put this point out of
scope is the right one.

Regards

PS: it seems we are in the good enough now vs perfect in the next
century case, so I am refraining my preference for the second (:-).

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Feb 2015 17:17:57 -0500

>  to each client. Without this a client can too easily impersonate

How can a client impersonate a different client without knowing that client's private key?

>  illusion but at least on the paper a PKI is supposed to be easier

Sure, but if for some reason the client's private key is compromised, the client can just generate a new key and re-register.   That's not very convenient, but it's no less convenient than pre-emptively signing keys and then revoking them if they are compromised.   The difference is that in the case where you are using certs, the cost is paid regardless of whether the key is ever compromised.

>  management facilities, etc, are clearly by default on the server

What does that have to do with anything?   Are you saying that the client shouldn't have to generate its key?

> a raw public key. Note it is what I have said from the beginning.

I'm not against a certificate on the client either--I just don't think there is a valid use case for it, whereas clearly there is a valid use case for a public key on the client.

> => at the exception of the key/client binding I have no concern

So you agree that the server has to maintain a database of client keys?

> plug the DHCPv6 server to an AAA agent perhaps you will need

Captive portals and AAA are orthogonal.   Certainly they can work together, but there is no requirement that they be made to work together.   If they did, the flow would be that you'd present your key to authenticate your DHCP transaction, the key wouldn't be recognized, and you'd be sent to the captive portal to enter your username and password, which would be validated using AAA.   The two systems here are essentially orthogonal: once the key is associated with the user ID, you don't need to consult AAA anymore.   This is important because the public key solution provides automatic authentication, whereas AAA through the captive portal requires user intervention.   You don't want to have to interact with the captive portal every time you join the network.

> want... Adn network connectivity is required for validity dates too.

No it's not.   Your device has a clock on it.   And if you want to fight the PKI battle, this is not the place to do it.   I agree that x.509 has issues, but the cert could also be a DNSSEC validation chain, at least in principle.

> => so you believe in the ease of management provided by PKIs

I don't see a way to associate an infrastructure key with a provider that doesn't involve certs, no, other than a global infrastructure key with the problems I've described.

> but surely they raise clear operational issues.

Either the key has to be short-lived, or there has to be a way to prove that it hasn't been revoked.

> what we can (should?) do).

If you have a trust relationship with a provider, the infrastructure key can be signed by a provider key that you have accepted, so the chain is one key deep.   Phones check certs all the time.   It's true that if you connect to a wifi network that wants to DoS your battery, you'd have to have a way of noticing that this is happening and dissociating with that AP after a certain number of failures.

> corner cases (e.g., rapid commit), etc.

Does anyone use Rapid Commit?

> certificate comparison is not the bit to bit one could expect (:-).

BTW, one thing we haven't discussed is using public keys to establish shared secrets rather than using the public keys themselves on every transaction.   It is possible that this would be a better solution.   But the bottom line is that right now we are shooting in the dark, and I don't see a way forward that doesn't involve proposing something and seeing if people use it.   The PK->shared secret method would involve a change to the DHCP state machine, so this seems like a better place to start.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 20 Feb 2015 16:12:55 -0800

At Fri, 20 Feb 2015 22:19:36 +0100,

> secure than shared secret mechanisms. So you can't say the RFC3315

Mainly for educating me (= not really a security expert), could you
explain exactly how sedhcpv6 (a private/public key mechanism) is
strictly more secure than RFC3315 (a shared secret mechanism) in the
case of client->server authentication?  In that an attacker would have
to compromise all clients it wants to attack while in the case of
shared secret the attacker would only have to break the centralized
"key database" (assuming such a thing is used)?

--
JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Sat, 21 Feb 2015 20:24:35 +0100

>  How can a client impersonate a different client without knowing that

=> when you verify the public key and the signature are fine
but not the public key is bound to this particular client
(i.e., per client list of keys vs a global list of keys).

>  Sure, but if for some reason the client's private key is compromised,
>  the client can just generate a new key and re-register.   That's not
>  very convenient, but it's no less convenient than pre-emptively signing
>  keys and then revoking them if they are compromised.   The difference is
>  that in the case where you are using certs, the cost is paid regardless
>  of whether the key is ever compromised.

=> I exposed the PKI argument, I didn't say I bought it. Or with
other words I prefer raw public keys but I shan't fight the idea
to use a certificate in place of a public key.

>  What does that have to do with anything?   Are you saying that the
>  client shouldn't have to generate its key?

=> I expect key pair generation to be a rare event so it is a
second order concern. Here my concern is about the cost of validating
a certificate (get the chain, verify signature, check CRLs, check
attributes, etc) vs the cost of membership in a short list.

>  I'm not against a certificate on the client either--I just don't think
>  there is a valid use case for it, whereas clearly there is a valid use
>  case for a public key on the client.

=> IMHO we have a better use of our time than to speculate about
future use model, especially when it should delay without a bound
the progress of the specs to use (:-). So agree to disagree and
move forward?

>  So you agree that the server has to maintain a database of client keys?

=> a database of client keys or certificates or both.

>  No it's not.   Your device has a clock on it.

=> I am afraid you can't make this assumption, in particular for
a booting device. Please note IMHO it is important the secure DHCPv6
protocol to work with clients without a clock (here a clock is
a piece of hardware which can provide a good UTC date after a long
poweroff state).

>  I don't see a way to associate an infrastructure key with a provider
>  that doesn't involve certs, no, other than a global infrastructure key
>  with the problems I've described.

=> you have some hidden assumptions about what is the infrastructure.
For instance there is no problem when the infrastructure is one DHCP
server. Note I didn't raise a concern about the term provider so
I left you to describe an environment which could be not the most
common one...

>  > => short-lived public keys don't bring an important security
>  > advantage but surely they raise clear operational issues.
>

=> to be honest I don't believe in revocation (and I live in a country
where a 80,000,000 entry CRL was deployed :-).

>  If you have a trust relationship with a provider, the infrastructure key
>  can be signed by a provider key that you have accepted, so the chain is
>  one key deep.

=> in the real world the only reason to get short chains is for the
top level CA to get better control over client CAs/RAs (cf the
maximum depth in Basic Constraints attribute).

>  Does anyone use Rapid Commit?

=> anyone which knows what it is and how to configure it...

>  BTW, one thing we haven't discussed is using public keys to establish
>  shared secrets rather than using the public keys themselves on every
>  transaction.   It is possible that this would be a better solution.

=> it is stateful vs stateless. I believe there was some messages
about this tradeoff and the concensus was to keep no state as
it was done for the DHCPv6 protocol itself.

>  But the bottom line is that right now we are shooting in the dark,
>  and I don't see a way forward that doesn't involve proposing
>  something and seeing if people use it.  The PK->shared secret
>  method would involve a change to the DHCP state machine, so this
>  seems like a better place to start.

=> I agree.

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Sat, 21 Feb 2015 21:50:49 +0100

>  > secure than shared secret mechanisms. So you can't say the RFC3315

=> it is about where is the secret: for a private/public key mechanism
the secret is in one place, for a shared secret mechanism it is in two
places. To summary the term "shared secret" is basically an oxymoron...

Regards

PS: in particular applied to long term secrets as for this context.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 21 Feb 2015 19:03:06 -0500

> (i.e., per client list of keys vs a global list of keys).

Yes, of course, you have to have both authentication and authorization; just authentication won't do any good.   I think the document already explains this.

> to use a certificate in place of a public key.

OK, cool.

> the progress of the specs to use (:-). So agree to disagree and

Completely agree.

> a piece of hardware which can provide a good UTC date after a long

I think that such devices will have to accept a more limited assurance of the security of the transaction.

> I left you to describe an environment which could be not the most

You are correct: for that use case, a cert adds no value.

> where a 80,000,000 entry CRL was deployed :-).

In principle the mechanism in RFC 6962 isn't bad.   But I don't think we can use it.

> => anyone which knows what it is and how to configure it...

So no-one (rapid commit)?

> it was done for the DHCPv6 protocol itself.

Yup.

>> seems like a better place to start.

Okay.   I think the discussion is useful, but we have no action item.   The question is whether Jinmei-san and Ralph can live with not trying to document use cases.   I think that the standard ought to be along the lines of what's documented in RFC 7282, though--I don't think we're going to get to complete consensus on this.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 23 Feb 2015 10:51:23 -0800

At Sat, 21 Feb 2015 21:50:49 +0100,

> places. To summary the term "shared secret" is basically an oxymoron...

It's still vague to me...specifically what kind of attack should we
worry about in the case of client->server authentication when we use
the shared secret mechanism, and in which sense is it more serious
than with the public/private key mechanism?

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Wed, 25 Feb 2015 11:09:39 -0800

At Sat, 21 Feb 2015 19:03:06 -0500,
Ted Lemon <[email-masked]> wrote:

> Okay.   I think the discussion is useful, but we have no action
> item.   The question is whether Jinmei-san and Ralph can live with
> not trying to document use cases.   I think that the standard ought
> to be along the lines of what's documented in RFC 7282, though--I
> don't think we're going to get to complete consensus on this.

As (I believe) I stated before, I'm okay with not documenting specific
use cases per se.  But that's because describing use cases are just an
attempt to explain why we need this mechanism (and why the existing
mechanism does not answer it), especially for the case of
client->server authentication.  I'm totally okay with removing the use
case discussion if we can reasonably answer this question in some
other way, but I'm not yet okay with completely ignoring the question.

In that sense I'd still love to see an answer to my specific question:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg16268.html
(aside from whether to include that answer in the final document).

I can see how a public-key based authentication is "strictly more
secure" (while reducing deployment cost) in the case of
"server->client" authentication.  But it's not at all clear to me for
the case of "client->server".  Maybe this is too obvious to some
others, but I hope someone could clarify this for some non-security
experts like me.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Feb 2015 14:30:36 -0500

> than with the public/private key mechanism?

What we are trying to do with the public key is to identify a client and authenticate the client's identity.   If you want to phrase it in terms of preventing an attack, the attack it prevents is one client presenting another client's identity and getting access to the second client's resources because the credential it presents is never authenticated.

But in practice, as a general rule we simply don't ever bother to treat clients as having meaningful identities, because there is no way to authenticate them.   So we aren't trying to prevent an attack, really.   We are trying to provide an enabling technology that allows the network infrastructure to do something new, that it couldn't previously do.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 26 Feb 2015 10:04:44 -0800

At Wed, 25 Feb 2015 14:30:36 -0500,

> But in practice, as a general rule we simply don't ever bother to treat clients as having meaningful identities, because there is no way to authenticate them.   So we aren't trying to prevent an at…

I guess the point of my question is what's the "something new, that it
couldn't previously do."?  Can you be a bit more specific about it?
Or, did you mean "we don't know what it is"?

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 Feb 2015 13:47:27 -0500

On Feb 26, 2015, at 1:04 PM, 神明達哉 <[email-masked]> wrote:
> Can you be a bit more specific about it?

>> What we are trying to do with the public key is to identify a client and authenticate the client's identity.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 26 Feb 2015 11:27:53 -0800

At Thu, 26 Feb 2015 13:47:27 -0500,

> >> What we are trying to do with the public key is to identify a client and authenticate the client's identity.

But can't we do this with the RFC3315-based shared secret mechanism
with a comparable operational cost and security level?  I still don't
see what's essentially new with the public key based mechanism...

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 Feb 2015 15:36:30 -0500

On Feb 26, 2015, at 2:27 PM, 神明達哉 <[email-masked]> wrote:
> with a comparable operational cost and security level?

No, because it uses shared secrets, and doesn't provide a way to establish the shared secret.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 26 Feb 2015 16:52:16 -0800

At Thu, 26 Feb 2015 15:36:30 -0500,

> No, because it uses shared secrets, and doesn't provide a way to establish the shared secret.

But we don't have a secure and practical way of installing clients'
public keys on the server, either, right?  We could manually copy the
clients' public keys to the server, but we could do so for clients'
shared secrets.

So, in the practical sense I still don't see a fundamental difference
between the public key based mechanism and shared secret based one.
I'm afraid I'm sounding too dumb and may look someone who can't
understand something too obvious to others, but could you, or someone
else, show a very specific example that can explain how exactly the
public key based mechanism is safer and less operationally expensive
than the shared secret mechanism for client authentication?

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 Feb 2015 21:51:37 -0500

> clients' public keys to the server, but we could do so for clients'

The client sends its public key in the DHCP message, so the key is on the server the first time the client communicates with it.  There is no equivalent flow for shared secrets.

---

From: "Niall O'Reilly" <[email-masked]>
Date: Fri, 27 Feb 2015 15:47:10 +0000

On Fri, 27 Feb 2015 02:51:37 +0000,
Ted Lemon wrote:
> 
> The client sends its public key in the DHCP message, so the key is
> on the server the first time the client communicates with it.

  So, TOFU?

  That should be fine, provided that the process for creating each
  distinct (physical or virtual) client results in a distinct
  identity.

  Best regards,
  Niall O'Reilly

---

From: Ted Lemon <[email-masked]>
Date: Fri, 27 Feb 2015 11:24:31 -0500

>  So, TOFU?

Depends on what you are trying to do.   If you just want to make sure that client A doesn't swipe client B's resources, TOFU is all you need.   If you want to do some kind of RADIUS transaction, as we talked about previously, there's probably some sort of captive portal registration process.

---

From: Sten Carlsen <[email-masked]>
Date: Fri, 27 Feb 2015 18:14:05 +0100

> Depends on what you are trying to do.   If you just want to make sure that client A doesn't swipe client B's resources, TOFU is all you need.   If you want to do some kind of RADIUS transaction, as…
Would signing the client cert with a particular root cert allow another
level of control? If the client cert is signed by the correct party, it
is admitted - if not, it is rejected.

Just a thought.
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
> 

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"

---

From: "Niall O'Reilly" <[email-masked]>
Date: Fri, 27 Feb 2015 17:33:05 +0000

On Fri, 27 Feb 2015 16:24:31 +0000,
Ted Lemon wrote:
> Depends on what you are trying to do.  If you just want to make sure
> that client A doesn't swipe client B's resources, TOFU is all you
> need.

  That's what I thought you meant.
  Thanks for confirming.

  Best regards,
  Niall O'Reilly

---

From: 神明達哉 <[email-masked]>
Date: Fri, 27 Feb 2015 11:13:14 -0800

At Thu, 26 Feb 2015 21:51:37 -0500,
Ted Lemon <[email-masked]> wrote:

> on the server the first time the client communicates with it.  There
> is no equivalent flow for shared secrets.
[...]
At Fri, 27 Feb 2015 11:24:31 -0500,
Ted Lemon <[email-masked]> wrote:
> >  So, TOFU?
>
> Depends on what you are trying to do.   If you just want to make
> sure that client A doesn't swipe client B's resources, TOFU is all
> you need.

In this case, it doesn't even have to be TOFU (in its usual sense);
the server only needs to remember the client's public key during the
specific DHCPv6 session.  But, yes, I see the advantage of the public
key based mechanism in this case, although I'm personally not sure if
this is really a serous threat that we want to prevent by introducing
a new protocol.

> If you want to do some kind of RADIUS transaction, as we
> talked about previously, there's probably some sort of captive
> portal registration process.

And, in this case, it could also be a shared secret-based mechanism
without any essential difference in terms of operational cost and
security level, correct?  The client would create a secret, and
register it at the portal.  The server would retrieve the secret from
the portal and they can securely share the secret.

Am I understanding it correctly so far?

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Fri, 27 Feb 2015 14:17:27 -0500

> is admitted - if not, it is rejected.

We already discussed that.   I don't think it's a very useful flow.   Generally speaking, if you want access control for clients, signing their public key just adds an extra step.   You could have a flow a lot like the flow we have now where the MAC address is added to a database in the receiving department, and then the key for that device is connected to the MAC address the first time the DHCP server sees it.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 27 Feb 2015 14:24:16 -0500

> the portal and they can securely share the secret.

There would be a shared secret in the RADIUS transaction, but not in the DHCP transaction.   Who generates the secret is out of scope (indeed, the whole RADIUS part of the flow is out of scope) but you are probably right that it's done through some kind of user registration process where the user enters a password.

Of course, this flow is actually a really bad idea--it would be much better to use the public key for the whole thing, so that there is no shared secret and no risk of the end user choosing a weak password, so if I were designing such a flow from scratch I would not used a shared secret at all.   The only reason to support this flow is that it would work with existing installations and is better than what we have now.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 27 Feb 2015 19:41:00 +0000

On Friday, February 27, at 2015 11:17 AM, Ted Lemon wrote
 
> > Would signing the client cert with a particular root cert allow
> > another level of control? If the client cert is signed by the correct
> > party, it is admitted - if not, it is rejected.
> 
> We already discussed that.   I don't think it's a very useful flow.   Generally
> speaking, if you want access control for clients, signing their public key just
> adds an extra step.   You could have a flow a lot like the flow we have now
> where the MAC address is added to a database in the receiving department,
> and then the key for that device is connected to the MAC address the first
> time the DHCP server sees it.

Second that.

Please consider the "anonymity" (or privacy) use case, in which the client does not want to disclose a long term identity.

You want to counter a specific Denial Of Service threat, in which someone spoofs an existing DHCP session and messes up with existing leases. Associating a public key with the session is sufficient. But you don't want a full blown certificate mechanism that would compel client identity disclosure inside the DHCP exchange. If some identity has to be disclosed, it is better to leave that to another mechanism, like maybe a captive portal.

-- Christian Huitema

---

From: 神明達哉 <[email-masked]>
Date: Fri, 27 Feb 2015 11:54:04 -0800

At Fri, 27 Feb 2015 14:24:16 -0500,
Ted Lemon <[email-masked]> wrote:

> There would be a shared secret in the RADIUS transaction, but not in
> the DHCP transaction.   Who generates the secret is out of scope
> (indeed, the whole RADIUS part of the flow is out of scope) but you
> are probably right that it's done through some kind of user
> registration process where the user enters a password.
>
> Of course, this flow is actually a really bad idea--it would be much
> better to use the public key for the whole thing, so that there is
> no shared secret and no risk of the end user choosing a weak
> password, so if I were designing such a flow from scratch I would
> not used a shared secret at all.   The only reason to support this
> flow is that it would work with existing installations and is better
> than what we have now.

I don't understand how it's better than what we have now.  In the
above flow I didn't expect the shared secret for DHCPv6 is something
like a (human) user-generated password.  It would probably be
generated by a backend system of the OS or DHCP client, and should be
generally unpredictable.  I don't see any difference between creating
a secure public-private key pair and creating a secure secret (to be
shared) in this scenario.  So the security level of this framework
depends on some details of the yet-to-be-seen "portal", and that level
of security equally applies to a publickey-based DHCPv6 security
mechanism and to a shared-secret based DHCPv6 mechanism.  Am I right?

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Fri, 27 Feb 2015 15:19:39 -0500

On Feb 27, 2015, at 2:54 PM, 神明達哉 <[email-masked]> wrote:
> I don't understand how it's better than what we have now.

I think this is the heart of the matter.   I do not understand how you can have doubts about this.   It is clearly better than what we have now.   There is a reason why kerberos is almost never used, and TLS is ubiquitous: shared secrets are much harder to use securely than public key encryption.   We have seen _zero_ deployment of shared secret authentication in DHCP.   There is no question that it doesn't work in practice.   It's possible that we will see zero deployment of this mechanism as well, but if so that'll be because there is no demand for secure DHCP, not because it's hard to deploy.

We've had a long discussion about various flows that the mechanism defined in the draft can support.   I don't think there's any question but that the mechanism could be useful.   We don't know that it will be used, and I think that is your core objection.   But if that objection were a valid objection, we would never have developed DNSSEC.   This is a _much_ easier lift than DNSSEC.   So if your argument was wrong for DNS, I think it's also wrong for DHCP.

It's possible that there is some technical flaw in the current proposal that means it won't work for the flows we've discussed.   If so, we should fix that technical flaw.   If you think such a flaw exists, I hope you will point it out.   But I think that further debates about hypothetical flows that we don't actually know will be used should be out of scope, because it's not getting to the core of your objection.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 27 Feb 2015 13:29:01 -0800

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

> I think this is the heart of the matter.

Perhaps, and although you may not be comfortable with saying anything
about this specific case, could you answer my question to the specific

>> portal registration process.

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?

I'm not trying to say we don't need sedhcpv6 just because of that, but
I'd like to understand exactly where we are.  Also, if the answer to
that question is "no", I'd like to understand any specific counter
example, even if it's hypothetical.

--
JINMEI, Tatuya

---

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

> 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.   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.

None of the scenarios I've described just now work with DHCP shared secret authentication.

> Also, if the answer to

Numerous examples have been mentioned.   E.g.:

- 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
- client sends public key, server recognizes the key, server grants client access to network according to some pre-existing arrangement
- 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

The RADIUS flow we've talked about is an example of a way that arrangements could be made to grant network access for the client, but other examples include a credit card transaction, some other sort of login, etc.