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

From: Charles Monia <[email-masked]>
Date: Fri, 5 Sep 2003 14:01:07 -0700

Hi:

In response to the security issues, the following change to the security
section is proposed.  Please let me know if this is satisfactory. 

=====================
Security:

Security considerations pertinent to DHCP are described in [RFC3118].  Among
these is the potential for a "man-in-the-middle" attack by a hostile entity
modifying or replacing the original iSNS option message. If the
authentication option in [RFC3118] is not implemented, then an attacker may
trick the iSNS client into connecting into rogue iSNS servers.

It is therefore RECOMMENDED that [RFC3118] be implemented and used on the
client and server.  If the authentication option for DHCP is not implemented
and it is determined that the potential exists for one of the attacks
described in [RFC3118], then the DHCP option message for iSNS should not be
utilized.

======================

Thanks,
Charles Monia

> -----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
> 
> 
> -----Original Message-----
> From: Charles Monia [mailto:[email-masked]] 
> Sent: Thursday, August 28, 2003 4:31 PM
> To: 'Ralph Droms'; Charles Monia
> Cc: Thomas Narten (E-mail); DHCP (E-mail); Ips (E-mail); 
> David Black (E-mail); Elizabeth Rodriguez (E-mail); Allison 
> Mankin (E-mail); Charles Monia; Joshua Tseng; Kevin Gibbons
> Subject: RE: [dhcwg] Response to IESG comments on 
> draft-ietf-dhc-isnsoption-08.txt
> 
> Hi:
> 
> I have incorporated Ralph's suggestion in revision 9 of the 
> spec,  along with changes to reflect the other IESG comments. 
>  This new version has been submitted to the IETF archive.
> 
> Pending the announcement of document availability from the 
> archive, the spec can be obtained from 
> ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption
> -09.pdf or 
> ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption-09.txt.
> 
> Markups visible in the PDF version show the text that was 
> added or deleted.
> 
> Charles
> > -----Original Message-----
> > From: Ralph Droms [mailto:[email-masked]]
> > Sent: Wednesday, August 27, 2003 3:09 AM
> > To: Charles Monia
> > Cc: Thomas Narten (E-mail); DHCP (E-mail); Ips (E-mail); 
> > David Black (E-mail); Elizabeth Rodriguez (E-mail); Allison 
> > Mankin (E-mail); Charles Monia; Joshua Tseng; Kevin Gibbons
> > Subject: Re: [dhcwg] Response to IESG comments on 
> > draft-ietf-dhc-isnsoption-08.txt
> > 
> > 
> > Note that, because there are no implementations of RFC 3118
> > today, and no 
> > plans by any important vendors to implement RFC 3118 in the 
> > future, making 
> > RFC 3118 authentication mandatory will effectively disallo 
> > any use of this 
> > option.
> > 
> > Perhaps we can modify this requirement to something like "use
> > of RFC 3118 
> > is mandatory if it is available in the client and server".
> > 
> > - Ralph
> > 
> > At 03:37 PM 8/19/2003 -0700, Charles Monia wrote:
> > 
> > > > "Steven M. Bellovin" <[email-masked]> writes:
> > >
> > > > Is 3118 mandatory-to-implement or not?  I have a hard time
> > > > understanding why it should be optional.
> > >
> > >We will revise the spec to make implementation of RFC 3118 
> mandatory.
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > dhcwg mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> > 
> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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

---

From: [email-masked]
Date: Fri, 5 Sep 2003 17:25:29 -0400

At the risk of complicating this further, I don't think "RECOMMENDED"
is going to be the right solution, as "cannot obtain an implementation"
does not strike me as a "valid reason in particular circumstances"
(cf. RFC 2119) to ignore a "RECOMMENDED" requirement statement.

I think the right thing to do here is to address Ralph's concern directly
rather than trying to craft language that avoids it.  In other words,
discuss the usefulness of DHCP Authentication, but point out that it is
not widely implemented, recommend its use  when available (lower case
"recommended"), and discuss alternative measures that can prevent contact
with a rogue iSNS server (e.g., in addition to not using the iSNS DHCP
option, IPsec can provide countermeasures based on setting policy for
traffic to the TCP port used by iSNS, but one has to have local policy
override the IPsec on/off setting in the iSNS DHCP option).

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Charles Monia <[email-masked]>
Date: Wed, 10 Sep 2003 11:58:09 -0700

Hi All:

Another cut at the security section to address David Black's concerns.

=====================
Security:

DHCP security considerations are addressed in [RFC3118].  Among these is the
potential for a "man-in-the-middle" attack by a hostile entity modifying or
replacing the original iSNS option message. Unless some form of
authentication is implemented, an attacker may trick the iSNS client into
connecting into rogue iSNS servers.

To thwart such attacks, the DHCP response should be verified in some manner.
One approach is direct authentication via [RFC3118], when implemented.
Since this technology is not widely deployed, an alternative is to
authenticate the discovered iSNS server through use of IPSec or the iSNS
authentication block as described in [ISNS]. Of course, use of iSNS Server
authentication implies a site-wide policy requiring use of one of the
authentication methods specified in [ISNS] by all iSNS servers.

If no authentication is used and it is determined that the potential exists
for one of the attacks described in [RFC3118], then the DHCP option message
for iSNS should not be utilized.

======================

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, September 05, 2003 2:25 PM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> draft-ietf-dhc-isnsoptio n-08.txt
> 
> 
> is going to be the right solution, as "cannot obtain an 
> implementation" does not strike me as a "valid reason in particular 
> circumstances" (cf. RFC 2119) to ignore a "RECOMMENDED" requirement 
> statement.
> 
> I think the right thing to do here is to address Ralph's concern 
> directly rather than trying to craft language that avoids it.  In 
> other words, discuss the usefulness of DHCP Authentication, but point 
> out that it is not widely implemented, recommend its use  when 
> available (lower case "recommended"), and discuss alternative measures 
> that can prevent contact with a rogue iSNS server (e.g., in addition
> to not using the iSNS DHCP option, IPsec can provide 
> countermeasures based on setting policy for traffic to the 
> TCP port used by iSNS, but one has to have local policy 

<stuff Deleted>

Thanks,
-- Charles
-----------------------------------------
Charles Monia
Senior Technology Consultant
Nishan Systems
email: [email-masked]
voice: (408) 519-3986
fax:   (408) 435-8385