[dhcwg] comments on dhc-eap-auth-analysis-01

["Alper Yegin" <[e-mail]>]

   This analysis will
   also cite architectural and best practice considerations for the
   authors to consider as part of this work.

IAB's RFC 5505 deserves being mentioned in this I-D particularly because it
states:

2.5. Configuration Is Not Access Control


   Network access authentication and authorization is a distinct problem
   from Internet host configuration.  Therefore, network access
   authentication and authorization is best handled independently of the
   Internet and higher-layer configuration mechanisms. 


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

   [I-D.pruss-dhcp-auth-dsl] requires that end-user DHCP-based
   authentication must be handled independently in the case where both
   IPv4 and IPv6 service are present.  [I-D.pruss-dhcp-auth-dsl] is not
   clear as to how clients and servers handle conflicts where both IPv4
   and IPv6 are used simultaneously and further how conflicts are
   resolved when such scenarios arise.  See the beginning of section 5
   of [I-D.pruss-dhcp-auth-dsl].

In no other access network architectures the host/subscriber needs to be
authenticated/authorized for IPv4 and IPv6 separately. One major issue with
the proposed approach is it relies on the subscriber being authenticated
twice; but legacy AAA infrastructure expects one authorized session at a
time. So, this looks like either a double login attempt, or latter session
overwriting the former. This does not work. (please consider consulting
RADEXT and DIME WGs if you want a deeper analysis).

Also, what happens when DHCPv4 auth succeeds but not DHCPv6? Does that mean
only IPv4 service is authorized? What if there are multiple IPv4 addresses
allocated via DHCP? What is IPv6 uses stateless address auto-config? Etc.
etc.


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

   Hence, we strongly recommend that the proposed protocol be changed so
   that, after a successful DHCP/EAP exchange, the DHCP client restarts
   its state machine at the INIT state and sends a new DHCPDISCOVER,
   with a new transaction ID.

This is certainly a move in the right direction. The problem is the whole
thing this proposal is trying to do: inlining/coupling access authentication
with DHCP procedure. There is no value in doing that, and it breaks a lot of
things. The right thing is to decouple them, completely. Once they are
decoupled, people would realize that there is no point in hacking up DHCP to
do subscriber authentication.


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

   We recommend that each EAP message sourced by the client
   have a new transaction ID, which should then be returned in the
   response from the server.


The problem is, EAP requests are sourced by the network. Hence transaction
IDs generated by the client does not work. Wrong direction, totally
incompatible state machines between EAP and DHCP. [I think this is a perfect
example of how one cannot stack up any two arbitrary protocol]

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

Final DHCPEAP is sent one-way from network to client. What happens if it is
lost? How does this reflect on the state machines? 

One thing, this proposal is lacking any discussion on state machines. How do
EAP and DHCP state machines interact with each other? What changes are
needed on the standard DHCP state machines? There are 3 state machines as I
see: one on the host, one on the DHCP relay, one on the DHCP server. DHCP
relay is not a relay; it terminates and sources DHCP messages. And those
messages are wedged in the ongoing DHCP session between the host and DHCP
server. There is a unique state machine relationship here. I don't know how
this whole thing holds up, but a clear documentation of state machines would
reveal it.

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

EAP retransmissions are not taken into consideration at all. They require
DHCP server or DHCP relay to keep sourcing DHCP messages when there is no
outstanding request from the client...... Does this look like DHCP to
anyone??

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

DHCPDISCOVER is cached throughout the length of full EAP authentication;
which can take multiple round-trips and few seconds (even longer when user
input is required). Would this not cause a timeout and rexmit on the client?

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

   None of the ones which do not support fragmentation are likely to
   exceed even 100 bytes in normal usage , so implementations MAY set
   DHCP message size to the common DHCP relay practice of 576 limit with
   some risk of some new non-fragmenting EAP protocol not being
   supported, but the recommendation of this draft is to set the maximum
   message size to that of the interface MTU.


Risk? This I-D is defining an EAP transport that may not work for some type
of EAP methods? This cannot be acceptable. 

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

   NAS on receiving a DHCPDISCOVER with
   unknown option silently discards unknown message.  Alternatively NAS
   MAY ignore the unknown option, but still process the message and then
   reply to the DHCP client with traditional response.  

There should be one correct way. Which one is it?

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

dhcp-auth I-D should describe why RFC 5191 is not good enough and why IETF
and DHC WG shall embark on this work. 

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

dhcp-auth requires DHCP relay to strip off EAP payload before relaying the
DHCP message to the DHCP server.

When RFC 3118 is used, that'd cause problems. Because the message is getting
modified by a middle man (DHCP relay) and the authentication code will not
verify at the receiver (DHCP server). OK, maybe this does not apply to the
initial DHCP Discover as there is no security association is setup for RFC
3118; but the subsequent EAP re-authentications (the ones that happen after
the initial EAP authentication, and RFC 3118 kicked in) will break RFC 3118.


Alper