DHC Working Group Y. Zhao
Internet-Draft Huawei Technologies Co.,Ltd
Intended status: Standards Track February 28, 2007
Expires: September 1, 2007
DHCP User-based Authentication
draft-zhao-dhc-user-authentication-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 1, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document defines a mechanism to couple DHCP to an
authentication, authorization and accounting (AAA) system in an
access network, thus enabling users to supply user credentials for
AAA via DHCP.
Zhao Expires September 1, 2007 [Page 1]
Internet-Draft DHCP User-based Authentication February 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 4
3. Digest Authentication . . . . . . . . . . . . . . . . . . . . 4
4. DHCPv4 Options . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. User-based Authentication Option . . . . . . . . . . . . . 6
4.1.1. Option Format . . . . . . . . . . . . . . . . . . . . 6
4.1.2. Option Format of Digest authentication . . . . . . . . 7
4.2. Relay Agent User-based authentication sub-option . . . . . 8
4.2.1. Sub-option Format . . . . . . . . . . . . . . . . . . 8
5. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 9
6. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . 9
7. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Zhao Expires September 1, 2007 [Page 2]
Internet-Draft DHCP User-based Authentication February 2007
1. Introduction
Traditionally, DHCP has mainly been used in private domains.
However, in public domain environments, DHCP will be used between a
user-equipment and a DHCP Server which is inside an Access Network
and possibly several routers away from the Access Router, such as
NAS. Network service offered via this access network is more likely
to be based on the user credentials instead of the equipment
identification.
There are two primary transitions in Digital Subscriber Line (DSL)
technologies and protocols. One is migration from ATM to Ethernet in
access network. Another is migration from PPP session to IP session
[WT-146] . In IP session, authentication is left as an open issue
needing resolution. For DHCP subscribers, authentication based on a
username and password needs to be addressed when moving to IP
session.
In the DHCP-based access environment, there lacks a means of
obtaining user credentials. In order to collect subscriber
credentials, a user-based authentication model needs to be created.
An authentication mechanism for DHCPv4 protocol messages was
developed in [RFC3118].This allows DHCP clients and servers to
authenticate each other. Our purpose differs in that we want to
authenticate a user before he or she accesses a provider network.
As [I-D.dhcv4-treat-analysis] pointed out that [RFC3118] is concerned
specifically with DHCP clients and servers authenticating themselves
to each other if required by an administrative domain. This is not
the same thing as authenticating users for establishing their
Identity, access rights, permissions, or other matters relating to
what they can view or do once connected to the network. Only one
mechanism is not sufficient and a well-secured network needs both.
Zhao Expires September 1, 2007 [Page 3]
Internet-Draft DHCP User-based Authentication February 2007
Consider the following architecture:
+--------+
AAA Protocol | AAA |
+---------------------+ Server |
| +--------+
|
|
+--------+ +-------+-------+ +--------+
| DHCP | DHCP | NAS/DHCP Relay| DHCP | DHCP |
| Client |---------| /AAA Client |--------------| Server |
+--------+ +---------------+ +--------+
Figure 1: Referenced Architecture
In some access network environments, a Network Access Server(NAS)
enabling authenticated network access acts as a DHCP relay agent to
forward requests and responses between the access client and a DHCP
server within the network. We proposes in this document that the
NAS, acting as a DHCP relay agent and a AAA client, can be used as
AAA triggers intercepting and conveying relevant information from
clients to AAA servers.
The interface between AAA server and NAS is out of the scope of this
document.
2. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Definitions for terms and acronyms used in this document are defined
in [RFC2131] .
3. Digest Authentication
The digest authentication is based on a simple challenge-response
paradigm and uses a server-specified nonce to seed the generation of
the digest value. The user retrieves the nonce and calculates a
digest(by default, the HMAC-MD5 digest) of the password, the
retrieved nonce value. In this way, the password is never sent in
the clear text.
This document defines the use of a particular technique based on the
HMAC protocol[RFC2104] using the MD5 hash[RFC1321].
Zhao Expires September 1, 2007 [Page 4]
Internet-Draft DHCP User-based Authentication February 2007
The following is an example of message flow (Success):
Client Relay/AAA Client AAA Server DHCP Server
------ ---------------- ----------- -----------
| Discover{username}| | |
| ----------------> | Challenge Request | |
| | {username} | |
| | --------------------> | |
| | Challenge Response | |
| | {username,Nonce} | |
| | <-------------------- | |
| | Discover{Nonce,username} |
| | --------------------------------------->|
| Offer{username | Offer{Nonce,username} |
| Nonce} | <---------------------------------------|
| <---------------- | | |
| | | |
| Request{username, | | |
| Nonce, digest} | | |
| ----------------> | Auth Request{username,| |
| | Nonce,digest} | |
| | --------------------> | |
| | Auth Response{success}| |
| | <-------------------- | |
| | Request |
| | --------------------------------------->|
| | Ack |
| Ack | <-------------------------------------- |
| <---------------- | | |
| | | |
Figure 2: Digest Authentication example
1. The client sends DHCP DISCOVER message by inserting the username
into User-Class option.
2. Upon receiving the DHCPDISCOVER message , relay agent extracts
the username, then sends challenge request to AAA server with
username.
3. AAA server responses Challenge Response with a challenge value .
4. Relay Agent forwards the DHCPDISCOVER message to DHCP Server by
inserting the retrieved challenge value into Relay Agent User-
based Authentication sub-option.
5. Upon receiving the forwarded DHCP DISCOVER message, DHCP Server
extracts the challenge value from Relay Agent User-based
Authentication sub-option and responses with a DHCP OFFER by
inserting the challenge to the User-based Authentication option.
Zhao Expires September 1, 2007 [Page 5]
Internet-Draft DHCP User-based Authentication February 2007
6. Relay Agent forwards the DHCP OFFER to the client.
7. Upon receiving the forwarded DHCP OFFER, client extracts the
challenge value from user-based authentication option and
calculates the digest with the user's password and the challenge
value, then sends the DHCPREQUEST by inserting username into
User-Class option and digest password into User-based
Authentication option.
8. Upon receiving DHCPREQUEST, Relay agent extracts the username,
digest password and challenge value ,then supplies the username/
digest password/challenge value information to AAA Server by
sending Auth Request message.
9. AAA server response with Auth Success Response.
10. Relay Agent forwards the DHCPREQUEST message to DHCP Server .
11. Upon receiving forwarded DHCPREQUEST message , DHCP Server
responses with DHCP ACK.
Rapid commit, defined by[RFC4039] , specifies how a two-message
exchange between client and server can dramatically decrease the
elapsed time for address assignment, a feature becoming significant
as more and more highly mobile devices desire an abbreviated address
assignment phase for short duration communications. Therefore, the
User-based Digest Authentication simply cannot be used as the
DHCPOFFER message required to return a nonce value to the client is
not present.
4. DHCPv4 Options
4.1. User-based Authentication Option
4.1.1. Option Format
The format of the DHCPv4 User-based Authentication option is shown
below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Protocol | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| User-based Authentication Information |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: User-based Authentication Option Format
Zhao Expires September 1, 2007 [Page 6]
Internet-Draft DHCP User-based Authentication February 2007
Code
TBD
length
contains the length of the protocol,algorithm and user-based
authentication Information fields in octets.
Protocol
defines the particular technique for user-authentication used in
the option.
Digest Authentication = 1
Algorithm
defines the specific algorithm within the technique identified by
the protocol field.
HMAC-MD5 = 1 (specific to Digest Authentication)
User-based Authentication Information
The authentication information, as specified by the protocol and
algorithm used in this user-authentication option
4.1.2. Option Format of Digest authentication
The format of the User-based Authentication option in a DHCPDISCOVER
message for digest authentication is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length |0 0 0 0 0 0 0 1| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the User-based Authentication option in a DHCPOFFER for
digest authentication is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length |0 0 0 0 0 0 0 1| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the User-based Authentication option in a DHCPREQUEST/
DHCPACK for a digest authentication is:
Zhao Expires September 1, 2007 [Page 7]
Internet-Draft DHCP User-based Authentication February 2007
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length |0 0 0 0 0 0 0 1| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Digest ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nonce
a random value which is used by HMAC-MD5
Digest
the result by using the Digest generating function HMAC-MD5.
The sender computes the Digest using the HMAC[RFC2104] generation
algorithm and the MD5[RFC1321] hash function. The password including
is used as input to the HMAC-MD5 computation function. The 'nonce'
field MUST be set to the random value used to generate the Digest.
Algorithm 1 specifies the use of HMAC-MD5. Use of a different
technique, such as HMAC-SHA, will be specified as a separate
algorithm.
4.2. Relay Agent User-based authentication sub-option
4.2.1. Sub-option Format
In digest authentication mechanism, NAS uses this sub-option to carry
the challenge value to DHCP server.
This sub-option is a new sub-option for the DHCP Relay Agent
Information option.
Zhao Expires September 1, 2007 [Page 8]
Internet-Draft DHCP User-based Authentication February 2007
The format of the relay agent user-based sub-option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: User-based authentication sub-option Format
Code
TBD
length
The sub-option length.
data
This field contains a random challenge value
5. DHCP Client Behavior
The username and password are provided by the user at the beginning
of the DHCP.
The DHCP client SHOULD inserts the username in the User-Class
option[RFC3004]. The username SHOULD be in the form of a Network
Access Identifier (NAI) [RFC2486] .
In digest authentication mechanism:
o The client MUST include the User-based Authentication option in
its DHCPDISCOVER message by setting protocol field to 1 .
o If the client receives a DHCPOFFER message including the User-
based Authentication option, it extracts the challenge value from
the nonce field of the User-based Authentication option and
computes the digest using HMAC-MD5, with password and challenge
value as input parameters, else the client SHOULD ignore the
DHCPOFFER.
o The client replies with a DHCPREQUEST that MUST include User-based
Authentication information by setting the digest field to the
computed digest value .
o If the client receives a DHCPACK message without the User-based
Authentication option, it SHOULD ignore the DHCPACK.
6. DHCP Relay Agent Behavior
In digest authentication mechanism:
Zhao Expires September 1, 2007 [Page 9]
Internet-Draft DHCP User-based Authentication February 2007
o If the relay agent, acting as AAA client at the same time,
receives DHCPDISCOVER message with user-based authentication
option, it SHOULD get a challenge value from AAA server or
generates the challenge value by itself.
o The relay agent forwards the challenge value to DHCP server by
inserting the challenge value into the relay agent user-based
authentication sub-option of DHCPDISCOVER .
o Upon receiving DHCPREQUEST, the relay agent , acting as an AAA
client at the same time, extracts the digest password and the
challenge value from the User-based authentication option, the
username from the user-class option, supplies the user-name/the
digest password/challenge value information to AAA server for
authentication and receives the authentication result from AAA
server
o If authentication succeed, relay agent forwards the DHCPREQUEST to
DHCP Server and MAY insert the identification and authorization
attributes into the Radius Attributes sub-option [RFC4014]. If
authentication failed, relay agent SHOULD not forward the Request
to DHCP Server.
7. DHCP Server Behavior
If the received request message is included the User-based
Authentication option, the DHCP Server SHOULD includes the User-based
Authentication option in the response message.
In digest authentication mechanism:
o Upon receiving a relayed DHCPDISCOVER message with user-based
authentication option and user-based authentication sub-option,
DHCP server extracts the challenge value from the relay agent
user-based authentication sub-option .
o The DHCP server replies with a DHCPOFFER message by inserting the
challenge value into the user-based Authentication option.
o Upon receiving a relayed DHCPREQUEST message
* If previous received DHCPDISCOVER includes a User-based
Authentication option, and the received DHCPREQUEST message
does not include a User-based Authentication option, DHCP
Server SHOULD ignore the DHCPREQUEST message.
8. Security Considerations
In digest authentication mechanism, there is a delay between request
and response Message. If the delay is too long ,it will affect the
client state machine and results in retransmission of request
message.
Zhao Expires September 1, 2007 [Page 10]
Internet-Draft DHCP User-based Authentication February 2007
The transport of the user credentials between the AAA infrastructure
and the NAS is subject to the standard RADIUS and Diameter security
consideration. No new security consideration are imposed by the
usage of this document. The security mechanisms provided by
[RFC2865] and [RFC3588] are applicable and provide adequate security
for this purpose.
The communication between the NAS/DHCP relay agent and the DHCP
server must be authenticated, integrity and replay protected.
9. IANA Considerations
IANA is requested to allocate DHCPv4 option code and DHCPv4 Relay
agent sub-option for this purpose.
10. Acknowledgements
We would like to thank Pavan Kurapati, bharat_joshi, Kostur, Andre,
Eliot Lear and Markus Kai Richard Stenberg for their comments to this
draft.
11. References
11.1. Normative References
[RFC1321] Rivest, R., "HMAC: The MD5 Message-Digest Algorithm",
RFC 1321, April 1992.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[RFC3004] Stump, G., Droms, R., and Y. Gu, "The User Class Option
for DHCP", RFC 3004, November 2000.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Zhao Expires September 1, 2007 [Page 11]
Internet-Draft DHCP User-based Authentication February 2007
Messages", RFC 3118, June 2001.
[RFC4014] Droms, R. and J. Schnizlein, "Remote Authentication
Dial-In User Service (RADIUS) Attributes Suboption for the
Dynamic Host Configuration Protocol (DHCP) Relay Agent
Information Option", RFC 4014, February 2005.
[WT-146] DSL Forum, "Internet Protocol (IP) Sessions", WT-146
(work in progress), April 2007.
11.2. Informative References
[I-D.dhcv4-treat-analysis]
Hibbs, R., Smith, C., Volz, B., and M. Zohar, "Dynamic
Host Configuration Protocol for IPv4 (DHCPv4) Threat
Analysis", draft-ietf-dhc-v4-threat-analysis-03 (work in
progress), June 2006.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for
the Dynamic Host Configuration Protocol version 4
(DHCPv4)", RFC 4039, March 2005.
Author's Address
Yuping Zhao
Huawei Technologies Co.,Ltd
Huihong Mansion,No.91 Baixia Rd.
Nanjing, Jiangsu 210001
P.R.China
Phone: +86(25)84565476
Email: zhaoyuping@huawei.com
Zhao Expires September 1, 2007 [Page 12]
Internet-Draft DHCP User-based Authentication February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Zhao Expires September 1, 2007 [Page 13]