< draft-ietf-pkix-wlan-extns-04.txt		draft-ietf-pkix-wlan-extns-05.txt >
	PKIX Working Group R. Housley		PKIX Working Group R. Housley
	Internet-Draft RSA Laboratories		Internet-Draft Vigil Security
	December 2002 T. Moore		March 2004 T. Moore
	Expires: June 2003 Microsoft		Expires: September 2004 Microsoft
	Certificate Extensions and Attributes Supporting		Certificate Extensions and Attributes Supporting
	Authentication in PPP and Wireless LAN		Authentication in PPP and Wireless LAN
	<draft-ietf-pkix-wlan-extns-04.txt>		<draft-ietf-pkix-wlan-extns-05.txt>
	Status of this Memo		Status of this Memo
	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.		all provisions of Section 10 of RFC2026.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	purpose consistent with both extensions. If there is no purpose		purpose consistent with both extensions. If there is no purpose
	consistent with both critical extensions, then the certificate MUST		consistent with both critical extensions, then the certificate MUST
	NOT be used for any purpose.		NOT be used for any purpose.
	3. WLAN SSID Public Key Certificate Extension		3. WLAN SSID Public Key Certificate Extension
	The Wireless LAN (WLAN) System Service identifiers (SSIDs) public key		The Wireless LAN (WLAN) System Service identifiers (SSIDs) public key
	certificate extension is always non-critical. It contains a list of		certificate extension is always non-critical. It contains a list of
	SSIDs. When more than one certificate includes an extended key usage		SSIDs. When more than one certificate includes an extended key usage
	extension indicating that the certified public key is appropriate for		extension indicating that the certified public key is appropriate for
	use with the EAP in the LAN environment, the list of SSIDs MAY be		use with the EAP in the LAN environment, then the list of SSIDs MAY
	used to select the correct certificate for authentication in a		be used to select the correct certificate for authentication in a
	particular WLAN.		particular WLAN.
			Since SSID values are unmanaged, the same SSID can appear in
			different certificates that are intended to be used with different
			WLANs. When this occurs, automatic selection of the certificate will
			fail, and the implementation SHOULD obtain help from the user to
			choose the correct certificate. In cases where a human user is
			unavailable, each potential certificate MAY be tried until one
			succeeds. However, by maintaining a cache of Access Point (AP) MAC
			addresses or authentication server identity with which the
			certificate has successfully authenticated, user involvement can be
			minimized. RADIUS [RADIUS1, RADIUS2] is usually used as the
			authentication service in WLAN deployments. The cache can be used to
			avoid future human user interaction or certificate selection by
			trial-and-error.
	The WLAN SSID extension is identified by id-pe-wlanSSID.		The WLAN SSID extension is identified by id-pe-wlanSSID.
	id-pe OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)		id-pe OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
	dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1 }		dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1 }
	id-pe-wlanSSID OBJECT IDENTIFIER ::= { id-pe 13 }		id-pe-wlanSSID OBJECT IDENTIFIER ::= { id-pe 13 }
	The syntax for the WLAN SSID extension is:		The syntax for the WLAN SSID extension is:
	SSIDList ::= SEQUENCE SIZE (1..MAX) OF SSID		SSIDList ::= SEQUENCE SIZE (1..MAX) OF SSID
	skipping to change at page 5, line 10 ¶		skipping to change at page 5, line 24 ¶
	The procedures and practices employed by the certification authority		The procedures and practices employed by the certification authority
	(CA) MUST ensure that the correct values for the extended key usage		(CA) MUST ensure that the correct values for the extended key usage
	extension and SSID extension are inserted in each certificate that is		extension and SSID extension are inserted in each certificate that is
	issued. Relying parties may accept or reject a particular		issued. Relying parties may accept or reject a particular
	certificate for an intended use based on the information provided in		certificate for an intended use based on the information provided in
	these extensions. Incorrect representation of the information in		these extensions. Incorrect representation of the information in
	either extension could cause the relying party to reject an otherwise		either extension could cause the relying party to reject an otherwise
	appropriate certificate or accept a certificate that ought to be		appropriate certificate or accept a certificate that ought to be
	rejected.		rejected.
			If multiple SSIDs are included in a certificate, then information can
			be obtained from a certificate about the SSIDs associated with
			several WLANs, not the WLAN that is currently being accessed. The
			intended use of the SSID extensions is to help a client determine the
			correct certificate to present when trying to gain access to a WLAN.
			In most situations, including EAP-TLS, the client will have the
			opportunity to validate the certificate provided by the server before
			transmitting one of its own certificates to the server. While the
			client may not be sure that the server has access to the
			corresponding private key until later in the protocol exchange, the
			identity information in the server certificate can be used to
			determine whether or not the client certificate ought to be provided.
			When the same client certificate is used to authenticate to multiple
			WLANs, the list of SSIDs is available servers associated with each
			WLAN. Of course, the list of SSIDs is also made available to any
			eavesdroppers on the WLAN. Whenever this SSID disclosure is a
			concern, different client certificates ought to be used for the each
			WLAN.
			SSID values are unmanaged; therefore SSIDs may not be unique. Hence,
			it is possible for client certificates that are intended to be used
			with different WLANs to contain the same SSID. In this case,
			automatic selection of the certificate will fail, and the
			implementation SHOULD obtain help from the user to choose the correct
			certificate. In cases where a human user is unavailable, each
			potential certificate MAY be tried until one succeeds, disclosing the
			list of SSIDs associated with each certificate, which might otherwise
			not be disclosed. Therefore, it is RECOMMENDED that sequentially
			trying each certificate only be employed when user selection is
			unavailable or impractical.
			In practice, disclosure of the SSID is of little concern. Some WLAN
			security experts recommend that the SSID be masked in the beacon sent
			out by Access Points (APs). The intent is to make it harder for an
			attacker to find the correct AP to target. However, other WLAN
			management messages include the SSID, so this practice only forces
			the attacker to eavesdrop on the WLAN management messages instead of
			the beacon. Therefore, placing the SSID in the certificate does not
			make matters worse.
	6. IANA Considerations		6. IANA Considerations
	Certificate extensions and extended key usage values are identified		Certificate extensions and extended key usage values are identified
	by object identifiers (OIDs). Some of the OIDs used in this document		by object identifiers (OIDs). Some of the OIDs used in this document
	are copied from X.509 [X.509]. Other OIDs were assigned from an arc		are copied from X.509 [X.509]. Other OIDs were assigned from an arc
	delegated by the IANA. No further action by the IANA is necessary		delegated by the IANA. No further action by the IANA is necessary
	for this document or any anticipated updates.		for this document or any anticipated updates.
	7. References		7. References
	Normative and informative references are provided.		Normative and informative references are provided.
	7.1. Normative References		7.1. Normative References
	[ACPROFILE] Farrell, S., and R. Housley, "An Internet Attribute		[ACPROFILE] Farrell, S., and R. Housley, "An Internet Attribute
	Certificate Profile for Authorization", RFC 3281,		Certificate Profile for Authorization", RFC 3281,
	skipping to change at page 6, line 17 ¶		skipping to change at page 7, line 23 ¶
	[EAP] Blunk, L. and J. Vollbrecht, "PPP Extensible		[EAP] Blunk, L. and J. Vollbrecht, "PPP Extensible
	Authentication Protocol (EAP)", RFC2284, March 1998.		Authentication Protocol (EAP)", RFC2284, March 1998.
	[EAPTLS] Aboba, B. and D. Simon, "PPP EAP TLS Authentication		[EAPTLS] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
	Protocol", RFC2716, October 1999.		Protocol", RFC2716, October 1999.
	[PPP] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",		[PPP] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
	STD 51, RFC 1661, July 1994.		STD 51, RFC 1661, July 1994.
			[RADIUS1] Rigney, C., S. Willens, A. Rubens, and W. Simpson, "Remote
			Authentication Dial In User Service (RADIUS)", RFC 2865,
			June 2000.
			[RADIUS2] Congdon, P., B. Aboba, A. Smith, G. Zorn, and J. Roese,
			"IEEE 802.1X Remote Authentication Dial In User Service
			(RADIUS) Usage Guidelines", RFC 3580, September 2003.
	8. ASN.1 Module		8. ASN.1 Module
	WLANCertExtn		WLANCertExtn
	{ iso(1) identified-organization(3) dod(6) internet(1)		{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)		security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-wlan-extns(24) }		id-mod-wlan-extns(24) }
	DEFINITIONS IMPLICIT TAGS ::=		DEFINITIONS IMPLICIT TAGS ::=
	BEGIN		BEGIN
	skipping to change at page 7, line 4 ¶		skipping to change at page 8, line 18 ¶
	-- Extended Key Usage Values		-- Extended Key Usage Values
	id-kp-eapOverPPP OBJECT IDENTIFIER ::= { id-kp 13 }		id-kp-eapOverPPP OBJECT IDENTIFIER ::= { id-kp 13 }
	id-kp-eapOverLAN OBJECT IDENTIFIER ::= { id-kp 14 }		id-kp-eapOverLAN OBJECT IDENTIFIER ::= { id-kp 14 }
	-- Wireless LAN SSID Extension		-- Wireless LAN SSID Extension
	id-pe-wlanSSID OBJECT IDENTIFIER ::= { id-pe 13 }		id-pe-wlanSSID OBJECT IDENTIFIER ::= { id-pe 13 }
	SSIDList ::= SEQUENCE SIZE (1..MAX) OF SSID		SSIDList ::= SEQUENCE SIZE (1..MAX) OF SSID
	SSID ::= OCTET STRING (SIZE (1..32))		SSID ::= OCTET STRING (SIZE (1..32))
	-- Wireless LAN SSID Attribute Certificate Attribute		-- Wireless LAN SSID Attribute Certificate Attribute
	-- Uses same syntax as the certificate extension: SSIDList		-- Uses same syntax as the certificate extension: SSIDList
	id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 6 }		id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 6 }
	END		END
	9. Author's Address		9. 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.
			10. Author's Address
	Russell Housley		Russell Housley
	RSA Laboratories		Vigil Security, LLC
	918 Spring Knoll Drive		918 Spring Knoll Drive
	Herndon, VA 20170		Herndon, VA 20170
	USA		USA
	rhousley@rsasecurity.com		housley@vigilsec.com
	Tim Moore		Tim Moore
	Microsoft Corporation		Microsoft Corporation
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	USA		USA
	timmoore@microsoft.com		timmoore@microsoft.com
	10. Full Copyright Statement		11. Full Copyright Statement
	Copyright (C) The Internet Society 2002. All Rights Reserved.		Copyright (C) The Internet Society 2004. All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
End of changes. 13 change blocks.
	12 lines changed or deleted		99 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/