Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

From: 神明達哉 <[email-masked]>
Date: Mon, 2 Jun 2014 09:53:06 -0700

At Fri, 30 May 2014 20:47:12 -0400,
Ted Lemon <[email-masked]> wrote:

> > I think it is important to add a section that enumerates those and
> > similar use cases. Otherwise you risk that this work will be stalled
> > and you'd be asked to write a separate problem statement document.
>
> A use case can't be theoretical.   You should have an actual use for it.

I fully agree, but then I'd wonder if all we can come up with
is theoretical use cases how we can define an effective solution to
them.

> So I think documenting use cases like a "high security network" is pointless.   The point of this mechanism is to authenticate DHCP transactions in both directions using public keys.   Why do we need a list of use cases for this?   This is something we've been asked for for over a decade.   Does someone seriously think there's a different way to do this that's more appropriate?   If so, please explain!   Does someone think that the actual uses documented in the draft won't work?   If so, please say why.

I didn't know if this (= "authenticating DHCP transactions in both
directions using public keys", correct?) is something people have
asked for over a decade, but if so, I'd like to know why they've been
asking for it, since, once I read this particular draft carefully I
realize that's not clear to me at all.  Defining a mechanism simply
because someone(s) asked for it without clear understanding of "why"
doesn't make sense to me.

One possibility is that I'm too dumb and can't just understand
something so obvious to others, in which case I'll simply shut up.

But, the fact that at least two others wanted to have use cases seems
to suggest that at least it's not only me who can't fully understand
why we need it.  And, if at least three people have difficulty in
understanding it, that probably means there are potentially may more.
So, I think this has to be documented somewhere explicitly.  Whether
it should be in the protocol document is a different question, though,
so...

> I certainly think that if people want to suggest ways of clarifying the document, that would be beneficial, but let's not get carried away throwing the kitchen sink into the document for no good reason.   That makes it slower to review and is as likely to generate controversy as quell it.

...this is fine, but in that case I'd like to see the separate
discussion and documentation first, as I already said in an earlier
message of mine:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg15520.html
It doesn't make sense to me to defer the clarification of "why"
because it slows to review the "solution".

But you don't seem to like this idea either, presumably due to the
processing delay.  My understanding is, hence a brief summary of use
cases in this draft as a kind of compromise.  If the use cases are so
obvious to some people, this can be pretty simple and avoid making the
document a kitchen sink.  I actually showed one possible outline of
this addition: http://www.ietf.org/mail-archive/web/dhcwg/current/msg15526.html
We can then answer the question that many future readers of this
document (i.e., why we need this?) would have at the time of its
publication.  And, we can still minimize the processing delay by
avoiding to require a completely separate document to explain the use
cases as a prerequisite of the protocol document.

I thought it was a reasonable and pragmatic suggestion.  But if the
majority of the wg still doesn't think it worth doing, we should
probably just agree to disagree, and in which case I'll stop at that
point; I don't have a strong motivation to prevent its publication.

--
JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Mon, 2 Jun 2014 16:29:19 -0400

> something so obvious to others, in which case I'll simply shut up.

I'm willing to agree that I'm off in the weeds.  But I haven't been convinced, yet.

I think the purpose of authentication is to provide trustworthy DHCP transactions.  That trustworthiness depends on both the authenticate messages and the trust of the other endpoint.  I think the document could use some more words about that nuance.

Doesn't have to be use cases, per se, and the document certainly shouldn't dictate where authentication is useful and where it isn't.  Jinmei-san has more precisely described the thread I've been trying to pull on, which is "why authenticate" and "under what circumstances does this mechanism answer the question 'why authenticate'".

> cases as a prerequisite of the protocol document.

I just re-read http://www.ietf.org/mail-archive/web/dhcwg/current/msg15526.html

I very much like your categorization of applicability considerations, which address "why authenticate" and "considerations for each case".

> point; I don't have a strong motivation to prevent its publication.

In my opinion, the suggestion was, indeed, reasonable and pragmatic.  I, too, am willing to drop the discussion if the WG feels otherwise.

- Ralph

> 
> --
> JINMEI, Tatuya
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Jun 2014 16:52:54 -0400

I have no personal objection to Jinmei's text, although I think it's incomplete.   Could you guys work with Sheng to see if you can come up with a mutually agreeable update?

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 3 Jun 2014 05:55:14 +0000

The authors plan to produce an update version, which addresses the comments received during the WGLC, in two weeks. The "applicability statement" would be major target in this update. We will come up with a proposal text and invoke discussion in email list in a couple of days.

Best regards,

Sheng

>-----Original Message-----
>From: dhcwg [mailto:[email-masked]] On Behalf Of Ted Lemon
>Sent: Tuesday, June 03, 2014 4:53 AM
>To: Ralph Droms
>Cc: dhcwg; 神明達哉
>Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May
>18
>
>I have no personal objection to Jinmei's text, although I think it's incomplete.
>Could you guys work with Sheng to see if you can come up with a mutually
>agreeable update?
>

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 03 Jun 2014 18:19:26 +0200

