Subject: WG last call for "Authentication for DHCP Messages"

From: Ralph Droms <[email-masked]>
Date: Tue, 13 Jun 2000 23:19:14 -0400

This message announces a DHC WG last call for "Authentication for DHCP 
Messages", <draft-ietf-dhc-authentication-13.txt>.  The WG discussed the 
previous revision in Adelaide and agreed to go to WG last call after some 
editorial changes, which have been incorporated into this latest revision 
of the spec:

* edited "Discussion" in section 1 to eliminate references to expired
   Internet Drafts
* exchanged RDM and Algorithm fields
* fixed RDM values - 0x00 is counter method (as defined in draft); all
   other values are "reserved"
* edited first sentence of 5.1 to clarify that protocol 1 is aimed at
   intradomain authentication and other protocols may address
   interdomain authentication
* changed the two header diagrams in 5.2 to show "Algorithm" field
   (allowing for multiple algorithms) rather than specifying "00000000"
   (which didn't match with the specification that HMAC-MD5 use
   "0x01").
* Edited first sentence of 5.3 to refer more generally to the
   specified RDM, rather than explicitly desribing the use of RDM 1.
* Also edited 5.3 to allow for different algorithms.
* Edited section 6 to describe definition of new protocol. algorithm
   or RDM.

Please forward any comments you may have on this draft to 
[email-masked] by Friday, June 23.

- Ralph Droms

---

From: Richard Jones <[email-masked]>
Date: Wed, 21 Jun 2000 09:45:29 -0700

Some questions about the draft:

In the first format diagram (Section 2) there are two fields labelled
'Algorithm'. Should the second one be RDM, or do I misunderstand?

The last paragraph of Section 5.2 (Format) states that the authentication
request can only appear in a DHCPDISCOVER message, while section
5.5.5 (DHCPINFORM) suggests that the client SHOULD use the request
in that message type. I'm fine with using it in both messages, but
wonder if the wording of section 5.2 should be changed to avoid
confusion.

In the second paragraph of Section 5.6.4, the implication seems to be
that if a server doesn't have a shared secret value with a client sending
a DHCPINFORM with authentication request, it needs to either ACK or
NAK the message. But ignoring the message seems like a valid option
too. Perhaps this is too obvious, but I thought it would be good for
the sake of clarity to state it.

Editorial stuff:

Section 5, sentence 2, you might want to remove the second 'information'.
Section 5.3, sentence 2, should start "Next the receiver..."?

Thanks,
Richard

---

From: "Bernard D. Aboba" <[email-masked]>
Date: Wed, 21 Jun 2000 16:42:09 -0800 (GMT-0800)

I have some general comments on the draft. 

The Key Management Technique presented in Appendix A results
in all DHCP clients knowing the master key (MK). Thus any
DHCP client can impersonate any other DHCP client. I do not
feel that this technique provides much protection other than
avoidance of accidentally configured rogue DHCP servers. 

Having encountered other standards (e.g. 802.11 WEP) that
used this global key model, I have to say that it is quite
unwieldy to deploy. For example, if any DHCP client were
to be compromised, all clients would need to obtain a new
master key. No mechanism is described in the draft for how
this would be accomplished. 

Even assuming that the technique in Appendix A is not used, I have
difficulty imagining the deployment model for the 
authentication techniques described in this draft. 
For example, while it is conceivable that a DHCP server
might locally hold a list of client identifiers and
corresponding shared secrets, for an organization with
many DHCP servers, this would be awkward. As a result,
a more likely model would be that a centralized 
authentication server would be used. 

However, since the draft requires the DHCP server to
sign and verify DHCP messages, if the DHCP server does
not have access to cleartext secrets, it will typically be 
necessary to ship a received DHCP packet off to the authentication
server for verification. In addition, the proposed
response would need to be composed and sent off to the
authentication server as well, so that the authentication
server could compute the MAC. This requires the authentication
server to have knowledge of DHCP, which is typically not the
case. 

A similar approach was taken with Mobile IP (RFC 2002), and
failed to garner significant deployment. As a result,  
challenge-response approach is now being proposed, which
does not require a centralized authentication server to
have knowledge of Mobile IP. I recommend that the DHC
WG consider addition of a technique that works along
the same lines.

---

From: "William A. Arbaugh" <[email-masked]>
Date: Thu, 22 Jun 2000 13:36:55 -0400 (EDT)

> 'Algorithm'. Should the second one be RDM, or do I misunderstand?
The second one should be RDM.

> wonder if the wording of section 5.2 should be changed to avoid
Agreed.

> the sake of clarity to state it.
Fine with me- although I usually like to have some kind of feedback.

> Section 5.3, sentence 2, should start "Next the receiver..."?
Thanks.

Thanks for the good comments and thorough review!

Bill

---

From: "William A. Arbaugh" <[email-masked]>
Date: Thu, 22 Jun 2000 14:25:34 -0400 (EDT)

