Subject: RE: [dhcwg] Response to IESG comments on draft-ietf-dhc-isnsoptio n-08.txt

From: Charles Monia <[email-masked]>
Date: Fri, 29 Aug 2003 14:18:12 -0700

See embedded response.

> -----Original Message-----
> From: Elizabeth G. Rodriguez [mailto:[email-masked]] 
> Sent: Friday, August 29, 2003 9:56 AM
> To: 'Charles Monia'; 'Ralph Droms'; 'Steven Bellovin'
> Cc: 'Thomas Narten (E-mail)'; 'DHCP (E-mail)'; 'Ips 
> (E-mail)'; 'David Black (E-mail)'; 'Allison Mankin (E-mail)'; 
> 'Joshua Tseng'; 'Kevin Gibbons'
> Subject: RE: [dhcwg] Response to IESG comments on 
> draft-ietf-dhc-isnsoption-08.txt
> 
> 
> Hi all,
> 
> I am struggling with the new wording here.
> I understand Ralph Droms' concerns, but not sure that this is 
> the right solution.  In addition, the current wording is 
> mandating use, something that in general we try to avoid in 
> IETF documents.
> 
> I have added Steve Bellovin to the distribution, and hope he 
> will comment on this proposed change -- he is the AD who 
> questioned making RFC 3118 optional.  If he is OK with the 
> proposed change to keep RFC 3118 optional, then I recommend 
> changes to the effect of:
> 
> 1) It is RECOMMENDED that RFC 3118 be implemented.  
> 
> 2) It is recommended that if RFC 3118 is available on both 
> the client and server, it be used.
> 
> Elizabeth Rodriguez
> 
> 

Here's the original text from rev 08:

===================================
[RFC3118] should be consulted to determine the requirements for
additional security measures to authenticate the iSNS option message
received by the DHCP client. If necessary, the authentication
option described in [RFC3118] should be utilized.

With regard to security considerations specific to the use of this
DHCP option for iSNS server discovery, exposure to a "man-in-themiddle"
attack by a hostile entity modifying or replacing the
original iSNS option message should be considered a potential
security exposure. If the authentication option in [RFC3118] is not
implemented, then an attacker may trick the iSNS client into
connecting into rogue iSNS servers.

If the authentication option for DHCP is not implemented and it is
determined that the potential exists for a "man-in-the-middle"
attack, then the DHCP option message for iSNS should not be
utilized.
======================

What's wrong with that?

Charles

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