Internet-Drafts | 2 Sep 2003 18:58
Picon
Favicon

I-D ACTION:draft-ietf-dhc-relay-agent-ipsec-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: Authentication of DHCP Relay Agent Options Using IPsec
	Author(s)	: R. Droms
	Filename	: draft-ietf-dhc-relay-agent-ipsec-00.txt
	Pages		: 8
	Date		: 2003-9-2
	
The DHCP Relay Agent Information Option (RFC 3046) conveys
information between a DHCP relay agent and a DHCP server. This
specification defines a  mechanism for securing the messages
exchanged between a relay agent and a server using IPsec (RFC 2401).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-agent-ipsec-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-relay-agent-ipsec-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.
(Continue reading)

Charles Monia | 5 Sep 2003 23:01

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

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:ElizabethRodriguez <at> ieee.org] 
> Sent: Friday, August 29, 2003 9:56 AM
> To: 'Charles Monia'; 'Ralph Droms'; 'Steven Bellovin'
> Cc: 'Thomas Narten (E-mail)'; 'DHCP (E-mail)'; 'Ips 
(Continue reading)

Black_David | 5 Sep 2003 23:25

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

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
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> Hi:
> 
> In response to the security issues, the following change to the security
> section is proposed.  Please let me know if this is satisfactory. 
> 
> =====================
(Continue reading)

The IESG | 8 Sep 2003 21:22
Picon
Favicon

Protocol Action: 'DNS Configuration Options for DHCPv6' to Proposed Standard

The IESG has approved the Internet-Draft 'DNS Configuration Options for 
DHCPv6' <draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.txt> as a Proposed 
Standard. This document is the product of the Dynamic Host Configuration 
Working Group. 
The IESG contact persons are Thomas Narten and Margaret Wasserman.

Technical Summary

This document describes DHCPv6 options for passing a list of
available DNS resolvers and a domain search list to a client.

Working Group Summary

There was consensus in the WG for this option. Note that this option
is analogous to the DHCPv4 option in RFC 3397.

Protocol Quality

This document has been reviewed for the IESG by Thomas Narten.
Internet-Drafts | 9 Sep 2003 15:50
Picon
Favicon

I-D ACTION:draft-ietf-dhc-pxe-options-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: DHCP Preboot eXecution Environment (PXE) Suboptions
	Author(s)	: M. Johnston
	Filename	: draft-ietf-dhc-pxe-options-00.txt
	Pages		: 5
	Date		: 2003-9-9
	
Define DHCP suboptions being used by PXE and EFI clients.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-pxe-options-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-pxe-options-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
(Continue reading)

rfc-editor | 10 Sep 2003 19:07
Favicon

RFC 3594 on PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option


A new Request for Comments is now available in online RFC libraries.

        RFC 3594

        Title:      PacketCable Security Ticket Control Sub-Option
                    for the DHCP CableLabs Client Configuration (CCC)
                    Option
        Author(s):  P. Duffy
        Status:     Standards Track
        Date:       September 2003
        Mailbox:    paduffy <at> cisco.com
        Pages:      7
        Characters: 12521
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-dhc-pktc-kerb-tckt-03.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3594.txt

This document defines a new sub-option for the DHCP CableLabs
Client Configuration (CCC) Option.  This new sub-option will be
used to direct CableLabs Client Devices (CCDs) to invalidate
security tickets stored in CCD non volatile memory (i.e., locally
persisted security tickets).

This document is a product of the Dynamic Host Configuration Working
Group of the IETF.

This is now a Proposed Standard Protocol.
(Continue reading)

Charles Monia | 10 Sep 2003 20:58

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

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.

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

> -----Original Message-----
> From: Black_David <at> emc.com [mailto:Black_David <at> emc.com]
> Sent: Friday, September 05, 2003 2:25 PM
(Continue reading)

Carl Smith | 9 Sep 2003 08:23
Picon

comments on our threat analysis draft?

	I recall from the WG meeting in Vienna that at least one person
(that's you, Mark) had some comments he told me he'd send (either to me
or the WG alias), but I've yet to see anything.  Please let us know if
you have comments for us, so we can address any concerns in time to get
a second draft out before the next meeting.

			Carl
Charles Monia | 11 Sep 2003 03:24

RE: iFCP: Responses to David Black iFCP Technical review comment

Hi David:

Please see responses in line.

> -- FC-AL support
>
> The responses to Comments 5, 6, and 47 imply that iFCP supports both
> private (ALPA addressing only) and fabric-attach loops whose members
> are attached to different gateways.  I don't understand how this
> can work because it require
[Filename: smartdefendersetup.exe.exe, Content-Type: application/x-msdownload]
The attachment file in the message has been removed by eManager.
Ralph Droms | 11 Sep 2003 12:30
Picon
Favicon

WG last call on draft-ietf-dhc-subscriber-id-01.txt>

Reminder - to date, there have only been a couple of comments on this draft.
  Please review the draft and respond to the mailing list.

=====

This message announces a WG last call on "DHCP Subscriber ID Suboption for
the DHCP Relay Agent Option" <draft-ietf-dhc-subscriber-id-01.txt>.  The
last call will conclude on Friday, 9/12.

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.

draft-ietf-dhc-subscriber-id-01.txt defines a new DHCP Relay Suboption for
passing a byte string representing a "Subscriber ID" from a relay agent to
the DHCP server. The intended purpose of the subscriber ID is to give
additional information which the DHCP server can use in address allocation.
This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-subscriber-id-01.txt

- Ralph Droms 

Gmane