Subject: [dhcwg] DHCPv6 Authentication Option

From: "punit shah" <[email-masked]>
Date: Sat, 5 May 2007 11:33:22 +0530

Dear DHCP-WG Mailing List members,

                    I have several queries on the authentication
option specified in RFC 3315. I would greatly appreciate if you could
take the time to go through them and clarify my doubts:-

1.) The Delayed Authentication Protocol specifies that the Client
requests Authentication in Solicit message which is answered in the
Adverstise message. What if the Client also attached Rapid Commit
Option - would it violate the RFC if the server authenticated itself
in the Reply message? In other words should the server ignore rapid
commit option, where the authentication option is specified?

2.) The format of the authentication option specifies a variable
length DHCP realm, a key id and the hmac-md5 value. Is it compulsory
to specify the dhcp realm and the key id ? How does one ensure dhcp
realm names are uniques like URL's? And also why use a DHCP realm? Is
not a client DUID enough?

3.)  RFC 3315 focueses on authentication of server by client but what
about the reverse i.e., authentication of client by server?

rgds,
Punith S. Shah.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 9 May 2007 12:13:40 -0700

> commit option, where the authentication option is specified?

If RDM is 2, I think it does violate the RFC.  If not, then I
think a server can authenticate its reply, as it would have
authenticated the Advertise in the same way.

Personally, I think ignoring rapid-commit in this case would be
less complicated and more general.

> to specify the dhcp realm and the key id ?

This is not very clear at all.  The authentication option uses a
variable length field followed by a key-id of inspecific length
then followed by a 128-bit MAC.  There's no way for a server to
distinguish between the first two fields, so if it were
compulsory, there's no way to validate that.

So, similarly to client identification, I would understand that
the trailing 128-bits are the key's MAC, and all preceeding bytes
are an opaque "key identity field".

> How does one ensure dhcp
> realm names are uniques like URL's?

How do you ensure that WiFi SSID's are unique?  That's all that's
required here.

> And also why use a DHCP realm? Is

That's a good question.

I suspect that in some circumstances there's an expectation that
a key would be shared among multiple DUID's.

In this case, even among multiple DUID's, you would imagine that
a key id would be sufficiently unique.

> about the reverse i.e., authentication of client by server?

Authentication is sparsely documented, but it is clearly a general
method used by both the client and server.

My interpretation is that clients are expected not to authenticate
their Solicits...just to include 'preference' information.  The
servers authenticate their Advertises, and the client selects (if
it has the key) the key the servers specified to authenticate the
clients' messages.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "punit shah" <[email-masked]>
Date: Thu, 10 May 2007 01:01:37 +0530

Dear David,

    Thanx for da reply. But I thought you got the first point "wrong". The
RDM field is for replay detection. It is protocol field that is set to 2.
Would it proper if when the client attache both rapid commit and
authentication options for solicit msg, then the server replied immedately
with a reply message with relevant options instead of ignoring any option?

rgds,
Punith.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 9 May 2007 14:29:00 -0700

> RDM field is for replay detection. It is protocol field that is set to 2.

Oops, s/RDM/protocol/

> with a reply message with relevant options instead of ignoring any option?

Where the protocol field is 2?  I would say it's not reference
behaviour.  I don't recall any normative language that says MUST or
MUST NOT in this case.  It's my estimation that a conservative
implementation would disable rapid-commit, or disable authentication.

The reference only describes sending the nonce in the Advertise, so
if it sends a Reply, that's not matching reference.