RE: [dhcwg] WG last call on draft-ietf-dhc-relay-agent-auth-00

Ralph,

I generally support this document. But here are some specific comments on
the current draft.

- The Abstract should refer to IPsec per RFC 2401, not RFC 2041. Also,
shouldn't RFC 2401 be included as a normative reference?
- Section 5 explains the use of IPsec ESP. It would seems that a normative
reference to RFC 2406, "IP Encapsulating Security Payload (ESP)", would be
in order. That means that this draft's requirement that "Packet
authentication MUST be applied" implies a requirement to support "HMAC with
MD5" and "HMAC with SHA-1" per section 5 of RFC 2406. Is that intended?
- Some updates may be needed in the "Authors' Addresses" section. ;^)
- This might not be a critical flaw, but... only the HMAC-MD5 algorithm is
defined for the Relay Agent Option Authentication Sub-option. I notice that
in several other IETF contexts (IPsec AH, RFC 2402; IPsec ESP, RFC 2406;
SNMPv3 USM, RFC 3414; TLS, RFC 2246), the HMAC-SHA1 keyed hash is also
leveraged. The following text from RFC 2104 may help explain why:

   Note: To the date of writing of this document MD5 and SHA-1 are the
   most widely used cryptographic hash functions. MD5 has been recently
   shown to be vulnerable to collision search attacks [Dobb].  This
   attack and other currently known weaknesses of MD5 do not compromise
   the use of MD5 within HMAC as specified in this document (see
   [Dobb]); however, SHA-1 appears to be a cryptographically stronger
   function. To this date, MD5 can be considered for use in HMAC for
   applications where the superior performance of MD5 is critical.

Note that RFC 2747, "RSVP Cryptographic Authentication", is a good
counter-example in that it only defines HMAC-MD5 for the INTEGRITY object,
but explains its rationale in section 1 if its RFC. Another counter-example
is RFC 2845, "Secret Key Transaction Authentication for DNS (TSIG)" -- but
also see
<http://www.ietf.org/internet-drafts/draft-eastlake-tsig-sha-01.txt>.

-- Rich

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, April 30, 2003 12:03 PM
To: dhcwg@ietf.org
Subject: [dhcwg] WG last call on draft-ietf-dhc-relay-agent-auth-00

This message announces a WG last call on "The Authentication
Suboption for the DHCP Relay Agent Option"
<draft-ietf-dhc-relay-agent-auth-00>.  The last call
will conclude on Friday, May 16.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.

This specification defines two mechanisms for securing the messages
exchanged between a relay agent and a server.  The first mechanism
defines a new authentication suboption for the Relay Agent
Information Option that supports source entity authentication and
data integrity for relayed DHCP messages.  The authentication
suboption contains a cryptographic signature in a payload derived
from the option used in DHCP Authentication (RFC 3118).  The second
mechanism uses IPsec (RFC 2041) to protect messages exchanged between
relay agents and servers.  This document is being considered for
publication as Informational, and is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-agent-auth-00.txt

- Ralph Droms 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg