idnits 2.17.1 draft-fossati-core-server-name-id-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 (February 29, 2016) is 2977 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-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 CORE T. Fossati 3 Internet-Draft Nokia 4 Intended status: Standards Track H. Tschofenig 5 Expires: September 1, 2016 ARM Ltd. 6 February 29, 2016 8 Introducing Server Name Identifiers in Certificates 9 draft-fossati-core-server-name-id-00.txt 11 Abstract 13 TBD. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on September 1, 2016. 32 Copyright Notice 34 Copyright (c) 2016 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terminology and Requirements Language . . . . . . . . . . . . 3 51 3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. Server Name Indication (SNI) Name Type and Server Name Syntax 4 53 5. Subject Alternative Name Extension . . . . . . . . . . . . . 4 54 6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . 5 55 7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . 5 56 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 60 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 62 12.2. Informative References . . . . . . . . . . . . . . . . . 9 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 65 1. Introduction 67 Today, many Internet of Things (IoT) deployments consist of an IoT 68 device that interacts with a cloud service infrastructure. (This 69 deployment model is described in Section 2.2 of [RFC7452].) If TLS/ 70 DTLS is used to mutually authenticate the device and the cloud 71 server, then the guidance in [I-D.ietf-dice-profile] - which, in 72 turn, takes [RFC7252] recommendations into account - should be 73 followed. 75 Let us take the CoAP protocol as an example. According to 76 Section 9.1.3.3 of [RFC7252], a DTLS client that receives a 77 certificate from the DTLS server must check that the authority of the 78 requested URI matches "at least one of the authorities of any CoAP 79 URI found in a field of URI type in the SubjectAltName (SAN) set. If 80 there is no SubjectAltName in the certificate, then the authority of 81 the request URI must match the Common Name (CN) found in the 82 certificate [...].". A URI that includes an authority, such as a 83 'coaps' URI, needs to include a fully qualified domain name (FQDN), 84 or an IP literal as its host part, as stated in Section 4.2.1.6 of 85 [RFC5280]. So, an IoT device that wants to talk to a CoAP server at 86 coaps://example.com will expect to receive a certificate with a 87 matching URI in either the content of the SAN extension or the CN. 89 The Server Name Indication (SNI) extension [RFC6066] defined for TLS/ 90 DTLS allows a client to tell a server the name of the server it is 91 contacting. This is a feature useful when the server is part of a 92 hosting solution where multiple virtual servers are using a single 93 underlying network address. Section 3 of [RFC6066] only allows FQDN 94 hostname of the server in the ServerName field. 96 When a TLS/DTLS server has an FQDN registered in the DNS then the use 97 of certificates work well with TLS/DTLS to secure protocols like HTTP 98 or CoAP. While the DNS can be taken for granted in the Web, many IoT 99 deployments do not mandate its presence. There are even IoT 100 deployments where the server infrastructure is located in a 101 residential environment in which IoT devices interact with the server 102 solely in the local network (see also Section 2.1 of [RFC7452]). 104 Since static configuration is not generally a viable option from a 105 usability point of view, in order to cope with scenarios like the one 106 described above there is a need to define some kind of stable, non- 107 DNS-based identifier that can be used with certificates. Note that 108 an alternative is to avoid using certificates altogether and to 109 instead use raw public keys. With raw public keys, the raw public 110 key itself is the identifier and some out-of-band validation 111 technique is needed instead, as described in RFC 7250 [RFC7250]. 113 This document specifies such identifiers for use with certificates. 115 2. Terminology and Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. Syntax 123 [Editor's Note: This is a strawman proposal for the identifier 124 definition.] 126 This section defines the syntax for the instance and the domain 127 component, which are separated by the "@" sign. The structure for 128 the name and the domain component are determined by the namespace 129 prefix. We call this new construct the 'Server Name Identifier' (SN- 130 ID). 132 The following ABNF reuses ALPHA and DIGIT from [RFC5234]. 134 char = ALPHA / DIGIT / "-" / "_" / "~" / "!" / 135 "$" / "&" / "'" / "(" / ")" / "*" / 136 "," / ";" / "=" 137 ns = ALPHA *(ALPHA / DIGIT / "-") 138 name = 1*RD-char 139 domain = 1*63RD-char 140 authority = [ ns "." ] name [ "@" domain ] 142 Note that the "@" and the "." signs are illegal characters in the 143 name and the ns components. 145 Here are some examples: 147 o eui64.01-23-45-67-89-ab-cd-ef 149 o imei.+123456789012345 151 o uuid.84c05e54-1d3c-48b6-bf12-c11c55f8fdac@foo 153 4. Server Name Indication (SNI) Name Type and Server Name Syntax 155 In order to encode the SN-ID in a ServerNameList, the extension_data 156 field of the server_name extension is expanded to allow the SN-ID in 157 a ServerName extension: 159 struct { 160 NameType name_type; 161 select (name_type) { 162 case host_name: HostName; 163 case sn_id: AuthorityType; 164 } name; 165 } ServerName; 167 enum { 168 host_name(0), 169 sn_id(1), 170 (255) 171 } NameType; 173 opaque AuthorityType<1..2^16-1>; 175 AuthorityType, the data structure associated with the authority 176 declaration, is a variable-length vector that begins with a 16-bit 177 length field indicating the length of the following authority. The 178 value in the authority field is represented as a byte string using 179 ASCII encoding. It MUST NOT contain any percent-encoded character 180 other than for those characters not explicitly allowed by the grammar 181 in Section 3. 183 5. Subject Alternative Name Extension 185 As described in RFC 5280 [RFC5280] the subjectAltName may carry 186 additional name types through the use of the otherName field. The 187 format and semantics of the name are indicated through the OBJECT 188 IDENTIFIER in the type-id field. The name itself is conveyed as 189 value field in otherName. This document defines a new value for the 190 type-id field. 192 This section defines the SN-ID as a form of otherName from the 193 GeneralName structure in SubjectAltName defined in [RFC5280]. 195 id-sn-id OBJECT IDENTIFIER ::= { id-pkix id-sn-id(TODO) } 197 An X.509 server certificate intended to be used with this 198 specification MUST contain an otherName SAN identified using a type- 199 id of 'id-sn-id-san'. 201 id-sn-id-san OBJECT IDENTIFIER ::= { id-sn-id 2 } 203 The value field of the otherName MUST contain the SN-ID, as described 204 in Section 3, encoded as a IA5String. 206 6. Client Behaviour 208 TLS/DTLS clients behave as follows: 210 1) Clients MAY include an extension of type "server_name" in the 211 (extended) client hello. A client supporting this specification 212 MAY include one (and one only) ServerName element conveying the 213 SN-ID. 215 2) Process the Certificate message, verify the digitial signature 216 and perform path validation (as described in Section 3.2 of RFC 217 5280). 219 3) Verify that the intended server name is indeed one of the 220 identities bound to the presented certificate, by checking that 221 the name in the SAN otherName of type id-sn-id-san matches the 222 authority requested via server_name. 224 4) Upon receiving the CertificateRequest message, send the 225 certificate via a Certificate message - or CertificateURL 226 message, if the client_certificate_url extension has been 227 successfully negotiated during the "hello" exchange. 229 5) Send ClientKeyExchange and then CertificateVerify to complete the 230 mutual authentication process. 232 7. Server Behaviour 234 TLS/DTLS servers behave as follows: 236 1) A server receiving the extended ClientHello carrying a 237 server_name extension uses the given server_name (with the 238 included SN-ID) to select the appropriate certificate. The 239 selected certificate MUST include a SAN otherName with an id-sn- 240 id-san type-id and value, which MUST match the requested 241 ServerName; 243 a) If no certificate can be selected, the server MUST terminate 244 the handshake by sending a fatal-level unrecognized_name(112) 245 alert. [[CREF1: Prefer a single, hard failure, path over 246 soft failure, or worse: ignoring the error altogether. 247 Rationale: do not waste time/energy; provide clear and prompt 248 diagnostic to the peer. It doesn't look like the condition 249 that could be exploited by a timing attack.]] 251 b) If a matching certificate exist, the server SHALL include an 252 extension of type "server_name" in the (extended) ServerHello 253 message with an empty value. 255 2) The server MUST send the selected certificate to the client in 256 the Certificate message. 258 3) Server MAY request a client certificate via a CertificateRequest 259 message and conclude its negotiation with a ServerHelloDone 260 message. 262 4) When server receives the Certificate message from the client it 263 MUST process the Certificate message, verify the digitial 264 signature of the certificate and perform path validation (as 265 described in Section 3.2 of RFC 5280). 267 a) If the client certificate processing fails then the server 268 MUST tear down the exchange. 270 b) If the client certificate processing is successful then the 271 server finalizes the TLS handshake. 273 5) The server application running on top of the TLS/DTLS stack MUST 274 check the included client identity against the access control 275 policy at the server. It is important to note that this 276 verification check is done outside the TLS/DTLS stack; failure to 277 do it at the application layer may result in unauthorized access. 279 8. Example 281 In this section we discuss a more complete scenario where the 282 mechanism described in this document is practical. Consider the 283 following setup where IoT devices are located in a small home network 284 with a Resource Directory (RD) [I-D.ietf-core-resource-directory] 285 helping with discovery. 287 A resource directory is an entity that acts as a centralized store 288 where protocol endpoints can register their resources and thereby 289 make them available to others. Other devices subsequently use the 290 resource directory to lookup devices and their resources. 292 The RD defines the concept of an "endpoint name" which identifies a 293 given endpoint within a "domain". Endpoint (EP) is a term used to 294 describe a web server or client in [RFC7252]. In the context of 295 [I-D.ietf-core-resource-directory] an endpoint is used to describe a 296 web server that registers resources to the resource directory. An 297 endpoint is identified by its endpoint name, which is included during 298 registration, and is unique within the associated domain of the 299 registration. 301 Imagine various IoT devices registering their resources with the pre- 302 configured RD (or dynamically discoverd RD). Section 5.2 of 303 [I-D.ietf-core-resource-directory] contains a description of 304 registration procedure using CoAP and offers examples. The resource 305 server stores, among other things, the endpoint name and (optionally) 306 a domain. 308 Once the resources are registered nodes may use the resource 309 directory to discover the resources offered by others. Section 7 of 310 [I-D.ietf-core-resource-directory] describes the discovery procedure 311 and lists examples. A node may, for example, search for resources of 312 type 'temperature' and learns the network addresses of the nodes 313 hosting those resources as well as their endpoint name (and, if 314 available, their domain). 316 Once the network address has been obtained, direct communication 317 between the two entities can be initiated. During the subsequent 318 DTLS exchange to secure CoAP the server hosting the resources offers 319 his certificates and the client executes the steps outlined in 320 Section 6 to match the endpoint name (and optionally the domain) 321 learned through the resource directory with the SN-ID provided in the 322 server certificate. Note that it is not envisioned that the client 323 compares the input to the discovery procedure with the SN-ID. In 324 this example the input to the discovery procedure with the resource 325 directory was the resource type, i.e., the 'temperature' string. It 326 is therefore assumed that the client trusts the resource directory to 327 return genuine mappings from abstract search terms to specific 328 servers hosting those resources. 330 9. IANA Considerations 332 TBD: This document requires registration of various identifiers into 333 existing registries,namely 334 o id-sn-id 336 o OtherName.type-id::id-sn-id-san 338 o NameType::sn-id 340 o ServerName.name::Authority 342 10. Security Considerations 344 It's the responsibility of the CA issuing the certificate to verify 345 the content of the certificate before issuing a new certificate. In 346 particular, the CA MUST ensure uniqueness of the issued certificates 347 and that the included SN-ID is indeed correct. This should exclude 348 the threat of a (possibly rogue) node to successfully impersonate 349 another node's identity. 351 Security considerations from Section 11.1 of [RFC6066] fully apply. 353 11. Acknowledgements 355 We would like to thank Martin Thomson, Carsten Bormann, Andrew 356 McGregor, and Zach Shelby for their feedback during IETF 92. 358 12. References 360 12.1. Normative References 362 [I-D.ietf-core-resource-directory] 363 Shelby, Z. and C. Bormann, "CoRE Resource Directory", 364 draft-ietf-core-resource-directory-02 (work in progress), 365 November 2014. 367 [I-D.ietf-dice-profile] 368 Tschofenig, H. and T. Fossati, "TLS/DTLS Profiles for the 369 Internet of Things", draft-ietf-dice-profile-17 (work in 370 progress), October 2015. 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 374 RFC2119, March 1997, 375 . 377 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 378 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 379 RFC5234, January 2008, 380 . 382 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 383 Housley, R., and W. Polk, "Internet X.509 Public Key 384 Infrastructure Certificate and Certificate Revocation List 385 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 386 . 388 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 389 Extensions: Extension Definitions", RFC 6066, DOI 390 10.17487/RFC6066, January 2011, 391 . 393 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 394 Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ 395 RFC7252, June 2014, 396 . 398 12.2. Informative References 400 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 401 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 402 Transport Layer Security (TLS) and Datagram Transport 403 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 404 June 2014, . 406 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 407 "Architectural Considerations in Smart Object Networking", 408 RFC 7452, DOI 10.17487/RFC7452, March 2015, 409 . 411 Authors' Addresses 413 Thomas Fossati 414 Nokia 415 3 Ely Road 416 Milton, Cambridge CB24 6DD 417 Great Britain 419 Email: thomas.fossati@nokia.com 421 Hannes Tschofenig 422 ARM Ltd. 423 110 Fulbourn Rd 424 Cambridge CB1 9NJ 425 Great Britain 427 Email: Hannes.tschofenig@gmx.net 428 URI: http://www.tschofenig.priv.at