RE: AD review of draft-ietf-dhc-isnsoption-05.txt

[Charles Monia <cmonia@NishanSystems.com>]

Hi Thomas:

The following are changes proposed in response to your review comments
raising non-editorial issues for the iSNS DHCP option.

> -----Original Message-----
> From: Thomas Narten [mailto:narten@us.ibm.com] 
> Sent: Tuesday, April 22, 2003 10:30 AM
> To: cmonia@nishansystems.com; jtseng@nishansystems.com; 
> kgibbons@nishansystems.com
> Cc: dhcwg@ietf.org
> Subject: AD review of draft-ietf-dhc-isnsoption-05.txt 
> 
> General issues:
> 
> I'd like to see a justification for the vendor specific fields. I'd
> like to understand how these can be safely used without leading to
> interoperability issues. Besides, there are other ways in DHC to do
> vendor-specific things. Can we just remove them from this
> option/document?
> 

The vendor-specific fields will be redefined as "reserved" fields.

<Material deleted>

> >      3.       Security Considerations
> > 
> >         DHCP currently provides no authentication or 
> security mechanisms.
> >         Potential exposures to attack are discussed in 
> section 7 of the DHCP
> >         protocol specification [DHCP].
> 
> What about RFC 3118?
> 
> 
> >         iSNS security considerations are discussed in 
> [iSNS] and [SEC-IPS].
> >         With regard to security considerations specific to 
> the use of this
> >         DHCP option to discover the location of the iSNS 
> server, exposure to
> >         a "man-in-the-middle" attack by an hostile entity 
> modifying or
> >         replacing the original iSNS option message should 
> be considered a
> >         potential security exposure.  To prevent an 
> attacker from weakening
> >         the required security and potentially tricking the 
> iSNS client into
> >         connecting into rogue iSNS servers, reliance on 
> local security
> >         policy configuration is an appropriate countermeasure.
> 
> This says almost nothing. What can happen if there is a  man-in-the
> middle? Really bad things? or just DOS? And what "local security
> policy configuration" helps mitigate the threats?
> 

We propose the following replacement text.

Section 3.0 -- Security

"[RFC3118] should be consulted to determine the requirements for additional
security measures to verify the authenticity of 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 to discover the
location of the iSNS server, exposure to a "man-in-the-middle" 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.

iSNS security considerations are discussed in [iSNS] and [SEC-IPS]."


-- Charles
-----------------------------------------
Charles Monia
Senior Technology Consultant
Nishan Systems
email: cmonia@nishansystems.com
voice: (408) 519-3986
fax:   (408) 435-8385