idnits 2.17.1 draft-sanz-openid-dns-discovery-01.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 (April 16, 2018) is 2201 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-07 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: October 18, 2018 DENIC eG 6 April 16, 2018 8 OpenID Connect DNS-based Discovery 9 draft-sanz-openid-dns-discovery-01 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 October 18, 2018. 35 Copyright Notice 37 Copyright (c) 2018 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 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Notation and Conventions . . . . . . . . . . . . 2 54 3. DNS-based Discovery Resource Record . . . . . . . . . . . . . 3 55 4. DNS-based Issuer Discovery Process . . . . . . . . . . . . . 5 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 60 7.2. Informative References . . . . . . . . . . . . . . . . . 7 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 63 1. Introduction 65 "OpenID Connect Discovery 1.0" [OpenID.Discovery] uses WebFinger 66 [RFC7033] to locate the OpenID Provider for an End-User in a process 67 called "issuer discovery". While this mechanism has been in place 68 for quite some time now and it has proven to work, it presents some 69 operational inconveniences: A (dedicated) WebFinger service has to be 70 setup and operated on top of an HTTPS server. Furthermore: in an 71 OpenID deployment with distributed resources, each resource would 72 have to be running its own WebFinger service to point to its issuer. 73 This presents scaling/operating challenges, especially in a scenario 74 where the deployment happens at Internet scale and each resource may 75 use a different, personal domain name. 77 This document presents a lightweight discovery mechanism based on top 78 of DNS (and DNS has to be setup anyway for the WebFinger approach to 79 work). This so-called "DNS-based discovery" does not disrupt the 80 existing discovery specification and is presented as an alternative 81 discovery process, compatible to the existing issuer discovery 82 process described in "OpenID Connect Discovery 1.0" 83 [OpenID.Discovery] if interpreted as a so-called "out-of-band" 84 mechanism. 86 Additionally the mechanisms described in this document enrich the 87 discovery process by allowing to discover not only the issuer, but 88 also potential Claims Providers [OpenID.Core] available for a given 89 End-User identifier. 91 2. Requirements Notation and Conventions 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 Throughout this document, values are quoted to indicate that they are 98 to be taken literally. When using these values in protocol messages, 99 the quotes MUST NOT be used as part of the value. 101 3. DNS-based Discovery Resource Record 103 The format defined here has been inspired by the DMARC [RFC7489] and 104 DKIM [RFC6376] specifications and some text passages have been 105 directly copied from those standards to allow for a reading without 106 following references. 108 DNS-based discovery metadata are stored as DNS TXT records in 109 subdomains named "_openid". The underscore construct is used to 110 define a semantic scope for DNS records that are associated with the 111 parent domain (s. "DNS Scoped Data Through Global '_Underscore' 112 Naming of Attribute Leaves" [I-D.ietf-dnsop-attrleaf]). 114 For example, the domain owner of "myname.example.com" would post 115 OpenID configuration in a TXT record at "_openid.myname.example.com". 116 This DNS-located OpenID metadata will hereafter be called the "OpenID 117 record". 119 To allow for the use of e-mail addresses as resources, the following 120 additional rules are defined: 122 o In case the resource identifier contains at least one "@" 123 character, the rightmost "@" character is replaced by the string 124 "._openidemail.", which introduces an additional DNS subdomain 125 inside the identifier's domain name. 127 o If any character in the resulting resource identifier is 128 disallowed from use in domain names as per [RFC1035] section 129 2.3.1, the punycoding algorithm defined in [RFC3492] is applied. 131 Per [RFC1035] a TXT record can comprise several "character-string" 132 objects. Where this is the case, the evaluator of the OpenID record 133 must concatenate these strings by joining together the objects in 134 order and parsing the result as a single string. 136 Content of OpenID records follow the extensible "tag=value" syntax 137 for DNS-based key records defined in [RFC6376] and definition there 138 applies. Specifically: 140 o Values are a series of strings containing either plain text or 141 "base64" text (as defined in [RFC2045], Section 6.8). The 142 definition of the tag will determine the encoding of each value. 144 o Unencoded semicolon (";") characters must not occur in the value, 145 since that separates tag-value pairs. 147 o Whitespaces are allowed anywhere around tags. In particular, any 148 whitespace after the "=" and any whitespace before a terminating 149 ";" is not part of the value; however, whitespace inside the value 150 is significant. 152 o Tags must be interpreted in a case-sensitive manner. Values must 153 be processed as case sensitive unless the specific tag description 154 of semantics specifies case insensitivity. Host and domain names 155 in this context are to be compared in a case insensitive manner, 156 per [RFC4343]. 158 o Tags with duplicate names must not occur within a single tag-list; 159 if a tag name does occur more than once, the entire tag-list is 160 invalid. 162 o Tag=value pairs that represent the default value for optional 163 records may be included to aid legibility. 165 o Unrecognized tags must be ignored. 167 o Tags that have an empty value are not the same as omitted tags. 168 An omitted tag is treated as having the default value; a tag with 169 an empty value explicitly designates the empty string as the 170 value. 172 Only tags defined in this document or in later extensions are to be 173 processed; note that given the rules of the previous paragraph, 174 addition of a new tag into the registered list of tags does not 175 itself require a new version of OpenID record to be generated (with a 176 corresponding change to the "v" tag's value, see later), but a change 177 to any existing tags does require a new version. 179 The following tags are introduced as the initial valid OpenID tags: 181 o v: Version (plain-text; REQUIRED). Identifies the record 182 retrieved as a OpenID record. It must have the value of "OID1". 183 The value of this tag must match precisely; if it does not or it 184 is absent, the entire record must be ignored. It must be the 185 first tag in the list. 187 o iss: The designated hostname for the Issuer (plain-text; 188 REQUIRED). Internationalized domain names must be encoded as 189 A-labels, as described in Section 2.3 of [RFC5890]. That hostname 190 can be used as the issuer location of an OpenID Connect Discovery 191 1.0 (Section 4) Configuration Request to discover its relevant 192 OpenID endpoints. The issuer MAY contain port and/or path 193 components (e.g. "issuer.example.com:8080/path"). 195 o clp: The designated hostname for the Claims Provider (plain-text; 196 OPTIONAL). Internationalized domain names must be encoded as 197 A-labels, as described in Section 2.3 of [RFC5890]. That hostname 198 can be used by Identity Providers as a claim source for aggregated 199 or distributed claims. Support for Aggregated Claims and 200 Distributed Claims is OPTIONAL in the OpenID Core specification, 201 so is the usage of this tag. The value of this tag MAY contain 202 port and/or path components (e.g. "provider.example.com:8080/ 203 path"). 205 The following is an example of a valid OpenID record for the domain 206 example.com according to this specification: 208 _openid IN TXT "v=OID1;iss=auth.freedom-id.de;clp=identityagent.de" 210 Figure 1: Example OpenID record 212 4. DNS-based Issuer Discovery Process 214 DNS-based OpenID Provider Issuer discovery is the process of 215 determining the location of the OpenID Provider with this 216 specification. 218 DNS-based issuer discovery requires the following information to make 219 a discovery request: 221 o resource - Identifier for the target End-User that is the subject 222 of the discovery request 224 o host - Hostname target of the discovery DNS query 226 To start discovery of OpenID endpoints, the End-User supplies an 227 Identifier to the Relying Party. The RP applies the same 228 normalization rules to the Identifier as described in "OpenID Connect 229 Discovery 1.0" [OpenID.Discovery] to determine the Resource and Host. 230 It is worth mentioning that as result of those rules the resource 231 could exactly match the host (e.g. resource is "example.com" and host 232 is "example.com"). 234 The RP will then follow the following lookup scheme: 236 1. The RP queries the DNS for an OpenID record at host. A possibly 237 empty set of records is returned. 239 2. Records that do not start with a "v=" tag that identifies the 240 current version of this document, or an older version of this 241 document supported by the RP, are discarded. If a tag 242 identifying the current version is found, all records identifying 243 other versions are discarded. If no tag identifying the current 244 version is found, but other tags identifying older versions are, 245 the records using the latest supported version are kept, and all 246 others are discarded. 248 3. If the remaining set contains multiple records or no records, the 249 DNS-based discovery process terminates. 251 4. If the retrieved OpenID record does not contain a valid iss tag, 252 the process terminates. 254 5. Once the Issuer has been extracted from the iss tag, the regular 255 dynamic discovery process can be resumed in Section 4 "Obtaining 256 OpenID Provider Configuration Information" of [OpenID.Discovery]. 258 As already mentioned in [OpenID.Discovery] it is also worth noting 259 that no relationship can be assumed between the user input Identifier 260 string and the resulting Issuer location. 262 5. Security Considerations 264 DNS-based discovery depends directly on the security of the DNS. 265 OpenID records must be ignored if not deployed in parallel with 266 DNSSEC [RFC4033]. DNSSEC validation of OpenID records MUST be 267 performed at all time before using them for any purpose. DNSSEC- 268 validation errors must result in abortion of this DNS-based discovery 269 process. 271 6. IANA Considerations 273 tbd 275 7. References 277 7.1. Normative References 279 [RFC1035] Mockapetris, P., "Domain names - implementation and 280 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 281 November 1987, . 283 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 284 Extensions (MIME) Part One: Format of Internet Message 285 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 286 . 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, 290 DOI 10.17487/RFC2119, March 1997, 291 . 293 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 294 for Internationalized Domain Names in Applications 295 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, 296 . 298 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 299 Rose, "DNS Security Introduction and Requirements", 300 RFC 4033, DOI 10.17487/RFC4033, March 2005, 301 . 303 [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case 304 Insensitivity Clarification", RFC 4343, 305 DOI 10.17487/RFC4343, January 2006, 306 . 308 [RFC5890] Klensin, J., "Internationalized Domain Names for 309 Applications (IDNA): Definitions and Document Framework", 310 RFC 5890, DOI 10.17487/RFC5890, August 2010, 311 . 313 7.2. Informative References 315 [I-D.ietf-dnsop-attrleaf] 316 Crocker, D., "DNS Scoped Data Through '_Underscore' Naming 317 of Attribute Leaves", draft-ietf-dnsop-attrleaf-07 (work 318 in progress), March 2018. 320 [OpenID.Core] 321 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 322 C. Mortimore, "OpenID Connect Core 1.0", November 2014, 323 . 325 [OpenID.Discovery] 326 Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID 327 Connect Discovery 1.0", November 2014, 328 . 331 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 332 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 333 RFC 6376, DOI 10.17487/RFC6376, September 2011, 334 . 336 [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, 337 "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 338 2013, . 340 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 341 Message Authentication, Reporting, and Conformance 342 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 343 . 345 Authors' Addresses 347 Vittorio Bertola 348 Open-Xchange 349 Via Treviso 12 350 Torino 10144 351 Italy 353 Email: vittorio.bertola@open-xchange.com 354 URI: https://www.open-xchange.com 356 Marcos Sanz 357 DENIC eG 358 Kaiserstrasse 75 - 77 359 Frankfurt am Main 60329 360 Germany 362 Email: sanz@denic.de 363 URI: https://www.denic.de