Ralph:

Isn't this discussion a bit late given that RFC 3118 exists and RFC 3315
contains Authentication?

RFC 3118 abstract reads:

   This document defines a new Dynamic Host Configuration Protocol
   (DHCP) option through which authorization tickets can be easily
   generated and newly attached hosts with proper authorization can be
   automatically configured from an authenticated DHCP server.  DHCP
   provides a framework for passing configuration information to hosts
   on a TCP/IP network.  In some situations, network administrators may
   wish to constrain the allocation of addresses to authorized hosts.
   Additionally, some network administrators may wish to provide for
   authentication of the source and contents of DHCP messages.

Other than the data used to authenticate (which in this case is a
username and password, instead of a shared secret), what really is the
difference? I guess it all depends on what "authorized" hosts means.

RFC 3118 does have issues as it is difficult to handle client
authentication without exposing the client's identity (since there's no
good way to "delay" the authentication) -- this is discussed in
draft-ietf-dhc-v4-threat-analysis-03.txt, section 5.

One additional flaw with Rick draft's is that there's no provision to
authenticate the server -- which means that if a client doing this is
mobile and attaches to other networks, it may expose the username and
password.

I think Ted Lemon's point that Ric's draft should stick to the DHC
client/server authentication communication and not mention how other
network elements may use the end result of the DHCP exchange (i.e., the
"authorization" to use the network). See
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg07138.html.

If we could work this out within the RFC 3118 framework, it certainly
would kick start DHCP authentication.

- Bernie

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Thursday, March 29, 2007 1:47 PM
To: [email protected]
Subject: [dhcwg] Discussion of subscriber authentication

At the dhc WG meeting in Prague, there was a discussion of "subscriber
authentication" and how that function might be provided through DHCP.
Ric
Pruss gave a presentation about a proposal for subscriber authentication
through DHCP:

http://www3.ietf.org/proceedings/07mar/slides/dhc-2.pdf
http://www.ietf.org/internet-drafts/draft-pruss-dhcp-auth-dsl-00.txt

There is a related draft that was not discussed at the dhc WG meeting:

http://www.ietf.org/internet-drafts/draft-zhao-dhc-user-authentication-0
1.tx
t

There was also a discussion of "Principles of Internet Host
Configuration".
Dave Thaler gave a presentation about the draft he co-authored with
Bernard
Aboba:

http://www3.ietf.org/proceedings/07mar/slides/dhc-7.pdf
http://www.ietf.org/internet-drafts/draft-aboba-ip-config-00.txt

During the discussion of subscriber authentication, it was noted that
the
proposed solutions assume that DHCP is the right vehicle through which
subscriber authentication should take place.  That assumption needs to
be
further examined; PANA, for example, provides an alternative solution
which
does not depend on DHCP.  Before the IETF proceeds with a DHCP-based
solution, we need to discuss the broader issue of where subscriber
authentication should be implemented.

Accordingly, the Internet Area directors and the WG chairs have decided
to
move the discussion of subscriber authentication to the int-area mailing
list.  This discussion will explore the subscriber authentication
problem
space and requirements, to come to some initial consensus about where a
solution might belong.

To kick off the discussion, we are trying to get permission to publish
subscriber authentication requirements from the DSL Forum.

I've included [EMAIL PROTECTED] as a BCC to this note, to inform the dhc WG
members that further discussion of subscriber authentication will move
to
[EMAIL PROTECTED]  I've also included [EMAIL PROTECTED] as a BCC, to
make sure we have appropriate security clue in the discussion.

- Ralph




_______________________________________________
dhcwg mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area

Reply via email to