idnits 2.17.1 draft-sanz-openid-dns-discovery-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2017) is 2379 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-dnsop-attrleaf-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Bertola 3 Internet-Draft Open-Xchange 4 Intended status: Informational M. Sanz 5 Expires: April 21, 2018 DENIC eG 6 October 18, 2017 8 OpenID Connect DNS-based Discovery 9 draft-sanz-openid-dns-discovery-00 11 Abstract 13 The following document describes a DNS-based mechanism for a client 14 to discover an OpenID Identity Provider given an Identifier of the 15 End-User, as a complementary alternative to the existing WebFinger- 16 based mechanism. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 21, 2018. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Introduction 52 "OpenID Connect Discovery 1.0" [OpenID.Discovery] uses WebFinger 53 [RFC7033] to locate the OpenID Provider for an End-User in a process 54 called "issuer discovery". While this mechanism has been in place 55 for quite some time now and it has proven to work, it presents some 56 operational inconveniences: A (dedicated) WebFinger service has to be 57 setup and operated on top of an HTTPS server. Furthermore: in an 58 OpenID deployment with distributed resources, each resource would 59 have to be running its own WebFinger service to point to its issuer. 60 This presents scaling/operating challenges, especially in a scenario 61 where the deployment happens at Internet scale and each resource may 62 use a different, personal domain name. 64 This document presents a lightweight discovery mechanism based on top 65 of DNS (and DNS has to be setup anyway for the WebFinger approach to 66 work). This so-called "DNS-based discovery" does not disrupt the 67 existing discovery specification and is presented as an alternative 68 discovery process, compatible to the existing issuer discovery 69 process described in "OpenID Connect Discovery 1.0" 70 [OpenID.Discovery] if interpreted as a so-called "out-of-band" 71 mechanism. 73 Additionally the mechanisms described in this document enrich the 74 discovery process by allowing to discover not only the issuer, but 75 also potential Claims Providers [OpenID.Core] available for a given 76 End-User identifier. 78 2. Requirements Notation and Conventions 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 Throughout this document, values are quoted to indicate that they are 85 to be taken literally. When using these values in protocol messages, 86 the quotes MUST NOT be used as part of the value. 88 3. DNS-based Discovery Resource Record 90 The format defined here has been inspired by the DMARC [RFC7489] and 91 DKIM [RFC6376] specifications and some text passages have been 92 directly copied from those standards to allow for a reading without 93 following references. 95 DNS-based discovery metadata are stored as DNS TXT records in 96 subdomains named "_openid". The underscore construct is used to 97 define a semantic scope for DNS records that are associated with the 98 parent domain (s. "DNS Scoped Data Through Global '_Underscore' 99 Naming of Attribute Leaves" [I-D.ietf-dnsop-attrleaf]). 101 For example, the domain owner of "myname.example.com" would post 102 OpenID configuration in a TXT record at "_openid.myname.example.com". 103 This DNS-located OpenID metadata will hereafter be called the "OpenID 104 record". 106 To allow for the use of e-mail addresses as resources, the following 107 additional rules are defined: 109 o In case the resource identifier contains at least one "@" 110 character, the rightmost "@" character is replaced by the string 111 "._openidemail.", which introduces an additional DNS subdomain 112 inside the identifier's domain name. 114 o If any character in the resulting resource identifier is 115 disallowed from use in domain names as per [RFC1035] section 116 2.3.1, the punycoding algorithm defined in [RFC3492] is applied. 118 Per [RFC1035] a TXT record can comprise several "character-string" 119 objects. Where this is the case, the evaluator of the OpenID record 120 must concatenate these strings by joining together the objects in 121 order and parsing the result as a single string. 123 Content of OpenID records follow the extensible "tag=value" syntax 124 for DNS-based key records defined in [RFC6376] and definition there 125 applies. Specifically: 127 o Values are a series of strings containing either plain text or 128 "base64" text (as defined in [RFC2045], Section 6.8). The 129 definition of the tag will determine the encoding of each value. 131 o Unencoded semicolon (";") characters must not occur in the value, 132 since that separates tag-value pairs. 134 o Whitespaces are allowed anywhere around tags. In particular, any 135 whitespace after the "=" and any whitespace before a terminating 136 ";" is not part of the value; however, whitespace inside the value 137 is significant. 139 o Tags must be interpreted in a case-sensitive manner. Values must 140 be processed as case sensitive unless the specific tag description 141 of semantics specifies case insensitivity. Host and domain names 142 in this context are to be compared in a case insensitive manner, 143 per [RFC4343]. 145 o Tags with duplicate names must not occur within a single tag-list; 146 if a tag name does occur more than once, the entire tag-list is 147 invalid. 149 o Tag=value pairs that represent the default value for optional 150 records may be included to aid legibility. 152 o Unrecognized tags must be ignored. 154 o Tags that have an empty value are not the same as omitted tags. 155 An omitted tag is treated as having the default value; a tag with 156 an empty value explicitly designates the empty string as the 157 value. 159 Only tags defined in this document or in later extensions are to be 160 processed; note that given the rules of the previous paragraph, 161 addition of a new tag into the registered list of tags does not 162 itself require a new version of OpenID record to be generated (with a 163 corresponding change to the "v" tag's value, see later), but a change 164 to any existing tags does require a new version. 166 The following tags are introduced as the initial valid OpenID tags: 168 o v: Version (plain-text; REQUIRED). Identifies the record 169 retrieved as a OpenID record. It must have the value of "OID1". 170 The value of this tag must match precisely; if it does not or it 171 is absent, the entire record must be ignored. It must be the 172 first tag in the list. 174 o iss: The designated hostname for the Issuer (plain-text; 175 REQUIRED). Internationalized domain names must be encoded as 176 A-labels, as described in Section 2.3 of [RFC5890]. That hostname 177 can be used as the issuer location of an OpenID Connect Discovery 178 1.0 (Section 4) Configuration Request to discover its relevant 179 OpenID endpoints. The issuer can contain path components (e.g. 180 "issuer.example.com/path"). 182 o clp: The designated hostname for the Claims Provider (plain-text; 183 OPTIONAL). Internationalized domain names must be encoded as 184 A-labels, as described in Section 2.3 of [RFC5890]. That hostname 185 can be used by Identity Providers as a claim source for aggregated 186 or distributed claims. Support for Aggregated Claims and 187 Distributed Claims is OPTIONAL in the OpenID Core specification, 188 so is the usage of this tag. The value of this tag can contain 189 path components (e.g. "provider.example.com/path"). 191 The following is an example of a valid OpenID record for the domain 192 example.com according to this specification: 194 _openid IN TXT "v=OID1;iss=auth.freedom-id.de;clp=identityagent.de" 196 Figure 1: Example OpenID record 198 4. DNS-based Issuer Discovery Process 200 DNS-based OpenID Provider Issuer discovery is the process of 201 determining the location of the OpenID Provider with this 202 specification. 204 DNS-based issuer discovery requires the following information to make 205 a discovery request: 207 o resource - Identifier for the target End-User that is the subject 208 of the discovery request 210 o host - Hostname target of the discovery DNS query 212 To start discovery of OpenID endpoints, the End-User supplies an 213 Identifier to the Relying Party. The RP applies the same 214 normalization rules to the Identifier as described in "OpenID Connect 215 Discovery 1.0" [OpenID.Discovery] to determine the Resource and Host. 216 It is worth mentioning that as result of those rules the resource 217 could exactly match the host (e.g. resource is "example.com" and host 218 is "example.com"). 220 The RP will then follow the following lookup scheme: 222 1. The RP queries the DNS for an OpenID record at host. A possibly 223 empty set of records is returned. 225 2. Records that do not start with a "v=" tag that identifies the 226 current version of this document, or an older version of this 227 document supported by the RP, are discarded. If a tag 228 identifying the current version is found, all records identifying 229 other versions are discarded. If no tag identifying the current 230 version is found, but other tags identifying older versions are, 231 the records using the latest supported version are kept, and all 232 others are discarded. 234 3. If the remaining set contains multiple records or no records, the 235 DNS-based discovery process terminates. 237 4. If the retrieved OpenID record does not contain a valid iss tag, 238 the process terminates. 240 5. Once the Issuer has been extracted from the iss tag, the regular 241 dynamic discovery process can be resumed in Section 4 "Obtaining 242 OpenID Provider Configuration Information" of [OpenID.Discovery]. 244 As already mentioned in [OpenID.Discovery] it is also worth noting 245 that no relationship can be assumed between the user input Identifier 246 string and the resulting Issuer location. 248 5. Security Considerations 250 DNS-based discovery depends directly on the security of the DNS. 251 OpenID records must be ignored if not deployed in parallel with 252 DNSSEC [RFC4033]. DNSSEC validation of OpenID records MUST be 253 performed at all time before using them for any purpose. DNSSEC- 254 validation errors must result in abortion of this DNS-based discovery 255 process. 257 6. IANA Considerations 259 tbd 261 7. References 263 7.1. Normative References 265 [RFC1035] Mockapetris, P., "Domain names - implementation and 266 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 267 November 1987, . 269 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 270 Extensions (MIME) Part One: Format of Internet Message 271 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 272 . 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, 276 DOI 10.17487/RFC2119, March 1997, 277 . 279 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 280 for Internationalized Domain Names in Applications 281 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, 282 . 284 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 285 Rose, "DNS Security Introduction and Requirements", 286 RFC 4033, DOI 10.17487/RFC4033, March 2005, 287 . 289 [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case 290 Insensitivity Clarification", RFC 4343, 291 DOI 10.17487/RFC4343, January 2006, 292 . 294 [RFC5890] Klensin, J., "Internationalized Domain Names for 295 Applications (IDNA): Definitions and Document Framework", 296 RFC 5890, DOI 10.17487/RFC5890, August 2010, 297 . 299 7.2. Informative References 301 [I-D.ietf-dnsop-attrleaf] 302 Crocker, D., "DNS Scoped Data Through Global '_Underscore' 303 Naming of Attribute Leaves", draft-ietf-dnsop-attrleaf-02 304 (work in progress), March 2017. 306 [OpenID.Core] 307 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 308 C. Mortimore, "OpenID Connect Core 1.0", November 2014, 309 . 311 [OpenID.Discovery] 312 Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID 313 Connect Discovery 1.0", November 2014, 314 . 317 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 318 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 319 RFC 6376, DOI 10.17487/RFC6376, September 2011, 320 . 322 [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, 323 "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 324 2013, . 326 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 327 Message Authentication, Reporting, and Conformance 328 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 329 . 331 Authors' Addresses 332 Vittorio Bertola 333 Open-Xchange 335 Email: vittorio.bertola@open-xchange.com 336 URI: https://www.open-xchange.com 338 Marcos Sanz 339 DENIC eG 340 Kaiserstrasse 75 - 77 341 Frankfurt am Main 60329 342 Germany 344 Email: sanz@denic.de 345 URI: https://www.denic.de