Subject: [dhcwg] [New I-D] DHCP User-based Authentication

From: Amy Zhao <[email-masked]>
Date: Sun, 08 Oct 2006 11:07:17 +0800

Hi, All:

We posted a new I-D as follows.  

It's a pretty rough draft  and we need your feedback.

 Any comments / advices will be highly appreciated!

Thanks!

B.R.
Amy 

------------------------------

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: DHCP User-based Authentication
	Author(s)	: Y. Zhao
	Filename	: draft-zhao-dhc-user-authentication-00.txt
	Pages		: 24
	Date		: 2006-10-2
	
This document defines an authentication mechanism to provide an
authentication for a user in an access network by means of dhcp.  The
authentication mechanism described here couples DHCP to an
authentication, authorization and accounting system (AAA), thus
enabling users to supply user credentials for AAA via DHCP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zhao-dhc-user-authentication-00.tx
t

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-zhao-dhc-user-authentication-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-zhao-dhc-user-authentication-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
-------------- next part --------------
Skipped content of type multipart/alternative

------------------------------

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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Oct 2006 08:26:45 +0200

I have the following three questions:

   1. Why is DHCP the correct protocol to do user-based authentication?
   2. How would this work interact with RFC 3118 (as mentioned by Andre
      Kostur)?
   3. At this late date it seems wise to at least address the issue of
      the authentication server proving itself to the connecting
      device.  This seems to me to change the nature of risk with regard
      to who is giving up information.  What in your proposal is to
      prevent a rogue DHCP server from snarfing passwords?

Thanks,

Eliot

---

From: Amy Zhao <[email-masked]>
Date: Thu, 12 Oct 2006 11:27:24 +0800

Hello,Eliot!
     Thank for your comments. 
     Please see in line.

Thanks!

B.R.
Amy 

> -----Original Message-----
> From: Eliot Lear [mailto:[email-masked]] 
> Sent: Wednesday, October 11, 2006 2:27 PM
> To: Amy Zhao
> Cc: [email-masked]
> Subject: Re: [dhcwg] [New I-D] DHCP User-based Authentication
> 

If we want to use DHCP for configuring clients accessing the Internet
through some form of high-speed access technology such as cable or ADSL, we
need a coupling between AAA and DHCP.

>    2. How would this work interact with RFC 3118 (as 

You and Andre both mention this issue. To tell the truth, I really missed
it. but until now, I think the two options are seperate. Maybe I miss some
issues. 

>       prevent a rogue DHCP server from snarfing passwords?
Sorry, I could not catch your mean.Do you mean to add some context in the
draft?

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Oct 2006 10:22:28 +0200

> need a coupling between AAA and DHCP.

What resource is DHCP protecting, and is it effective at protecting that
resource?

> it. but until now, I think the two options are seperate. Maybe I miss some

Fundamentally the issue is this: what is to prevent a rogue DHCP server
from snarfing a client password?  More precisely: how does the client
properly recognize an authorized DHCP server versus a rogue server.  I
think that leads us to 3 below.

> Sorry, I could not catch your mean.Do you mean to add some context in the

See above.  How do I know that I am handing my password to A Good Guy?

Eliot

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 12 Oct 2006 11:35:25 -0400

A fundamental question.

Is this WG chartered for developing a solution for network access
authentication and authorization other than developing authentication
mechanisms for DHCP?

I am asking this because Introduction of
draft-zhao-dhc-user-authentication-00.txt says:

"
   An authentication mechanism for DHCPv4 protocol messages was
   developed in [RFC3118].This allows DHCP clients and servers to
   authenticate each other.  Our purpose differs in that we want to
   authenticate and authorize a user before he accesses a provider
   network, to apply policy to customize this access connection to
   account for the service.
"

Best regards,
Yoshihiro Ohba

---

From: Mark Stapp <[email-masked]>
Date: Thu, 12 Oct 2006 14:03:25 -0400

yes, this is a fundamental question. the ietf protocol for IP-based
network access is EAP in UDP: PANA. whatever we may think of the details
of PANA, it's hard to imagine that the DHCP packet format and protocol
state-machine are likely to provide a technically superior solution. and
it's hard to imagine the ietf's supporting the use of DHCP for this
purpose, when much work has gone into EAP and PANA. trying to solve all
of the technical problems (especially the security problems) within DHCP
packets would likely - in my opinion - consume a great deal of time and
effort but be very unlikely to result in a standard. I don't think it's
worth heading down that path.

I also agree on the charter issue: I don't think anything more than
security for the DHCP client/server exchanges is in the DHCP charter.

-- Mark

---

From: Amy Zhao <[email-masked]>
Date: Fri, 13 Oct 2006 10:01:42 +0800

Hello!
    Thanks!

     We just use DHCP to supply user-credential(username/password) for AAA.
 
    Sorry, maybe this text need to be modified. :-).

