Subject: Authentication draft

From: Ralph Droms <[email-masked]>
Date: Tue, 2 Nov 1999 09:28:06 -0500 (EST)

*Please* be sure to read and review carefully the current DHCP
authentication draft:

http://www.ietf.org/internet-drafts/draft-ietf-dhc-authentication-12.txt

If you have comments, bring them up on the mailing list as soon as
possible.  Bill and I would *very* much like to take the draft to last call
after the DC WG meeting.  At the last couple of meetings, we've received
last minute comments that have caused us to recycle the draft.  We'd like
to avoid that at all costs for this meeting.  Thanks...

- Ralph

---

From: Bernie Volz <[email-masked]>
Date: Tue, 2 Nov 1999 11:49:46 -0500 (EST)

Per Ralph's request, here are some comments on the 
http://www.ietf.org/internet-drafts/draft-ietf-dhc-authentication-12.txt.
Most of these are more editorial type issues.

1. [Minor] In section 5.1, "This protocol is focused [on] solving ...".

2. In section 5.2, can the sizes of the secret ID (32-bits) and HMAC-MD5
fields (256-bits I believe) be explicited specified? This also means that
the length for the options can be specified, since I believe they are
fixed.

3. In section 5.3, 'counter' is referenced. What is this? I assume it
should be 'Replay Detection'. Also, see counter references in 5.6.1.

4. In Appendix A, the key is generated using the "subnet address". Do you
mean the [proposed] address for the client or the SUBNET address (ie,
client's address ANDed with subnet mask).

5. In section 5.5.1, item 2, it references section 5.2. This should be
5.3.

6. [Minor References to other documents are somewhat inconsistent. Note
for example the references to the DHCP specification in section 5.5.2
and 5.5.3.

7. In sections 5.6.2, .3 there are references to section 4.1 and 4.2.
There are no corresponding sections in the draft.

- Bernie Volz
  Process Software

---

From: "William A. Arbaugh" <[email-masked]>
Date: Mon, 8 Nov 1999 21:29:50 -0500 (EST)

> Most of these are more editorial type issues.
	I will make the appropriate changes.

> client's address ANDed with subnet mask).
I didn't write this part of the draft, but I read it to mean the IP subnet
address, e.g. 192.168.1.0.  In my opinion, this is problematic. It may be
that we can get by with just the client identifier.  We can talk about
tomorrow in the meeting.

Bill