PKIX Working Group Internet Draft Jong-Wook, Park Document: draft-ietf-pkix-sim-01.txt KISA Expires: April 2004 Polk, Tim NIST October 2003 Internet X.509 Public Key Infrastructure Subject Identification Method (SIM) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes a straightforward mechanism to authenticate the certificate subject itself by not only generating the PII (Protected Identification Information), using a non-public nature identifier being protected, a secret value only known to the subject and one-way function, but also placing it in certificate for the relying parties who also obtain a secret value in a secure manner to Park, et al. Expires - - April 2004 [Page 1] Subject Identification Method October 2003 identify the subject. A public key certificate including PII can easily bind together with any kind of identification based services but typically requires a precise subject authentication. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Table of Contents 1. Introduction...................................................2 2. Requirements...................................................4 2.1 Security Requirements......................................4 2.2 Usability Requirements.....................................5 2.3 Solution...................................................5 3. Procedures.....................................................6 3.1 Symbols....................................................6 3.2 Initialization.............................................6 3.3 Random Number Generation...................................6 3.4 User Chosen Password.......................................7 3.5 SII and SIItype............................................7 3.6 Generation of PII..........................................7 3.7 Encryption of PII..........................................7 3.8 Certification Request......................................8 3.9 Certification..............................................8 4. Definition.....................................................8 4.1 SIM naming extension.......................................8 4.2 Protected Identification Information (PII).................8 4.3 Encrypted PII (EPII).......................................9 5. Example Usage of PII...........................................9 6. Acknowledgements..............................................10 7. ASN.1 Syntax..................................................10 Security Considerations..........................................11 References.......................................................11 Acknowledgments..................................................12 Author's Addresses...............................................12 1. Introduction The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Park, et al. Expires - April 2004 [Page 2] Subject Identification Method October 2003 A Certification Authority (CA) issues X.509 public key certificates to bind a public key to a subject. The subject is specified through one or more subject names in the "subject" and/or "subjectAltName" fields of a certificate. The "subject" field contains a hierarchically structured distinguished name. The "subjectAltName field" may contain an electronic mail address, IP address, or other name forms that correspond to the subject. For each particular CA, a subject name corresponds to a unique person, device, group, or role. The CA will not knowingly issue certificates to multiple entities under the same name. That is, for a particular certificate issuer, all currently valid certificates asserting the same subject name(s) are bound to the same entity. Where the subject is a person, the name that is specified in the subject field of the certificate typically reflects the legal name of the individual and affiliated entities (e.g., their corporate affiliation). In reality, however, there are individuals or corporations that have the same or similar names. It may be difficult for a relying party (e.g., a person or application) to associate the certificate with a specific person. This ambiguity presents a problem for many applications. In some cases, applications need to ensure that the subject of certificates issued by different CAs are in fact the same entity. This requirement may be met by including a "permanent identifier" in all certificates issued to the same subject, which is unique across multiple CAs. By comparing the "permanent identifier", the relying party may identify certificates from different CAs that are bound to the same subject. This solution is defined in [PI]. In many cases, such as a Social Security Number, a person or corporation's identifier is regarded as a sensitive, private or personal data. Such an identifier cannot simply be included as part of the subject field, since its disclosure to lead to misuse. Therefore, privacy sensitive identifiers cannot be included in certificates as plaintext. On the other hand, such an identifier is not actually a secret. People choose to disclose these identifiers for certain classes of transactions. For example, people may disclose their Social Security Number to open a bank account or obtain a loan. This is typically corroborated by presenting physical credentials (e.g., a driverĘs license) which confirms the personĘs name or address. To support such applications in an online environment, relying parties need to determine whether the subject of a particular certificate is also the person corresponding to a particular sensitive identifier. Ideally, applications would leverage the Park, et al. Expires - April 2004 [Page 3] Subject Identification Method October 2003 applicantĘs electronic credential (e.g., the X.509 public key certificate) to corroborate this identifier, but the subject field of a certificate does not provide sufficient information. To fulfill these demands, this document defines the Protected Identification Information (PII) format for including a privacy sensitive identifier in a certificate. When the subject of the certificate chooses to disclose the identifier and the relying party may verify the identifier. A party that obtains the certificate containing a PII can not determine the privacy sensitive identifier without performing a brute force attack, and each certificate must be attacked separately. Furthermore, the subject can prove to the relying party that they are associated with a valid identification with out disclosing the identifier. For example, a person could prove they possessed a valid social security number without disclosing the identifier itself. In addition, this document defines an Encrypted Protected Identification Format (EPII) so that the RA and CA can exchange sensitive identifier information without disclosing the identifier. This document is organized as follows: Section 2 establishes security and usability requirements; Section 3 provides an overview of the mechanism; Section 4 defines syntax and generation rules. 2. Requirements 2.1 Security Requirements Given . Alice, a certificate holder, with an a sensitive identifier SIIa (such as her Social Security Number, SSN) . Bob, a relying party who will rely on knowing Alice's true SII . Eve an attacker who has Alice's certificate . An RA to whom Alice must divulge her SII; and . A CA who will issue Alice's cert. We wish to design a SIM certificate extension, using a password that Alice chooses, that has the following properties: . Alice can prove her true SII, SIIa to Bob; . Eve has a large work factor to determine the Alice's SSN from her certificate, even if Alice chooses a weak password, and a very large work factor if Alice chooses a good password; . Even if Eve can determine SIIa she has an equally hard problem to find any other SII from any other SIM extension; that is, Park, et al. Expires - April 2004 [Page 4] Subject Identification Method October 2003 there is nothing she can pre-compute that helps every attack against a SIM, and nothing she learns from a successful attack that helps in any other attack; . The CA does not learn Alice's SIIa or her password; . The CA can treat the SIM as an ordinary private extension with no special processing; and . Alice cannot find another SII, password combination that will allow her to use the certificate to prove a false SII to Bob. 2.2 Usability Requirements In addition to the security properties stated above, we have the following usability requirements: . When the SIM extension is used, any custom processing occurs at the relying party. Alice can use commercial off the shelf software (e.g., a standard browser) without modifications. 2.3 Solution The solution: Let SIM = R, PII where PII = H(R || SIItype || H(R || P || SII)). Then: 1. Alice picks a password, Pa, and gives Pa, SIIa to the RA. SIIa is composed of identifier type (SIItype) and identifier value SII. 2. The RA validates SIIa. 3. The RA generates a Random value R. 4. The RA generates the SIMa = R, PII where PII = H(R || SIItype || H(R || Pa || SIIa)) 5. The RA passes the SIMa to the CA which generates Alice's certificate including the SIM private extension in the cert 6. Alice sends Bob her Cert, as well as Pa, SIIa 7. Bob can get R from the SIM in the cert, SIMa, then compute H(R || H(R || Pa || SIIa) and compare it to the value in SIMa, thereby verifying SIIa. If Alice wishes to prove she has a valid identifier, without disclosing it, then steps 6 and 7 are as follows: 6. Alice computes the intermediate value H(R || Pa || SIIa) and sends the certificate and intermediate value to Bob. 7. Bob can get R from the SIM in the cert, SIMa, then compute H(R || intermediate value) and compare it to the value in SIMa, thereby verifying AliceĘs knowledge of Pa and SIIa. Eve has to exhaustively search the H(R || P || SII) space to find Alice's SIIa. This is a fairly hard problem even if Alice uses a Park, et al. Expires - April 2004 [Page 5] Subject Identification Method October 2003 poor password, and a really hard problem if Alice uses a fairly good password. Even if Eve finds Alice's Pa, SIIa, pair or constructs a massive dictionary of P, SII pairs, it doesn't help find any other SII, because a new R is used for each SIM field. 3. Procedures TBD 3.1 Symbols The following cryptography symbols will be used in this document. Symbol Meaning ------ ------- h() One-way function (owf) for generating a PII. (This specification requires use of SHA-1 [FIPS 180-1].) R A 160-bit random number. It is a prerequisite input value to produce the PII. P A user chosen password. It is a prerequisite input value to produce the PII. SII A Sensitive Identification Information in the real world. An SII may be composed of numbers, text, or can be and alphanumeric value. The SII is another input value required to generate a PII. SIItype An alphanumeric string that describes the type of Sensitive Identification Information (e.g., ęęsocial security numberĘĘ or ęęMaryland DriverĘs LicenseĘĘ). The SII type is input value required to generate a PII. E() Encryption function. The public key algorithm such as RSA in the CA's certificate MUST be applied to produce the EPII (Encrypted PII). PII A Protected Identification Information. It is calculated from the input values R, P, SII and SIItype using two iterations of h(). EPII Encrypted PII. This value resulted from a SIM and R to the encryption fuction. 3.2 Initialization TBD. 3.3 Random Number Generation Park, et al. Expires - April 2004 [Page 6] Subject Identification Method October 2003 The random number 'R' is a 160-bit random number. A new R MUST be generated for each SIM extension in a certificate. Whenever a certificate or key needs to be updated, a new R SHOULD be generated and the SIM extension SHOULD be recomputed. Replicating the value of the previous SIM extension from a previous certificate permits an attacker to identify certificates associated with the same physical person, which may be undesirable. 3.4 User Chosen Password The user selects a password as one of the input values for the SIM extensions. The strength of the password is critical to protection of the userĘs SII. UserĘs should be encouraged to select passwords that will be difficult to guess and long enough to protect against bute force attacks. Implementations of this specification MUST permit a user to select passwords of up to 28 characters. RAs SHOULD implement password selection rules to prevent user selection of trivial passwords. 3.5 SII and SIItype The user presents evidence that a particular SII has been assigned to them. The SII is composed of an alphanumeric string and has a type assigned as well. For closed communities, the SSI type value (e.g., ęęSSNĘĘ or ęęsocial Security numberĘĘ) may be assigned by the CA itself. For interoperability, the SII type value should be registered with IANA. 3.6 Generation of PII The PII in the subjectAltName extension of the certificate identifies an entity even it has multiple names in its certificates. The unique value of the PII MUST be derived from the designated inputs according to the following algorithm: PII = h(R || SIItype || h(R || P || SII)) For this specification, h may be SHA-1 or SHA-256. The syntax and associated the OID for PII are also provided in the ASN.1 modules in Section 3.2. 3.7 Encryption of PII <> 3.8 Certification Request As described above, the certification request message MAY contain the EPII. [PKCS#10] and [RFC2511] are widely message syntaxes for certification requests. An EPII MAY be included in optional attributes for conveying attributes to the CA with additional information. Basically, PKCS#10 is composed of the entity name and public key. To satisfy this specification, it SHOULD be contain the EPII attributes for additional authentication information for the entity's identity. In case of using the RFC2511 (CRMF) for certificate request message, an EPII SHOULD enter into the "regToken" control defined in section 6.1 of [RFC2511]. 3.9 Certification <> 4. Definition 4.1 SIM naming extension This section specifies the syntax for SIM extension. The SIM is composed of the three fields, the hash algorithm identifier, the authority chosen random value, and the value of the PII itself. SIM ::= SEQUENCE { hashAlg AlgorithmIdentifier, authorityRandom BIT STRING, -- RA chosen random number -- used in computation of -- protectedIDInfo protectedIDInfo [0] OCTET STRING, -- hash of HashContent -- with algorithm hashAlg } } 4.2 Protected Identification Information (PII) This section specifies the syntax for Protected Identification Information (PII). The PII is generated by performing the same hash Park, et al. Expires - April 2004 [Page 8] Subject Identification Method October 2003 function twice. The initial hash is generated over the ASN.1 structure innerHashConent. InnerHashContent has four values: the authority chosen random number, the identifer type, the identifier itself, and the user selected password. InnerHashContent ::= SEQUENCE { authorityRandom BIT STRING, -- RA chosen random number -- order is important! userPassword BIT STRING -- user supplied password identifierType UTF8String, -- SIItype identifier UTF8String, -- SII } The second hash is gerenated over the ASN.1 struicture HashContent. HashContent contains three values: the authority chosen random number, the identifer type, and the hash of the InnerHashContent. HashContent ::= SEQUENCE { authorityRandom BIT STRING, -- RA chosen random number -- order is important! identifierType UTF8String, -- SIItype innerHash OCTET STRING -- hash of HashInnerContent } 4.3 Encrypted PII (EPII) This section describes the syntax for Encrypted PII. <> 5. Example Usage of PII The user access control and certification by using PII can be used to several different verification procedures in various situations. Especially, the relying party that perform the entity's self- identification and access control by using PII can take a separate verification step considering the entity's requirements and its own profile as following three cases: (Case 1) For the necessary case of PII from a relying party (Case 2) For the case that relying party already obtained the SII (Case 3) For the case of SII needed to be protected by the relying party For the Case 1 that a relying party doesn't have any information of an entity's identification, the entity SHOULD send its SII and R Park, et al. Expires - April 2004 [Page 9] Subject Identification Method October 2003 simultaneously. The whole step as follows: Step ---- 1. The entity sends the SII and P to a relying party securely. 2. The certificate including the PII computed from the information in step 1 is sent to the relying party. 3. The relying party extracts PII value from certificate of step 2. 4. Using the SII and P obtained in step 1 and the R conveyed in the SIM extension, compute PII' value. 5. Verify that the PII value in the certificate and PII' value calculated in step 4 are identical. The order in which data are sent in step 1 and 2 doesn't matter, but the SII and R MUST be transferred securely so as not to be leaked to a third party. For Case 2 where relying party already obtained the SII, the entity SHOULD securely transmit P with the certificate containing the PII to the relying party. Upon receiving P and the certificate, the relying party can derive the PII' by using the entity's SII already obtained in advance and the R. As above, the relying party verifies that the PII value in the certificate and the calculated PII' value are identical. In Case 3, the relying party needs to verify the subject has a legitimate SII, but does not need to the value. In this case, the subject calculates the value of the innerHashContent and transmits this value along with the claimed identifier type securely to the relying party. The relying party uses R from the SIM extension, the claimed identifier type, and the innerHashContent to calculate PIIĘ. If PII and PIIĘ are identical, the relying party has confirmed that the subject has an identifier of the claimed type. Regardless the cases of verification process, the significant point is not the order of step 1 or 2, but it is more important to maintain the secure encryption channel to send the information of SII and P without any disclosure to any third party. 6. Acknowledgements The authors wish to acknowledge the contributions of Yoon Jae-Ho, Kim Seungjoo, park Sangjoon, Lee Jaae-Il, Lee Hong-Sub, Lee(ISTF), Morrie Dworkin, Bill Burr, and Russ Housley. 7. ASN.1 Syntax Park, et al. Expires - April 2004 [Page 10] Subject Identification Method October 2003 <> Security Considerations First of all, the security of PII by composing hash value of SII and R is totally depending on hash function. Thus, secure hash algorithm SHOULD be used for maintaining the integrity of PII. Second, the P value is transmitted across the network when used in applications, Section 5. A secure communication channel SHOULD be used for protecting the value R to avoid disclosing the SII. References [X.509] ITU-T Recommendation X.509: The Directory - Public-Key and Attribute Certificate Frameworks. 2000. [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure, Certificate Management Protocols", RFC 2510, March 1999. [RFC2511] Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet X.509 Certificate Request Message Format", RFC 2511, March 1999. [RFC3280] Housley, R., Polk, T, Ford, W. and Solo, D., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [PKCS#5] RSA Laboratories, "PKCS #5: Password-Based Cryptography Standard Version 2.0", March, 1999. [PKCS#8] RSA Laboratories, "PKCS #8: Private Key Information Syntax Standard Version 1.2", November 1993. [PKCS#10] RSA Laboratories, "PKCS #10: Certification Request Syntax Version 1.7", November 2001. [PKCS#11] RSA Laboratories, "PKCS #11: Cryptographic Token Interface Standard Version 2.10", November, 1999. [FIPS 180-1] Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. [Supersedes FIPS PUB 180 dated 11 May 1993.] Park, et al. Expires - April 2004 [Page 11] Subject Identification Method October 2003 Acknowledgments The authors wish to acknowledge the contributions of Yoon Jae-Ho, Kim Seungjoo, Park Sangjoon, Lee Jaae-Il, Lee Hong-Sub, Lee(ISTF), Morrie Dworkin, Bill Burr, and Russ Housley. Author's Addresses Jong-Wook, Park Korea Information Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 REPUBLIC OF KOREA EMail: khopri@kisa.or.kr Tim Polk National Institute of Standards and Technology 100 Bureau Drive, MS 8930 Gaithersburg, MD 20899 Email: tim.polk@nist.gov Park, et al. Expires - April 2004 [Page 12]