Ric, >> 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.
Hmm. I was not trying to argue that we need two approaches. If we only had the EAP scheme, would that be enough for the PPPoE migration case? >> >> 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. True. But it still creates an additional dependency on how the "regular DHCP state machine" and the authentication scheme work together. >> >> 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. Ok. >> 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. I don't mind the packet being in DHCP OFFER either, but either way you should specify what goes on where and the draft should be consistent about this. >> 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. That is not exactly the situation you have here. EAP methods are the ones that ultimately need to fragment if EAP lower layer does not have a big enough MTU. But not all methods support fragmentation; EAP base specification guarantees that they can rely on 1020 byte MTU, and some may rely on earlier PPP 1500 byte MTU. So it is true that lower layers (including RADIUS) can support fragmentation if the MTU is otherwise too low. But I did not find support for fragmentation in draft-pruss. Again, if the MTU on DSL networks is always >= 1020 that is fine. >> 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. Ok. >> 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. Ah, I see the rationale. But if you had 802.1x, would you still need binding to what the DHCP security is? This isn't used elsewhere, is there a reason why it would be needed in the DSL environment? Or are you doing it as a nice to have additional feature? It will also complicate things, because now you would also have to indicate type or source of key... >> 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. Ok. (I will be sending mail about the bigger issues later; the impact to IPv6 is one of those.) > I would rather fix the DHCP security by securing the DHCP exchange. Yes, but even more important is to understand that this only works when combined with some source address spoofing prevention mechanisms or suitable environments; these do not exist on typical Ethernet environments, for instance. >> >> 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? That may be enough. >> >> 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. Ok, but this needs to be described. >> 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. Yes. > We can add a key identifier, we do define one in the draft, but in > general source MAC should be enough. MAC can keep different hosts separate, or perhaps even one host's attachments to different DHCP servers separate. But it does not help in ensuring confusion about keys between the same two nodes. >> >> I would like to see the IPv4 and IPv6 versions of DHCP addressed at the >> same time. > Will do for the next draft. Good. Jari _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
