Re: [dhcwg] Discussion of subscriber authentication

[John Schnizlein <[e-mail]>]

The authentication in RFC 3118 (for DHCPv4) and RFC 3315 (for DHCPv6)  
is message authentication, not subscriber authentication.

Message authentication is all about ensuring that the contents are  
not fake, assuming that there is enough shared trust between client  
and server host computers.  The shared trust also serves to control  
authorization to exchange DHCP messages.

Subscriber authentication is about the user of network access, and  
the user is often the person who has credentials rather than the  
host, although storing user credentials on the host happens.

The point of section 2.5 of draft-aboba-ip-config-00.txt is that  
these are different:

   2.5.  Configuration is Not Access Control

    Network access authentication is a distinct problem from Internet
    host configuration.

John

On Mar 29, 2007, at 2:50 PM, Bernie Volz ((volz)) 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
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg

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