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

From: George Tsirtsis <[email-masked]>
Date: Fri, 26 Jan 2001 17:42:01 -0500

Bernard,

Thanks for this excellent analysis. Lets see if all this makes sense. See
comment below. 

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: Friday, January 26, 2001 6:55 PM
To: DHCPv4 discussion list
Subject: Comments on draft-ietf-dhc-aaa-ra-00.txt

Overall, I have substantial concerns about this draft. 

Before launching into a proposed architecture, I would
like to first see a definition of the problem to be
solved and a set of requirements for the solution. 

Reading between the lines, it appears that the problem
involves access-control for inter-domain mobility. For
example, the draft refers to "DHCP-based Internet access".

GT> Mobility was not the main focus of the draft, although I guess it could
be considered. The idea of the draft was born after working with xDSL
networks. 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.

Implicitly, it is assumed that authenticated DHCP can 
be used as an access control mechanism. However, this
is not one of the threats discussed in the authenticated
DHCP draft, so I wonder whether this is an appropriate 
use of DHCP. Since clients can just allocate static
addresses, DHCP by itself cannot keep a host from 
accessing the network. 

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

Implicitly it is assumed that AAA mechanism is appropriate
for integration with DHCP. However, the mechanisms discussed
in the authenticated DHCP draft do not lend themselves well
to integration with AAA, because the signing the DHCP
authentication option requires access to the DHCP packet,
which in turn may require the AAA server to understand
DHCP. 

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.

Defining a challenge/response authentication option 
within DHCP may not be a good idea because then the 
DHCP messages wouldn't be integrity protected. 
This prevents implementation of a secure boot process, 
which was one of the original objectives of authenticated 
DHCP.

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.

Furthermore the coupling of DHCP and AAA will result in
a multi-hop architecture that will result in substantial
latency.  

GT> I guess that is a fair point.

So after reading the draft, I am left with the feeling that
we need to step back and define the problem. Some questions
to think about:

1. Why is it that existing access control mechanisms (e.g.
mobile ip) are inadequate for the task at hand?

GT> I would argue that the main competing access control mechanisms is PPP
rather than Mobile IP but I think this is a good discussion to have. Lets do
this in a separate thread.

2. Is it valid to think of DHCP an access control mechanism?

3. Do we want to change the threat model described in the
authenticated DHCP draft to incorporate the goals described
in this draft? 

4. What are the requirements for a DHCP authentication extension
that could satisfy the goals, assuming that we think they are
valid?  

GT> I think (1) is the most important one. If we find that existing
mechanisms are not adequate then we can continue with the others. 

Regards
George

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 26 Jan 2001 21:57:42 -0800

>We were trying to figure out how to build an initially xDSL, but

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

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.

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.

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.

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.