On 29.04.2014 20:21, Tomek Mrugalski wrote:
> The draft is available here:
> http://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-02
> 
> Please send your comments by May 18th 2014. If you do not feel this
> document should advance, please state your reasons why.
It took us a bit longer to wrap this up, but here is goes.

We received quite a few insightful comments and had a decent discussion
following up. Number of issues were raised, but the the comments were
supportive in general as nobody objected that work. Even though this
WGLC technically passed, authors will need to update their draft. One
particular area that requires some work is an applicability statement.
Once updated rev is posted, we will do another WGLC to confirm that
those changes addresses raised issues adequately.

Just a heads up for the authors: I know that Francis Dupont will do the
review of this draft as part of the GEN-ART review. He only had time to
casually look at it so far, but has some crypto related comments. I'm
not aware of the details, though. We'll have to wait and see when he
posts his comments to the ML. Hopefully, that will happen next week.

Bernie & Tomek

---

From: 神明達哉 <[email-masked]>
Date: Tue, 3 Jun 2014 14:06:49 -0700

At Mon, 2 Jun 2014 16:52:54 -0400,
Ted Lemon <[email-masked]> wrote:

> I have no personal objection to Jinmei's text, although I think it's
> incomplete.   Could you guys work with Sheng to see if you can come
> up with a mutually agreeable update?

I'm happy to do that.  I've seen a followup message from the draft
authors with the plan of starting the discussion, so I think we can
continue this topic there.

--
JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Wed, 4 Jun 2014 08:37:19 -0400

> continue this topic there.

I'll participate in that discussion, as well.

- Ralph

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 5 Jun 2014 09:38:41 +0000

Hi, Jinmei, Ralph, Ted and all,

The below text is the proposal from SeDHCPv6 authors in order to clarify the applicability. We plan to add these text, of course after reaching consensus in the mail list, into the next update version. Any comments are appreciated.

Deployment consideration

This document has defined two levels of authentication: full authentication based on certificate or pre-shared key verification and weaker authentication based on leap-of-faith. Both levels can be applied on servers and clients. The deployment scenarios can be categorized as below:

	Authenticating a server on a client
	   - Both fully authentication and leap-of-faith can be used. The latter is weaker. But, it is better than no protection by narrowing the attack scope.

	Authenticating a client on a server
	   - With fully authentication, the server can selectively serve a specific client (or deny specific clients). The server can prevent an attacker from breaking an existing DHCPv6 session of a client. The server can also prevent an attacker from pretending to be a past legitimate client.
	   - With leap-of-faith authentication, the server can only prevent an attacker from breaking an existing DHCPv6 session of a client and pretending to be a past legitimate client.
	   - A server may maintain both fully authentication and leap-of-faith authentication at the same time. In such scenarios, the clients authenticated through leap-of-faith normally have lower priority or/and limited network access. One example would be in an enterprise network, office devices or employers’ devices used full authentication are allowed to access all network resources, including the internal database; devices of occasional visitors also get authenticated, but through leap-of-faith, they can only access public web services of this enterprise and the Internet.

Best regards,

Sheng

>From: dhcwg [mailto:[email-masked]] On Behalf Of Sheng Jiang
>Sent: Tuesday, June 03, 2014 1:55 PM
>To: Ted Lemon; Ralph Droms
>Cc: dhcwg; 神明達哉
>The authors plan to produce an update version, which addresses the
>comments received during the WGLC, in two weeks. The "applicability
>statement" would be major target in this update. We will come up with a
>proposal text and invoke discussion in email list in a couple of days.
>
>Best regards,
>
>Sheng
>

---

From: 神明達哉 <[email-masked]>
Date: Fri, 6 Jun 2014 11:51:46 -0700

At Thu, 5 Jun 2014 09:38:41 +0000,
Sheng Jiang <[email-masked]> wrote:

> The below text is the proposal from SeDHCPv6 authors in order to
> clarify the applicability. We plan to add these text, of course
> after reaching consensus in the mail list, into the next update
> version. Any comments are appreciated.

The proposed text seems to be almost a minor revise of my outline I
showed on the list, so I guess Ted would still complain that it's
incomplete:-).  I'm not sure how much we should be "complete" in this
document (especially if we wouldn't like to make the document a
kitchen sink), but I'll show my own try below.  Not intending to push
this particular text, but I thought I'm responsible for providing
something more concrete as someone who keeps raising the point.

X. Deployment consideration

This document defines two levels of authentication: full
authentication based on certificate or pre-shared key verification and
weaker authentication based on leap-of-faith (LoF).  As a mechanism,
both levels can be applied on servers and clients.  Depending on the
details of expected threats and other constraints, some cases may have
limited applicability.  This section discusses such details.

X.1 Authentication on a client

For clients, DHCP authentication generally means authenticating the
server (the sender of DHCP messages) and verifying message integrity.

This is satisfied with full authentication.  Due to the configuration
overhead, however, full authentication may not always be feasible.  It
would still be viable in a controlled environment with skilled stuff,
such as a corporate intranet.

