One document matched: draft-zhao-dhc-user-authentication-00.txt
DHC Working Group Amy. Zhao
Internet-Draft Huawei Technologies Co.,Ltd
Expires: March 26, 2007 September 22, 2006
DHCP User-based Authentication
draft-zhao-dhc-user-authentication-00
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 March 26, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines an authentication mechanism to provide an
authentication for a user in an access network by means of dhcp. The
authentication mechanism described here couples DHCP to an
authentication, authorization and accounting system (AAA), thus
enabling users to supply user credentials for AAA via DHCP.
Zhao Expires March 26, 2007 [Page 1]
Internet-Draft DHCP User-based Authentication September 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 5
3. Basic Authentication . . . . . . . . . . . . . . . . . . . . . 6
4. Digest Authentication . . . . . . . . . . . . . . . . . . . . 8
5. DHCPv4 Options . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. User-based Authentication Option . . . . . . . . . . . . . 11
5.1.1. Option Format . . . . . . . . . . . . . . . . . . . . 11
5.1.2. Digest authentication Format . . . . . . . . . . . . . 12
5.2. Relay Agent User-based authentication sub-option . . . . . 13
5.2.1. Sub-option Format . . . . . . . . . . . . . . . . . . 13
5.2.2. digest authentication format . . . . . . . . . . . . . 14
6. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 16
7. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . 17
8. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
Zhao Expires March 26, 2007 [Page 2]
Internet-Draft DHCP User-based Authentication September 2006
1. Introduction
Traditionally ,DHCP has mainly been used in private domains.
Howerver, in public domain environments, the DHCP protocol will be
used between a user-equipment and a DHCP Server which is inside the
Access Network and possibly several routers away from the Access
Router, such as NAS. Network service offered via this access network
mainly need user identification instead of equipment identification,
therefore, the DHCP required a user-based authenticaiton.
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 and authorize a user before he accesses a provider
network, to apply policy to customize this access connection to
account for the service.
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.
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 enviornments, 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, be used as AAA
triggers intercepting and conveying relevant information from clients
to AAA servers.
Zhao Expires March 26, 2007 [Page 3]
Internet-Draft DHCP User-based Authentication September 2006
The interface between AAA server and NAS is out of the scope of this
document.
Zhao Expires March 26, 2007 [Page 4]
Internet-Draft DHCP User-based Authentication September 2006
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] .
Zhao Expires March 26, 2007 [Page 5]
Internet-Draft DHCP User-based Authentication September 2006
3. Basic Authentication
In basic authentication, DHCP client inserts the username and
password in clear text into the DHCP request message. The NAS,
acting as DHCP relay agent and AAA client at the same time, extracts
the username/password information from request message, and sends
this information to AAA server for user authentication. If
authenticated successfully, NAS relays the request message to DHCP
Server.
The following is an example of message flow (Success):
Client Relay/AAA Client AAA Server DHCP Server
------ ---------------- ----------- -----------
| Discover{username | | |
| password} | Auth Request{username | |
| ----------------> | Password} | |
| | --------------------> | |
| | Auth Response{success}| |
| | <-------------------- | |
| | Discover |
| | --------------------------------------->|
| | Offer |
| Offer | <---------------------------------------|
| <---------------- | | |
| Request | | |
| ----------------> | Request |
| | --------------------------------------->|
| | Ack |
| Ack | <-------------------------------------- |
| <---------------- | | |
| | | |
Figure 2: Basic Authentication example
1. The client sends DHCPDISCOVER message by inserting the username
into User-Class option and the password into User-base
Authentication option.
2. Upon receiving the DHCPDISCOVER message,Relay agent extracts the
username and password, then supplies the username/password
information to AAA Server by sending Auth Request message.
3. AAA server response with Auth Success Response.
4. Relay Agent forwards the DHCPDISCOVER message to DHCP Server by
inserting the authentication result into Relay agent user-based
authentication sub-option.
Zhao Expires March 26, 2007 [Page 6]
Internet-Draft DHCP User-based Authentication September 2006
5. Upon receiveing forwarded DHCPDISCOVER message with successful
authentication result in Relay agent user-based authentication
sub-option, DHCP Server reponses with DHCP OFFER.
The mechanism is not considered to be a secure method of user
authentication, as the user name and password are passed over the
network as cleartext.
Zhao Expires March 26, 2007 [Page 7]
Internet-Draft DHCP User-based Authentication September 2006
4. Digest Authentication
In digest authentication, user's password is not sent in clear-text.
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..
This document defines the use of a particular technique based on the
HMAC protocol[RFC2104] using the MD5 hash[RFC1321].
The following is an example of message flow (Success):
Client Relay/AAA Client AAA Server DHCP Server
------ ---------------- ----------- -----------
| Discover{username}| | |
| ----------------> | Challenge Request | |
| | {usename} | |
| | --------------------> | |
| | Challenge Response | |
| | {username,Nonce} | |
| | <-------------------- | |
| | Discover{Nonce,username} |
| | --------------------------------------->|
| Offer{username | Offer{Nonce,username} |
| Nonce} | <---------------------------------------|
| <---------------- | | |
| Request{username, | | |
| Nonce,encrypted | | |
| password} | Auth Request{username,| |
| ----------------> | Nonce,encrypted | |
| | password} | |
| | --------------------> | |
| | Auth Response{success}| |
| | <-------------------- | |
| | Request |
| | --------------------------------------->|
| | Ack |
| Ack | <-------------------------------------- |
| <---------------- | | |
| | | |
Figure 3: Digest Authentication example
Zhao Expires March 26, 2007 [Page 8]
Internet-Draft DHCP User-based Authentication September 2006
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 response 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 reponses with a DHCP OFFER by
inserting the challenge to the User-based Authentication option.
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 Succes Response.
10. Relay Agent forwards the DHCPREQUEST message to DHCP Server by
inserting the authentication result into Relay agent user-based
authentication sub-option.
11. Upon receiving forwarded DHCPREQUEST message with successful
authentication in Relay agent user-based authentication sub-
option, 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
Zhao Expires March 26, 2007 [Page 9]
Internet-Draft DHCP User-based Authentication September 2006
DHCPOFFER message required to return a nonce value to the client is
not present.
The Digest authentication mechanism described here is a replacement
for Basic authentication and nothing more. It is not as secure as
Kerberos, and not as secure as any client-side private-key mechanism.
Nevertheless it is better than nothing, and better than Basic
authentication.
Zhao Expires March 26, 2007 [Page 10]
Internet-Draft DHCP User-based Authentication September 2006
5. DHCPv4 Options
5.1. User-based Authentication Option
5.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 4: User-based Authentication Option Format
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.
Basic Authentication = 0
Digest Authentication = 1
Algorithm
defines the specific algorithm within the technique identified by
the protocol field.
HMAC-MD5 = 1 (specific to Digest Authentication)
Zhao Expires March 26, 2007 [Page 11]
Internet-Draft DHCP User-based Authentication September 2006
User-based Authentication Information
The authentication information, as specified by the protocol and
algorithm used in this user-authentication option
5.1.2. Digest authentication Format
The format of the user-authentication request 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-authentication information 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-authentication information in a DHCPREQUEST/
DHCPACK for a digest authentication is:
Zhao Expires March 26, 2007 [Page 12]
Internet-Draft DHCP User-based Authentication September 2006
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.
5.2. Relay Agent User-based authentication sub-option
5.2.1. Sub-option Format
In digest authentication mechanism, NAS uses this suboption to carry
the challenge value or the authentication result to DHCP server.
This sub-option is a new suboption for the DHCP Relay Agent
Information option.
Zhao Expires March 26, 2007 [Page 13]
Internet-Draft DHCP User-based Authentication September 2006
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 | type | data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: User-based authentication sub-option Format
Code
TBD
length
the suboption length.
type
define the type of the data field
0 ----- authentication result
1 ----- random challenge value
data
if type =1, this field contains the authentication result
0 ----- FAILURE
1 ----- SUCCESS
if type =2, this field contains a random challenge value
5.2.2. digest authentication format
The format of the Relay Agent user-authentication information in a
DHCPOFFER for digest authentication is:
Zhao Expires March 26, 2007 [Page 14]
Internet-Draft DHCP User-based Authentication September 2006
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| challenge |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ challenge ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the user-authentication information in a DHCPREQUEST
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 0| result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zhao Expires March 26, 2007 [Page 15]
Internet-Draft DHCP User-based Authentication September 2006
6. DHCP Client Behavior
The username and password are provided by the user at the beginning
of the DHCP.
The DHCP client SHOUD inserts the username in the User-Class
option[RFC3004]. The username SHOULD be in the form of a Network
Access Identifier (NAI) [RFC2486] .
In basic authentication mechanism:
o The client MUST include the User-based Authentication option in
its request message by setting the Protocol field to 0 ,algorithm
field to 0 and User-based Authentication information fields to the
password,which is provided by user.
o If the received response message does not include the User-based
Authentication option, the DHCP client SHOULD ignore the received
message.
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, else the
client SHOULD ignore the DHCPOFFER.
o The client compute the digest using HMAC-MD5, with password and
challenge value as input parameters.
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.
Zhao Expires March 26, 2007 [Page 16]
Internet-Draft DHCP User-based Authentication September 2006
7. DHCP Relay Agent Behavior
In basic authentication mechanism.
o The relay agent extracts the password from the User-based
Authentication option and the user-name from user-class option.
o The relay agent, acting as an AAA client at the same time,
supplies the user-name/password information to AAA server for
authentication and receives the authentication result from AAA
server.
o The relay agent forwards the authentication result to DHCP server
by insert the result into the relay agent user-based
authentication sub-option.
In digest authentication mechanism:
o The relay agent,acting as AAA client at the same time, gets a
challenge value from AAA server or generates the challenge value
by itself.
o The relay agent forwards the challenge value to DHCP server to the
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 extracts the digest
password and the challenge value from the User-based
authentication option, the username from the user-class option.
o The relay agent, acting as an AAA client at the same time,
supplies the user-name/the digest password/challenge value
information to AAA server for authentication and receives the
authentication result from AAA server
o The relay agent forwards the authentication result to DHCP server
by inserting the result into the relay agent user-based
authentication sub-option
Zhao Expires March 26, 2007 [Page 17]
Internet-Draft DHCP User-based Authentication September 2006
8. 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 basic authentication mechanism:
o If the authentication result in the relay agent user-based
authentication sub-option is SUCCESS, The DHCP Server handles the
request message from the DHCP client according to [RFC2131]
o Otherwise, the DHCP Server replies with DHCPNAK for DHCPREQUEST.
In digest authentication mechanism:
o Upon receiving a relayed DHCPDISCOVER message, 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.
* If the authentication result in the relay agent user-based
authentication sub-option is FAILURE, DHCP server replies with
DHCPNAK.
Zhao Expires March 26, 2007 [Page 18]
Internet-Draft DHCP User-based Authentication September 2006
9. Security Considerations
In basic authentication mechanism and 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.
The transport of the user-based authentication 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.
Zhao Expires March 26, 2007 [Page 19]
Internet-Draft DHCP User-based Authentication September 2006
10. IANA Considerations
IANA is requested to allocate DHCPv4 option code and DHCPv4 Relay
agent sub-option for this purpose.
Zhao Expires March 26, 2007 [Page 20]
Internet-Draft DHCP User-based Authentication September 2006
11. Acknowledgements
Zhao Expires March 26, 2007 [Page 21]
Internet-Draft DHCP User-based Authentication September 2006
12. References
12.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
Messages", RFC 3118, June 2001.
12.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.
Zhao Expires March 26, 2007 [Page 22]
Internet-Draft DHCP User-based Authentication September 2006
Author's Address
Yuping Zhao
Huawei Technologies Co.,Ltd
Huihong Mansion,No.91 Baixia Rd.
Nanjing, Jiangsu 210001
P.R.China
Phone: +86(25)84565403
Email: zhaoyuping@huawei.com
Zhao Expires March 26, 2007 [Page 23]
Internet-Draft DHCP User-based Authentication September 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhao Expires March 26, 2007 [Page 24]
| PAFTECH AB 2003-2026 | 2026-04-24 02:46:36 |