Subject: [dhcwg] DHCP interconnected to RADIUS for AAA

From: "Chen, Weijing" <[email-masked]>
Date: Fri, 7 Mar 2003 16:18:35 -0600

Questions for DHCP experts:

1)  Does today's DHCP protocol specification support the client
authentication by user@domain and password?  If not, is it possible to
extend it?

2)  Is there any DHCP server implementation of obtaining IP address
assignment through RADIUS protocol (i.e. IP address pool managed by RADIUS)?

Thanks.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Barr Hibbs" <[email-masked]>
Date: Sun, 9 Mar 2003 08:50:01 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Chen, Weijing
> Sent: Friday, March 07, 2003 14:19
>
...DHCP is defined by RFCs 2131 and 2132 (ignoring BOOTP for this answer)
and extended by RFC 3118.  RFC 3118 specifies a mechanism for authentication
of DHCP clients and servers and defines two protocols for use to do so.
Protocol 0 uses a clear-text authenticator (password, if you will), but does
not specify how the authenticator could be constructed.  It could be the
tuple "user@domain" and "password," but that is a very bad idea in actual
practice:  it exposes both the user identity and their password to
interception.  It also has the fundamental flaws for large-scale
implementations of key distribution and lack of client and server support
for RFC 3118.

> assignment through RADIUS protocol (i.e. IP address pool managed
...while I'm aware of some experimental DHCP server implementations that
used RADIUS for user authentication--and granted access to a client whose
user was RADIUS authenticated--I'm not certain if any of them are now
commercially available.  RADIUS servers typically use DHCP for IP address
assignment corresponding to the dial-in connections they support, not the
other way around.  The RADIUS server provides user authentication;  the DHCP
server treats the RADIUS server as a legitimate client, without further
authentication.

--Barr

---

From: "Barr Hibbs" <[email-masked]>
Date: Mon, 10 Mar 2003 17:33:46 -0800

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Shankar
> Agarwal
> Sent: Monday, March 10, 2003 16:34
>
> Right now we don't have a simple username password authentication
> mechanism for DHCP and we have something very complicated which will not
> be used in most common deployments. In most of the cases we are happy
> with either cleartext user name password or may be MD5 encoded username
> password authentication. If we put this within the current DHCP
> framework then this will help in replacing the ppp in DSL and cabel
> modem world where username password is used to pick up the profile of
> the user.
>
...you are making an assumption that is not true in the general case:  using
the tuple "username" and "password" for CLIENT authentication assumes that
CLIENT and USER are identically equal.

DHCP authentication (per RFC 3118) makes no such claim of equivalence.

Can you guarantee that CLIENT and USER are, in fact, identical in your
environment?  If so, do your policies permit multiple instances of the same
user to be "logged-in" simultaneously?  If that is permitted by your
policies, of what use is it to you?  Giving multiple clients the same
username and password credentials is equivalent to no protection at all.

If your policies do not permit multiple simultaneous instances of a user
being logged-in, do you deny all subsequent client configuration attempts
until the first has logged off?

Also, have you implemented RFC 3118?  If so, could you identify the client
and server? (vendor name and product name)

--Barr

---

From: Shankar Agarwal <[email-masked]>
Date: Mon, 10 Mar 2003 16:34:18 -0800

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Mar 2003 14:51:38 +0100 (CET)

> modem world where username password is used to pick up the profile of

An alternative would be to figure out how PANA and DHC would work
together in this case.

  Erik

---

From: John Schnizlein <[email-masked]>
Date: Tue, 11 Mar 2003 10:39:51 -0500

>An alternative would be to figure out how PANA and DHC would work

Another alternative is to follow the AAA that controls initial access 
at layer 2 (e.g. RADIUS authentication for IEEE 802.1X) with sending
those RADIUS attributes to the DHCP server. This approach protects
the access network and separates the functions of user authentication 
from address (and other parameter) configuration. The mechanism for interworking this way is in draft-ietf-dhc-agentopt-radius-02.txt.

John

---

From: Markus Schabel <[email-masked]>
Date: Tue, 11 Mar 2003 17:00:04 +0100

> assignment through RADIUS protocol (i.e. IP address pool managed by RADIUS)?

Maybe 802.1x is a solution for you? There you have an authentication on
the switch-PORT (which could be done with a RADIUS-backend), and *after*
you are authenticated the port is open and you can communicate with the
network - you can only communicate with your DHCP *after* you passed the
authentification-process.

If your RADIUS uses LDAP as backend-database you probably can have some
uid-password-mac-ip-mappings stored in the database, and DHCP is able
(at least with a patch) to use LDAP as configuration-base.

^ correct quotes are ^-- $ (note the *space*)

regards
-- 
           \\\ ||| ///                               _\=/_
            (  @ @  )                                (o o)
+--------oOOo-(_)-oOOo--------------------------oOOo-(_)-oOOo------+
| Markus Schabel      TGM - Die Schule der Technik   www.tgm.ac.at |
| IT-Service          A-1200 Wien, Wexstrasse 19-23  net.tgm.ac.at |
| [email-masked]                   Tel.: +43(1)33126/316 |
| [email-masked]             Fax.: +43(1)33126/154 |
| FSF Associate Member #597, Linux User #259595 (counter.li.org)   |
|        oOOo        Yet Another Spam Trap:     oOOo               |
|       (    )    oOOo    [email-masked]       (   )     oOOo      |
+--------\  (----(   )--------------------------\ ( -----(   )-----+
           \_)     ) /                            \_)      ) /
                  (_/                                     (_/

Computers are like airconditioners:
   They stop working properly if you open windows.

---

From: "Prakash Jayaraman" <[email-masked]>
Date: Tue, 11 Mar 2003 08:25:03 -0800

> An alternative would be to figure out how PANA and DHC would work

Is there work currently in progress on such an alternative? (triggering a PANA
transaction upon a DHCP message from the client or something similar). Would
this be an appropriate forum to start a discussion?

- prakash

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Mar 2003 21:45:08 +0100 (CET)

> Is there work currently in progress on such an alternative? (triggering a
> PANA transaction upon a DHCP message from the client or something similar).
> Would this be an appropriate forum to start a discussion?

The simplest thing would be to have them operate independently
e.g. PANA authentication first then DHC address assignment etc.
That doesn't allow you to assign different addresses for different classes
of authenticated devices though.

  Erik

---

From: Ralph Droms <[email-masked]>
Date: Thu, 13 Mar 2003 13:35:50 -0500

I don't understand how PANA can be used first - the requirements doc says:

    PANA does not perform any address assignment functions
    but MUST only be invoked after the client has a usable
    IP address (e.g., a link-local address in IPv6 or a
    DHCP-learned address in IPv4)

- Ralph

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 13 Mar 2003 14:45:14 -0500

The latest version of PANA requirements draft says:
(it missed the submission deadline, but it is available on 
 http://www.toshiba.com/tari/pana/draft-ietf-pana-requirements-05.txt)

4.2. IP Address Assignment

   Providing address assignment functionality is outside the scope
   of PANA. PANA protocol design MAY require the PaC to configure
   an IP address before using this protocol. Allocating an IP address
   to unauthenticated PaCs may enable security vulnerabilities, such as
   IP address depletion attacks on the access network [SECTHREAT]. This
   threat may not be an issue for IPv6 because of the large address
   space, but it can effect IPv4 deployments. Such a threat can be
   mitigated by allowing the protocol to run without an IP address on
   the PaC (e.g., using unspecified source address), but this choice 
   might limit the re-use of existing security mechanisms, and impose
   additional implementation complexity. This trade off should be taken
   into consideration in designing PANA.

Yoshihiro Ohba