Subject: [Int-area] Re: DHCP auth: comments on pruss-dhcp-auth-dsl-02

From: Richard Pruss <[email-masked]>
Date: Mon, 03 Dec 2007 07:37:02 +1000

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-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 3 Dec 2007 03:36:57 +0200

Here is my review comments on this I-D. Putting aside all the issues that
have been already raised, just concentrating on the text in this I-D...

- DHCP client on "home network devices" scenario missing, despite clear
indication in the I-D that this is a valid scenario.

- In Figure 1, is there a DHCP relay on both AN and NAS? If only NAS has it,
can the AN still insert DHCP option 82? 

- Figure 2 cannot deliver IP address to HGW via DHCPOFFER as the IP address
is only known after the RADIUS Access Accept. But this violates RFC 2131, as
DHCPOFFER must provide the IP address.

- In Figure 3, NAS inserts CHAP option in the DHCPOFFER. I don't think DHCP
relays are allowed to inject options towards the DHCP clients.

- In Figure 3, DHCP server receives the DHCPREQUEST but does not respond to
it. NAS (DHCP relay) becomes the entity that generates DHCPACK/NAK. This
totally breaks DHCP.

- Multi-round DHCPEAP is wedged into the current DHCP state machine,
effectively altering it.

- In Figure 4, EAP retransmission can cause the DHCP server to transmit
unsolicited DHCPEAP. This again breaks the usual request-response type DHCP
state machine.

- Regarding Figure 4, I-D states:

	The message following this exchange is a DHCP Offer, sent unchanged
	by the Server.

That's not true, as the DHCPOFFER carries EAP result.

- In Figure 5, NAS (DHCP relay) is generating a DHCP message. This is not
compliant with DHCP.

- In Figure 5, when the NAS receives a retransmitted EAP message over
RADIUS, what should it do? Would it send the DHCP client an unsolicited DHCP
message from DHCP relay? 

- In Figure 5, how is the EAP re-authentication initiated by the AAA server
handled?

- With the DHCP relay generating messages and otherwise adding options in
both ways, end-to-end model is broken. RFC 3118 cannot be used.

- In Figure 5, DHCP relay "caches" the DHCPDISCOVER message, goes on with a
multiple round-trips of DHCPEAP with the client, and then "releases" the
DHCPDISCOVER message towards the DHCP server. Very strange
behavior.......... 

- In Figure 5, DHCP server never sees DHCPREQUEST. Because DHCPREQUEST is
consumed by the DHCP relay. This is just broken.

- How does this solution guarantee orderly delivery of EAP payloads?

- IETF would not standardize anything with MD5. This was already said, not
sure why this is still hanging around.

We had published an I-D for securing DHCP using EAP-generated keys.
draft-yegin-eap-boot-rfc3118. As you can see, that does not require mixing
up DHCP and EAP protocols.

Overall, this proposal suffers the obvious consequences that'd arise when
one stacks up two distinctly unrelated protocols where
	- State machines do not match
	- End-points do not match
	- Call flows do not match
	- External interactions do not match

These are fundamental issues...

Alper

---

From: Jari Arkko <[email-masked]>
Date: Sun, 02 Dec 2007 20:29:47 -0800

Ric,

> 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?

> 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.

> No, it is not really deployed that I know of.  We can probably safely

Ok.

> 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.

>> 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.

> 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.

> 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...

> 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.

> 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.

> This should work even when EAP is in the mix.

Ok, but this needs to be described.

> 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.

> Will do for the next draft.
Good.

Jari

---

From: <[email-masked]>
Date: Mon, 3 Dec 2007 08:36:29 -0800

Here is my review. 

Review of draft-pruss-dhcp-auth-dsl-02.txt

"For the latter, existence of a client using a given IP address can be
detected by a number of means, including Address Resolution Protocol
(ARP) [RFC1433], ICMP Echo/Echo Response [RFC0792], or Bidirectional
Forwarding Detection (BFD) [I-D.ietf-bfd-base]."

RFC 1433 is "Directed ARP".  Did you mean to reference this specification
or RFC 826? 

Section 2

Maybe I'm missing something, but this section doesn't describe the
problem statement with respect to access control.  While PPPOE
prevents a client failing authentication from accessing the network
in any way (e.g. no IP, IPX, NetBEUI traffic), I am not clear
whether the goal is the same for this proposal, and if so, how it
is accomplished. 

For example, is there an assumption on the NAS side that EAP is
being used for port access control?  Or is this access control
based on the client MAC or IP address?  Unlike with PPPoE, the data
packets aren't being encapsulated, so I don't understand how
access control decisions are to be enforced on the NAS.  For
example, is there a filter operating on the NAS that only enables
packets to pass that originate from or are destined to an IP 
address that was assigned as the result of a successful EAP 
authentication? 

