Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt

From: George Tsirtsis <[email-masked]>
Date: Mon, 29 Jan 2001 06:09:48 -0500

Bernard,

New comments are indicated with GT>>

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: Saturday, January 27, 2001 5:58 AM
To: George Tsirtsis; DHCPv4 discussion list
Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt

>We were trying to figure out how to build an initially xDSL, but
>then generic always-on, access network without the use of PPP. Main reason
>was that always on networks are... "always-on" => no dial-up and thus no
>much reason for PPP. On the other hand providing the corporate network
>environment to home network users (dhcp plug and play) has some appeal.
Then
>again, public access networks need access controls and the draft is what we
>came up with.

I've also often wondered why it is that we need PPP in xDSL. The Ethernet
in the Last Mile (ELM) study group in IEEE is looking at DSL-based
Ethernet PHYs, so that you could use Ethernet as the link layer instead.
For this, IEEE 802.1X Network Port Authentication would be used for
access control. See:

http://www.drizzle.com/~aboba/IEEE/8021x-d10.pdf.gz

GT>> That is great, I will have a look, but as always an IP solution to this
is preferable in terms of doing the same thing regardless of Link
Layer...and anyway this does not solve exactly the same problem...see below.

Another approach is to do the authentication at the IP layer. A while
back B. Patil proposed an IP-layer authentication protocol (BURP), which
he envisaged could be used for authentication and access control in
multiple access methods.

In both the above approaches, authentication and access control occurs
separate from, and prior to, DHCP.

GT>> Jerome replied to this...we notified the BURP BOF mailing list about
this draft so we can get their point of view too.

GT> Indeed, only the Access router can do that...hence the point of this
draft.

Well, the question is whether the authentication/access control is
intertwined with DHCP, or kept separate, and the number of messages
and state required in the upstream router as a result. For example,
are we talking about per-address state, or per-port state.
The difference turns out to be important for larger deployments.

GT>> This is a good point. In always-on and fixed systems per-port
authentication can be viewed as implicit! The provider sets-up a xDSL line
with a customer in a controlled way => i.e.: per-port authentication may not
be the main (or only) issue here. What is now needed is some control over
users at the end of this line...and this is not only for refusal of service
but maybe for enabling controlled roaming between customer's networks...etc

GT> Agreed but does this still apply when AAA is triggered at RA? I think it
depends how we do this exactly so I will leave it for now.

The thing to think about is what information would be included in a AAA
request and response. For the DHCP authentication draft, I think that the
DHCPDISCOVER/DHCPREQUEST (including the auth option) would need to go in the
response,
and a DHCPOFFER/ACK/NAK would need to be sent in the response. This
effectively
requires an integrated AAA/DHCP server, which is a complex beast to build.

GT>> In the lab we tried something different, which would require upgrade in
the capabilities of the DHCP RA to be fully functional. 
Build a combined AAA/DHCP client (AAA-client + DHCP RA) and let the servers
be separate. The end nodes does DHCP + Auth options. The DHCP RA triggers
AAA client with the auth options received from the end node. If, and Only
if, the AAA server confirms the identity of the end user the DHCP RA relays
the DHCP message to the DHCP server...As I said this may require some
modification to the RA but I think it is worth investigating as an
alternative approach.

GT> Again, not so sure, nothing prevents you from using Authenticated DHCP
in its current form in combination with the new proposal but again depends
how we do it.

The issue with Challenge/Response is that it typically doesn't include
calculation of a MIC a la the authenticated DHCP draft, in order to
avoid the problem described above. By not including a MIC, the DHCP
packet is no longer integrity protected. This allows an attack to
change the TFTP server, for example. With diskless boot making
something of a resurgence, that is worrisome.

GT>> Here is were my ignorance becomes apparent :-) ...what is MIC?

Thanks
George

---

From: "Bernard D. Aboba" <[email-masked]>
Date: Mon, 29 Jan 2001 19:09:05 -0800 (GMT-0800)

Out of curiousity, how does IP-layer auth work in a multi-protocol 
situation? 

For example, if I'm running dual stack (IPv4, IPv6), do I now need two 
authentications, one for each protocol? What if one auth succeeds and 
another fails? In effect, the interface is down for one protocol and up 
for another. How does this work? 

I think that while it's easy to advocate "doing it at the IP layer" it's 
a lot harder to describe how this would work (and why this solution would 
be better than a linklayer one).

---

From: Subir Das <[email-masked]>
Date: Tue, 30 Jan 2001 15:07:16 -0500

Bernard,

Here is an attempt to answer your question:

 1. Authentication above layer-2 works for any link technology (e.g., home,
cable, cellular, office).

 2. Authentication at the application layer (as is proposed for BURP,  for
example),  independent of IP        address, eliminates the need to do
separate authentication for a dual stack(IPv4, IPv6).

Appreciate your comments.

 Regards,

 Subir

--
********************************************************************************
Subir Das                         Ofc: MCC 1D-210R
Telcordia Technologies            Tel: 973 829 4959
(Formerly Bellcore)               Fax: 973 829 5888
445, South Street              E-mail: [email-masked]
Morristown, NJ 07960-6438
********************************************************************************