Subject: [dhcwg] New version of EAP authentication analysis draft...

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Nov 2009 22:21:54 -0500

After the meeting last Thursday, Alper pointed out several omissions in the existing authentication analysis draft.   Consequently, I've revved the draft to address the points he made, and at the same time clarified some fairly incomprehensible language in the section of text talking about the lack of documentation on how DHCPEAP-capable clients handle situations where DHCPOFFERs are received prior to DHCPEAP messages.

The new draft should be available online shortly, if it isn't already.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 24 Nov 2009 01:07:59 +0900

I am waiting for the new draft before I comment on the draft.

On the other hand, according to the DHC WG IETF76 minutes:

"
- Ted Lemon:
     *** 12th is today ***
     *** 23rd is deadline for feedback on list ***
     *** 30th question will be called ***
"

I think the 23rd deadline for feedback on the auth analysis 
draft is not reasonable since new draft has not been 
submitted yet.

Any thoughts?

Yoshihiro Ohba

Ted Lemon wrote:
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: John Jason Brzozowski <[email-masked]>
Date: Mon, 23 Nov 2009 11:23:13 -0500

The current version of the draft can be found here:

http://tools.ietf.org/id/draft-jjmb-dhc-eap-auth-analysis-00.txt

It looks like it was posted circa 11/15/2009.

John

On 11/23/09 11:07 AM, "Yoshihiro Ohba" <[email-masked]> wrote:

>> After the meeting last Thursday, Alper pointed out several omissions in the
>> existing authentication analysis draft.   Consequently, I've revved the draft
>> to address the points he made, and at the same time clarified some fairly
>> incomprehensible language in the section of text talking about the lack of
>> documentation on how DHCPEAP-capable clients handle situations where
>> DHCPOFFERs are received prior to DHCPEAP messages.
>> 

=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:[email-masked]
o) 609-377-6594
m) 484-962-0060
=========================================

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Nov 2009 11:37:24 -0500

> http://tools.ietf.org/id/draft-jjmb-dhc-eap-auth-analysis-00.txt

It looks like I missed a step when I submitted the -01 version of the draft.   It's available now.

---

From: John Jason Brzozowski <[email-masked]>
Date: Mon, 23 Nov 2009 11:45:05 -0500

http://www.ietf.org/id/draft-jjmb-dhc-eap-auth-analysis-01.txt

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 24 Nov 2009 01:51:24 +0900

OK, now I found -01.

Can you please give us a couple of days for reviewing this one?

Yoshihiro Ohba

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Nov 2009 11:59:44 -0500

> Can you please give us a couple of days for reviewing this one?

That seems reasonable... :')

---

From: "MILES DAVID" <[email-masked]>
Date: Tue, 24 Nov 2009 04:39:57 +0800

Some comments on both drafts:

100% behind abandoning a stateful relay (analysis-4.3) agent as
mentioned previously on list. I cannot see why an intermediate relay
agent would want to perform EAP, however it certainly may provide a form
of access control and IP filtering based off successful DHCP address
allocation (SAVI DHCP-based for example).

Analysis-4.1.4 proposes that DHCP restarts after DHCPEAP is completed
and send a new DHCPDISCOVER. I agree with this approach and analysis.
Analysis-3.1 also suggests one should avoid a message type overload (the
use of a single DHCPEAP message). If we combine the two analysis
comments I think a good solution may result, that is:
An EAP capable client shall send a DHCPEAP-START message (similar to the
EAPOL start in 802.1x) to trigger the EAP Identity Request from the DHCP
server/NAS. Using a unique message type that conveys
suppliant-to-authenticator and authenticator-to-supplicant is certainly
advantageous for message validity checks IMO. DHCPEAP-REQUEST (from
authenticator) and DHCPEAP-RESPONSE (from supplicant). At the end of the
EAP exchange the Success or Failure could be conveyed in a single
message type (DHCPEAP-COMPLETE) as an alternative to implementing an
individual message type for Success or Failure. From here a DHCP client
could proceed with a DISCOVER or SOLICIT. 

Analysis-4.1.2 states that to be complete a standalone client
implementation must exist. I am not sure I understand the intent of this
comment -- is this suggesting the use case should be described to make
the document complete, or that the analysis draft authors believe some
protocol variation may need to exist to support stand-alone clients? I
am curious how DHCPEAP would be implemented in a corporate LAN, but that
seems to be more of a question of how the DHCP server should interact
with an edge device implementing access control (ie, is IP assumed and
SAVI in use?) as the current protocol combines the access-control device
(NAS) with the DHCP server. Certainly 802.1x already covers this
scenario in LAN environments.

