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 we could work this out within the RFC 3118 framework, it certainly
would kick start DHCP authentication.
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.
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
