Subject: [Dhcpv6bis] issue #86 -- authentication in stateless situations

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Jan 2015 09:25:08 -0500

re: http://tools.ietf.org/group/dhcpv6bis/ticket/86

I think the issue is that we can not use symmetric authentication mechanism
in the stateless case because there is no Discovery phase in which the server
can assert what keyIDs are to be used.

  "In particular, this assumption prohibits the use of the mechanism with the
       "stateless"  service using DHCPv6 [RFC3736]."

If we want to solve this, then we need to adjust the state machine
significantly for the *stateless* case.

I propose that we may want to conclude that this is limitation of symmetric
authentication, and we should perhaps better document it, and maybe someone
will figure out a way to solve it, or maybe, in the stateless case, we really
should be using asymmetric authentication anyway.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: 神明達哉 <[email-masked]>
Date: Wed, 7 Jan 2015 09:45:34 -0800

At Wed, 07 Jan 2015 09:25:08 -0500,

> should be using asymmetric authentication anyway.

I'm not sure if this is essentially an issue of symmetric vs
asymmetric authentication.  I'm not necessarily pushing this
particular idea, but I don't see why the "suggested resolution"
described in my old draft (Section 2.1 of
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-clarify-auth-01)
doesn't work or it adjusts the (server's?) state machine
significantly.  This suggested resolution still keeps the server-side
stateless, still uses symmetric authentication, and still uses
different keys for different clients.

--
JINMEI, Tatuya