B.R.
Amy 

> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Thursday, October 12, 2006 11:35 PM
> To: Amy Zhao
> Cc: [email-masked]
> Is this WG chartered for developing a solution for network 
> access authentication and authorization other than developing 
> authentication mechanisms for DHCP?
> 
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > logging in, type "cd internet-drafts" and then "get 
> > draft-zhao-dhc-user-authentication-00.txt".
> > 
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 	"FILE 
> /internet-drafts/draft-zhao-dhc-user-authentication-00.txt".
> > 	
> > -------------- next part -------------- Skipped content of type 
> > multipart/alternative
> >

---

From: Pavan Kurapati <[email-masked]>
Date: Fri, 13 Oct 2006 14:43:12 +0530

Hi Amy,

A few comments that I have :

1. Since the AAA server is interacting with Relay Agent, why do we carry 
the messages to the server if the authentication is failed? Your 
solution looks more complex to me in case of Digest Authentication where 
you carry the challenge response to the server and server justs puts the 
same in the OFFER. In my opinion, there should be a mechanism where NAS 
(relay agent) should relay the DHCP message only after the 
authentication is successful. Say, we use new message types to 
communicate between Relay agent and DHCP client for the authentication 
process. NAS can challenge the DHCP client and verify the response 
through AAA server. Only if it is 'success' it can forward the DISCOVER 
message to the Server. I know that currently Relay and Client do not 
communicate directly. But as an eg, even in case of NAS acting as PPP 
relay agent there are instances where NAS sends LCP requests directly to 
the client even if it doesn't terminate the PPP. Similar mechanism can 
be employed here.

2. Section 5.2.1 : You defined type values as "0" and "1". In the 
description of 'data' you mentioned "if type = 1 ... if type = 2 ...". 
Change either one of the description

3. In section 6, In basic authentication mechanism, client will put 
User-based Authentication option only in DISCOVER packet (as per the 
initial flow chart) and the REQUEST does not contain this option. I 
think you need to make it clear in first bullet point.

Regards,
Pavan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 13 Oct 2006 08:04:38 -0400

Hi Mark and Amy,

Thank you for the clarification.

Yoshihiro Ohba

---

From: Markus Kai Richard Stenberg <[email-masked]>
Date: Fri, 13 Oct 2006 23:28:58 +0900

I also read through the draft. Some thoughts..

- Typically, the relay-server link is secured and doing the AAA centrally
  in the server sounds more sensible anyway, as you have less ACLs needed
  for the AAA server access, and in general can have AAA server far away
  from relays. Is there some real case due to which doing this in the relay
  makes more sense? (and no, "NAS deployment models do this with other
  protocols" isn't justification)

- As others noted, EAP is the way to go for this kind of stuff in general,
  not much point in adding it here too? PANA, PPPoX, and even IKE can
  leverage EAP, reinventing wheels isn't fun.

- If we wanted to add it here, specifying MD5 in this day and age sounds
  rather naive - it can be argued to be a broken hash algorithm.

- "Basic authentication" sounds about as good as no authentication, as far
  as security goes - if someone can snoop on the wire, you're hosed. The
  reason the "basic authentication" in WWW is successful is (I posit)
  mostly due to being able to leverage SSL/TLS as transport, after which it
  is just somewhat distasteful matter of sharing the password with
  identified remote party (remember, SSL/TLS _has_ authentication of server
  via certificate, but your scheme for DHCP does not authenticate the
  relay)

All in all? I'd recommend forgetting about it, or alternatively crafting
ugly EAP-o-DHCP to compete with the EAP-o-UDP of PANAland? I doubt it'd be
within charter either, though, due to disclaimer of ".. not duplicate
existing mechanism" in the charter.

Anyway, using existing extensible auth arch over crafting a new one would
be clearly preferrable..

-Markus

---

From: Amy Zhao <[email-masked]>
Date: Sat, 14 Oct 2006 14:27:17 +0800

Hello,Eliot!

        Please see in line.
     
Thanks!

B.R.
Amy 

> Sent: Thursday, October 12, 2006 4:22 PM
> To: Amy Zhao
> Cc: [email-masked]
> > through some form of high-speed access technology such as cable or 
> > ADSL, we need a coupling between AAA and DHCP.
> >   
> 
> What resource is DHCP protecting, and is it effective at 
> protecting that resource?
> 

The resource that DHCP is protecting is user password. 
I will not tell you this mechanism is very effective in all situations, I
can not make such a conclusion . 
After all, the security of this mechanism is not very strong, 
but it does not mean that  we need the strongest secure mechanism in all
situations, enough is OK.
If you and other folks can give me some advices/comments to make this
mechanism stronger,
I will be very appreciated. :-)

