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. 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. > 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. Alan DeKok. _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
