< draft-ietf-pkix-rfc3770bis-02.txt   draft-ietf-pkix-rfc3770bis-03.txt >
PKIX Working Group R. Housley PKIX Working Group R. Housley
Internet-Draft Vigil Security Internet-Draft Vigil Security
Onsoletes: RFC 3770 T. Moore Onsoletes: RFC 3770 T. Moore
April 2005 Microsoft April 2005 Microsoft
Expires: October 2005 Expires: October 2005
Certificate Extensions and Attributes Supporting Certificate Extensions and Attributes Supporting
Authentication in Point-to-Point Protocol (PPP) Authentication in Point-to-Point Protocol (PPP)
and Wireless Local Area Networks (WLAN) and Wireless Local Area Networks (WLAN)
<draft-ietf-pkix-rfc3770bis-02.txt> <draft-ietf-pkix-rfc3770bis-03.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
or will be disclosed, and any of which I become aware will be have been or will be disclosed, and any of which he or she becomes
disclosed, in accordance with RFC 3668. 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. 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 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."
skipping to change at page 2, line 12 skipping to change at page 2, line 12
key certificate extension to carry Wireless LAN (WLAN) System Service key certificate extension to carry Wireless LAN (WLAN) System Service
identifiers (SSIDs). This document obsoletes RFC 3770. identifiers (SSIDs). This document obsoletes RFC 3770.
1. Introduction 1. Introduction
Several Extensible Authentication Protocol (EAP) [EAP] authentication Several Extensible Authentication Protocol (EAP) [EAP] authentication
methods employ X.509 public key certificates. For example, EAP-TLS methods employ X.509 public key certificates. For example, EAP-TLS
[EAP-TLS] can be used with PPP [PPP] as well as IEEE 802.1X [802.1X]. [EAP-TLS] can be used with PPP [PPP] as well as IEEE 802.1X [802.1X].
PPP is used for dial-up and VPN environments. IEEE 802.1X defines PPP is used for dial-up and VPN environments. IEEE 802.1X defines
port-based, network access control, and it is used to provide port-based, network access control, and it is used to provide
authenticated network access for Ethernet, Token Ring, and Wireless authenticated network access for Ethernet, Token Ring, Wireless LANs
LANs (WLANs) [802.11]. (WLANs) [802.11], and other IEEE 802 networks.
Automated selection of certificates for PPP and IEEE 802.1X clients Automated selection of client certificates for use with PPP and IEEE
is highly desirable. By using certificate extensions to identify the 802.1X is highly desirable. By using certificate extensions to
intended environment for a particular certificate, the need for user identify the intended environment for a particular certificate, the
input is minimized. Further, the certificate extensions facilitate need for user input is minimized. Further, the certificate
the separation of administrative functions associated with extensions facilitate the separation of administrative functions
certificates used for different environments. associated with certificates used for different environments.
IEEE 802.1X can be used for authentication with multiple networks. IEEE 802.1X can be used for authentication with multiple networks.
For example, the same wireless station might use IEEE 802.1X to For example, the same wireless station might use IEEE 802.1X to
authenticate to a corporate IEEE 802.11 WLAN and a public IEEE 802.11 authenticate to a corporate IEEE 802.11 WLAN and a public IEEE 802.11
"hotspot." Each of these IEEE 802.11 WLANs has a different network "hotspot." Each of these IEEE 802.11 WLANs has a different network
name, called Service Set Identifier (SSID). If the network operators name, called Service Set Identifier (SSID). If the network operators
have a roaming agreement, then cross realm authentication allows the have a roaming agreement, then cross realm authentication allows the
same certificate to be used on both networks. However, if the same certificate to be used on both networks. However, if the
networks do not have a roaming agreement, then the IEEE 802.1X client networks do not have a roaming agreement, then the IEEE 802.1X
needs to select a certificate for the current network environment. supplicant needs to select a certificate for the current network
Including a list of SSIDs in a certificate extension facilitates environment. Including a list of SSIDs in a certificate extension
automated selection of an appropriate X.509 public key certificate facilitates automated selection of an appropriate X.509 public key
without human user input. Alternatively, a companion attribute certificate without human user input. Alternatively, a companion
certificate could contain the list of SSIDs. attribute certificate could contain the list of SSIDs.
This document defines extended key usage values and a WLAN-specific
certificate extension for use in certificates issued to clients of
PPP and WLANs.
1.1. Changes since RFC 3770 1.1. Changes since RFC 3770
This document is primarily same as RFC 3770. Three changes are This document is primarily same as RFC 3770. Three changes are
included: included:
* This document now uses the same normative reference for ASN.1 * This document now uses the same normative reference for ASN.1
as RFC 3280 [PROFILE]. The intent is to have the same as RFC 3280 [PROFILE]. The intent is to have the same
dependencies. dependencies.
* The discussion of the critical bit in the certificate extension * The discussion of the critical bit in the certificate extension
in section 2 is aligned with RFC 3280. Also, the discussion of in section 2 is aligned with RFC 3280. Also, the discussion of
the key usage certificate extension was expanded. the key usage certificate extension was expanded.
* RFC 3770 contained a typographical error in the object * RFC 3770 contained a typographical error in the object
identifier for the Wireless LAN SSID Attribute Certificate identifier for the Wireless LAN SSID Attribute Certificate
Attribute. Section 4 corrects the typographical error. Attribute. Section 4 corrects the typographical error.
* Clarified that the SSID extension may appear in certificates
that do not include the extended key usage extension.
* Uses the terms "peer", "EAP Server", and "supplicant" as they
are defined in [EAP] and [802.1X]. RFC 3770 used "client"
and "server".
1.2. Conventions Used In This Document 1.2. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [STDWORDS]. document are to be interpreted as described in RFC 2119 [STDWORDS].
1.3. Abstract Syntax Notation 1.3. Abstract Syntax Notation
All X.509 certificate [X.509] extensions are defined using ASN.1 All X.509 certificate [X.509] extensions are defined using ASN.1
[X.680,X.690]. [X.680,X.690].
skipping to change at page 3, line 34 skipping to change at page 3, line 45
The extended key usage extension syntax is repeated here for The extended key usage extension syntax is repeated here for
convenience: convenience:
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER KeyPurposeId ::= OBJECT IDENTIFIER
This specification defines two KeyPurposeId values: one for EAP over This specification defines two KeyPurposeId values: one for EAP over
PPP, and one for EAP over LAN (EAPOL). Inclusion of the EAP over PPP PPP, and one for EAP over LAN (EAPOL). Inclusion of the EAP over PPP
value indicates that the certified public key is appropriate for use value indicates that the certified public key is appropriate for use
with EAP in the PPP environment. The inclusion of the EAPOL value by a peer with EAP in the PPP environment. The inclusion of the
indicates that the certified public key is appropriate for use with EAPOL value indicates that the certified public key is appropriate
the EAP in the LAN environment. Inclusion of both values indicates for use by a peer with the EAP in the LAN environment. Inclusion of
that the certified public key is appropriate for use in either of the both values indicates that the certified public key is appropriate
environments. for use by a peer in either of the environments.
id-kp OBJECT IDENTIFIER ::= id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 3 } security(5) mechanisms(5) pkix(7) 3 }
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 }
The extended key usage extension MAY, at the option of the The extended key usage extension MAY, at the option of the
skipping to change at page 4, line 24 skipping to change at page 4, line 38
key usage extension, then both extensions MUST be processed key usage extension, then both extensions MUST be processed
independently and the certificate MUST only be used for a purpose independently and the certificate MUST only be used for a purpose
consistent with both extensions. If there is no purpose consistent consistent with both extensions. If there is no purpose consistent
with both extensions, then the certificate-using application MUST NOT with both extensions, then the certificate-using application MUST NOT
use the certificate for any purpose. use the certificate 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. The list of SSIDs MAY be used to select the correct
extension indicating that the certified public key is appropriate for certificate for authentication in a particular WLAN.
use with the EAP in the LAN environment, then the list of SSIDs MAY
be used to select the correct certificate for authentication in a If the extended key usage extension appears in the same certificate
particular WLAN. as the SSID extension, then the extended key usage extension MUST
indicate that the certified public key is appropriate for use with
the EAP in the LAN environment by including the id-kp-eapOverLAN
KeyPurposeId value.
Since SSID values are unmanaged, the same SSID can appear in Since SSID values are unmanaged, the same SSID can appear in
different certificates that are intended to be used with different different certificates that are intended to be used with different
WLANs. When this occurs, automatic selection of the certificate will WLANs. When this occurs, automatic selection of the certificate will
fail, and the implementation SHOULD obtain help from the user to fail, and the implementation SHOULD obtain help from the user to
choose the correct certificate. In cases where a human user is choose the correct certificate. In cases where a human user is
unavailable, each potential certificate MAY be tried until one unavailable, each potential certificate MAY be tried until one
succeeds. However, by maintaining a cache of Access Point (AP) MAC succeeds. However, by maintaining a cache of Access Point (AP) MAC
addresses or authentication server identity with which the addresses or EAP server identity with which the certificate has
certificate has successfully authenticated, user involvement can be successfully authenticated, user involvement can be minimized.
minimized. RADIUS [RADIUS1, RADIUS2] is usually used as the RADIUS [RADIUS1, RADIUS2] is usually used as the authentication
authentication service in WLAN deployments. The cache can be used to service in WLAN deployments. The cache can be used to avoid future
avoid future human user interaction or certificate selection by human user interaction or certificate selection by trial-and-error.
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 ::= id-pe OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 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:
skipping to change at page 6, line 10 skipping to change at page 6, line 20
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 If multiple SSIDs are included in a certificate, then information can
be obtained from a certificate about the SSIDs associated with be obtained from a certificate about the SSIDs associated with
several WLANs, not the WLAN that is currently being accessed. The several WLANs, not the WLAN that is currently being accessed. The
intended use of the SSID extensions is to help a client determine the intended use of the SSID extensions is to help a peer determine the
correct certificate to present when trying to gain access to a WLAN. correct certificate to present when trying to gain access to a WLAN.
In most situations, including EAP-TLS, the client will have the In most situations, including EAP-TLS, the peer will have the
opportunity to validate the certificate provided by the server before opportunity to validate the certificate provided by the EAP server
transmitting one of its own certificates to the server. While the before transmitting one of its own certificates to the EAP server.
client may not be sure that the server has access to the While the peer may not be sure that the EAP server has access to the
corresponding private key until later in the protocol exchange, the corresponding private key until later in the protocol exchange, the
identity information in the server certificate can be used to identity information in the EAP server certificate can be used to
determine whether or not the client certificate ought to be provided. determine whether or not the peer certificate ought to be provided.
When the same client certificate is used to authenticate to multiple When the same peer certificate is used to authenticate to multiple
WLANs, the list of SSIDs is available from servers associated with WLANs, the list of SSIDs is available from servers associated with
each WLAN. Of course, the list of SSIDs is also made available to each WLAN. Of course, the list of SSIDs is also made available to
any eavesdroppers on the WLAN. Whenever this SSID disclosure is a any eavesdroppers on the WLAN. Whenever this SSID disclosure is a
concern, different client certificates ought to be used for the each concern, different peer certificates ought to be used for the each
WLAN. WLAN.
SSID values are unmanaged; therefore SSIDs may not be unique. Hence, SSID values are unmanaged; therefore SSIDs may not be unique. Hence,
it is possible for client certificates that are intended to be used it is possible for peer certificates that are intended to be used
with different WLANs to contain the same SSID. In this case, with different WLANs to contain the same SSID. In this case,
automatic selection of the certificate will fail, and the automatic selection of the certificate will fail, and the
implementation SHOULD obtain help from the user to choose the correct implementation SHOULD obtain help from the user to choose the correct
certificate. In cases where a human user is unavailable, each certificate. In cases where a human user is unavailable, each
potential certificate MAY be tried until one succeeds, disclosing the potential certificate MAY be tried until one succeeds, disclosing the
list of SSIDs associated with each certificate, which might otherwise list of SSIDs associated with each certificate, which might otherwise
not be disclosed. Therefore, it is RECOMMENDED that sequentially not be disclosed. Therefore, it is RECOMMENDED that sequentially
trying each certificate only be employed when user selection is trying each certificate only be employed when user selection is
unavailable or impractical. unavailable or impractical.
skipping to change at page 7, line 21 skipping to change at page 7, line 30
[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,
April 2002. April 2002.
[PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 Public Key Infrastructure: Certificate and X.509 Public Key Infrastructure: Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280, Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002. April 2002.
[EAP] Aboba, B., Blunk, L., Vollbrechtand, J., Carlson, J.,
and H. Levkowetz, Ed. "Extensible Authentication
Protocol (EAP)", RFC 3748, June 2004.
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate [STDWORDS] 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.
[X.509] ITU-T. Recommendation X.509: The Directory - [X.509] ITU-T. Recommendation X.509: The Directory -
Authentication Framework. 2000. Authentication Framework. 2000.
[X.680] ITU-T Recommendation X.680: Information Technology - [X.680] ITU-T Recommendation X.680: Information Technology -
Abstract Syntax Notation One, 1997. Abstract Syntax Notation One, 1997.
[X.690] ITU-T Recommendation X.660 Information Technology - ASN.1 [X.690] ITU-T Recommendation X.660 Information Technology - ASN.1
skipping to change at page 7, line 44 skipping to change at page 8, line 14
7.2. Informative References 7.2. Informative References
[802.11] IEEE Std 802.11, "Wireless LAN Medium Access [802.11] IEEE Std 802.11, "Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications", Control (MAC) and Physical Layer (PHY) Specifications",
1999. 1999.
[802.1X] IEEE Std 802.1X, "Port-based Network Access Control", [802.1X] IEEE Std 802.1X, "Port-based Network Access Control",
2001. 2001.
[EAP] Blunk, L. and J. Vollbrecht, "PPP Extensible
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 [RADIUS1] Rigney, C., S. Willens, A. Rubens, and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000. June 2000.
 End of changes. 16 change blocks. 
48 lines changed or deleted 62 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/