[Int-area] Re: [dhcwg] Discussion of subscriber authentication

[Ralph Droms <[e-mail]>]

Bernie (private reply) - how did you "reply" to my original message?  I'm
trying to keep the discussion on the int-area mailing list.  Did your reply
automatically include dhcwg or did you add it manually?

- Ralph


On 3/29/07 2:50 PM, "Bernie Volz (volz)" <[e-mail]> wrote:

> 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: [e-mail]
> 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 [e-mail] as a BCC to this note, to inform the dhc WG
> members that further discussion of subscriber authentication will move
> to
> [e-mail].  I've also included [e-mail] as a BCC, to
> make sure we have appropriate security clue in the discussion.
> 
> - Ralph
> 
> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg

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