Analysis-4.1.6 states that EAP is server-initiated which is true, but
the EAP protocol is invoked by the authenticator after another protocol
or phase completes. In 802.1x/EAPoL is almost always client initiated as
the supplicant may first send the EAPOL-START message. This is also true
in EAPoW (802.11). The reference to EAP on PPP should consider that in
almost every case the client initiated the connection with either an LCP
ConfReq or PPPoE PADI and EAP is invoked after the link is open. Sending
an DHCPEAP-START using a unique message type would be comparable to
current EAPoL behaviour and does not change the EAP server-initiated
statement as a DHCPEAP message is not part of the EAP protocol, it would
be part of DHCPEAP in the same way the EAPOL-START message is specific
to EAPoL.

I believe the issues of fragmentation and packet size have been
addressed in the current draft-pruss: It specifies the RFC 3396 method
for long DHCP options and notes that EAP MTU is 1020B leaving enough
room for DHCP/UDP/IP headers provided we don't try and add additional
DHCP message options. I note that in cases of an intermediate
relay-agent the relay-agent options/relay-forward/relay-reply headers
will increase the packet size and this will need to be carefully
managed. By requiring that the DHCPEAP-START message is never longer
than 576 octets I would expect incompatible relay-agents to drop these
new message types as invalid rather than suffering a fragmentation
issue. Only a relay-agent that understands these new message types would
permit them to be relayed serving as an explicit indication to the
server that it can support >576 octet DHCP messages.

Reliable delivery is not assured by EAP in many of the other commonly
deployed environments (in a PPP or EAPoL) and the EAP protocol already
provides guidance that could be applied to the DHCPEAP case. Given we
are not implementing state in relay agents I do not see an issue with
the EAP protocol causing a DHCP message retransmission (the existing
DHCP does the same thing). The only other interested parties in the
communication are the DHCP client and the DHCP server, both of which
must be DHCPEAP capable.

Sorry for the long response. I realise my comments suggest significant
change to the current draft-pruss, however I want to be clear that in
the interest of deciding now and forever what to do with this draft, my
vote is to adopt into the WG and recharter as needed. 

BR,

-David

---

From: Richard Pruss <[email-masked]>
Date: Tue, 24 Nov 2009 15:17:36 +1000

> allocation (SAVI DHCP-based for example).

Yea,  I have never felt comfortable with calling what I am calling a  
relay a relay, most of the
vendors call it a DHCP proxy.

DHCP proxies are not a documented IETF term so it was a hassle to find  
some that would
work without all the trolls jumping on me say there is no such thing  
as a DHCP proxy.

DHCP proxies look like a server to the client and a client to the real  
DHCP server.  They
are stateful and used typically to enforce many aspects of client  
behaviour that are gleaned
from RADIUS and DHCP servers.

Now I guess we can for the sake of this document either define DHCP  
proxy or simply
leave it out as we can simply say that the DHCP proxy implementations  
are really
DHCP servers that use another DHCP server as a common database.

But yes I agree DHCP relay does not need to be part of the doc.

- Ric

---

From: "MILES DAVID" <[email-masked]>
Date: Tue, 24 Nov 2009 13:37:21 +0800

Yeah,

I understand.. perhaps we can call it a L2 relay agent/LDRA as at least
they are defining those terms right now in DHC (and thus are fresh) and
there should then be less confusion? In broadband and LAN these are all
L2 anyway, right? What about doing it this way? Ie, DHCPEAP interaction
with LDRA and L2RA and note it is applicable to both Broadband and LAN
environments if combined with TR-101 DHCP snooping or the SAVI WG items?

d

-----Original Message-----
From: Richard Pruss [mailto:[email-masked]] 
Sent: Tuesday, 24 November 2009 3:48 PM
To: MILES DAVID
Cc: dhc WG
Subject: Re: [dhcwg] New version of EAP authentication analysis draft...

- Ric

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 25 Nov 2009 12:23:37 +0200

Hi,

> allocation (SAVI DHCP-based for example).

Are you suggesting abandoning Figure 3 and sticking with Figure 2?

Support for NAS and DHCP separation is required by TR-101, and DSLF
requirements states:

IPAuth-6	Must fit into TR-101 operational model 

So, I don't think you can drop that case.

> could proceed with a DISCOVER or SOLICIT.

Sure, perfect decoupling of access authentication from host configuration
procedure. This makes sense (as I and many others have been saying all
along).

And when you do that, why do you still use message names that start with
"DHCP"? It has nothing to do with DHCP, it does not have to be hacked on top
of DHCP.

Alper

---

From: "MILES DAVID" <[email-masked]>
Date: Wed, 25 Nov 2009 19:55:53 +0800

Hi Alper,

>So, I don't think you can drop that case.

The use cases I am interested in are:
- BNG/NAS acting as a DHCP server, where all DHCP messages are
terminated by the BNG/NAS.
- BNG/NAS acting as a DHCP relay, where all DHCP messages are relayed to
a DHCP server.

