> Of course, the main problem with this solution is
the requirement to change the AAA to allow you to obtain the
data you
need BEFORE having the user's password?
Plus you need to change, or at least change the usage of,
the RADIUS
protocol to allow you to make an access request to get an
access accept
for the user data ( IP Address, DNS, etc ) without the valid
password
and then another ( access request ) to the server which can
return an
Access accept ( carry on as before ) or an Access Reject in
which case
this reject applies not to the associated request but to the
previous
for that user.
=> Which doesn't really meet the original requirement of
using the same
AAA server infrastructure and associated back end functions,
proxy
radius etc.
Cheers,
Derek.
+=============================+
Derek Harkness
Juniper Networks
Nymphenburger Strasse 13-15
80335 Munich
Germany
Tel: +49 89 5529 4916
Mobile: +49 172 843 6621
Email: DHarkness juniper.net
+=============================+
-----Original Message-----
From: Bernie Volz (volz) [mailto:volzcisco.com]
Sent: 22 March 2007 10:25
To: Ted Lemon; riccisco.com
Cc: DHC WG
Subject: RE: [dhcwg] draft-pruss-dhcp-auth-dsl-00.txt
I agree with Ted here. Of course, the main problem with this
solution is
the requirement to change the AAA to allow you to obtain the
data you
need BEFORE having the user's password?
And, I'd go a bit further to say you already have the option
you need to
communicate this information - the DHCP Auth option [RFC
3118].
Yes, you have to write a new draft that documents new
Protocol and
Algorithm fields and what the "Authentication
Information" contains. But
no new option is needed. No DHCP state machine changes are
needed.
Your draft has two options:
1. DHCP Authentication Protocol which communications two
values -
Authentication Protocol and Algorithm.
2. DHCP Authentication Data
These map very well into the existing RFC 3118 Auth option.
You might want to reference RFC 3318 Reconfigure Key
Authentication
Protocol as in the Auth data it has a flag that indicates
whether the
passed value is a key or digest (see 21.5.1). In your case,
you might
have 3 or 4 "type" values:
1. Username (sent in DHCPDISCOVER) ... Data in remainder of
auth field
is the username.
2. Challenge (sent in DHCPOFFER) ... Data in remainder of
auth field is
the CHAP challenge
3. Challenge-Response (sent in DHCPREQUEST) ... Data in
remainder of
auth field is the CHAP response.
4. ? (is something needed in DHCPACK? Perhaps not has if
challenge-response isn't valid, a DHCPNAK would be
returned?)
Perhaps you just use your "DHCP Authentication Data
Option"'s "data"
(Chap Code, Identifier, Data) as the auth data in the RFC
3118
"Authentication Information".
- Bernie
-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemonnominum.com]
Sent: Wednesday, March 21, 2007 4:42 PM
To: riccisco.com
Cc: DHC WG
Subject: Re: [dhcwg] draft-pruss-dhcp-auth-dsl-00.txt
On Mar 21, 2007, at 7:35 PM, Richard Pruss wrote:
> Ted could you possibly educate me on what the got
broken. The both
> options have state machine implications on both the
server and
> client. The second option constrains those effects to
new
> messages to handle the EAP in a series of messages but
beyond that
> DHCP exchange occurs as normal. This lends me to
suspect that
> option 2 may constrain its effect on the majority
current DHCP
> implementation by limiting the additional effort to
handling
> additional messages.
In your presentation you said that the main reason you went
to a six-
way handshake, and the entire reason you added the
EAP-specific
messages, was because someone told you that the protocol
didn't make
sense without EAP. Correct me if I am wrong about this -
I'm just
repeating what you said.
Both protocols you proposed were broken in that they require
six-way
handshakes, and one requires adding an entirely new set of
messages
to the DHCP protocol. Your proposed protocol doesn't add
enough
value to justify a change of this type - indeed, I can't
imagine
*any* protocol that would, for DHCPv4. DHCPv4 is a mature
protocol
- changing the fundamental packet exchange at this point is
a non-
starter. Changing it to make a transitional protocol work
is even
more non-starty than that.
It seemed, based on our back-and-forth today in the WG
meeting, that
you could make the protocol work with a four-way handshake.
The way
you'd do this would be for the client to present its
credentials in
the DHCPDISCOVER. The server would use those credentials
to get the
client configuration out of the AAA server without
authentication.
The server would then send a challenge in the DHCPOFFER, and
the
client would send a response in the DHCPREQUEST. If the
response
validated, the server would respond with a DHCPACK; if not,
it would
respond with a DHCPNAK. Because the configuration
information isn't
secret, sending it in the DHCPOFFER prior to authenticating
the
client is okay, and you haven't opened a security hole,
because the
client doesn't get a DHCPACK until the authentication
succeeds.
_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg
|
