From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5105.txt | 955 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 955 insertions(+) create mode 100644 doc/rfc/rfc5105.txt (limited to 'doc/rfc/rfc5105.txt') diff --git a/doc/rfc/rfc5105.txt b/doc/rfc/rfc5105.txt new file mode 100644 index 0000000..0075cbe --- /dev/null +++ b/doc/rfc/rfc5105.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group O. Lendl +Request for Comments: 5105 enum.at +Category: Standards Track December 2007 + + + ENUM Validation Token Format Definition + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + An ENUM domain name is tightly coupled with the underlying E.164 + number. The process of verifying whether the Registrant of an ENUM + domain name is identical to the Assignee of the corresponding E.164 + number is commonly called "validation". This document describes a + signed XML data format -- the Validation Token -- with which + Validation Entities can convey successful completion of a validation + procedure in a secure fashion. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Data Requirements ...............................................2 + 3. Digital Signature ...............................................3 + 4. Field Descriptions ..............................................4 + 4.1. The Element ...................................4 + 4.2. The Element ....................................5 + 5. Examples ........................................................6 + 5.1. Unsigned Token without Registrant Information ..............6 + 5.2. Signed Token ...............................................6 + 6. Formal Syntax ...................................................8 + 6.1. Token Core Schema ..........................................9 + 6.2. Token Data Schema .........................................10 + 7. Other Applications of the Token Concept ........................12 + 8. IANA Considerations ............................................12 + 9. Security Considerations ........................................13 + 10. Acknowledgements ..............................................14 + 11. References ....................................................14 + 11.1. Normative References .....................................14 + 11.2. Informative References ...................................15 + + + + + +Lendl Standards Track [Page 1] + +RFC 5105 ENUM Validation Token December 2007 + + +1. Introduction + + In the case where an ENUM (E.164 Number Mapping [1]) domain name + corresponds to an existing E.164 number [2], the delegation of this + domain needs to be authorized by the Assignee of the corresponding + E.164 number. In the role model described in [15], the entity that + performs this check is called the Validation Entity (VE). + + By conveying an ENUM Validation Token -- a signed XML document -- to + the Registry, a VE certifies that delegation requirements have been + met and are current. + + 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 [3]. + +2. Data Requirements + + In this model, the Token is the only piece of data passed from the VE + to the Registry. Therefore, the Token needs to contain at least as + much information as the Registry requires to grant the delegation of + the requested ENUM domain according to its registration policy. As + such, the Registry will need confirmation that: + + o the Token was created by an accredited VE, + + o the Token's duration of validity conforms to the policy, + + o the validation procedure employed has met minimum requirements as + set forth by policy, + + o and that the Token is protected against tampering and replay + attacks. + + Beyond such mandatory information, the Token may optionally include + number holder information, in particular, to simplify future + revalidations. + + For example, if initial validation requires the steps "Check the + identity of the Registrant" and "Check the ownership of an E.164 + number", then a later revalidation only needs to re-check the + ownership as the identity of the Registrant does not change. + + As the Token will be included (see e.g., [16]) in XML-based Registry/ + Registrar protocols like the Extensible Provisioning Protocol (EPP) + [13], it is a natural choice to use XML to encode Validation Tokens. + + + + + +Lendl Standards Track [Page 2] + +RFC 5105 ENUM Validation Token December 2007 + + +3. Digital Signature + + According to the architecture model the propriety of an ENUM + delegation depends on the trust relationship between the Registry and + the VE. In general, an untrusted link between the Registry and VE + should be assumed (for instance, the Token is passed along with the + registration request by a Registrar, who might have no role in + asserting the right-to-use). Therefore, the Token must be protected + against forgery, tampering, and replay-attacks. + + A digital signature on the token: + + o asserts that the token was indeed generated by the indicated VE + (authenticity). + + o guarantees that the token was not tampered with in transit + (integrity). + + o enables auditing the validation process (non-repudiation). + + The cryptographic signature on the token follows RFC 3275 (XML-DSIG + [4]). As tokens might be transmitted as part of an already XML based + protocol, the exclusive XML canonicalization [9] MUST be used. This + transform guarantees that namespace declarations inherited from the + surrounding XML do not invalidate the signature. In order to make + the signature an integral part of the token, the + "enveloped"-signature mode is employed. The signature covers all + information contained in the Token. + + XML-DSIG offers a number of cryptographic algorithms for digesting + and signing documents and recommends SHA1/RSA-SHA1. Recent advances + in cryptanalysis have cast doubt on the security of SHA1, thus + rendering this recommendation obsolete (see e.g., the Security + Considerations of [14]). RFC 4051 [5] defines how additional + algorithms can be used with XML-DSIG. + + Validation Entities MUST be able to sign tokens according to + XML-DSIG, MUST support RSA-SHA1 and RSA-SHA256 [5], MUST support RSA + key sizes of 1024 and 2048 bits, and MUST be able to embed X.509 [10] + certificates. The Registry MUST define which signature algorithms + and key sizes it will accept in Validation Tokens as part of its + local policy. + + The choice of a RSA-based signature does not require a public key + infrastructure. Whether the Registry acts as a certification + authority, accepts certs from a public certification authority, or + only accepts pre-registered keys is a local policy choice. + + + + +Lendl Standards Track [Page 3] + +RFC 5105 ENUM Validation Token December 2007 + + +4. Field Descriptions + + The Validation Token is structured into three parts: the basic + validation information, additional information about the Registrant, + and the digital signature. The XML schema can be found in Section 6. + +4.1. The Element + + A token MUST contain a element that contains the + following: + + o A single validation "serial" attribute identifying a validation + token for a certain VE. It must be unique per VE. + + o A single element containing the underlying E.164 + number in fully qualified (international) format. + + o An optional element. If present, it indicates + that the whole number block starting with up to and + including has been validated. To avoid + ambiguity, both numbers MUST be of the same length. + + o A single element identifying the VE. + + o A single element identifying the Registrar on whose + behalf the validation was performed. + + o A single element identifying the method used by the VE + for validation. + + o A single attribute containing the date of + validation formatted as "full-date" according to RFC 3339 [6]. + + o An optional attribute marking the expiration date + of the validation token formatted as "full-date" according to RFC + 3339. The Registry will automatically revoke the delegation at + this date unless a new Token has been submitted that extends the + lifetime of the validation. A missing indicates + infinite validity of the Token. + + The format and the uniqueness-constraints of these IDs is left to the + local policy of the Registry. + + + + + + + + + +Lendl Standards Track [Page 4] + +RFC 5105 ENUM Validation Token December 2007 + + +4.2. The Element + + A token may contain a section containing information + about the number holder, consisting of the following elements: + + o A single element containing the full name of the + organization to which the Registrant is affiliated. + + o A single element. If the Registrant is + a company, then this field can be used to uniquely identify this + company by its official registration number within the local + country. The interpretation of this field is thus + country-specific. + + o A single element. + + o A single <firstname> element. + + o A single <lastname> element. + + o A single <address> section containing the following elements: + * A single optional <streetName> + * A single optional <houseNumber> + * A single optional <postalCode> + * A single optional <locality> + * A single optional <countyStateOrProvince> + * A single optional <ISOcountryCode> + + o Up to 10 <phone> elements containing full E.164 numbers. + + o Up to 10 <fax> elements containing full E.164 numbers. + + o Up to 10 <email> elements. + + All elements directly under <tokendata> are optional. The + <ISOcountryCode> element specifies the country using the alpha-2 + country code from ISO 3166-1:2006 [11] (including updates published + by the 3166 Maintenance Agency). The definition of the first five + elements within the <address> element conforms to the second version + of the E.115 Computerized Directory Assistance [17]. + + + + + + + + + + + +Lendl Standards Track [Page 5] + +RFC 5105 ENUM Validation Token December 2007 + + +5. Examples + +5.1. Unsigned Token without Registrant Information + + This basic Token without any information about the Registrant and + without the cryptographic signature shows the basic layout of the + Token. + + <?xml version="1.0" encoding="utf-8" standalone="no" ?> + <token xmlns="urn:ietf:params:xml:ns:enum-token-1.0" Id="TOKEN" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation= + "urn:ietf:params:xml:ns:enum-token-1.0 enum-token-1.0.xsd"> + <validation serial="acmeve-000002"> + <E164Number>+442079460200</E164Number> + <lastE164Number>+442079460499</lastE164Number> + <validationEntityID>ACME-VE</validationEntityID> + <registrarID>reg-4711</registrarID> + <methodID>42</methodID> + <executionDate>2007-05-08</executionDate> + <expirationDate>2007-11-01</expirationDate> + </validation> + </token> + +5.2. Signed Token + + This example uses an X.509 based signature that includes the + certificate of the signing validation entity. Thus, the validity of + the signature can be verified without the need for a key-server. A + valid signature is a necessary, but not sufficient, condition for a + valid Token. Any entity evaluating a Token needs to check other + factors as well, e.g., the certificate and the XML schema. + +<?xml version="1.0" encoding="utf-8" standalone="no" ?> +<token xmlns="urn:ietf:params:xml:ns:enum-token-1.0" Id="TOKEN" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation= + "urn:ietf:params:xml:ns:enum-token-1.0 enum-token-1.0.xsd"> + <validation serial="acmeve-000001"> + <E164Number>+442079460123</E164Number> + <validationEntityID>ACME-VE</validationEntityID> + <registrarID>reg-4711</registrarID> + <methodID>42</methodID> + <executionDate>2007-05-08</executionDate> + </validation> + <tokendata xmlns="urn:ietf:params:xml:ns:enum-tokendata-1.0" + xsi:schemaLocation= + "urn:ietf:params:xml:ns:enum-tokendata-1.0 enum-tokendata-1.0.xsd"> + + + +Lendl Standards Track [Page 6] + +RFC 5105 ENUM Validation Token December 2007 + + + <contact> + <organisation>Example Inc.</organisation> + <commercialregisternumber>4711</commercialregisternumber> + <title>Dr. + Max + Mustermann +
+ Main + 10 + 1010 + London + London + GB +
+ +442079460123 + mm@example.com + + + + + + + + + + + + + + + VxqsBxSNPFwPAUlCHts3g3DehcexnB1dqUz+GypLZ0k= + + + +QKqphKRNPokVZFbenje+HZZV+RLrNweGnlWBw7ngAtH+rtuslR8LhMLmC4DlBb9V +HvKItl+7zLGm3VgYsqfHH8q3jCl1mFxUIuLlIPqtpJs+xAHAJDzZ+vmsF/q2IgrS +K0uMmKuU5V1gydDBOvIipcJx+PrPYyXYZSjQXkWknK8= + + + + + + +Lendl Standards Track [Page 7] + +RFC 5105 ENUM Validation Token December 2007 + + +MIIDZjCCAs+gAwIBAgIBBDANBgkqhkiG9w0BAQQFADB0MQswCQYDVQQGEwJBVDEP +MA0GA1UEBxMGVmllbm5hMRQwEgYDVQQKEwtCT0ZIIENlcnRzLjEbMBkGA1UEAxMS +Q0VSVFMuYm9maC5wcml2LmF0MSEwHwYJKoZIhvcNAQkBFhJjZXJ0c0Bib2ZoLnBy +aXYuYXQwHhcNMDQwNzIwMTMxNTA5WhcNMDUwNzIwMTMxNTA5WjB/MQswCQYDVQQG +EwJBVDEKMAgGA1UECBMBLTEPMA0GA1UEBxMGVmllbm5hMR0wGwYDVQQKExRBY21l +IEVOVU0gVmFsaWRhdGlvbjEQMA4GA1UEAxMHYWNtZS1WRTEiMCAGCSqGSIb3DQEJ +ARYTbm9ib2R5QGVudW0tYWNtZS5hdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC +gYEArJPcjMFc54/zwztSdQXGxUtodJT9r1qGI2lQPNjLvtPJg93+7o5SIOsZGSpg +zWbztDAV5qc7PHZWUVIyf6MbM5qSgQDVrjNRhTosNtyqmwi23BH52SKkX3P7eGit +LmqEkiUZRxZhZ6upRbtcqvKSwmXitvW4zXZhkVHYJZ2HuMcCAwEAAaOB/DCB+TAJ +BgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0 +aWZpY2F0ZTAdBgNVHQ4EFgQUyK4otTQtvv6KdSlMBOPT5Ve18JgwgZ4GA1UdIwSB +ljCBk4AUvfPadpm0HhmZx2iAVumQTwgnG2eheKR2MHQxCzAJBgNVBAYTAkFUMQ8w +DQYDVQQHEwZWaWVubmExFDASBgNVBAoTC0JPRkggQ2VydHMuMRswGQYDVQQDExJD +RVJUUy5ib2ZoLnByaXYuYXQxITAfBgkqhkiG9w0BCQEWEmNlcnRzQGJvZmgucHJp +di5hdIIBADANBgkqhkiG9w0BAQQFAAOBgQCB9CHBnIUhrdic4h5Ar4hdxjHSQkDH +sJWd+MYrNcuSrv3TIOsUkUgNpNNhmkZPtiXqfy3388IRdJtJiLWXSOb/XlZHOM9I +MvwKYwhcpQ9UdM/w7VpXQqf+CEj0XSyqxGw65UsHIOijgiG/WyhSj+Lzriw7CTge +P2iAJkJVC4t2XA== + + + + + + +6. Formal Syntax + + The formal syntax of the validation token is specified using XML + schema notation [7] [8]. Two schemas are defined: The "token core + schema" contains mandatory attribute definitions, and the "token data + schema" defines the format of the optional "tokendata" section. The + BEGIN and END tags are not part of the schema; they are used to note + the beginning and ending of the schema for URI registration purposes. + + + + + + + + + + + + + + + + + + +Lendl Standards Track [Page 8] + +RFC 5105 ENUM Validation Token December 2007 + + +6.1. Token Core Schema + + BEGIN + + + + + + + + + + + + Validation Token core schema + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + END + +6.2. Token Data Schema + + BEGIN + + + + + + + + + + + + + + + + + + + +Lendl Standards Track [Page 10] + +RFC 5105 ENUM Validation Token December 2007 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lendl Standards Track [Page 11] + +RFC 5105 ENUM Validation Token December 2007 + + + + + + + + + + + + + + + + + + + + + + END + +7. Other Applications of the Token Concept + + The concept of the validation token may be useful in other + registry-type applications where the proof of an underlying right is + a condition for a valid registration. + + An example is a Top Level Domain (TLD) where registration is subject + to proof of some precondition, like a trade mark or the right in a + name. Such situations often arise during the introduction of a new + TLD, e.g., during a "sunrise" phase. + + A Number Portability (NP) database faces very similar verification + issues. An NP system based on the Token concept could potentially be + superior to current methods, and aid in the convergence of NP and + ENUM. + +8. IANA Considerations + + This document uses Uniform Resource Names (URNs) to describe XML + namespaces and XML schemas conforming to a registry mechanism + described in RFC 3688 [12]. IANA has made the following four URI + assignments. + + + + + +Lendl Standards Track [Page 12] + +RFC 5105 ENUM Validation Token December 2007 + + + 1. Registration for the Token namespace: + * URI: urn:ietf:params:xml:ns:enum-token-1.0 + * Registrant Contact: See the "Author's Address" section of this + document. + * XML: None. Namespace URIs do not represent an XML + specification. + + 2. Registration for the Token XML schema: + * URI: urn:ietf:params:xml:schema:enum-token-1.0 + * Registrant Contact: See the "Author's Address" section of this + document. + * XML: See Section 6.1 of this document. + + 3. Registration for the Token Data namespace: + * URI: urn:ietf:params:xml:ns:enum-tokendata-1.0 + * Registrant Contact: See the "Author's Address" section of this + document. + * XML: None. Namespace URIs do not represent an XML + specification. + + 4. Registration for the Token Data XML schema: + * URI: urn:ietf:params:xml:schema:enum-tokendata-1.0 + * Registrant Contact: See the "Author's Address" section of this + document. + * XML: See Section 6.2 of this document. + + The IDs used in the validationEntityID, RegistrarID, and methodID + elements are subject to local policy and thus do not require IANA + registration. + +9. Security Considerations + + The security of the Validation Token depends on the security of the + underlying XML DSIG algorithms. As such, all the security + considerations from [4] apply here as well. Two points from [4] + merit repetition: + + Transforms are used to select the relevant data for signing and + discarding irrelevant information (e.g., pretty-printing and + name-space local names). + + The element and attribute combined with the + Id="TOKEN" attribute in specifies that the signature should + cover the complete token. Moving the Id="TOKEN" attribute to e.g., + the element would make the signature worthless. + + + + + + +Lendl Standards Track [Page 13] + +RFC 5105 ENUM Validation Token December 2007 + + + It is thus critical that the Registry not only checks whether the + Token passes a generic XML-DSIG signature check, but also that: + + 1. the signature uses approved transforms and cryptographic + algorithms. + 2. the signature references the element. + 3. the key used in the signature belongs to an accredited VE. + + The Token content is not encrypted. If local policy dictates that + the information contained within the token should be confidential, + then this has to be handled through a different mechanism. + + When processing a delegation request, the Registry MUST verify that + the information contained in the Token matches the delegation + request. The element in the Token prevents a malicious + second Registrar from using an eavesdropped Token to register a + domain in his name. The Registry MUST verify that the + given (including the case of no given expiration + date) conforms to the Registry's policy. To avert replay attacks, + local policy MUST specify how long after the Token + can be used to authorize a delegation. + +10. Acknowledgements + + The author would like to thank the following persons for their + valuable suggestions and contributions: Michael Haberler, Alexander + Mayrhofer, Bernie Hoeneisen, Michael Braunoeder, Staffan Hagnell, + Lawrence Conroy, and Tony Rutkowski. + +11. References + +11.1. Normative References + + [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource + Identifiers (URI) Dynamic Delegation Discovery System (DDDS) + Application (ENUM)", RFC 3761, April 2004. + + [2] ITU-T, "The international public telecommunication numbering + plan", Recommendation E.164, May 1997. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup + Language) XML-Signature Syntax and Processing", RFC 3275, March + 2002. + + + + + +Lendl Standards Track [Page 14] + +RFC 5105 ENUM Validation Token December 2007 + + + [5] Eastlake 3rd, D., "Additional XML Security Uniform Resource + Identifiers (URIs)", RFC 4051, April 2005. + + [6] Klyne, G. and C. Newman, "Date and Time on the Internet: + Timestamps", RFC 3339, July 2002. + + [7] Maloney, M., Beech, D., Mendelsohn, N., and H. Thompson, "XML + Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, + May 2001. + + [8] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes", W3C + REC REC-xmlschema-2-20010502, May 2001. + + [9] Eastlake, D., Boyer, J., and J. Reagle, "Exclusive XML + Canonicalization Version 1.0", W3C REC REC-xml-exc-c14n- + 20020718, July 2002. + + [10] International Telecommunications Union, "Information technology + - Open Systems Interconnection - The Directory: Public-key and + attribute certificate frameworks", ITU-T Recommendation X.509, + ISO Standard 9594-8, March 2000. + + [11] International Organization for Standardization, "Codes for the + representation of names of countries and their subdivisions -- + Part 1: Country codes, 2nd edition", ISO Standard 3166, + November 2006. + + [12] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + January 2004. + +11.2. Informative References + + [13] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC + 4930, May 2007. + + [14] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms + and Identifiers for RSA Cryptography for use in the Internet + X.509 Public Key Infrastructure Certificate and Certificate + Revocation List (CRL) Profile", RFC 4055, June 2005. + + [15] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation + Architecture", RFC 4725, November 2006. + + [16] Hoeneisen, B., "ENUM Validation Information Mapping for the + Extensible Provisioning Protocol", RFC 5076, December 2007. + + [17] ITU-T, "Computerized Directory Assistance Version 2", + Recommendation E.115v2, October 2005. + + + +Lendl Standards Track [Page 15] + +RFC 5105 ENUM Validation Token December 2007 + + +Author's Address + + Otmar Lendl + enum.at GmbH + Karlsplatz 1/2/9 + Wien A-1010 + Austria + + Phone: +43 1 5056416 33 + EMail: otmar.lendl@enum.at + URI: http://www.enum.at/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lendl Standards Track [Page 16] + +RFC 5105 ENUM Validation Token December 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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. + + 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, THE IETF TRUST 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. + +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. + + + + + + + + + + + + +Lendl Standards Track [Page 17] + -- cgit v1.2.3