< draft-perkins-aaav6-05.txt		draft-perkins-aaav6-06.txt >
	IPng Working Group Patrik Flykt		Submitted to AAA Working Group Charles E. Perkins
	INTERNET DRAFT Charles E. Perkins		INTERNET DRAFT Ernie Tacsik
	1 March 2002 Nokia		1 May 2003 Nokia
	Thomas Eklund		Thomas Eklund
	Xelerated Networks		Xelerated Networks
	AAA for IPv6 Network Access		AAA for IPv6 Network Access
	draft-perkins-aaav6-05.txt		draft-perkins-aaav6-06.txt
	Status of This Memo		Status of This Memo
	This document is a submission by the ipng Working Group of the
	Internet Engineering Task Force (IETF). Comments should be submitted
	to the ipng@sunroof.eng.sun.com mailing list.
	Distribution of this memo is unlimited.		Distribution of this memo is unlimited.
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026. Internet-Drafts are working		all provisions of Section 10 of RFC2026. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at		and may be updated, replaced, or obsoleted by other documents at
	skipping to change at page 1, line 117 ¶		skipping to change at page 1, line 113 ¶
	10.6. Generalized Key Reply option . . . . . . . . . . . . . . 29		10.6. Generalized Key Reply option . . . . . . . . . . . . . . 29
	11. Security Considerations 30		11. Security Considerations 30
	12. Open Issues and Discussion 30		12. Open Issues and Discussion 30
	12.1. Packet Service Filter . . . . . . . . . . . . . . . . . . 30		12.1. Packet Service Filter . . . . . . . . . . . . . . . . . . 30
	12.2. Use of Destination Options . . . . . . . . . . . . . . . 30		12.2. Use of Destination Options . . . . . . . . . . . . . . . 30
	12.3. AAAL . . . . . . . . . . . . . . . . . . . . . . . . . . 30		12.3. AAAL . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	12.4. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 30		12.4. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 30
			Contributors 31
	References 31		References 31
	Addresses 32		Addresses 32
	1. Introduction		1. Introduction
	This document proposes a way for IPv6 nodes (clients) to offer		This document proposes a way for IPv6 nodes (clients) to offer
	credentials to a local AAA server in order to be granted access to		credentials to a local AAA server in order to be granted access to
	the local network. Whereas for IPv4 it is not clear that routers and		the local network. Whereas for IPv4 it is not clear that routers and
	DHCP will be equipped to handle such functions, we believe that it is		DHCP will be equipped to handle such functions, we believe that it is
	skipping to change at page 29, line 5 ¶		skipping to change at page 29, line 5 ¶
	Length The Length of the option in octets not		Length The Length of the option in octets not
	including the Type and Length fields.		including the Type and Length fields.
	Subtype Currently two subtypes are defined: AAA		Subtype Currently two subtypes are defined: AAA
	Credential (0) and AAAH Authenticator (1).		Credential (0) and AAAH Authenticator (1).
	reserved 0, used for aligning the Challenge field.		reserved 0, used for aligning the Challenge field.
	Security Data The actual payload.		Security Data The actual payload.
	10.6. Generalized Key Reply option		10.6. Generalized Key Reply option
	0 1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = TBD | Length |		| Type = TBD | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Subtype | reserved |		| Subtype | reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| AAAH SPI |		| AAAH SPI |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Key SPI |		| Key SPI |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Encoded Key...		| Encoded Key...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type The Type field identifies the option as a Timestamp		Type The Type field identifies the option as a Timestamp
	option.		option.
	Length The Length of the option in octets not including the		Length The Length of the option in octets not including
	Type and Length fields.		The Type and Length fields.
	Subtype Currently three pairs of subtypes are defined:		Subtype Currently three pairs of subtypes are defined:
	Client-Attendant authentication key: Key to be used between the current attendant and		Client-Attendant authentication key: Key to be used
	the client for IPSec authentication (1)		between the current attendant and the client for
			IPSec authentication (1)
	Client-Attendant encryption key: Key to be used between the current attendant and		Client-Attendant encryption key: Key to be used
	the client for IPsec encryption (2)		between the current attendant and the client for
			IPsec encryption (2)
	MN-HA authentication key: Key to be used between the home agent and the		MN-HA authentication key: Key to be used between
	client for IPsec authentication (4)		The home agent and the client for Ipsec
			authentication (4)
	reserved 0, used for aligning the next field.		reserved 0, used for aligning the next field.
	AAAH SPI This field indicates the security association		AAAH SPI This field indicates the security association
	between the client and AAAH which should be used by		between the client and AAAH which should be used by
	the client to interpret the Encoded Key Data field.		the client to interpret the Encoded Key Data field.
	Key SPI This field indicates the SPI value for the new		Key SPI This field indicates the SPI value for the new
	security association into which the key should be		security association into which the key should be
	inserted.		inserted.
	Encoded Key This field contains the key, along with any other		Encoded Key This field contains the key, along with any other
	information required by the client to create the		information required by the client to create the
	security association. The contents of the field		security association. The contents of the field
	MUST be encrypted by AAAH as specified by AAAH SPI.		MUST be encrypted by AAAH as specified by AAAH SPI.
	11. Security Considerations		11. Security Considerations
	Source address based packet filtering does not guarantee that only		Source address based packet filtering does not guarantee that only
	authorized clients will be able to send out traffic through the		authorized clients will be able to send out traffic through the
	router. An attacker can fake the source address of IP packets. In		router. An attacker can fake the source address of IP packets. In
	situations where strong protection is needed, clients should be		situations where strong protection is needed, clients should be
	required to use an IPSec AH tunnel to the router.		required to use an IPSec AH tunnel to the router.
	12. Open Issues and Discussion		12. Open Issues and Discussion
	skipping to change at page 31, line 5 ¶		skipping to change at page 31, line 5 ¶
	received from the AAAH, the AAAL SHOULD have some means to enforce		received from the AAAH, the AAAL SHOULD have some means to enforce
	these. In this case the AAAL SHOULD also enforce some form of		these. In this case the AAAL SHOULD also enforce some form of
	filtering separate from the DHCP infrastructure.		filtering separate from the DHCP infrastructure.
	12.4. Other		12.4. Other
	How are the AAA Credentials computed?		How are the AAA Credentials computed?
	Do we need the padding in the DHCPv6 options?		Do we need the padding in the DHCPv6 options?
			Contributors
			Patrik Flykt (Nokia)
	References		References
	[1] B. Aboba and M. Beadles. The Network Access Identifier.		[1] B. Aboba and M. Beadles. The Network Access Identifier.
	Request for Comments (Proposed Standard) 2486, Internet		Request for Comments (Proposed Standard) 2486, Internet
	Engineering Task Force, January 1999.		Engineering Task Force, January 1999.
	[2] L. Blunk and J. Vollbrecht. PPP Extensible Authentication		[2] L. Blunk and J. Vollbrecht. PPP Extensible Authentication
	Protocol (EAP). Request for Comments (Proposed Standard) 2284,		Protocol (EAP). Request for Comments (Proposed Standard) 2284,
	Internet Engineering Task Force, March 1998.		Internet Engineering Task Force, March 1998.
	skipping to change at page 32, line 9 ¶		skipping to change at page 32, line 9 ¶
	December 2001.		December 2001.
	[10] S. Thomson and T. Narten. IPv6 Stateless Address		[10] S. Thomson and T. Narten. IPv6 Stateless Address
	Autoconfiguration. Request for Comments (Draft Standard) 2462,		Autoconfiguration. Request for Comments (Draft Standard) 2462,
	Internet Engineering Task Force, December 1998.		Internet Engineering Task Force, December 1998.
	Addresses		Addresses
	Questions about this memo can be directed to the authors:		Questions about this memo can be directed to the authors:
	Patrik Flykt Thomas Eklund		Ernie Tacsik Thomas Eklund
	Nokia Networks Xelerated Networks		Nokia Inc. Xelerated Networks
	P.O. Box 321 Regeringsgatan 67		6000 Connection Drive 3:1000 Regeringsgatan 67
	FIN-00045 NOKIA GROUP		Irving, Texas 75039
	103 86 Stockholm		USA 103 86 Stockholm
	Finland Sweden		Sweden
	Phone: +358 7180 39420 Phone: +46 8 50625753		Phone: +1 972 894 4044 Phone: +46 8 50625753
	E-mail: patrik.flykt@nokia.com E-mail: thomas.eklund@xelerated.com		E-mail: ernie.tacsik@nokia.com E-mail: thomas.eklund@xelerated.com
	Fax: +358 9 511 68080 Fax: +46 8 54553211		Fax: +1 972 894 5525 Fax: +46 8 54553211
	Charles E. Perkins		Charles E. Perkins
	Communications Systems Lab		Communications Systems Lab
	Nokia Research Center		Nokia Research Center
	313 Fairchild Drive		313 Fairchild Drive
	Mountain View, California 94043		Mountain View, California 94043
	USA		USA
	Phone: +1-650 625-2986		Phone: +1-650 625-2986
	EMail: charliep@iprg.nokia.com		EMail: charliep@iprg.nokia.com
	Fax: +1 650 625-2502		Fax: +1 650 625-2502
End of changes. 18 change blocks.
	53 lines changed or deleted		58 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/