> avoidance of accidentally configured rogue DHCP servers. 
I don't agree.  Each client is given K, where K = HMAC(MK,
client_id). Provided that the size of MK is at least one half of the hash
functions size, then the strength of the system relies on the either brute
force on MK, or a birthday attack on the hash function.  Provided
|MK|>=|H()|/2, the best an attacker can do is 2**|H()|. With SHA1 at
160bits and MD5 at 128bits, that gives a strength of 2**80 for SHA1 and
2**64 for MD5.

To summarize:

If I've missed something, please let me know.

> this would be accomplished. 
Agreed. Effective key management is always a pain in the tush.

....

> WG consider addition of a technique that works along
Please remember that the goal of the draft was to create a template that
could be used to define any number of authentication
approaches (without changing the underlying DHCP protocol), and I think we
have achieved that since there are PKI and Kerberos approaches proposed
using the draft. Can the Mobile IP approach be specified in a new draft?

Bill

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 23 Jun 2000 10:34:19 -0400

>Agreed. Effective key management is always a pain in the tush.

The key management schema described is weak at least, I think you MUST
put in a sentence that says that the Master Key MUST never be stored on
clients. Clients MUST only be given their K.
IF this is not made clear in the draft I'm sure someone will implement
a client requiring MK.
As far as I can tell the whole point of this schema is to allow the
server to calculate the keys on the fly when it sees a new client.
I think this motivation should also be stated more clearly.

I think the section should also contain a warning that if MK is
compromised all clients must be re keyed.

Hopefully someone will propose soon a dynamic key management system for
DHCP.

         Olafur

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 23 Jun 2000 10:36:08 -0400

> clients. Clients MUST only be given their K.

The fact that the client key is a function of the MK is completely
invisible to the client and wire protocol; it falls into the realm of
"implementation defined behavior" and should be documented as such in
the draft.

An interoperable server could store a separately generated key for
each client and the clients couldn't tell the difference based on
externally visible behavior.

					- Bill

---

From: "Barr Hibbs" <[email-masked]>
Date: Fri, 23 Jun 2000 15:23:54 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Ralph Droms
> Sent: Tuesday, June 13, 2000 8:19 PM

> Messages", <draft-ietf-dhc-authentication-13.txt>.

> [email-masked] by Friday, June 23.

...the draft can go forward with the editorial changes made by Bill in
response to the other comments from Bernard and Richard....  it will be good
to get this one finished!!

--Barr

---

From: [email-masked]
Date: Sat, 24 Jun 2000 09:30:24 -0700

>Each client is given K, where K = HMAC(MK, client_id). 

OK. So the master key is only known to the DHCP server, right? 
This makes more sense. This enables the DHCP server to 
calculate and verify the hashes without external help. 
However, it does mean that if the client_id is changed
(say if a new NIC is used), that the client will need
to get a new key.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 26 Jun 2000 21:52:16 -0400

OK, based on comments received during the WG last call, I will make the 
following changes to the "Authentication for DHCP Messages" prior to 
submission for PS:

* In the first diagram in section 2, change the second
   occurrence of 'Algorithm' to 'RDM'

* Add text to section 5.2 indicating that an
   authentication request can appear in either a
   DHCPDISCOVER or a DHCPINFORM message

* In section 5.6.4, add text allowing a server to
   ignore an authenticated DHCPINFORM message that
   the server cannot validate as well as replying
   with a DHCPNAK

* Section 5, second sentence: remove second
   instance of 'information'

* Section 5.3, second sentence: change to
   start with "Next, the receiver..."

* Add text to Appendix A:

   To avoid compromise of this key management system, the master
   key, MK, MUST NOT be stored in the client.  The client SHOULD
   only be given its key, K.  If MK is compromised, a new MK
   must be chosen and all clients given new individual keys.

- Ralph

---

From: [email-masked] (Greg Rabil)
Date: Wed, 28 Jun 2000 16:05:01 -0400

I'd be interested in other folks that have implemented support for 
draft-ietf-dhc-dhcp-dns-11/12 in their servers.  Particularly, I'm
trying to determine the proper value to be set in the 'flags' field
when the server is allowing the client to do the A RR update, and
it (the server) is going to do the PTR RR update.  I'm interested in
what others have done in this case.  It seems a bit unclear to me.
The only relavent text I can find is the following at the end of
paragraph 4 in Section 7 of the -12 draft:

   In either case, if the server intends to
   perform the DNS update and the client's REQUEST message included the
   FQDN option, the server SHOULD include the FQDN option in its ACK
   message, and MUST set the "S" bit in the option's Flags field.

OK, but this paragraph is in the context of the server doing the A RR
update.  My question is what should be set if the server is "honoring"
the client (W2K's default) request that the client do the A, and the
server does the PTR.

I assumed that the flags field in this case would
look as follows (ignoring the DNS-encoding):

00000010

This, hopefully, indicating that yes, I (the server) will do the PTR RR
update as indicated by the 1 in the 'O' bit.  And leave the 'S' bit clear,
again hopefully, indicating the I've honored the client's request, so I
think it should perform the A RR update.

Microsoft's documentation for W2K (the only client I'm aware of that has
implemented this draft) mentions only values of 1(00000001) and 3(00000011)
for 'flags'.

Ideas, comments?

Thanks,
Greg