idnits 2.17.1 draft-mandyam-rats-qwestoken-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2019) is 1633 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-rats-eat' is defined on line 188, but no explicit reference was found in the text == Unused Reference: 'RFC7049' is defined on line 193, but no explicit reference was found in the text == Unused Reference: 'RFC8152' is defined on line 197, but no explicit reference was found in the text == Unused Reference: 'RFC8392' is defined on line 201, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-00 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Rats Working Group G. Mandyam 3 Internet-Draft V. Sekhar 4 Intended status: Informational S. Mohammed 5 Expires: May 3, 2020 Qualcomm Technologies Inc. 6 October 31, 2019 8 The Qualcomm Wireless Edge Services (QWES) Attestation Token 9 draft-mandyam-rats-qwestoken-00 11 Abstract 13 An attestation format based on the Entity Attestation Token (EAT) is 14 described. The Qualcomm Wireless Edge Services (QWES) token is used 15 in the context of device onboarding and authentication. It is 16 verified in the same manner as any CBOR Web Token (CWT). 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 May 3, 2020. 35 Copyright Notice 37 Copyright (c) 2019 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. EAT Compliant Claims in QWES Token . . . . . . . . . . . . . 2 54 2.1. OEM ID . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2.2. nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. QWES Token Augmentation to EAT . . . . . . . . . . . . . . . 3 57 3.1. DevID . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2. HWVer . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.3. Context . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.4. PKHash . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.5. SPID . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.6. QSEEVersion . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.7. FWVersion . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.8. Security State . . . . . . . . . . . . . . . . . . . . . 4 65 3.9. CSR . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.10. AppData . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 69 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 72 1. Introduction 74 A description of the Qualcomm Wireless Edge Services (QWES) 75 attestation token is provided. QWES allows for service providers to 76 manage devices that implement Qualcomm semiconductor solutions. 77 Based on the EAT-compliant attestation token (see [I-D.ietf-rats- 78 eat]) produced in a trusted execution environment (TEE), a service 79 provider can verify the device identity in addition to several other 80 security-impacting characteristics. 82 2. EAT Compliant Claims in QWES Token 84 Certain claims defined for EAT are leveraged in the QWES token. 86 2.1. OEM ID 88 The QWES token makes use of an OEM ID. However, the type is a uint 89 (not a bstr as per the EAT specification). 91 2.2. nonce 93 The QWES token can carry a nonce. The nonce is a bstr. 95 3. QWES Token Augmentation to EAT 97 Several claims have been defined that are not currently present in 98 the EAT base set to complete the QWES token. 100 3.1. DevID 102 The DevID is a 256-bit bstr that serves as a device identifier. It 103 differs from the ueid (Universal Entity ID) defined in the EAT 104 specificaation. A specific device ID can be created for ISV's based 105 on their identifier combined with a salt. This allows for a certain 106 level of privacy preservation. Note that the RAND option for ueid 107 may be a suitable substitute for this claim. 109 3.2. HWVer 111 This is a bstr claim that distinguishes different system-on-chip 112 (SoC) models. 114 3.3. Context 116 This is a numerical (uint) index that denotes the context of the 117 attestation. The current values defined (0-4) are: on-demand 118 attestation, registration, provisioning, certificate issuance and 119 proof-of-possession. 121 3.4. PKHash 123 This is a bstr containing a SHA-256 hash of a public key provisioned 124 by the OEM. It can be used optionally in place of an OEM ID. 126 3.5. SPID 128 This is a numerical (uint) identifier of the service provider 129 associated with the QWES token. The EAT specification's origination 130 claim can be a suitable substitute. 132 3.6. QSEEVersion 134 This is tstr that designates the TEE version ("QSEE" = Qualcomm 135 Secure Execution Environment). 137 3.7. FWVersion 139 This is tstr that designates the firmware version specifically 140 dedicated to bootstrapping. 142 3.8. Security State 144 This is tstr that contains the state of one-time programmable (OTP) 145 memory. Bits in this field will be set as per the security-impacting 146 section of the OTP memory. The relevant bits in OTP would normally 147 be used to control secure boot enablement, debug disablement, debug 148 enablement parameters, and the state of device keys (i.e. whether 149 they are locked for reading or writing). 151 3.9. CSR 153 A Certificate Signing Request (CSR) may be carried in a QWES token as 154 a bstr. This allows for a CA (certifying authority) to verify an 155 attestation and provide a certificate without an extra round trip. 156 This is an optional claim. 158 3.10. AppData 160 This is a bstr containing a hash of the associated application data. 161 Since the QWES token can be service provider-specific, the hash that 162 is returned can correspond to the corresponding user space 163 application that invoked the generation of the attestation token. 164 This is an optional claim. 166 4. Example 168 A sample QWES token payload is shown. It would be signed and/or 169 encrypted as per COSE guidelines. 171 { 172 / DevID / h'0a', 173 / OEMID / 32, 174 / HWVer / h'0e', 175 / Context / 2, / provisioning / 176 / SPID / 10, 177 / Nonce / h'da378321bb' 178 } 180 Sample QWES Token Payload 182 5. IANA Considerations 184 This memo includes no request to IANA. 186 6. Normative References 188 [I-D.ietf-rats-eat] 189 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 190 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 191 ietf-rats-eat-00 (work in progress), June 2019. 193 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 194 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 195 October 2013, . 197 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 198 RFC 8152, DOI 10.17487/RFC8152, July 2017, 199 . 201 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 202 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 203 May 2018, . 205 Authors' Addresses 207 Giridhar Mandyam 208 Qualcomm Technologies Inc. 209 5775 Morehouse Drive 210 San Diego, California 92121 211 USA 213 Phone: +1 858 651 7200 214 Email: mandyam@qti.qualcomm.com 216 Vivek Sekhar 217 Qualcomm Technologies Inc. 218 5775 Morehouse Drive 219 San Diego, California 92121 220 USA 222 Phone: +1 858 651 3557 223 Email: vsekhar@qti.qualcomm.com 224 Shahid Mohammed 225 Qualcomm Technologies Inc. 226 5775 Morehouse Drive 227 San Diego, California 92121 228 USA 230 Phone: +1 858 651 7975 231 Email: shahidm@qti.qualcomm.com