PKIX Working Group J.W. Park(KISA) Internet Draft J.I. Lee(KISA) Document: draft-ietf-pkix-sim-06.txt H.S. Lee(KISA) Expires : March, 2006 S.J. Park(BCQRE) Target category: Standard Track Polk, Tim(NIST) September, 2005 Internet X.509 Public Key Infrastructure Subject Identification Method (SIM) Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 This Internet-Draft will expire on March 10, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines the Subject Identification Method (SIM) for including a privacy sensitive identifier in the subjectAltName extension of a certificate. Park, et. al. Expires - March 2006 [Page 1] INTERNET-DRAFT Subject Identification Method September 2005 The SIM is an optional feature that may be used by relying parties to determine whether the subject of a particular certificate is also the person corresponding to a particular sensitive identifier. 1. Introduction The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [2119]. 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 may reflect the 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 [RFC4043]. 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 lead to misuse. Therefore, privacy sensitive identifiers cannot be included in certificates as plaintext. Park, et. al. Expires - March 2006 [Page 2] INTERNET-DRAFT Subject Identification Method September 2005 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 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 applicants' 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 Subject Identification Method (SIM) and the Privacy-Enhanced Protected Subject Identifier (PEPSI) 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 SIM 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 an identifier without disclosing the identifier. For example, a person could prove he/she possessed a specific social security number without actually disclosing the social security number itself. In addition, this document defines an Encrypted PEPSI(EPEPSI) so that sensitive identifier information can be exchanged 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) Park, et. al. Expires - March 2006 [Page 3] INTERNET-DRAFT Subject Identification Method September 2005 - Bob, a relying party who will rely on knowing Alice's true SIIa - Eve, an attacker who has Alice's certificate - An RA to whom Alice must divulge her SIIa; and - A CA who will issue Alice's certificate. We wish to design SIM and PEPSI, 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 SIIa 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'a from any other PEPSI; that is, there is nothing she can pre-compute that helps every attack against a PEPSI, and nothing she learns from a successful attack that helps in any other attack; - The CA does not learn Alice's SIIa except the case where the CA needs to validate the SII passed by the RA. - The CA can treat the SIM as an additional name form in the "subjectAltName" extension with no special processing; and - Alice cannot find another SII'a, 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 and PEPSI are 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 || PEPSI where PEPSI = H(H( P || R || SIItype || SII)) Then: 1. Alice picks a password P, and gives P, SIItype, and SII to the RA. 2. The RA validates SIItype and SII. 3. The RA generates a random value R. 4. The RA generates the SIM = (R || PEPSI) where PEPSI = H(H(P || R || SIItype || SII)). 5. The RA sends the SIM to Alice by the out-of-band and also passes it to the CA. Park, et. al. Expires - March 2006 [Page 4] INTERNET-DRAFT Subject Identification Method September 2005 6. Alice sends a certRequest form to CA which generates Alice's certificate including the SIM as a form of otherName from the GeneralName structure in the SubjectAltName extension. 7. Alice sends Bob her Cert, as well as P, SIItype, and SII. 8. Bob can compute PEPSI' = H(H(P || R || SIItype || SII)) and compare SIM' = R || PEPSI' to the value in the SIM, thereby verifying SII. If Alice wishes to prove she has a valid identifier, without disclosing it, then steps 7 and 8 are as follows: 7. Alice sends intermediate value H(P || R || SIItype || SII)) and her certificate to Bob. 8. Bob can get R form the SIM in the certificate, then compute H(intermediate value) and compare it to the value in SIM, thereby verifying Alice's knowledge of P and SII. Eve has to exhaustively search the H(P || R || SIItype || SII) space to find Alice's SII. This is a fairly hard problem even if Alice uses a poor password, and a really hard problem if Alice uses a fairly good password. Even if Eve finds Alice's P, SIItype, SII pairs or constructs a massive dictionary of P, SIItype, SII pairs, it doesn't help find any other SII because a new R is used for each PEPSI and SIM. 3. Procedures 3.1 Symbols The following cryptography symbols are defined in this document. H() Cryptographically secure hash algorithm. SHA-1[FIPS 180-1] or more secure hash function is required. SII Sensitive Identification Information. (e.g., Social Security Number or Maryland Driver License) SIItype Object Identifier that identifies the type of SII. P A user chosen password. R The random number value generated by RA. Park, et. al. Expires - March 2006 [Page 5] INTERNET-DRAFT Subject Identification Method September 2005 PEPSI Privacy-Enhanced Protected Subject Information. Calculated from the input value P, R, SIItype, SII using two iteration of H(). E() The public key encryption algorithm used by RA. Used for encrypting the PEPSI. EPEPSI Encrypted PEPSI. D() The public key decryption algorithm used by CA. Used for decrypting the ESIM. 3.2 SII and SIItype The user presents evidence that a particular SII has been assigned to them. The SII is composed of an alphanumeric string. The SIItype is an OID which defines the format and scope of the SII value. For example, in Korea, SIItype is as below. KISA specific OIDs id-KISA OBJECT IDENTIFIER ::= {iso(1) member-body(2) korea(410) kisa(200004)} KISA arcs id-npki OBJECT IDENTIFIER ::= {id-KISA 10} id-attribute OBJECT IDENTIFIER ::= {id-npki 1} id-kisa-identifyData OBJECT IDENTIFIER ::= {id-attribute 1} id-VID OBJECT IDENTIFIER ::= {id-kisa-identifyData 10} id-SII OBJECT IDENTIFIER ::= {id-VID 1} For closed communities, the SIItype value may be assigned by the CA itself. 3.3 User Chosen Password The user selects a password as one of the input values for the SIM. The strength of the password is critical to protection of the user's SII. The user should be encouraged to select passwords that will be difficult to be guessed and long enough to protect against brute 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. See [FIPS 112] and [FIPS 180-1] for selecting security criteria for password and an automated password generator algorithm that randomly creates simple pronounceable syllables as passwords. Park, et. al. Expires - March 2006 [Page 6] INTERNET-DRAFT Subject Identification Method September 2005 3.4 Random Number Generation The RA generates a random number, R. A new R MUST be generated for each SIM in a certificate. The length of R MUST be the same as the length of the output of the hash algorithm H. For example, where H is SHA-1 the random number MUST be 160 bits. Whenever a certificate or key needs to be updated, a new R SHOULD be generated and the SIM SHOULD be recomputed. Replicating the value of the previous SIM from a previous certificate permits an attacker to identify certificates associated with the same physical person, which may be undesirable. A Random Number Generator(RNG) that meets the requirements defined in [FIPS 140-2] is strongly recommended. 3.5 Generation of SIM The SIM in the subjectAltName extension within the certificate identifies an entity even if it has multiple names in its certificates. RAs MUST calculate the unique value of the SIM with the designated inputs according to the following algorithm: SIM = R || PEPSI PEPSI = H(H(P || R || SIItype || SII)) The SII is known to an RA at user enrollment. One of SHA-1 or SHA-256 MUST be used for ensuring the integrity of a PEPSI and other one-way hash functions MAY be used. Note that the P, SIItype, and SII passing from the end entity to the RA MUST be protected. The syntax and the associated OID for SIM are also provided in the ASN.1 modules in Section 4.1. Also, Section 4.2 describes the syntax for PEPSI in the ASN.1 modules. 3.6 Encryption of PEPSI This section describes procedures for encrypting the SIItype, SII and SIM. It may be required that the CA itself verifies SII before issuing the certificate. To meet this requirement, RA SHOULD encrypt the SIItype, SII and SIM and send it to the CA. One method to encrypt the SIItype, SII and SIM is to use the CA's public key which is for encryption only. In this case, the RA MUST acquire the CA's public encryption certificate although the way of obtaining it is not covered in this Park, et. al. Expires - March 2006 [Page 7] INTERNET-DRAFT Subject Identification Method September 2005 document. EPEPSI = E(SIItype || SII || SIM) The syntax and the associated OID for EPEPSI is provided in the ASN.1 modules in Section 4.3. 3.7 Certification Request As described above, the certificate request message MAY contain the SIM. [RFC2314] and [RFC2511] are widely used message syntaxes for certification requests. Basically, PKCS#10 is consists of a distinguished name, a public key and a optionally a set of attributes, collectively signed by the end entity. The SIM alternative name SHOULD be placed in the subjectAltName extension. In case that CA itself verifies SII before issuing the certificate, the value of SIM in certification request form SHOULD be changed to EPEPSI which the requestor(Alice) has made by himself or herself. The requestor(Alice) MUST acquire the CA's public encryption certificate although the way of obtaining it is not covered in this document. 3.8 Certification A CA issues the certificates containing the SIM as a form of otherName from the GeneralName structure in "SubjectAltName" extension. In an environment where a CA verifies SII before issuing the certificate, a CA decrypts the EPEPSI with its own private key according to the following algorithm. It then validates that the SII value is correct. SIItype, SII, SIM = D(EPEPSI) 4. Definition 4.1 SIM Naming Syntax This section specifies the syntax for SIM name form included in subjectAltName extension. The SIM is composed of the three fields, the hash algorithm identifier, the authority chosen random value, and the value of the PEPSI itself. Park, et. al. Expires - March 2006 [Page 8] INTERNET-DRAFT Subject Identification Method September 2005 Suggest an OID in the id-on arc as follows: id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) } id-on OBJECT IDENTIFIER ::= { id-pkix 8 } id-on-SIM OBJECT IDENTIFIER ::= { id-on 6 } SIM ::= SEQUENCE { hashAlg AlgorithmIdentifier, authorityRandom OCTET STRING, -- RA chosen random number -- used in computation of -- pEPSI pEPSI OCTET STRING -- hash of HashContent -- with algorithm hashAlg } 4.2 PEPSI This section specifies the syntax for PEPSI. The PEPSI is generated by performing the same hash function twice. The PEPSI is generated over the ASN.1 structure HashContent. HashContent has four values: the user selected password, the authority chosen random number, the identifer type, and the identifier itself. HashContent ::= SEQUENCE { userPassword UTF8String, -- user supplied password authorityRandom OCTET STRING, -- RA chosen random number identifierType OBJECT IDENTIFIER, -- SIItype identifier UTF8String -- SII } Before calculating a PEPSI, conforming implementations MUST process the userPassword with the six step [LDAPBIS STRPREP] string preparation algorithm as follows: * In step 2, Map, the mapping shall include processing of characters commonly mapped to nothing, as specified in Appendix B.1 of [RFC 3454]. * Omit step 6, Insignificant Character Removal. 4.3 Encrypted PEPSI This section describes the syntax for Encrypted PEPSI. The Encrypted PEPSI has three fields: identifierType, identifier, and SIM. Park, et. al. Expires - March 2006 [Page 9] INTERNET-DRAFT Subject Identification Method September 2005 EncryptedPEPSI ::= SEQUENCE { identifierType OBJECT IDENTIFIER, -- SIItype identifier UTF8String, -- SII sIM SIM -- Value of the SIM } When it is used for certificate request, the OID in 'regInfo' of RFC2511 and PKCS#10 is as follows: id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 } 5. Example Usage of SIM Depending on a different security environments, there are three possible use cases with SIM. 1. When a relying party doesn't have any information about the certificate user. 2. When a relying party already have the SII of the certificate user. 3. When the certificate user doesn't want to disclose his SII. For the use case 1, SII and a user chosen password P which only the user knows must be sent to a relying party via secure communication. Together with the password, the certificate including the SIM must be transmitted. Then the relying party can get R from the certificate. The relying party can verify that the subject of the certificate issued by a CA is in fact the same entity who sends the password and the certificate. If the first two cases are compared, their overall procedure is almost same except that the SII isn't required by the relying party. Therefore, a certificate user transmits simply the password, P, and the certificate. The rest of detailed procedure is the same as that of the use case 1. For the last special use case that a certificate user doesn't want to disclose his or her SII, the only information sent by a certificate user is the intermediate value of the PEPSI, H(R || P || SIItype || SII). Upon receiving it, the relying party can verify the user by rehashing the value and comparing it with SIM in the certificate. Park, et. al. Expires - March 2006 [Page 10] INTERNET-DRAFT Subject Identification Method September 2005 6. Name Constraints The SIM value is stored in the other name field of subject alternative name, however, there are no constraints that can be placed on this form of the name. 7. Security Considerations The security of a SIM value is created by the hashing of the R, SIItype, and SII values. A SIM value depends on two properties of a hash function; the fact that it cannot be inverted and the fact that collisions (especially with correctly formatted data) are rare. The current attacks by [WANG] are not applicable to SIM values since the end entity supplying the SII and SIItype values does not supply all of the data being hashed. Some of the SIM value is provided by the RA in the form of an R value. In addition, a fairly good password is needed to protect against the brute force attacks on H(P || R || SIItype || SII) space. Due to the short length of the SII, it is likely that an attacker can reasonably guess it with partial information about gender, age, and date of birth. Therefore, it is important for users to select a fairly good password in order that an attacker is unable to verify whether the guessed SII is accurate or not unless he collects all input values for SIM. This protocol is premised that Bob must be a relying party and not reuse the Alice's information. Because of using this protocol with another party, Bob could "impersonate" Alice. Thus, it is recommended that this protocol should be used in parallel with the protocols which contain the digital signature messages. 8. IANA Considerations In the future, IANA may be asked to establish a registry of object identifiers to promote interoperability in the specification of SII types. 9. References 9.1 Normative Reference [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Park, et. al. Expires - March 2006 [Page 11] INTERNET-DRAFT Subject Identification Method September 2005 [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. [RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1.5", RFC 2314, March 1998. [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. [RFC3454] P. Hoffman, M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002. [RFC4043] D. Pinkas, T. Gindin, "Internet X.509 Public Key Infrastructure Permanent Identifier", RFC4043, May 2005. 9.2 Informative Reference [LDAPBIS STRPREP] Zeilenga, K., "LDAP: Internationalized String Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in progress. [CMC] J. Schaad, M. Myers, X. Liu, J. Weinstein, "Certificate Management Messages over CMS", draft-ietf-pkix-cmc-base-03.txt. [FIPS 112] Fedreal Information Processing Standards Publication (FIPS PUB) 112, "Password Usage", 30 May 1985. [FIPS 180-1] Federal Information Processing Standards Publication (FIPS PUB) 180-1, "Secure Hash Standard", 17 April 1995. [FIPS 181] Federal Information Processing Standards Publication (FIPS PUB) 181, "Automated Password Generator(APG)", 5 October 1993. [FIPS 140-2] Federal Information Processing Standards Publication (FIPS PUB) 140-2, "Security Requirements for Cryptographic Modules", 25 May 2001. Park, et. al. Expires - March 2006 [Page 12] INTERNET-DRAFT Subject Identification Method September 2005 [WANG] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu, "Finding Collisions in the Full SHA-1", Crypto'05. 10. Acknowledgments Jim Schaad(Soaring Hawk Consulting), Seungjoo Kim, Jaeho Yoon, Baehyo Park(KISA), Bill Burr, Morrie Dworkin(NIST), and ISTF(Internet Security Technical Forum, http://www.istf.org) have significantly contributed to work on the SIM and PEPSI concept and identified a potential security attack. Also their comments on the set of desirable properties for the PEPSI and enhancements to the PEPSI were most illumination. Also, thanks for Russell Housley, Stephen Kent, Denis Pinkas for their contribution for this document. 11. Authors' Address Jongwook Park Korea Information Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 REPUBLIC OF KOREA Phone: 2-405-5432 Email: khopri@kisa.or.kr Jaeil Lee Korea Information Security Agency Phone: 2-405-5300 Email: jilee@kisa.or.kr Hongsub Lee Korea Information Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 REPUBLIC OF KOREA Phone: 2-405-5100 EMail: hslee@kisa.or.kr Sungjun Park BCQRE Co.,Ltd Yuil Bldg. Dogok-dong 411-14, Kangnam-ku, Seoul, 135-270 REPUBLIC OF KOREA Email: sjpark@bcqre.com Tim Polk National Institute of Standards and Technology 100 Bureau Drive, MS 8930 Park, et. al. Expires - March 2006 [Page 13] INTERNET-DRAFT Subject Identification Method September 2005 Gaithersburg, MD 20899 Email: tim.polk@nist.gov Park, et. al. Expires - March 2006 [Page 14] INTERNET-DRAFT Subject Identification Method September 2005 Appendix A. "Compilable" ASN.1 Module, 1988 Syntax PKIXSIM {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-sim2005(38) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL IMPORTS AlgorithmIdentifier, AttributeTypeAndValue FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)} -- SIM -- SIM certificate OID id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) } id-on OBJECT IDENTIFIER ::= { id-pkix 8 } id-on-SIM OBJECT IDENTIFIER ::= { id-on 6 } -- Certificate Syntax SIM ::= SEQUENCE { hashAlg AlgorithmIdentifier, authorityRandom OCTET STRING, -- RA chosen radom number -- used in computation of -- pEPSI pEPSI OCTET STRING -- hash of HashContent -- with algorithm hashAlg } -- PEPSI UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING -- The content of this type conforms to RFC 2279 HashContent ::= SEQUENCE { userPassword UTF8String, -- user supplied password authorityRandom OCTET STRING, Park, et. al. Expires - March 2006 [Page 15] INTERNET-DRAFT Subject Identification Method September 2005 -- RA chosen random number identifierType OBJECT IDENTIFIER, -- SIItype identifier UTF8String -- SII } -- Encrypted PEPSI -- OID for encapsulated content type id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 } EncryptedPEPSI ::= SEQUENCE { identifierType OBJECT IDENTIFIER, -- SIItype identifier UTF8String, -- SII sIM SIM -- Value of the SIM } END Park, et. al. Expires - March 2006 [Page 16] INTERNET-DRAFT Subject Identification Method September 2005 Intellectual Property Statement 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. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Park, et. al. Expires - March 2006 [Page 17]