Thanks for a good technical review.
Jari Arkko wrote, around 30/11/07 12:19 AM:
This is a review of Ric's draft from the point of view of its technical
content. Not about whether it is needed, if there are better
alternatives, match to DSL Forum requirements, etc.
Is the draft suggesting one or both approaches (CHAP and EAP)? I would
argue that we should select at most one. If the CHAP model is sufficient
for the PPPoE migration to happen, this speaks strongly in favor of it.
However, if we can satisfy the migration concerns even with EAP then it
would be a more general mechanism, and selecting that might make more sense.
Agreed, that is a good summary of why we still have two.
It concerns me that DHCP DISCOVER and OFFER are separated by the
possibly lengthy DHCP EAP exchange (multiple roundtrips across the world
in the worst case). This seems to change the way the regular messages
operate; a normal client might already have given up.
The EAP exchange only occurs on demand from the client. Thus it is
expected that the client will be able to understand the DHCP EAP
exchange and adjust timing accordingly.
In fact current DSL implementations have this delay as well for Option
82 AAA authentication with RADIUS (which could be proxyed around the
world as well). EAP pushes out the potential to make this longer and
multi-packet, but the hiccup is already there.
RFC 4284 reference needs a big disclaimer about its limitations, or no
reference at all. Is there a true need to replicate PPPOE PADO
functionality?
No, it is not really deployed that I know of. We can probably safely
leave this out.
Section 5.2 carries EAP Success in DHCP OFFER but Section 6.3 talks only
about carrying EAP messages in DHCP EAP. Some details may be missing here.
Yes, that is a premature optimization and the authors can clean it up.
Can all link layers and networks where this is run satisfy MTU>=1020
which is required by EAP? If not, you need a fragmentation mechanism... > Yes, this is for ethernet in DSL networks. The limits on DHCP are
similar enough to RADIUS that we want to align it so that fragmentation
happens once for the system.
I would argue that the EAP-based approach should employ binding between
the EAP exchange and the actual DHCP operation, perhaps using something
similar to what Section 8.2 outlines with RFC 3118 keying. In fact, I
would be interested in making this mandatory to implement and perhaps
even to use. What credentials and EAP methods would a DSL deployment
moving from PPPoE use, and would this be possible. I.e., this would
require mutually authenticating EAP and key generating EAP methods.
Good suggestion. We could make this mandatory even for the
CHAP as it looks as if the EMU is working on rechartering to work on a
tunneling method (such as EAP-FAST,EAP-TTLS,PEAP) that basically runs
EAP-TLS and then uses a protected tunnel to run inner authentication.
You could implement such that the tunnel mechanism is terminated on the
BRAS and the inner chap authentication was validated over an existing
AAA interface.
Section 8.2 suggests that EMSK be used to derive RFC 3118 keys. I think
this is inappropriate, but I cannot find the other draft that this draft
suggests will describe this in detail. In any case, if one EAP run is
used for one application separately from any other L2 or other use, I do
not actually see any reason to avoid the use of MSK. Using MSK would
have the advantage of avoiding new AAA servers and new AAA
specifications on how to derive and use EMSK for this purpose. Current
systems do not transport EMSK.
We can post the draft this week. The basic reason for using the
EMSK is to make the key derivation as similar as possible to support RFC
3118 bootstrapping with other mechanisms such as 802.1x. For the
specific case of DHCP authentication we could use the MSK as a root
instead of the EMSK and make use of the same function.
The draft is rather brief on what assumptions it makes about the
applicability of this method. For instance, employing it in a
point-to-point like environment where non-DHCP traffic (e.g., stateless
IPv6) is prohibited provides some amount of network access control
functionality. However, running it on an Ethernet or Wireless LAN would
provide only security for the DHCP exchange itself. (And in the current
version of the draft, not even that because there is no binding to the
DHCP transaction.)
We do need to add a clear statement that this will not support static
IPv4 assigned deployments and stateless IPv6. I would rather fix the
DHCP security by securing the DHCP exchange.
How are different sessions separated from each other? Presumably on the
DSL case you would only hear about this particular client on the same
virtual interface, but what if this is run in a plain old wired
Ethernet? Note that the identifiers in EAP packets are probably too
short for this.
Shared VLANs somewhere between the DSLAM and the BRAS are common in DSL
current deployments so session separation is important. Do we really
need more than a source MAC for session separation?
Is it possible for the two endpoints to be come confused about what the
state is? E.g., client reboots, server thinks it should keep resending
EAP requests? Its likely that a state machine is needed for this.
If the client & server get out of sync, the client can do what it does
now: assume it has no IP, and start the process from scratch again.
This should work even when EAP is in the mix.
If keys are used in the process to bind the EAP run and DHCP OFFER/ACK
together, is there a possibility that the two endpoints become confused
about which keys should be used? E.g., move client between two DSL
lines. Note that there may be scenarios where these things are run over
wireless, such as Wimax deployments attempting to model DSL. Its likely
that some key identification would be needed for this. Maybe its in the
other draft that does not exist yet...
MAC separation should keep these sessions apart. We can add a key
identifier, we do define one in the draft, but in general source MAC
should be enough.
I would like to see the IPv4 and IPv6 versions of DHCP addressed at the
same time.
Will do for the next draft.
- Ric
Jari
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
