CoRE Working Group L. Seitz Internet-Draft SICS Swedish ICT Intended Status: Standards Track G. Selander Expires: April 24, 2014 Ericsson October 21, 2013 Additional Security Modes for CoAP draft-seitz-core-security-modes-00 Abstract The CoAP draft defines how to use DTLS as security mechanism. In order to establish which nodes are trusted to initiate a DTLS session with a device, the following security modes are defined: NoSec, PreSharedKey, RawPublicKey, and Certificate. These modes require either to provision a list of keys of trusted clients, or to handle heavyweight certificates. This memo proposes two intermediate security modes involving a trusted third party that are very similar to PreSharedKey and RawPublicKey respectively, but which do not require out-of-band provisioning of client keys to the device. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Seitz & Selander Expires April 24, 2014 [Page 1] INTERNET DRAFT Additional Security Modes for CoAP October 21, 2013 Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. DerivedKey Mode . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Generating The Nonce . . . . . . . . . . . . . . . . . . . . 5 2.2 Calculating The Derived Key . . . . . . . . . . . . . . . . 5 2.3 Generating PSK_IDENTITY . . . . . . . . . . . . . . . . . . 6 2.4 Key Expiration, Anti-replay, And Revocation . . . . . . . . 6 3. AuthorizedPublicKey Mode . . . . . . . . . . . . . . . . . . . 8 3.1 Structure of the Authorization Certificate Extension . . . . 9 3.2 Client and Server Handshake Behavior . . . . . . . . . . . . 10 3.3 Payload Verification Procedure . . . . . . . . . . . . . . . 10 3.4 Key Expiration, Anti-replay, And Revocation . . . . . . . . 11 4. Access Control Lists . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1 Normative References . . . . . . . . . . . . . . . . . . . 13 8.2 Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Seitz & Selander Expires April 24, 2014 [Page 2] INTERNET DRAFT Additional Security Modes for CoAP October 21, 2013 1. Introduction The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a light-weight web transfer protocol suitable for applications in embedded devices used in services such as smart energy, smart home, building automation, remote patient monitoring etc. Due to the nature of the these use cases including critical, unattended infrastructure and the personal sphere, security and privacy are critical components. CoAP message exchanges can be protected with different security protocols. The CoAP specification defines a DTLS [RFC6347] binding for CoAP, which provides communication security including authentication, encryption, integrity, and replay protection. In order to bootstrap trust relations, the CoAP specification defines four security modes that are the result of different provisioning procedures (see section 9 of [I-D.ietf-core-coap]): o NoSec o PreSharedKey (PSK) o RawPublicKey (RPK) o Certificate The NoSec alternative assumes security measures at another protocol layer and provides no security at all. PSK and RPK modes rely on a pre-provisioned list of keys that the device can initiate a DTLS session with. Certificate mode requires provisioning of certain root trust anchor public keys (equivalent to CA certificates) that can be used to validate previously unknown X.509 certificates, before using them to establish a DTLS session. Given a setting where security is required, and where at least some devices are too resource constrained to handle X.509 certificates, devices would have to use either the PSK or the RPK mode. If the set of nodes that a device would communicate with varies dynamically (e.g. a pay-per-use scenario) this would in turn require constant re- provisioning of lists of trusted clients to the individual devices. Such an approach will obviously not scale well and make consistent management of security policies over a set of devices very difficult. Therefore we propose two additional security modes that take advantage of the low resource consumption of the PSK and the RPK modes, but also allow to manage dynamic trust relations without having to re-provision the individual nodes. The basic idea is to provision a symmetric key of a trust anchor to the devices. A node wishing to connect to the device can obtain either a derived secret key, or a Message Authentication Code (MAC) of its public key from one of the trust anchors, and the device can verify that this derived Seitz & Selander Expires April 24, 2014 [Page 3] INTERNET DRAFT Additional Security Modes for CoAP October 21, 2013 secret key, or MAC is generated by a trust anchor. The derived key or public key is then used by the device as in PSK or RPK mode, respectively. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Certain security-related terms are to be understood in the sense defined in [RFC4949]. These terms include, but are not limited to, "authentication", "authorization", "confidentiality", "encryption", "data integrity", "message authentication code", and "verify". Terminology for constrained environments is defined in [I-D.ietf- lwig-terminology] e.g. "constrained device". Furthermore this memo refers to the following entities: o The constrained device providing resources is called the Resource Server (RS) o The node connecting to the Resource Server in order to request some resource is called Client (C) o The entity having an a-priori trust relation with RS is called the Trust Anchor (TA) 2. DerivedKey Mode This mode addresses similar use cases as the PSK mode, but without the requirement for out-of-band provisioning of shared keys between C and RS. Instead each resource server is configured with secret, symmetric keys shared with its trust anchors. For simplicity of explanation we assume here, that each RS only has a single TA, and that they share the key K_RS-TA. A client wishing to establish a connection to a RS needs to obtain a symmetric key K_RS-C and a nonce from the TA, where K_RS-C is derived from K_RS-TA and that nonce. C transmits the nonce in the psk_identity field of the ClientKeyExchange message of the DTLS protocol. The RS then derives K_RS-C from the nonce and K_RS-TA, and then both proceed using K_RS-C as a pre-shared key [RFC4279]. Figure 1 illustrates this procedure. Client Trust Anchor Resource Server Seitz & Selander Expires April 24, 2014 [Page 4] INTERNET DRAFT Additional Security Modes for CoAP October 21, 2013 | 1. Request key | | |--------------------->| | | | 2. Process | | | authorization | | 3. K_RS-C + nonce | | |<---------------------| | | + | | | | 4. DTLS handshake using PSK = K_RS-C | |<---------------------------------------->| | and psk_identity = nonce | Figure 1: The message flow for DerivedKey mode How C authenticates with the TA, and how the TA authorizes the request for a key K_RS-C is out of scope for this memo. 2.1 Generating The Nonce Upon request, the trust anchor verifies if C is authorized to connect to the resource server. How this is done is out of scope for this memo. If the verification succeeds, the TA generates the nonce as follows: nonce = 'DK.' + TA_id + '.' C_id + '.' + sequence_number where '+' indicates concatenation, 'TA_id' is an identifier that the RS can use to select the correct K_RS-TA, 'C_id' is an identifier of C, and 'sequence_number' is a sequence number maintained by the RS and the TA. The TA then generates the shared key K_RS-C as described in section 2.2 and transfers the nonce and K_RS-C to C via a secure channel. 2.2 Calculating The Derived Key K_RS-C is derived from K_RS-TA by the trust anchor and the resource server through a data expansion step, as defined in [RFC5246]: P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + HMAC_hash(secret, A(2) + seed) + HMAC_hash(secret, A(3) + seed) + ... where '+' indicates concatenation and A() is defined as: Seitz & Selander Expires April 24, 2014 [Page 5] INTERNET DRAFT Additional Security Modes for CoAP October 21, 2013 A(0) = seed A(i) = HMAC_hash(secret, A(i-1)) In the present case: o hash is SHA-256, o 'secret' is the shared key K_RS-TA, and o 'seed' is the nonce. The nonce, associated to the connection request, is generated by the trust anchor (see 2.1). A nonce SHALL NOT be reused with the same shared key K_RS-TA. With one iteration of the P_SHA256, the output data D of 256 bits can be used to define K_RS-C either as one 256 bit key, or as one 128 bit key using the first 128 bits of D and discarding the rest. 2.3 Generating PSK_IDENTITY The nonce is used as the psk_identity field of the DTLS ClientKeyExchange message. Upon receiving a psk_identity in the ClientKeyExchange message, an RS can determine by the 'DK' prefix that C wants to use the DerivedKey security mode, and select the corresponding key K_RS-TA by using the nonce in order to calculate the key K_RS-C as specified in 2.2. 2.4 Key Expiration, Anti-replay, And Revocation The key K_RS-C enables the client to open a DTLS connection to the resource server, but in many cases one does not want this key to be valid forever. Furthermore an attacker can reuse a stolen key to gain access to the RS. Therefore the sequence_number part of the nonce can be used to expire the key K_RS-C (i.e. make it invalid for setting up new DTLS sessions) and protect against reuse of a {key, nonce} pair in a DTLS handshake. The sequence number is a 32-bit number that is specific to a TA and an RS. The TA keeps a list of sequence numbers per RS it is responsible for. A RS's sequence number is incremented by 1 for each new shared key K_RS-C generated for this RS. For each TA an RS has (typically only one), it keeps a window of most recently verified sequence numbers. Sequence number verification SHOULD be performed using the following sliding window procedure, Seitz & Selander Expires April 24, 2014 [Page 6] INTERNET DRAFT Additional Security Modes for CoAP October 21, 2013 borrowed from Section 3.4.3 of [RFC2402] (see also [RFC6347] section 4.1.2.6). The sequence number MUST be initialized to zero when an association between a TA and an RS is established. For each received DTLS handshake using the DerivedKey Mode, the RS MUST verify that the nonce contains a fresh sequence number. This SHOULD be the first check applied to a nonce after it has been received in the ClientKeyExchange message, to speed rejection of duplicate or old records. Freshness is checked through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) A minimum window size of 32 MUST be supported, but a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the minimum) MAY be chosen by the RS. The "right" edge of the window represents the highest validated Sequence Number value received on this RS. DTLS handshakes, using this security mode, that contain Sequence Numbers lower than the "left" edge of the window are rejected. Handshakes falling within the window are checked against a list of received handshakes with sequence numbers within the window. An efficient means for performing this check, based on the use of a bit mask, is described in Appendix C of [RFC2401]. If the sequence number falls within the window and is new, or if the sequence number is to the right of the window the RS proceeds to generate the shared key K_RS-C. If the handshake succeeds the RS updates the window. On some occasions one may want to explicitly revoke a key K_RS-C before its expiration. In these cases the trust anchor has to send a message to the RS specifying the sequence number of the key K_RS-C it wants to revoke. The RS can then update the receive window to mark this key as used. If a server is in use for a long period of time and able to process DTLS handshakes rapidly, the sequence number range may get exhausted within the lifetime of the server. In that case a new shared key K_RS-TA must be provisioned to the server and the TA, and the sequence number counters must be reset. Note: If we make the very optimistic assumption that a DTLS handshake takes very roughly 1 second for a constrained device, a 32-bit sequence number can last roughly 136 years, before it needs to be Seitz & Selander Expires April 24, 2014 [Page 7] INTERNET DRAFT Additional Security Modes for CoAP October 21, 2013 reset (60*60*24*365 = max 31,536,000 handshakes per year, 2^32/31,536,000 > 136). 3. AuthorizedPublicKey Mode This security mode addresses similar use cases as the RPK mode, but without the need for out-of-band validation of public keys. As in the DerivedKey mode, we assume that the resource servers are configured with a symmetric key K_RS-TA for each of their trust anchors. In order to run this mode, the client needs to get its public key authorized for DTLS with the RS by one of the TA. The TA does this by creating an authorization certificate protected by a message authentication code (MAC) using the key K_RS-TA. The TA also provides C with the public key of RS for use in DTLS. The client then performs the DTLS handshake in RPK mode, but replaces the RawPublicKey ClientCertificate with the authorization certificate. The RS verifies the certificate, and if it is valid, proceeds with the DTLS handshake as if the client public key had been provisioned out of band. Furthermore the RS sends an empty certificate_list in the ServerCertificate message, since the key has already been provided to C by the TA. The authorization certificate is essentially the RawPublicKey certificate of [I-D.ietf-tls-oob-pubkey] with an additional MAC. As with the RPK mode, this security mode benefits from a significantly smaller size of the client's Certificate message in the DTLS handshake. The verification of a MAC is also less resource consuming than verifying a digital signature. A considerable reduction in message size compared with the RPK mode, is that the RS does not have to send any certificate. Figure 2 illustrates the message flow of this mode. Client Trust Anchor Resource Server | 1. Req. authz cert for | | |----------------------->| | | public key PubK_C | 2. Process | | | authorization | | 3. authz cert + | | |<-----------------------| | | public key PubK_RS + | | | | 4. DTLS handshake using authz cert | |<------------------------------------------>| | | Figure 2: The message flow for AuthorizedPublicKey mode Seitz & Selander Expires April 24, 2014 [Page 8] INTERNET DRAFT Additional Security Modes for CoAP October 21, 2013 How C authenticates with the TA, and how the TA authorizes the request for an authorization certificate out of scope for this memo. 3.1 Structure of the Authorization Certificate Extension This section outlines the changes to the DTLS handshake message contents for the AuthorizedPublicKey mode. The procedure is analogous to the one in [I-D.ietf-tls-oob-pubkey], using the new certificate_type 'AuthzCert' and the new structure 'MacCert'. struct { select(certificate_type) { // certificate type defined in this document case AuthzCert: MacCert certificate; // certificate type defined in [I-D.ietf-tls-oob-pubkey] case RawPublicKey: opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>; // X.509 certificate defined in RFC 5246 case X.509: ASN.1Cert certificate_list<0..2^24-1>; // Additional certificate type based on TLS // Certificate Type Registry }; } Certificate; The MacCert structure is defined as follows: struct { opaque ASN.1_subjectPublicKeyInfo<1..2^24-1> opaque trust_anchor_id; uint32 sequence_number; MACAlgorithm mac_algorithm; uint8 mac_length; opaque MAC[mac_length]; } MacCert; Where ASN.1_subjectPublicKeyInfo is defined in section 3 of [I- D.ietf-tls-oob-pubkey], and the MACAlgorithm type is defined in [RFC5246]. The 'mac_algorithm' parameter specifies a function MAC = M(key, message), where K_RS-TA is used as the key, and the certificate with an empty MAC value as the message. Note that the size of the MacCert structure is only marginally larger than the RawPublicKey certificate used in RPK mode. Seitz & Selander Expires April 24, 2014 [Page 9] INTERNET DRAFT Additional Security Modes for CoAP October 21, 2013 The extended client_hello and extended server_hello defined in section 3 of [I-D.ietf-tls-oob-pubkey] are also used here, with the new certificate_type 'AuthzCert'. 3.2 Client and Server Handshake Behavior Section 4 of [I-D.ietf-tls-oob-pubkey] shows the use of the client and server certificate types in TLS. The AuthorizedPublicKey mode uses a variant of the handshake exemplified in section 5.3 of [I- D.ietf-tls-oob-pubkey] as illustrated by figure 4. client_hello, client_certificate_type=(AuthzCert) //(1) -> <- server_hello, server_certificate_type=(X.509) //(2) certificate, //(3) client_certificate_type=(AuthzCert) //(4) certificate_request, //(5) server_key_exchange, server_hello_done certificate, // (6) client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data Figure 4: Example of a DTLS handshake with Authorization Certificate provided by the Client This handshake starts with the client indicating its ability to use AuthorizedPublicKey mode (1). Since the client has already received the server's public key from the TA, the server sends an empty certificate_list in the certificate message (3), using the indication for X.509 certificates in (2). This indication is only used, because it allows to send an empty certificate_list. For client authentication the server indicates in (4) that it selected the AuthorizedPublicKey mode and requests a certificate from the client in (5). The client provides a MacCert structure (6) after receiving and processing the server hello message. 3.3 Payload Verification Procedure After negotiating client_certificate_type="AuthzCert" in the Seitz & Selander Expires April 24, 2014 [Page 10] INTERNET DRAFT Additional Security Modes for CoAP October 21, 2013 ClientHello/ServerHello steps of the DTLS protocol, and receiving the ClientCertificate message, the RS proceeds to verify the C's public key using the following steps: o Check if the trust_anchor_id identifies a trust anchor o Check if the sequence_number is valid o Check that the ASN.1_subjectPublicKeyInfo contains a valid SubjectPublicKeyInfo structure o Check the mac with the shared key K_RS-TA. If any of these checks fail, the DTLS handshake is aborted and the RS MUST send a bad_certificate alert. 3.4 Key Expiration, Anti-replay, And Revocation The rationale and procedures for handling sequence numbers are the same as described in section 2.4. 4. Access Control Lists The CoAP specification uses Access Control Lists to keep track of pre-shared symmetric keys, raw public keys, and root trust anchors for X.509 certificates, used in the corresponding security modes (see section 9 and especially 9.1.3.2.1 of [I-D.ietf-core-coap]). An implementation supporting one or both of the security modes specified above MUST be extended to support storing lists of identifiers and secret keys of the trust anchors. 5. Security Considerations All security consideration from [RFC6347] and [RFC4279] also apply to this approach. Furthermore the trust anchors used for authorizing the use of keys in the two proposed security modes are valuable targets for attacks since they potentially allow access to many devices. They should be protected accordingly. The nonce used to generate the shared key for the DK mode is static except for the sequence number, an attacker could exploit this for a dictionary attack. If such an attack is considered feasible, an additional random seed should be added to the nonce to increase the variable part. The client identifier and other information in the nonce cannot be trusted until the client is authenticated using the key derived from the nonce. The sequence number mechanism for expiration can potentially lead to keys being valid for a longer time than expected. This will be the Seitz & Selander Expires April 24, 2014 [Page 11] INTERNET DRAFT Additional Security Modes for CoAP October 21, 2013 case if the number of requests for a device drops significantly, and it therefore takes longer to fill the sliding window. Trust anchors can monitor this and explicitly revoke keys if the frequency of requests drops significantly. It is also possible to use timers in the device to implement complementing expiry mechanisms. An attacker can induce a server to perform the DTLS handshake up to Flight 4, without having any legitimate key material from a trust anchor. This could be used for denial of service attacks against the server. However these problems are also present with any of the standard CoAP security modes and respective DTLS handshakes. 6. IANA Considerations IANA is asked to register a new value in the "TLS Certificate Types" registry of Transport Layer Security (TLS) Extensions [TLS- Certificate-Types-Registry], as follows: Value: 3 Description: Authorized Public Key Certificate (AuthzCert) Reference: [[THIS RFC]] 7. Acknowledgements The authors would like to thank Stefanie Gerdes, Mats Naeslund, and John Mattsson for contributions and helpful comments. Seitz & Selander Expires April 24, 2014 [Page 12] INTERNET DRAFT Additional Security Modes for CoAP October 21, 2013 8. References 8.1 Normative References [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf- core-coap-18 (work in progress), June 2013. [I-D.ietf-tls-oob-pubkey] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and T. Kivinen, "Out-of-Band Public Key Validation for Transport Layer Security (TLS)", draft-ietf-tls-oob- pubkey-10 (work in progress), October 2013. [TLS-Certificate-Types-Registry] "TLS Certificate Types Registry", February 2013, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4279] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. 8.2 Informative References [I-D.ietf-lwig-terminology] Bormann, C., Ersue, M., and Keranen, A., "Terminology for Constrained Node Networks", draft-ietf-lwig-terminology-05 (work in progress), July 2013. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. Obsoleted by RFC4301. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. Obsoleted by RFC4302, RFC4305. Seitz & Selander Expires April 24, 2014 [Page 13] INTERNET DRAFT Additional Security Modes for CoAP October 21, 2013 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007. Authors' Addresses Ludwig Seitz SICS Swedish ICT AB Scheelevagen 17 22370 Lund SWEDEN EMail: ludwig@sics.se Goeran Selander Ericsson Farogatan 6 16480 Kista SWEDEN EMail: goran.selander@ericsson.com Seitz & Selander Expires April 24, 2014 [Page 14]