< draft-ietf-abfab-arch-09.txt		draft-ietf-abfab-arch-10.txt >
	ABFAB J. Howlett		ABFAB J. Howlett
	Internet-Draft JANET(UK)		Internet-Draft JANET(UK)
	Intended status: Informational S. Hartman		Intended status: Informational S. Hartman
	Expires: June 9, 2014 Painless Security		Expires: July 4, 2014 Painless Security
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	E. Lear		E. Lear
	Cisco Systems GmbH		Cisco Systems GmbH
	J. Schaad		J. Schaad
	Soaring Hawk Consulting		Soaring Hawk Consulting
	December 6, 2013		December 31, 2013
	Application Bridging for Federated Access Beyond Web (ABFAB)		Application Bridging for Federated Access Beyond Web (ABFAB)
	Architecture		Architecture
	draft-ietf-abfab-arch-09.txt		draft-ietf-abfab-arch-10.txt
	Abstract		Abstract
	Over the last decade a substantial amount of work has occurred in the		Over the last decade a substantial amount of work has occurred in the
	space of federated access management. Most of this effort has		space of federated access management. Most of this effort has
	focused on two use cases: network access and web-based access.		focused on two use cases: network access and web-based access.
	However, the solutions to these use cases that have been proposed and		However, the solutions to these use cases that have been proposed and
	deployed tend to have few common building blocks in common.		deployed tend to have few common building blocks in common.
	This memo describes an architecture that makes use of extensions to		This memo describes an architecture that makes use of extensions to
	the commonly used security mechanisms for both federated and non-		the commonly used security mechanisms for both federated and non-
	federated access management, including the Remote Authentication Dial		federated access management, including the Remote Authentication Dial
	In User Service (RADIUS) and the Diameter protocol, the Generic		In User Service (RADIUS) the Generic Security Service (GSS), the
	Security Service (GSS), the Extensible Authentication Protocol (EAP)		Extensible Authentication Protocol (EAP) and the Security Assertion
	and the Security Assertion Markup Language (SAML). The architecture		Markup Language (SAML). The architecture addresses the problem of
	addresses the problem of federated access management to primarily		federated access management to primarily non-web-based services, in a
	non-web-based services, in a manner that will scale to large numbers		manner that will scale to large numbers of identity providers,
	of identity providers, relying parties, and federations.		relying parties, and federations.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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 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."
	This Internet-Draft will expire on June 9, 2014.		This Internet-Draft will expire on July 4, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 4, line 45 ¶		skipping to change at page 4, line 43 ¶
	Sometimes a Relying Party needs, or would like, to know more about		Sometimes a Relying Party needs, or would like, to know more about
	a client than an affiliation or a pseudonym. For example, a		a client than an affiliation or a pseudonym. For example, a
	Relying Party may want the Client's email address or name. Some		Relying Party may want the Client's email address or name. Some
	federated access management technologies provide the ability for		federated access management technologies provide the ability for
	the IdP to supply this information, either on request by the RP or		the IdP to supply this information, either on request by the RP or
	unsolicited.		unsolicited.
	This memo describes the Application Bridging for Federated Access		This memo describes the Application Bridging for Federated Access
	Beyond the Web (ABFAB) architecture. This architecture makes use of		Beyond the Web (ABFAB) architecture. This architecture makes use of
	extensions to the commonly used security mechanisms for both		extensions to the commonly used security mechanisms for both
	federated and non-federated access management, including the RADIUS		federated and non-federated access management, including RADIUS, the
	and the Diameter protocols, the Generic Security Service (GSS), the		Generic Security Service (GSS), the Extensible Authentication
	Extensible Authentication Protocol (EAP) and SAML. The architecture		Protocol (EAP) and SAML. The architecture should be extended to use
	addresses the problem of federated access management primarily for		Diameter in the future. The architecture addresses the problem of
	non-web-based services. It does so in a manner that will scale to		federated access management primarily for non-web-based services. It
	large numbers of identity providers, relying parties, and		does so in a manner that will scale to large numbers of identity
	federations.		providers, relying parties, and federations.
	1.1. Terminology		1.1. Terminology
	This document uses identity management and privacy terminology from		This document uses identity management and privacy terminology from
	[RFC6973]. In particular, this document uses the terms identity		[RFC6973]. In particular, this document uses the terms identity
	provider, relying party, identifier, pseudonymity, unlinkability, and		provider, relying party, identifier, pseudonymity, unlinkability, and
	anonymity.		anonymity.
	In this architecture the IdP consists of the following components: an		In this architecture the IdP consists of the following components: an
	EAP server, a RADIUS or a Diameter server, and optionally a SAML		EAP server, a RADIUS server, and optionally a SAML Assertion service.
	Assertion service.
	This document uses the term Network Access Identifier (NAI), as		This document uses the term Network Access Identifier (NAI), as
	defined in [I-D.ietf-radext-nai]. An NAI consists of a realm		defined in [I-D.ietf-radext-nai]. An NAI consists of a realm
	identifier, which is associated with an IdP and a username which is		identifier, which is associated with an IdP and a username which is
	associated with a specific client of the IdP.		associated with a specific client of the IdP.
	One of the problems people will find with reading this document is		One of the problems people will find with reading this document is
	that the terminology sometimes appears to be inconsistent. This is		that the terminology sometimes appears to be inconsistent. This is
	due the fact that the terms used by the different standards we are		due the fact that the terms used by the different standards we are
	referencing are not consistent. In general the document uses either		referencing are not consistent. In general the document uses either
	skipping to change at page 11, line 27 ¶		skipping to change at page 11, line 23 ¶
	GSS-EAP protocol) asking for the Client's name. The Client		GSS-EAP protocol) asking for the Client's name. The Client
	sends an EAP response with an NAI name form that, at a minimum,		sends an EAP response with an NAI name form that, at a minimum,
	contains the realm portion of its full NAI.		contains the realm portion of its full NAI.
	4. Discovery of federated IdP: The RP uses pre-configured		4. Discovery of federated IdP: The RP uses pre-configured
	information or a federation proxy to determine what IdP to use		information or a federation proxy to determine what IdP to use
	based on policy and the realm portion of the provided Client		based on policy and the realm portion of the provided Client
	NAI. This is discussed in detail below (Section 2.1.2).		NAI. This is discussed in detail below (Section 2.1.2).
	5. Request from Relying Party to IdP: Once the RP knows who the IdP		5. Request from Relying Party to IdP: Once the RP knows who the IdP
	is, it (or its agent) will send a RADIUS/Diameter request to the		is, it (or its agent) will send a RADIUS request to the IdP.
	IdP. The RADIUS/Diameter access request encapsulates the EAP		The RADIUS access request encapsulates the EAP response. At
	response. At this stage, the RP will likely have no idea who		this stage, the RP will likely have no idea who the client is.
	the client is. The RP sends its identity to the IdP in AAA		The RP sends its identity to the IdP in AAA attributes, and it
	attributes, and it may send a SAML Attribute Request in a AAA		may send a SAML Attribute Request in a AAA attribute. The AAA
	attribute. The AAA network checks that the identity claimed by		network checks that the identity claimed by the RP is valid.
	the RP is valid.
	6. IdP begins EAP with the client: The IdP sends an EAP message to		6. IdP begins EAP with the client: The IdP sends an EAP message to
	the client with an EAP method to be used. The IdP should not		the client with an EAP method to be used. The IdP should not
	re-request the clients name in this message, but clients need to		re-request the clients name in this message, but clients need to
	be able to handle it. In this case the IdP must accept a realm		be able to handle it. In this case the IdP must accept a realm
	only in order to protect the client's name from the RP. The		only in order to protect the client's name from the RP. The
	available and appropriate methods are discussed below in this		available and appropriate methods are discussed below in this
	memo (Section 2.2.1).		memo (Section 2.2.1).
	7. The EAP protocol is run: A bunch of EAP messages are passed		7. The EAP protocol is run: A bunch of EAP messages are passed
	skipping to change at page 12, line 21 ¶		skipping to change at page 12, line 18 ¶
	cryptographic keys: a Master Session Key (MSK), and an Extended		cryptographic keys: a Master Session Key (MSK), and an Extended
	MSK (EMSK). At this point the client has a level of assurance		MSK (EMSK). At this point the client has a level of assurance
	about the identity of the RP based on the name checking the IdP		about the identity of the RP based on the name checking the IdP
	has done using the RP naming information from the AAA framework		has done using the RP naming information from the AAA framework
	and from the client (by the channel binding data).		and from the client (by the channel binding data).
	9. Local IdP Policy Check: At this stage, the IdP checks local		9. Local IdP Policy Check: At this stage, the IdP checks local
	policy to determine whether the RP and client are authorized for		policy to determine whether the RP and client are authorized for
	a given transaction/service, and if so, what if any, attributes		a given transaction/service, and if so, what if any, attributes
	will be released to the RP. If the IdP gets a policy failure,		will be released to the RP. If the IdP gets a policy failure,
	it sends an EAP failure message to the RP.[] (The RP will have		it sends an EAP failure message to the RP. (The RP will have
	done its policy checks during the discovery process.)		done its policy checks during the discovery process.)
	10. IdP provides the RP with the MSK: The IdP sends a positive		10. IdP provides the RP with the MSK: The IdP sends a positive
	result EAP to the RP, along with an optional set of AAA		result EAP to the RP, along with an optional set of AAA
	attributes associated with the client (usually as one or more		attributes associated with the client (usually as one or more
	SAML assertions). In addition, the EAP MSK is returned to the		SAML assertions). In addition, the EAP MSK is returned to the
	RP.		RP.
	11. RP Processes Results: When the RP receives the result from the		11. RP Processes Results: When the RP receives the result from the
	IdP, it should have enough information to either grant or refuse		IdP, it should have enough information to either grant or refuse
	skipping to change at page 13, line 27 ¶		skipping to change at page 13, line 27 ¶
	| | |		| | |
	| |< - - (6) - -<| EAP method to Client		| |< - - (6) - -<| EAP method to Client
	| | |		| | |
	| |< - - (7) - ->| EAP Exchange to authenticate		| |< - - (7) - ->| EAP Exchange to authenticate
	| | | Client		| | | Client
	| | |		| | |
	| | (8 & 9) Local Policy Check		| | (8 & 9) Local Policy Check
	| | |		| | |
	|<====(10)====================<| IdP Assertion to RP		|<====(10)====================<| IdP Assertion to RP
	| | |		| | |
	(11) | | RP processes results		(11) | | RP processes results
	| | |		| | |
	|>----(12)----->| | Results to client app.		|>----(12)----->| | Results to client app.
	----- = Between Client App and RP		----- = Between Client App and RP
	===== = Between RP and IdP		===== = Between RP and IdP
	- - - = Between Client App and IdP		- - - = Between Client App and IdP (via RP)
	1.5. Design Goals		1.5. Design Goals
	Our key design goals are as follows:		Our key design goals are as follows:
	o Each party of a transaction will be authenticated, although		o Each party of a transaction will be authenticated, although
	perhaps not identified, and the client will be authorized for		perhaps not identified, and the client will be authorized for
	access to a specific resource.		access to a specific resource.
	o Means of authentication is decoupled so as to allow for multiple		o Means of authentication is decoupled so as to allow for multiple
	skipping to change at page 15, line 10 ¶		skipping to change at page 15, line 10 ¶
	The architecture consists of several building blocks, which is shown		The architecture consists of several building blocks, which is shown
	graphically in Figure 2. In the following sections, we discuss the		graphically in Figure 2. In the following sections, we discuss the
	data flow between each of the entities, the protocols used for that		data flow between each of the entities, the protocols used for that
	data flow and some of the trade-offs made in choosing the protocols.		data flow and some of the trade-offs made in choosing the protocols.
	+--------------+		+--------------+
	| Identity |		| Identity |
	| Provider |		| Provider |
	| (IdP) |		| (IdP) |
	+-^----------^-+		+-^----------^-+
	* EAP o RADIUS/		* EAP o RADIUS
	* o Diameter		* o
	--v----------v--		--v----------v--
	/// \\\		/// \\\
	// \\		// \\
	| Federation |		| Federation |
	| Substrate |		| Substrate |
	\\ //		\\ //
	\\\ ///		\\\ ///
	--^----------^--		--^----------^--
	* EAP o RADIUS/		* EAP o RADIUS
	* o Diameter		* o
	+-------------+ +-v----------v--+		+-------------+ +-v----------v--+
	| | | |		| | | |
	| Client | EAP/EAP Method | Relying Party |		| Client | EAP/EAP Method | Relying Party |
	| Application |<****************>| (RP) |		| Application |<****************>| (RP) |
	| | GSS-API | |		| | GSS-API | |
	| |<---------------->| |		| |<---------------->| |
	| | Application | |		| | Application | |
	| | Protocol | |		| | Protocol | |
	| |<================>| |		| |<================>| |
	+-------------+ +---------------+		+-------------+ +---------------+
	skipping to change at page 16, line 34 ¶		skipping to change at page 16, line 34 ¶
	o A method exists for carrying EAP packets within RADIUS [RFC3579]		o A method exists for carrying EAP packets within RADIUS [RFC3579]
	and Diameter [RFC4072].		and Diameter [RFC4072].
	o The use of EAP channel binding [RFC6677] along with the core ABFAB		o The use of EAP channel binding [RFC6677] along with the core ABFAB
	protocol provide the pieces necessary to establish the identities		protocol provide the pieces necessary to establish the identities
	of the RP and the client, while EAP provides the cryptographic		of the RP and the client, while EAP provides the cryptographic
	methods for the RP and the client to validate they are talking to		methods for the RP and the client to validate they are talking to
	each other.		each other.
	o A method exists for carrying SAML packets within RADIUS		o A method exists for carrying SAML packets within RADIUS
	[I-D.ietf-abfab-aaa-saml] and Diameter (work in progress) which		[I-D.ietf-abfab-aaa-saml] which allows the RP to query attributes
	allows the RP to query attributes about the client from the IdP.		about the client from the IdP.
	Future protocols that support the same framework but do different		Future protocols that support the same framework but do different
	routing may be used in the future. One such effort is to setup a		routing may be used in the future. One such effort is to setup a
	framework that creates a trusted point-to-point channel on the fly.		framework that creates a trusted point-to-point channel on the fly.
	2.1.1. AAA, RADIUS and Diameter		2.1.1. AAA, RADIUS and Diameter
	Interestingly, for network access authentication the usage of the AAA		Interestingly, for network access authentication the usage of the AAA
	framework with RADIUS [RFC2865] and Diameter [RFC6733] was quite		framework with RADIUS [RFC2865] and Diameter [RFC6733] was quite
	successful from a deployment point of view. To map to the		successful from a deployment point of view. To map to the
	skipping to change at page 18, line 11 ¶		skipping to change at page 18, line 11 ¶
	must be possible for the AAA client at the RP to determine where to		must be possible for the AAA client at the RP to determine where to
	send each RADIUS or Diameter message. Without this requirement, it		send each RADIUS or Diameter message. Without this requirement, it
	would be the RP's responsibility to determine the identity of the		would be the RP's responsibility to determine the identity of the
	client on its own, without the assistance of an IdP. This		client on its own, without the assistance of an IdP. This
	architecture makes use of the Network Access Identifier (NAI), where		architecture makes use of the Network Access Identifier (NAI), where
	the IdP is indicated by the realm component [I-D.ietf-radext-nai].		the IdP is indicated by the realm component [I-D.ietf-radext-nai].
	The NAI is represented and consumed by the GSS-API layer as		The NAI is represented and consumed by the GSS-API layer as
	GSS_C_NT_USER_NAME as specified in [RFC2743]. The GSS-API EAP		GSS_C_NT_USER_NAME as specified in [RFC2743]. The GSS-API EAP
	mechanism includes the NAI in the EAP Response/Identity message.		mechanism includes the NAI in the EAP Response/Identity message.
			As of the time this document was published, no profiles for the use
			of Diameter have been created.
	2.1.2. Discovery and Rules Determination		2.1.2. Discovery and Rules Determination
	While we are using the AAA protocols to communicate with the IdP, the		While we are using the AAA protocols to communicate with the IdP, the
	RP may have multiple federation substrates to select from. The RP		RP may have multiple federation substrates to select from. The RP
	has a number of criteria that it will use in selecting which of the		has a number of criteria that it will use in selecting which of the
	different federations to use:		different federations to use:
	o The federation selected must be able to communicate with the IdP.		o The federation selected must be able to communicate with the IdP.
	o The federation selected must match the business rules and		o The federation selected must match the business rules and
	skipping to change at page 36, line 9 ¶		skipping to change at page 35, line 48 ¶
	o The Relying Party knows the IP address of the Client. It is		o The Relying Party knows the IP address of the Client. It is
	possible that the Relying Party could choose to expose this IP		possible that the Relying Party could choose to expose this IP
	address by including it in a RADIUS header such as Calling Station		address by including it in a RADIUS header such as Calling Station
	ID. This is a privacy consideration to take into account of the		ID. This is a privacy consideration to take into account of the
	application protocol.		application protocol.
	o The EAP MSK is transported between the IdP and the RP over the AAA		o The EAP MSK is transported between the IdP and the RP over the AAA
	infrastructure, for example through RADIUS headers. This is a		infrastructure, for example through RADIUS headers. This is a
	particularly important privacy consideration, as any AAA Proxy		particularly important privacy consideration, as any AAA Proxy
	that has access to the EAP MSK is able to decrypt and eavesdrop on		that has access to the EAP MSK is able to decrypt and eavesdrop on
	any traffic encrypted using that EAP MSK (i.e. all communications		any traffic encrypted using that EAP MSK (i.e., all communications
	between the Client and IdP).		between the Client and RP). This problem can be mitigted by the
			application protocol setting up a secure tunnel between the Client
			and the RP and performing a cryptographic binding between the
			tunnel and EAP MSK.
	o Related to the above, the AAA server has access to the material		o Related to the above, the AAA server has access to the material
	necessary to derive the session key, thus the AAA server can		necessary to derive the session key, thus the AAA server can
	observe any traffic encrypted between the Client and RP. This		observe any traffic encrypted between the Client and RP. This
	"feature" was" chosen as a simplification and to make performance		"feature" was" chosen as a simplification and to make performance
	faster; if it was decided that this trade-off was not desirable		faster; if it was decided that this trade-off was not desirable
	for privacy and security reasons, then extensions to ABFAB that		for privacy and security reasons, then extensions to ABFAB that
	make use of techniques such as Diffie-Helman key exchange would		make use of techniques such as Diffie-Helman key exchange would
	mitigate against this.		mitigate against this.
	skipping to change at page 40, line 4 ¶		skipping to change at page 39, line 46 ¶
	easily be reverse engineered by the service provider. If it can be		easily be reverse engineered by the service provider. If it can be
	reversed then the service provider can consult an oracle to determine		reversed then the service provider can consult an oracle to determine
	if a given unique long term identifier is associated with a different		if a given unique long term identifier is associated with a different
	known identifier.		known identifier.
	6. IANA Considerations		6. IANA Considerations
	This document does not require actions by IANA.		This document does not require actions by IANA.
	7. Acknowledgments		7. Acknowledgments
	We would like to thank Mayutan Arumaithurai, Klaas Wierenga and Rhys		We would like to thank Mayutan Arumaithurai, Klaas Wierenga and Rhys
	Smith for their feedback. Additionally, we would like to thank Eve		Smith for their feedback. Additionally, we would like to thank Eve
	Maler, Nicolas Williams, Bob Morgan, Scott Cantor, Jim Fenton, Paul		Maler, Nicolas Williams, Bob Morgan, Scott Cantor, Jim Fenton, Paul
	Leach, and Luke Howard for their feedback on the federation		Leach, and Luke Howard for their feedback on the federation
	terminology question.		terminology question.
	Furthermore, we would like to thank Klaas Wierenga for his review of		Furthermore, we would like to thank Klaas Wierenga for his review of
	the pre-00 draft version.		the pre-00 draft version.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2743] Linn, J., "Generic Security Service Application Program		[RFC2743] Linn, J., "Generic Security Service Application Program
	Interface Version 2, Update 1", RFC 2743, January 2000.		Interface Version 2, Update 1", RFC 2743, January 2000.
	[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,		[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
	"Remote Authentication Dial In User Service (RADIUS)", RFC		"Remote Authentication Dial In User Service (RADIUS)", RFC
	2865, June 2000.		2865, June 2000.
	[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
	"Diameter Base Protocol", RFC 6733, October 2012.
	[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.		[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
	Levkowetz, "Extensible Authentication Protocol (EAP)", RFC		Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
	3748, June 2004.		3748, June 2004.
	[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication		[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
	Dial In User Service) Support For Extensible		Dial In User Service) Support For Extensible
	Authentication Protocol (EAP)", RFC 3579, September 2003.		Authentication Protocol (EAP)", RFC 3579, September 2003.
	[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible		[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
	Authentication Protocol (EAP) Application", RFC 4072,		Authentication Protocol (EAP) Application", RFC 4072,
	skipping to change at page 41, line 13 ¶		skipping to change at page 41, line 7 ¶
	[I-D.ietf-radext-nai]		[I-D.ietf-radext-nai]
	DeKok, A., "The Network Access Identifier", draft-ietf-		DeKok, A., "The Network Access Identifier", draft-ietf-
	radext-nai-05 (work in progress), November 2013.		radext-nai-05 (work in progress), November 2013.
	[RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding		[RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding
	Support for Extensible Authentication Protocol (EAP)		Support for Extensible Authentication Protocol (EAP)
	Methods", RFC 6677, July 2012.		Methods", RFC 6677, July 2012.
	8.2. Informative References		8.2. Informative References
			[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
			"Diameter Base Protocol", RFC 6733, October 2012.
	[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC		[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
	6749, October 2012.		6749, October 2012.
	[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,		[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
	Morris, J., Hansen, M., and R. Smith, "Privacy		Morris, J., Hansen, M., and R. Smith, "Privacy
	Considerations for Internet Protocols", RFC 6973, July		Considerations for Internet Protocols", RFC 6973, July
	2013.		2013.
	[I-D.ietf-radext-radius-fragmentation]		[I-D.ietf-radext-radius-fragmentation]
	Perez-Mendez, A., Lopez, R., Pereniguez-Garcia, F., Lopez-		Perez-Mendez, A., Lopez, R., Pereniguez-Garcia, F., Lopez-
End of changes. 19 change blocks.
	40 lines changed or deleted		45 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/