[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [dhcwg] [New I-D] DHCP User-based Authentication
Hello,Pavan!
Thank you for your comments!
Please see in line!
B.R.
Amy
> -----Original Message-----
> From: Pavan Kurapati [mailto:pavan_kurapati at infosys.com]
> Sent: Friday, October 13, 2006 5:13 PM
> To: Amy Zhao
> Cc: dhcwg at ietf.org
> Subject: Re: [dhcwg] [New I-D] DHCP User-based Authentication
>
> 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?
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 ...".
> Change either one of the description
>
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.
>
> Regards,
> Pavan
>
>
> Amy Zhao wrote:
>
> >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-authe
> ntication-
> >00.tx
> >t
> >
> >To remove yourself from the I-D Announcement list, send a message to
> >i-d-announce-request at ietf.org 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:
> > mailserv at ietf.org.
> >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
> >dhcwg at ietf.org
> >https://www1.ietf.org/mailman/listinfo/dhcwg
> >
> >
>
>
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg