< draft-manner-nsis-nslp-auth-02.txt		draft-manner-nsis-nslp-auth-03.txt >
	Network Working Group J. Manner		Network Working Group J. Manner
	Internet-Draft University of Helsinki		Internet-Draft TKK
	Intended status: Standards Track M. Stiemerling		Intended status: Standards Track M. Stiemerling
	Expires: April 26, 2007 NEC		Expires: September 4, 2007 NEC
	H. Tschofenig		H. Tschofenig
	Siemens Networks GmbH & Co KG		Siemens Networks GmbH & Co KG
	October 23, 2006		March 3, 2007
	Authorization for NSIS Signaling Layer Protocols		Authorization for NSIS Signaling Layer Protocols
	draft-manner-nsis-nslp-auth-02.txt		draft-manner-nsis-nslp-auth-03.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 26, 2007.		This Internet-Draft will expire on September 4, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	Signaling layer protocols in the NSIS working group may rely on GIST		Signaling layer protocols in the NSIS working group may rely on GIST
	to handle authorization. Still, in certain cases, the signaling		to handle authorization. Still, the signaling layer protocol itself
	layer protocol may require separate authorization to be performed		may require separate authorization to be performed when a node
	when a node receives a request for a certain kind of service or		receives a request for a certain kind of service or resources. This
	resources. This draft presents a generic model and object formats		draft presents a generic model and object formats for session
	for session authorization within the NSIS Signaling Layer Protocols.		authorization within the NSIS Signaling Layer Protocols. The goal of
	The goal of session authorization is to allow the exchange of		session authorization is to allow the exchange of information between
	information between network elements in order to authorize the use of		network elements in order to authorize the use of resources for a
	resources for a service and to coordinate actions between the		service and to coordinate actions between the signaling and transport
	signaling and transport planes.		planes.
	Table of Contents		Table of Contents
	1. Conventions used in this document . . . . . . . . . . . . . . 4		1. Conventions used in this document . . . . . . . . . . . . . . 4
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Session Authorization Object . . . . . . . . . . . . . . . . . 6		3. Session Authorization Object . . . . . . . . . . . . . . . . . 6
	3.1. Session Authorization Object format . . . . . . . . . . . 6		3.1. Session Authorization Object format . . . . . . . . . . . 6
	3.2. Session Authorization Attributes . . . . . . . . . . . . . 7		3.2. Session Authorization Attributes . . . . . . . . . . . . . 7
	3.2.1. Authorizing Entity Identifier . . . . . . . . . . . . 8		3.2.1. Authorizing Entity Identifier . . . . . . . . . . . . 8
	3.2.2. Source Address . . . . . . . . . . . . . . . . . . . . 9		3.2.2. Source Address . . . . . . . . . . . . . . . . . . . . 9
	skipping to change at page 5, line 34 ¶		skipping to change at page 5, line 34 ¶
	resources by a host has been properly authorized before allowing the		resources by a host has been properly authorized before allowing the
	signaling application to commit the resource request, e.g., a QoS		signaling application to commit the resource request, e.g., a QoS
	reservation or mappings for NAT traversal. In order to meet this		reservation or mappings for NAT traversal. In order to meet this
	requirement,there must be information in the NSLP message which may		requirement,there must be information in the NSLP message which may
	be used to verify the validity of the request. This can be done by		be used to verify the validity of the request. This can be done by
	providing the host with a session authorization policy element which		providing the host with a session authorization policy element which
	is inserted into the message and verified by the network.		is inserted into the message and verified by the network.
	This document describes a generic NSLP layer session authorization		This document describes a generic NSLP layer session authorization
	policy object (AUTH_SESSION) used to convey authorization information		policy object (AUTH_SESSION) used to convey authorization information
	for the request. The requesting host inserts its authorization		for the request. The scheme is based on third-party tokens. A
	information into the NSLP message to allow verification of the		trusted third party provides authentication tokens to clients and
	network resource request. Network elements verify the request and		allows verification of the information by the network elements. The
	then process the resource reservation message based on admission		requesting host inserts its authorization information acquired from
			the trusted third party into the NSLP message to allow verification
			of the network resource request. Network elements verify the request
			and then process the resource reservation message based on admission
	policy. This work is based on RFC 3520 [RFC3520] and RFC 3521		policy. This work is based on RFC 3520 [RFC3520] and RFC 3521
	[RFC3521].		[RFC3521].
			The default operation of the authorization is to add one
			authorization policy object. Yet, in order to support end-to-end
			signaling and request authorization from different networks, a host
			initiating an NSLP signaling session may add more than one
			AUTH_SESSION object in the message. The identifier of the
			authorizing entity can be used by the network elements to use the
			third party they trust to verify the request.
	3. Session Authorization Object		3. Session Authorization Object
	This section presents a new NSLP layer object called session		This section presents a new NSLP layer object called session
	authorization (AUTH_SESSION). The AUTH_SESSION object can be used in		authorization (AUTH_SESSION). The AUTH_SESSION object can be used in
	the currently specified and future NSLP protocols.		the currently specified and future NSLP protocols.
	The authorization attributes follow the format and specification		The authorization attributes follow the format and specification
	given in RFC3520 [RFC3520].		given in RFC3520 [RFC3520].
	3.1. Session Authorization Object format		3.1. Session Authorization Object format
	skipping to change at page 29, line 11 ¶		skipping to change at page 29, line 11 ¶
	This document is based on the RFC 3520 [RFC3520] and credit therefore		This document is based on the RFC 3520 [RFC3520] and credit therefore
	goes to the authors of RFC 3520, namely Louis-Nicolas Hamer, Brett		goes to the authors of RFC 3520, namely Louis-Nicolas Hamer, Brett
	Kosinski, Bill Gage and Hugh Shieh.		Kosinski, Bill Gage and Hugh Shieh.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-nsis-nslp-natfw]		[I-D.ietf-nsis-nslp-natfw]
	Stiemerling, M., "NAT/Firewall NSIS Signaling Layer		Stiemerling, M., "NAT/Firewall NSIS Signaling Layer
	Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-12 (work in		Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-13 (work in
	progress), June 2006.		progress), October 2006.
	[I-D.ietf-nsis-ntlp]		[I-D.ietf-nsis-ntlp]
	Schulzrinne, H. and R. Hancock, "GIST: General Internet		Schulzrinne, H. and R. Hancock, "GIST: General Internet
	Signaling Transport", draft-ietf-nsis-ntlp-11 (work in		Signalling Transport", draft-ietf-nsis-ntlp-12 (work in
	progress), August 2006.		progress), March 2007.
	[I-D.ietf-nsis-qos-nslp]		[I-D.ietf-nsis-qos-nslp]
	Manner, J., "NSLP for Quality-of-Service Signaling",		Manner, J., "NSLP for Quality-of-Service Signaling",
	draft-ietf-nsis-qos-nslp-11 (work in progress), June 2006.		draft-ietf-nsis-qos-nslp-12 (work in progress),
			October 2006.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography		[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
	Standards (PKCS) #1: RSA Cryptography Specifications		Standards (PKCS) #1: RSA Cryptography Specifications
	Version 2.1", RFC 3447, February 2003.		Version 2.1", RFC 3447, February 2003.
	[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den		[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
	Bosch, "Next Steps in Signaling (NSIS): Framework",		Bosch, "Next Steps in Signaling (NSIS): Framework",
	skipping to change at page 31, line 8 ¶		skipping to change at page 31, line 8 ¶
	[RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for		[RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for
	Session Set-up with Media Authorization", RFC 3521,		Session Set-up with Media Authorization", RFC 3521,
	April 2003.		April 2003.
	[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",		[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
	RFC 3852, July 2004.		RFC 3852, July 2004.
	Authors' Addresses		Authors' Addresses
	Jukka Manner		Jukka Manner
	University of Helsinki		Helsinki University of Technology (TKK)
	P.O. Box 68		P.O. Box 5400
	University of Helsinki FIN-00014 University of Helsinki		Espoo FIN-02015 TKK
	Finland		Finland
	Phone: +358 9 191 51298		Phone: +358 9 451 4161
	Email: jmanner@cs.helsinki.fi		Email: jmanner@tml.hut.fi
	URI: http://www.cs.helsinki.fi/u/jmanner/		URI: http://www.tml.tkk.fi/~jmanner/
	Martin Stiemerling		Martin Stiemerling
	Network Laboratories, NEC Europe Ltd.		Network Laboratories, NEC Europe Ltd.
	Kurfuersten-Anlage 36		Kurfuersten-Anlage 36
	Heidelberg 69115		Heidelberg 69115
	Germany		Germany
	Phone: +49 (0) 6221 4342 113		Phone: +49 (0) 6221 4342 113
	Email: stiemerling@netlab.nec.de		Email: stiemerling@netlab.nec.de
	URI: http://www.stiemerling.org		URI: http://www.stiemerling.org
	skipping to change at page 32, line 7 ¶		skipping to change at page 32, line 7 ¶
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bavaria 81739		Munich, Bavaria 81739
	Germany		Germany
	Phone: +49 89 636 40390		Phone: +49 89 636 40390
	Email: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@siemens.com
	URI: http://www.tschofenig.com		URI: http://www.tschofenig.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
End of changes. 16 change blocks.
	35 lines changed or deleted		47 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/