Section 5.2

                 (DHCP messages continue normally from
                  this point forward if successful)

                    <------- DHCPOFFER (w/EAP Success Message)
                             (w/yiaddr)

       DHCPREQUEST  ------->

                    <------- DHCPACK

This flow seems to assume that an Access-Accept will always contain
an EAP Success message.  This is not necessarily the case.  It is
possible that it could contain an EAP Failure, for example (see
RFC 3579 Section 2.6.3).  In that case, it is possible that the
DHCPREQUEST could be responded to with a DHCPNAK. 

   The retransmittion is handled by EAP as per Section 4.1 in [RFC3748].

In EAP, retransmission is handled by the authenticator, but in DHCP
doesn't the client do the retransmission?  So how does this work? 
How does the DHCP transport provide for in-order delivery?  Is there
some kind of sequence number included in the DHCPEAP packets? 

   The identity hint information from [RFC4284] may be sent inside an
   EAP-Request/Identity before the authentication conversation begins.
   This allows replacement of PPPoE scenarios where PPPoE server
   responds with a PPPoE Active Discovery Offer (PADO) packet that
   advertises a list of available services.

I don't think that EAP can provide PPPoE PADO functionality based on
RFC 4284, which is only about realm advertisement, not general 
capability discovery or negotiation.  

Section 8.2

   RFC 3118 provides a mechanism to cryptographically protect DHCP
   messages using a key, K, shared between a DHCP client and Server,
   however no mechanism is defined to manage these keys.  Authentication
   exchanges based on EAP have been built into authentication portions
   of network access protocols such as PPP, 802.1X, PANA, IKEv2, and now
   DHCP.  EAP methods may provide for the derivation of shared key
   material, the MSK and the EMSK, on the EAP peer and EAP server.  This
   dynamic key generation enables [RFC3118] protection and allows modes
   of operation where messages are protected from DHCP client to DHCP
   relay which previously would be difficult to manage.

Isn't the goal of RFC 3118 to protect exchanges between the DHCP client
and server (not between the client and relay)?

---

From: Mark Townsley <[email-masked]>
Date: Mon, 03 Dec 2007 12:21:37 -0800

> had the EAP scheme, would that be enough for the PPPoE migration case?
Yes, either of these options could work, and both have pros and cons - 
this is exactly the type of thing that I would like to see the dhc WG 
hash out if the IETF takes on this work.... I could say the same for 
many of items in this particular thread.

- Mark

---

From: Richard Pruss <[email-masked]>
Date: Mon, 03 Dec 2007 16:08:10 -0800

Thanks for a solid review.

> RFC 1433 is "Directed ARP".  Did you mean to reference this specification
Yes, thanks for catching that.
> based on the client MAC or IP address?
IP session enforcement is well deployed today and there are a couple of 
ways the various implementations handle IP sessions.
Possibly predominantly enforcement is to a MAC + IP host (or IP Subnet) 
together, but with different security & redundancy implications you also 
get:
VLAN+MAC+IP host (or IP Subnet)
VLAN+IP host (or IP Subnet)
IP host (or IP Subnet)
>   Unlike with PPPoE, the data
> packets to pass that originate from or are destined to an IP address 
> that was assigned as the result of a successful EAP authentication?
Yes, the NAS will not pass packets to an IP session that it did not 
allocate with DHCP and typically the NAS gets DHCP config from RADIUS 
for in current implementations. Currently the NAS takes Option 82 puts 
it into the Username field and does an Access Request.  The Access 
Access accept provides a profile that is used for the session and often 
an IP address that is then returned in the DHCPOFFER.  Access Reject 
does result in a DHCPNAK.

The EAP is just adding a dialog with the CPE RW at this point.

> doesn't the client do the retransmission?  So how does this work? 
The EAP message retransmission is handled by the authenticator.
> some kind of sequence number included in the DHCPEAP packets?
No, we considered that at great length but we feel you can safely assume 
that the Layer 2  wired switched system delivers packets in order.
If you are getting out of order in the access between the NAS and the 
CPE you have far greater problems that EAP struggling.

> capability discovery or negotiation.
Yes. We will remove this in the next draft.

> and server (not between the client and relay)?   
In the current implementation's the NAS's act as DHCP servers so for 
that the scope of RFC 3118 will would just fine.

One thing that the comments on the draft has taught me is that talking 
about the NAS as a relay is introducing confusion.
The NAS is either a DHCP server and getting IP address allocations from 
locally managed pools or AAA, what allot of people call "proxy" instead 
of relay.  The difference is NAS overides the server to be itself and 
can see all the DHCP messages as a result.

There is a draft on how to do this neatly but often implementations just 
override the Server-ID.
http://ietfreport.isoc.org/ids/draft-ietf-dhc-server-override-05.txt

- Ric