Subject: RE: [Int-area] RE: [dhcwg] Discussion of subscriber authentication

From: "Alper Yegin" <[email-masked]>
Date: Wed, 2 May 2007 04:36:34 +0300

Bernie,

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

Why do you think we should "kick start DHCP authentication?"

If people know some smart way to use existing IETF protocols to solve
whatever problems there are, so be it. But if IETF is asked to do additional
work, first we need to understand the nature of the problem and agree that
there is no existing solution. 

I don't understand why we are jumping ahead here....

Alper

> 
> - Bernie
> 
> -----Original Message-----
> From: Ralph Droms (rdroms)
> Sent: Thursday, March 29, 2007 1:47 PM
> To: [email-masked]
> 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-masked] as a BCC to this note, to inform the dhc WG
> members that further discussion of subscriber authentication will move
> to
> [email-masked].  I've also included [email-masked] as a BCC, to
> make sure we have appropriate security clue in the discussion.
> 
> - Ralph
> 
> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/int-area

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

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 1 May 2007 23:43:01 -0400

The RFC 3118 authentication methods are not things that people really
want. One is completely insecure and the other requires key
distributions. If we used username/passwords, we solve the key
distribution problem -- the keys are the password.

- Bernie 

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Tuesday, May 01, 2007 9:37 PM
To: Bernie Volz (volz); Ralph Droms (rdroms); [email-masked];
'DHC WG'
Subject: RE: [Int-area] RE: [dhcwg] Discussion of subscriber
authentication

Bernie,

If people know some smart way to use existing IETF protocols to solve
whatever problems there are, so be it. But if IETF is asked to do
additional
work, first we need to understand the nature of the problem and agree
that
there is no existing solution. 

Alper

---

From: Richard Pruss <[email-masked]>
Date: Wed, 02 May 2007 19:17:30 +1000

Alan DeKok wrote:
> Bernie Volz (volz) wrote:
>   
>> Isn't this discussion a bit late given that RFC 3118 exists and RFC 3315
>> contains Authentication?
>>     
> ...
>   
>> 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?
>>     
>
>   Quite a bit.  RFC 3118 is about protecting the DHCP protocol.  This
> proposal is about using DHCP as a transport mechanism for user
> authentication protocols.  Both systems could be deployed
> (theoretically), as they are independent of one another.
>
>   
>> 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.
>>     
The second option in the draft allows server to be authenticated.
>
>   Exposing the password via a CHAP request?
>   
>   
>> 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 you can't control network access via DHCP, I don't see why we
> should even be trying.
>   
It is common practice to control network access to via DHCP, source 
address verification in first hop switches and ARP table protections are 
based on snooping DHCP.
>   If user authentication traffic is carried over DHCP, I would say that
> RFC 3118 support would be required *first*.  Otherwise, user
> authentication traffic would be carried over an insecure network layer. 

For CHAP there is no difference from current PPPoE

For EAP rfc3748;
"

 [3] Lower layer security.  EAP does not require lower layers to
       provide security services such as per-packet confidentiality, 
authentication, integrity, and replay protection.

"

-Ric
>   Alan DeKok.

---

From: Richard Pruss <[email-masked]>
Date: Fri, 04 May 2007 13:20:15 +1000

Alan DeKok wrote:
> Richard Pruss wrote:
>   To "try" to control network access.  As was pointed out in the
> referenced article:
> 
> ... a theme for the DHCP community pretty much since day one, is that
> you *can't* control access to the network using the DHCP protocol.
> 
>   As for what is common practice, it is common practice to try to design
> good solutions when existing common practices demonstrate their
> shortcomings.
No Allan, we are not "try"ing to control network access, we do control 
network access based on DHCP on all Cisco switches.

IP source guard  - for upstream traffic
Initially, all IP traffic on the port is blocked except for DHCP packets 
that are captured by the DHCP snooping process. When a client receives a 
valid IP address from the DHCP server, or when a static IP source 
binding is configured by the user, a per-port and VLAN Access Control 
List (PVACL) is installed on the port. This process restricts the client 
IP traffic to those source IP addresses configured in the binding; any 
IP traffic with a source IP address other than that in the IP source 
binding will be filtered out. This filtering limits a host's ability to 
attack the network by claiming a neighbor host's IP address.

You can read more about source guard on the Cisco web site or if you 
want to catch up a little about what the security messure commonly 
deployed on layer 2 networks you can have a look at the SAFE blueprint:
http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/networking_solutions_white_paper09186a008014870f.shtml

Regards,
Ric

---

From: Alan DeKok <[email-masked]>
Date: Wed, 02 May 2007 15:37:17 +0200

Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 May 2007 08:21:41 +0200

ContentFrom [email-masked] Wed May 09 08:28:56 2007
Date: Wed, 02 May 2007 15:37:17 +0200
From: Alan DeKok <[email-masked]>
To: [email-masked]
Subject: Re: [Int-area] RE: [dhcwg] Discussion of subscriber authentication
Cc: DHC WG <[email-masked]>, "Bernie Volz \(volz\)" <[email-masked]>,
	[email-masked]

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 May 2007 08:21:41 +0200

Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 May 2007 08:21:41 +0200

> network access based on DHCP on all Cisco switches.

  Forgive me for quoting people who know more about DHCP than I do.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 02 May 2007 07:13:41 +0200

...

> client/server authentication communication and not mentio-Type: text/plain; charset=ISO-8859-1

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 02 May 2007 07:13:41 +0200

...

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 02 May 2007 07:13:41 +0200

...

  Alan DeKok.

n how other

  Alan DeKok.

n how other

  Alan DeKok.