I do not have any demand to perform RADIUS-based authentication (EAP)
from the NAS while maintaining DHCP for address assignment with from an
external DHCP server (I'll call it the hybrid model) per figure 3. AFAIK
there is no explicit requirement in TR-101 to concurrently support
RADIUS and DHCP. 

In the case where the BNG/NAS is a DHCP server, RADIUS may be used for
authentication and optionally address assignment.

I think there is a thread from earlier this year where I put some of
this down and suggested we need a new "figure" and description that
addresses a NAS performing a complete DHCP relay function without
forking the EAP off to RADIUS.

>"DHCP"? It has nothing to do with DHCP, it does not have to be hacked
on top

I do not disagree, there are a variety of approaches that are feasible
for EAP-based authentication. For me this is just one more in the mix
that has other interesting aspects for a broadband network operator who
may already have DHCP-aware infrastructure. Certainly it is going
head-to-head with PANA and 802.1x on this front.

Cheers,

-d

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 26 Nov 2009 02:29:58 +0200

David,

> forking the EAP off to RADIUS.

Not sure I understand. (Referring to Figure 1) do you mean it would not be
the NAS but the DHCP server that implements an interface to the AAA/RADIUS
Server?

> head-to-head with PANA and 802.1x on this front.

I suspect the DHCP-aware infra is parsing DHCP messages. Wouldn't the
EAPoDHCP have an impact there too, now that we all realize this proposal
means a number of new DHCP messages? Now it is clear that the solution is
not as simple as defining one new DHCP option, despite how it was portrayed
in the early days.

Regards,

Alper

---

From: "MILES DAVID" <[email-masked]>
Date: Thu, 26 Nov 2009 13:31:45 +0800

>the NAS but the DHCP server that implements an interface to the
AAA/RADIUS

Hmm... perhaps I am opening my own can of worms here. I was suggesting
the DHCP server itself implement an EAP component without an external
RADIUS interface. However comments would be appreciated on such an idea.
If we are going to take the leap and extend the protocol to do EAP
authentication then I would think it logical for a DHCP server to have
such a capability in the longer term. As I mentioned before, RADIUS
should be optional when the NAS is implementing a DHCP server (such that
it may locally authenticate users), I just extended that concept to a
remote DHCP server.

>not as simple as defining one new DHCP option, despite how it was
portrayed

Yes, adding new message types has impact on existing DHCP relay
implementations. As we keep no state and the structure of these are
consistent with existing DHCP messages, I am not overly concerned with
implementation complexity.

I do take on board the point, I think we really need to hear from the
authors (on both drafts) re the suggestions made regarding additional
DHCP message types. For the analysis authors, were new messages (along
the lines of DHCPEAP-START, DHCPEAP-REQUEST, DHCPEAP-RESPONSE and
DHCPEAP-COMPLETE [not sure if we need the last]) what was intended?

-d

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 26 Nov 2009 10:44:19 +0200

David,

> >Not sure I understand. (Referring to Figure 1) do you mean it would
> not
> be

There is a whole bunch of authentication, authorization, and accounting bits
that needs to be signaled between a centralized AAA server and the NAS (or
BNG), so I don't think you can NOT have a RADIUS interface on the NAS
(whether the NAS hosts a DHCP relay, proxy, server, or none of that).

Alper

---

From: Richard Pruss <[email-masked]>
Date: Thu, 26 Nov 2009 21:31:25 +1000

> (whether the NAS hosts a DHCP relay, proxy, server, or none of that).

Actually we have allow folks to do local AAA authorisation without a  
centralised
RADIUS or Diameter server for many years.

Mostly we either see that with central Accounting still but some turn  
off that as well.

The main reasons for doing this step, which is painful from a  
provisioning and
management perspective are:
a) In small remote sites/areas where central connectivity is often  
unreliable but some local
resources are still useful.
b) Optimisation of the bring-up speed of a POP, the trick is it can be  
faster delegating locally than going
to a central RADIUS bottleneck.

To date this practice has mostly been for sites where the list of  
possible users is small and predictable,
but now with the advent of large storage in solid state drives, we  
will probably will see more
distribution.

- Ric

---

From: "MILES DAVID" <[email-masked]>
Date: Thu, 26 Nov 2009 19:35:33 +0800

Just want to add that we are describing EAP methods -- EAP-TLS does not
require me to populate a local database with much information at all,
just the correct (CA/root) certificates and a path to a CRL. 

I am aware of EAP-TLS being used in some existing EAP broadband
deployments.

-d

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 28 Nov 2009 19:16:26 +0200

David,

> require me to populate a local database with much information at all,

Actually you do. The only one-less-thing to store in your AAA DB is a
"secret key" of the subscriber (if we were to compare EAP-TLS with a
symmetric key authentication method such as CHAP). You still need to store a
whole bunch of stuff, starting from "list of subscriber identifiers" (since
not everyone with a certificate automatically becomes your subscriber), and
their authorization parameters (gold, silver, etc... and how they translate
to RADIUS attributes), and accounting records, etc. etc.

Alper