> > You and Andre both mention this issue. To tell the truth, I really 
> > missed it. but until now, I think the two options are 
> seperate. Maybe 
> > I miss some issues.
> 
> Fundamentally the issue is this: what is to prevent a rogue 
> DHCP server from snarfing a client password?  More precisely: 
> how does the client properly recognize an authorized DHCP 
> server versus a rogue server.  I think that leads us to 3 below.
> 
Thanks to point out this problem.

If I catch your mean correctly, you mean if we use dhcp authentication
option and user -based authentication
simutaneously, the password information will be delivered to dhcp server
before the client and the server authenticated 
each other?

Now, we are considering this problem but it seems to me there is no good
idea. Any comments?

In digest mechanism, what the server know about a client password is the
digest of this password,
not the plain-text password. I think it will be useful for snarfing attack.

> > Sorry, I could not catch your mean.Do you mean to add some 
> context in 
> > the draft?
> >   
>

---

From: Amy Zhao <[email-masked]>
Date: Sat, 14 Oct 2006 14:44:00 +0800

Hello,Pavan!

      Thank you for your comments!

      Please see in line!

B.R.
Amy 

> From: Pavan Kurapati [mailto:[email-masked]] 
> Sent: Friday, October 13, 2006 5:13 PM
> To: Amy Zhao
> Cc: [email-masked]
> 1. Since the AAA server is interacting with Relay Agent, why 
> do we carry the messages to the server if the authentication 
> is failed? 

The purpose is to avoid dhcp client to retransmit request message.
If the authentication is failed and we do not carry this message to the
server,
server will not response to dhcp client, the timer on the client will
expire, and this 
will result in retransmission of dhcp request message.

>Your solution looks more complex to me in case of 
> Digest Authentication where you carry the challenge response 
> to the server and server justs puts the same in the OFFER. 

The challenge path is AAA server --> NAS --> DHCP server --> DHCP client,
because there is not directly communication between relay agent and client.
so, I use dhcp server as a intermediator to transfer the challenge.

>In my opinion, there should be a mechanism where NAS (relay 
> agent) should relay the DHCP message only after the 
> authentication is successful. Say, we use new message types 
> to communicate between Relay agent and DHCP client for the 
> authentication process. 
> NAS can challenge the DHCP client and 
> verify the response through AAA server. Only if it is 
> 'success' it can forward the DISCOVER message to the Server. 
> I know that currently Relay and Client do not communicate 
> directly. But as an eg, even in case of NAS acting as PPP 
> relay agent there are instances where NAS sends LCP requests 
> directly to the client even if it doesn't terminate the PPP. 
> Similar mechanism can be employed here.

It's very attractive to me, but under current dhcp mechanism, I can not do
like that. :-)
If WG agree to define new message types for user authentication, I will do.

> 
> 2. Section 5.2.1 : You defined type values as "0" and "1". In 
> the description of 'data' you mentioned "if type = 1 ... if 
> type = 2 ...". 

Thanks to point out.  I will modify it.

> 3. In section 6, In basic authentication mechanism, client 
> will put User-based Authentication option only in DISCOVER 
> packet (as per the initial flow chart) and the REQUEST does 
> not contain this option. I think you need to make it clear in 
> first bullet point.

OK, I will do.

> >http://www.ietf.org/internet-drafts/draft-zhao-dhc-user-authe
> ntication-
> >00.tx
> >t
> >