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

["Julien Bournelle" <[e-mail]>]

Hi,

On 3/29/07, John Schnizlein <[e-mail]> wrote:
> 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.

 right, I don't think we should overload DHCP with subscriber authentication.

 My 2 cents,

 Julien


>
> 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
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/int-area
>

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