If LoF is used, message integrity is provided but there is a chance
for the client to incorrectly trust a malicious server at the
beginning of the first session with the server (and therefore keep
trusting it thereafter).  But LoF guarantees the subsequent messages
are sent by the same server that sent the public key, and therefore
narrows the attack scope.  This may make sense if the network can be
reasonably considered secure and requesting pre-configuration is
deemed to be infeasible.  A small home network would be an example of
such cases.

For environments that are neither controlled nor really trustworthy,
such as a network cafe, full authentication wouldn't be feasible due
to configuration overhead, while pure LoF, i.e. silently trusting the
server at the first time, would be too insecure.  But some
middleground might be justified, such as requiring human intervention
at the point of LoF.

X.2 Authentication on a server

As for authentication on a server, there are several different
scenarios to consider, each of which has different applicability
issues.

A server may have to selectively serve a specific client or deny
specific clients depending on the identify of the client.  This will
require full authentication, since if the server allows LoF any
malicious user can pretend to be a new legitimate client.  Also, the
use of certification wouldn't be feasible in this case, since it's
less likely for all such clients to have valid (and generally
different) certificates.  So the applicable case may be limited, but a
controlled environment with skilled stuff and a specifically expected
set of clients such as a corporate intranet may still find it useful
and viable.

A server can prevent an attack on the DHCP session with an existing
client from a malicious client, e.g., by sending a bogus Release
message: the server would remember the original client's public key
at the beginning of the DHCP session and authenticate subsequent
messages (and their sender).  Neither full authentication nor LoF is
needed for this purpose, since the server does not have to trust the
public key itself.  So this can be generally used for any usage of
DHCP.

A server can prevent an attack by a malicious client that pretends to
be a valid past client and tries to establish a new DHCP session
(whether this is a real security threat may be a subject of debate,
but this is probably at least annoying).  This is similar to the first
scenario, but full authentication may not necessarily be required;
since the purpose is to confirm a returning client has the same
identify as a valid past client, the server only has to remember the
client's public key at the first time.  So LoF can be used at the risk
of allowing a malicious client to mount this attack before the initial
session with a valid client.  An uncontrolled, but reasonable reliable
network like a home network may use this defense with LoF.

--
JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Tue, 17 Jun 2014 13:15:39 -0400

Sheng - I think Jinmei-san's suggested text is very good, although I do have one question about authentication on a server.  The text includes examples for the various scenarios, which addresses my primary concern.

Jinmei-san - I have one question about your text.  Can you explain in a little more detail how the second and third examples of authentication on a server work, in which you say the server only has to remember the client's public key so neither full authentication nor LoF is required?

- Ralph

---

From: 神明達哉 <[email-masked]>
Date: Tue, 17 Jun 2014 15:27:17 -0700

At Tue, 17 Jun 2014 13:15:39 -0400,

> Jinmei-san - I have one question about your text.  Can you explain in a little more detail how the second and third examples of authentication on a server work, in which you say the server only has…

In the second example, the client sends its public key in Solicit, and
the server remembers it during the DHCP session starting from that
Solicit.  The server uses the public key to authenticate any
subsequent message from that client (or anyone claiming to be that
client) for that DHCP session.  I said LoF (let alone full
authentication) isn't needed because when the server accepts and
remembers the public key sent in the Solicit, it doesn't do so for the
purpose of authenticating the Solicit itself.  It only remembers the
public key to confirm that subsequent messages of the session are
certainly sent from the same client as the one sent the Solicit, and
there's no "leap" here.

In the third example, I actually didn't say LoF isn't required.  Could
the text read as if I did?

--
JINMEI, Tatuya

p.s., I noticed one type in the text, a kind only non native English

> > such as a corporate intranet.
[...]
> > set of clients such as a corporate intranet may still find it useful

if we use any part of my suggested text, please correct these > authors.

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 18 Jun 2014 09:30:16 +0000

Thanks Ralph for confirmation. Thanks Jinmei for helpful input. We have included these text in the ongoing update version.

Best regards,

Sheng

>From: Ralph Droms [mailto:[email-masked]]
>Sent: Wednesday, June 18, 2014 1:16 AM
>To: 神明達哉; Sheng Jiang
>Cc: Lemon Ted; dhcwg
>Subject: Re: [dhcwg] Deployment consideration for SeDHCPv6
>
>Sheng - I think Jinmei-san's suggested text is very good, although I do have
>one question about authentication on a server.  The text includes examples
>for the various scenarios, which addresses my primary concern.
>
>Jinmei-san - I have one question about your text.  Can you explain in a little
>more detail how the second and third examples of authentication on a server
>work, in which you say the server only has to remember the client's public key
>so neither full authentication nor LoF is required?
>
>- Ralph
>

---

From: Ralph Droms <[email-masked]>
Date: Thu, 19 Jun 2014 12:03:18 -0400

> On Jun 17, 2014, at 6:27 PM, 神明達哉 <[email-masked]> wrote:
> 

I see.  I missed the point that the messages still use the authentication option to prove that the messages come from the same source and to prove message integrity, but the source is not checked for authorization to use the server.

> the text read as if I did?

I reread the text.  You are right, it does not say LoF is not required.  I misread the text initially.

- Ralph