idnits 2.17.00 (12 Aug 2021) /tmp/idnits33204/draft-tschofenig-ace-overview-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 14, 2014) is 3011 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-abfab-arch has been published as RFC 7831 == Outdated reference: draft-ietf-kitten-sasl-oauth has been published as RFC 7628 == Outdated reference: draft-ietf-lwig-terminology has been published as RFC 7228 == Outdated reference: draft-ietf-oauth-json-web-token has been published as RFC 7519 == Outdated reference: A later version (-02) exists of draft-seitz-ace-usecases-00 -- Obsolete informational reference (is this intentional?): RFC 3281 (Obsoleted by RFC 5755) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft ARM Ltd. 4 Intended status: Best Current Practice February 14, 2014 5 Expires: August 18, 2014 7 Authentication and Authorization for Constrained Environments (ACE): 8 Overview of Existing Security Protocols 9 draft-tschofenig-ace-overview-00.txt 11 Abstract 13 This document surveys existing three party authentication and 14 authorization protocols for use with Internet of Things use cases. 15 The discussed protocol frameworks are Kerberos, OAuth, ABFAB, and the 16 certificate model. The aim is to understand whether any of the 17 available standardized security protocols are re-usable for 18 constrained environments. A future version of this document will 19 provide a more detailed analysis against the requirements. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 18, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 1. Introduction 55 [I-D.seitz-ace-usecases] introduces a number of use cases that 56 require device-to-device authentication whereby both devices may be 57 constrained. [I-D.ietf-lwig-terminology] discusses the different 58 types of constraints of these devices. 60 This document aims to raise the high-level question about the 61 possible re-use of existing three party authentication and key 62 exchange protocols for use in IoT environments. This version of the 63 document does not aim to map requirements derived from the use cases 64 against these protocols. Such a detailed analysis is premature at 65 this point when use case descriptions are still in flux. 67 The starting assumption for the architectures in this document is 68 that a device (a client) wants to access some resource (referred as 69 service in this document). It unfortunately does not have any 70 relationship with the server offering that service. Figure 1 shows 71 the scenario graphically. 73 +-----------+ no prior +-----------+ 74 | Client | relationship | Service | 75 | | | | 76 +-----------+ +-----------+ 78 Figure 1: Two Party Scenario. 80 Imagine that the client is a light-switch and the service is a light- 81 bulb. 83 Today, companies solve this case by using a pairing protocol (at the 84 link layer typically) where the two devices execute a special 85 imprinting/pairing protocol to establish an initial key by using out- 86 of-band (OOB) channel. This OOB channel can come in many forms: 88 o Using an alternative communication channel, such as a USB stick, 89 Ethernet cable 91 o Human involvement by comparing hashed keys, entering passkeys, 92 scanning QR codes 94 o Second wireless connectivity (e.g., infrared) 95 o Proximity-based information 97 The pairing is a suitable approach where wireless communication 98 replaces a wired communication technology previously used. For 99 example, a headset connected to a music player using a wired 100 connection is replaced with the wireless version. Not all use cases 101 do, however, allow users to pair their device with other devices 102 upfront. Consider an enterprise with electronic door locks. It is 103 hard to imagine an employee who has to pair their digital key with 104 every door in the building first before they use the system. 106 Requiring every device to pair with every other device upfront is 107 often inconvenient or not feasible. Hence, this document does not 108 explore pairing solutions further. To offer an improved user 109 experience with better scalability properties a device might either 110 share credentials with some trusted third party. There are various 111 ways how credentials can be shared with these trusted third parties. 112 For example, credentials may be provisioned during the manufacturing 113 process or devices may have been paired with the trusted third party 114 (in case the trusted third party is local to the user). In fact, 115 today is it very common for IoT devices to have at least credentials 116 pre-provisioned for use with the vendor / manufacturer of the device 117 to allow software updates to be provided securely. 119 Thus, we move to a model where the device (client) shares some 120 credentials with a trusted third party. This trusted third party 121 does not need to be a server on the Internet; ideally it could also 122 be operated locally within someones' home, within an enterprise, or 123 within a factory. 125 This three party architecture is shown in Figure 2. 127 +-----------+ 128 | Trusted | 129 +--------------------------->|Third Party| 130 | Key +-----------+ 131 | ^ 132 | | 133 | | 134 | | Key 135 | | 136 | | 137 | | 138 v v 139 +-----------+ no prior +-----+-----+ 140 | | relationship | | 141 | Client | <..................>| Service | 142 +-----------+ +-----------+ 144 Figure 2: Three Party Scenario. 146 This three party architecture and messaging pattern has been explored 147 with prior IETF work and this document lists the most relevant 148 efforts (on a high level). 150 The goal of the communication exchange is that the client has been 151 authorized to access the service, and is able to secure the exchange 152 of information. The client and the service may, optionally, possess 153 keying material for future use of the service with the benefit of 154 better performance for future interactions. 156 Note: This document does not aim to cover the use cases in their 157 entirety. First, we assume that the security protocol interaction 158 for link layer authentication is outside the scope. The focus of 159 this document is on the application layer interactions when accessing 160 services. Second, this document does not survey access control 161 policy languages and mechanisms for managing these access control 162 policies. These policies are important since many of the systems 163 described below only provide an answer to the question 'Who is the 164 holder of this key?' and standards for answering the question 'Can 165 this key be used for this purpose?' (authorization) are often 166 realized in a proprietary way. 168 While Figure 1 shows three parties the protocols described in 169 Section 2 have been generalized to four or even multi-party scenario. 170 The result is shown in Figure 2. 172 +-----------+ +-----------+ 173 | Trusted | Agreement w/key | Trusted | 174 | Third |<-------------------->| Third | 175 | Party A | | Party B | 176 +-----------+ +-----------+ 177 ^ ^ 178 | | 179 | Key | Key 180 | | 181 | | 182 | | 183 | | 184 v v 185 +-----------+ no prior +-----+-----+ 186 | | relationship | | 187 | Client | <..................>| Service | 188 +-----------+ +-----------+ 190 Figure 3: Generalization of Three Party Scenario. 192 2. Three Party Security Frameworks 194 This section introduces four authentication and authorization 195 frameworks standardized in the IETF. The description is 196 intentionally kept at a high level and a reader is encouraged to 197 consult the referenced documents for details and various options 198 these protocols offer. The terminology with each of these protocols 199 is lightly different and appropriate mappings have been applied. 201 To demonstrate the level of maturity of these frameworks availability 202 of products, source code, and deployment experience is mentioned for 203 each of these frameworks. Note, however, that this experience does 204 not imply suitability for use with the IoT environment. 206 2.1. Application Bridging for Federated Access Beyond Web Architecture 208 This section describes the Application Bridging for Federated Access 209 Beyond Web architecture [I-D.ietf-abfab-arch], which builds on the 210 Authentication, Authorization and Accounting (AAA) framework. The 211 AAA framework re-uses the Extensible Authentication Protocol (EAP) 212 [RFC5247] and EAP methods for the authentication protocol 213 capabilities. A detailed description of the AAA keying framework can 214 be found in [RFC5247]. 216 +--------------+ 217 | Identity | 218 | Provider | 219 | (IdP) | 220 +-^----------^-+ 221 * EAP o RADIUS 222 * o 223 * o 224 +-------------+ +-v----------v--+ 225 | | | | 226 | Client | EAP/EAP Method | Relying | 227 | |<****************>| Party | 228 | | GSS-API | | 229 | |<---------------->| | 230 | | Application | | 231 | | Data | | 232 | |<================>| | 233 +-------------+ +---------------+ 235 Terminology Mapping: 236 - The term 'Relying Party' corresponds to the 'service'. 237 - The term 'Identity Provider' corresponds to the 238 'trusted third party'. 240 Figure 4: ABFAB Architecture. 242 With the message exchange shown in Figure 4 the client wants to 243 obtain access to a service and starts interacting with that service. 244 Since no prior relationship between the client and the service is 245 assumed the EAP message exchanges is relayed by the service and the 246 EAP server component of the IdP. Between the client and the service 247 these EAP payloads are encapsulated within the GSS-API. After a 248 successful authentication and authorization session keys are 249 delivered from the IdP to the service and can then be used to secure 250 the application layer data exchange between the client and the 251 service. 253 While the use of EAP and the AAA architecture has mostly found use 254 for network access authentication the work on ABFAB applies this 255 architecture to application layer services. 257 Pros: 259 o Re-uses existing protocols: RADIUS, GSS-API, EAP, EAP methods. 261 o Security properties of the AAA / EAP framework well studied and 262 large deployments of the AAA framework exist. 264 o Products and open source code exists for EAP, EAP methods, RADIUS, 265 and the GSS-API. The extensions needed for ABFAB also have been 266 implemented but they are less mature compared to the EAP/AAA 267 deployment. 269 o Large range of EAP methods available offering all possible 270 authentication and key exchange protocols for authentication 271 between the client and the AAA server. These mechanisms have been 272 deployed and are in widespread use today. While many EAP methods 273 have been standardized only a few are in widespread use in non-IoT 274 environments. However, there are many (open source) 275 implementations available such that further experience concerning 276 IoT suitability can be gathered. 278 o IoT devices might use the AAA/EAP architecture for network access 279 authentication (e.g., WLAN-based, IEEE 802.15.4-based ZigBee-IP 280 deployments). 282 o The AAA framework also supports authentication in a federated 283 environment. 285 o Authorization information is conveyed within RADIUS (and 286 potentially in SAML assertions, as envisioned by ABFAB). 288 Cons: 290 o The initial authentication and authorization exchange requires 291 real-time interaction between the AAA server and the service. 293 o Deployments have so far used this architecture mainly for network 294 access and for specific applications (VoIP) only. Experience with 295 other applications, as ABFAB envisions, is rather limited. 297 o ABFAB architecture uses layering of EAP within the GSS-API, which 298 adds additional overhead. A binding for the transport of EAP 299 payloads in CoAP, for example, does not exist. 301 o No unified authorization policy language has been defined for the 302 AAA/EAP architecture. Instead, RADIUS attributes carry 303 information about access control decisions. 305 2.2. Kerberos 307 Kerberos [RFC4120] is authentication system for distributed 308 environments that has enjoyed deployment for more than three decades. 309 The security properties have been extensively studied and various 310 implementations exist. 312 +----------------+ 313 | Authentication | 314 | Server (AS) | 315 +----------------+ 316 ^ / 317 Request / / 318 Ticket / / 319 / /Ticket 320 / /{SK}C-KDC 321 / / 322 / / 323 / / 324 / v 325 +-----------+ +-----------+ 326 | | Ticket + Authenticator | | 327 | Client |---------------------------->| Server | 328 | |<===========================>| | 329 +-----------+ Application Data +-----------+ 331 Terminology Mapping: 332 - The term AS corresponds to the 'trusted third party.' 333 - The term Server corresponds to the 'service'. 335 Figure 5: Kerberos. 337 The Kerberos exchange shown in Figure 5 illustrates a client who 338 wants to get access to a server. It first has to interact with the 339 Authentication Server (AS) to request a ticket. In response, the AS 340 provides a ticket, which is a data structure encrypted with a key 341 known only between the server and the AS. This ticket includes 342 information about the client, a session key (SK) for later use, and 343 various other security relevant information elements. The client 344 also obtains the session key encrypted with a key it shares with the 345 AS. 347 When a service access is required then the client interacts with the 348 server and presents the ticket along with an Authenticator. The 349 Authenticator demonstrates that the client was able to decrypt the 350 session key with the key it shares with the AS and that it was able 351 to apply this key to compute a keyed message digest over several 352 fields, including a time-stamp, when accessing the service. The 353 time-stamp avoids replay attacks. 355 Pros: 357 o Re-uses existing protocol: Kerberos 359 o Security properties well studied and large deployments exist. 361 o Products and open source service exist. 363 o Most parts of Kerberos, particularly the ticket concept, are 364 designed with symmetric key cryptography, which improves 365 performance. The Kerberos ticket is consequently fairly small and 366 uses a binary encoding. 368 o Kerberos also supports cross-realm authentication for scalable 369 deployments. 371 o Kerberos also specifies a UDP-based transport. 373 o The message exchanges between the client and the service can be 374 tailored to the need of the application. 376 Cons: 378 o Each ticket is only usable for a single service (intentionally). 379 As such, new tickets have to be requested whenever the client 380 wants to access a new service or when the ticket expired. 382 o For the authentication between the client and the KDC a limited 383 number of authentication protocols have been specified. 385 o Kerberos uses ASN.1 for encoding of the ticket and various 386 messages. This may increase implementation complexity but the 387 binary encoding is more efficient than other encodings, like XML 388 or JSON. 390 o No standardized access control policy has been standardized for 391 inclusion inside a ticket. Proprietary policies are, however, 392 used in real-world deployments. 394 o A CoAP binding for the KRB_PRIV and the KRB_SAFE message exchanges 395 used to secure application data between the client and the service 396 have not been defined. 398 2.3. OAuth 400 The OAuth protocol is a recent development for the Web, which re-uses 401 the Kerberos interaction pattern with influences from the Web / 402 mobile app space. It initially aimed to solve the problem of 403 delegated access to protected resources where websites asked users to 404 share their long-term password. Over time OAuth has been used in 405 other use cases that require delegated access. 407 +-------------+ 408 |Authorization| 409 |Server (AS) | 410 +-------------+ 411 ^ / 412 Request / / 413 Access / / 414 Token / /Access Token 415 / / 416 / / 417 / / 418 / / 419 O / v 420 /|\ +-----------+ +-----------+ 421 | -----> | | Access Token | Resource | 422 / \ <----- | Client |----------------->| Server | 423 Resource | |<================>| (RS) | 424 Owner +-----------+ Application Data +-----------+ 426 Terminology Mapping: 427 - The term AS corresponds to the 'trusted third party'. 428 - The term RS corresponds to the 'service'. 430 Figure 6: Simplified OAuth Architecture. 432 Figure 6 shows the high-level OAuth message exchange. The canonical 433 OAuth example allows a web user (resource owner) to grant a printing 434 service (client) access to her private photos stored at a photo 435 sharing service (resource server), without sharing her username and 436 password. Instead, she authenticates directly with the authorization 437 server which issues the printing service delegation-specific 438 credentials. 440 Pros: 442 o Re-uses existing protocols: OAuth Core [RFC6749], OAuth Bearer 443 Token [RFC6750] OAuth MAC Token [I-D.ietf-oauth-v2-http-mac]/ HOTK 444 [I-D.tschofenig-oauth-hotk], JWT [I-D.ietf-oauth-json-web-token]. 446 o Large deployments in the Web environment exist, which use the 447 OAuth Bearer Token. 449 o Products and open source service exist. 451 o OAuth is flexible with regard to the used cryptography. A 452 standardized format for the access token has been described with 453 the JSON Web Token (JWT). For security protection of the JWT 454 various specifications from the JOSE working group are available. 456 o The message exchanges between the client and the service can be 457 tailored to the need of the application. Bindings are available 458 for HTTPS and SASL [I-D.ietf-kitten-sasl-oauth]. 460 o With regard to the offered security mechanism the interaction 461 between the client and the resource server gives several choices: 462 The OAuth Bearer Token requires a TLS exchange between the client 463 and the resource server. The MAC Token specification is 464 conceptually similar to Kerberos; a version based on asymmetric 465 cryptography exists as well (see HOTK). 467 Cons: 469 o For an environment with more than one authorization server or 470 where the authorization server is located in a different domain 471 than the resource server the standardization work is still in 472 progress. Efforts have mostly be done in Kantara with the User- 473 Managed-Access (UMA) working group. 475 o A binding for CoAP does not exist for the client to authorization 476 server nor for the client to resource server. 478 o The OAuth architecture does not standardize the authentication 479 procedure of the resource owner to the authorization server 480 itself. This is a common approach for the Web environment where a 481 number of different authentication protocols are in use in the 482 browser. As such, the protocol works with any authentication 483 mechanism. 485 2.4. Certificate Model 487 Prior work on the Public Key Infrastructure, certificate formats, 488 certificate extensions, and various certificate management protocols 489 can be re-used in the IoT context. With respect to the use cases 490 described in [I-D.seitz-ace-usecases] certificates may be short-lived 491 and might need to contain attributes (which may be used for making 492 access control decisions) rather than purely relying on the identity 493 of users and their devices. 495 For the purpose of dynamic provisioning short-lived certificates, 496 this document envisions to re-use a subset of the functionality 497 offered by protocols like the Certificate Management over CMS (CMC) 498 [RFC5272], the Certificate Management Protocol (CMP) [RFC4210], the 499 Simple Certificate Enrollment Protocol [I-D.nourse-scep], 500 Certification Request Syntax Standard - PKCS#10 [RFC2315] (with TLS 501 or with PKCS#7 [RFC2986] ). While these protocols offer slightly 502 different features, on a high-level the all fulfill the same 503 function. Note that the management of trust anchors may be provided 504 by a different protocol, such as Trust Anchor Management Protocol 505 (TAMP) [RFC5934]. 507 Of course, certificates do not necessarily need to be short-lived and 508 could even be provisioned during the manufacturing process and never 509 changed during the lifetime of the device. The drawback of such an 510 approach is, however, that mechanisms for certificate revocation have 511 to be provided. Furthermore, privacy concerns might be arise since 512 the same client certificate content will be shown to every service 513 rather than information that is only relevant for a specific purpose. 515 +-------------+ 516 |Certification| 517 | Authority | 518 +-------------+ 519 ^ / 520 Request / / 521 (Short) / / 522 Lived / /(Short) Lived 523 Cert / / Certificate 524 / / 525 / / 526 / / 527 / v 528 +-----------+ +-----------+ 529 | | DTLS with certificate | | 530 | | or app layer msg w/cert | | 531 | Client |---------------------------->| Service | 532 | |<===========================>| | 533 +-----------+ Application Data +-----------+ 535 Figure 7: Certificate Model. 537 Pros: 539 o Re-uses existing protocols: DTLS (or application protocol), CMP/ 540 CMC/PKCS#10/SCEP, specifications (certificate format - RFC 6818 541 [RFC6818]), and concepts (PKI). 543 o Large deployments on the Web and with enterprise system exist. 545 o Products and open source code exists. 547 o The certificate format offers flexibility in terms of content. 548 New extensions have been defined over time. 550 o Certificates can be used with DTLS without any additional 551 modifications. Certificates can also used with application 552 security mechanisms. 554 o Authorization information may be placed in an extension of a 555 public key certificate or in a separate attribute certificate 556 [RFC3281]. Earlier work on KeyNote [RFC2704]could be re-used as 557 it provides a more flexible authorization policy language. 559 o A single certificate can be used with a number of different 560 services. 562 o Various PKI management protocols have been defined and they offer 563 some flexibility. The properties vary on the specific use cases. 565 Cons: 567 o The certificate format and the PKI management protocols use ASN.1. 569 o No UDP or CoAP transport is defined for CMC/CMP/SCEP. For PKCS#10 570 no transport is defined at all. 572 o The public key infrastructure only focuses on asymmetric 573 cryptography. A separate body of work is available for 574 provisioning symmetric keys (like one-time-keys), such as the 575 Portable Symmetric Key Container (PSKC) [RFC6030] and Dynamic 576 Symmetric Key Provisioning Protocol (DSKPP) ([RFC6063]). 578 o Protocols for certificate enrollment are in use but many 579 deployments use their own strategy for distributing certificates 580 (typically long-lived) to their users. 582 o Asymmetric cryptography is computationally more expensive than 583 symmetric cryptography but offers additional security benefits. 585 3. Conclusion 587 Several existing protocols can be used to meet the use cases outlined 588 in [I-D.seitz-ace-usecases]. Each technology presented here offers a 589 number of possibilities for profiling to make them work on for 590 constrained devices. Despite the range of available security 591 protocols, the use cases suggest that there is a need to profile and 592 to extend those in order to make them fit for the constrained 593 environment. 595 The right choice of authentication and authorization protocol will 596 heavily depend on the envisioned usage environment. 598 It is, however, also worth noting that several aspects that are not 599 discussed in this document although they appear as requirements in 600 the use case document, namely 602 o a language for describing access control policies, 604 o the encoding of these policies, and 606 o the container for associating these policies with keying material. 608 4. Security Considerations 610 This entire document is about security. 612 5. IANA Considerations 614 This document does not require any actions by IANA. 616 6. Acknowledgements 618 The author would like to thank Stefanie Gerdes for her review 619 comments. 621 7. Informative References 623 [I-D.ietf-abfab-arch] 624 Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. 625 Schaad, "Application Bridging for Federated Access Beyond 626 Web (ABFAB) Architecture", draft-ietf-abfab-arch-10 (work 627 in progress), December 2013. 629 [I-D.ietf-kitten-sasl-oauth] 630 Mills, W., Showalter, T., and H. Tschofenig, "A set of 631 SASL Mechanisms for OAuth", draft-ietf-kitten-sasl- 632 oauth-12 (work in progress), December 2013. 634 [I-D.ietf-lwig-terminology] 635 Bormann, C., Ersue, M., and A. Keranen, "Terminology for 636 Constrained Node Networks", draft-ietf-lwig-terminology-06 637 (work in progress), December 2013. 639 [I-D.ietf-oauth-json-web-token] 640 Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 641 (JWT)", draft-ietf-oauth-json-web-token-15 (work in 642 progress), January 2014. 644 [I-D.ietf-oauth-v2-http-mac] 645 Richer, J., Mills, W., Tschofenig, H., and P. Hunt, "OAuth 646 2.0 Message Authentication Code (MAC) Tokens", draft-ietf- 647 oauth-v2-http-mac-05 (work in progress), January 2014. 649 [I-D.nourse-scep] 650 Pritikin, M., Nourse, A., and J. Vilhuber, "Simple 651 Certificate Enrollment Protocol", draft-nourse-scep-23 652 (work in progress), September 2011. 654 [I-D.seitz-ace-usecases] 655 Seitz, L., Gerdes, S., and G. Selander, "ACE use cases", 656 draft-seitz-ace-usecases-00 (work in progress), February 657 2014. 659 [I-D.tschofenig-oauth-hotk] 660 Bradley, J., Hunt, P., Nadalin, A., and H. Tschofenig, 661 "The OAuth 2.0 Authorization Framework: Holder-of-the-Key 662 Token Usage", draft-tschofenig-oauth-hotk-03 (work in 663 progress), January 2014. 665 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 666 Version 1.5", RFC 2315, March 1998. 668 [RFC2704] Blaze, M., Feigenbaum, J., Ioannidis, J., and A. 669 Keromytis, "The KeyNote Trust-Management System Version 670 2", RFC 2704, September 1999. 672 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 673 Request Syntax Specification Version 1.7", RFC 2986, 674 November 2000. 676 [RFC3281] Farrell, S. and R. Housley, "An Internet Attribute 677 Certificate Profile for Authorization", RFC 3281, April 678 2002. 680 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 681 Kerberos Network Authentication Service (V5)", RFC 4120, 682 July 2005. 684 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 685 "Internet X.509 Public Key Infrastructure Certificate 686 Management Protocol (CMP)", RFC 4210, September 2005. 688 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 689 Authentication Protocol (EAP) Key Management Framework", 690 RFC 5247, August 2008. 692 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 693 (CMC)", RFC 5272, June 2008. 695 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 696 Management Protocol (TAMP)", RFC 5934, August 2010. 698 [RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric 699 Key Container (PSKC)", RFC 6030, October 2010. 701 [RFC6063] Doherty, A., Pei, M., Machani, S., and M. Nystrom, 702 "Dynamic Symmetric Key Provisioning Protocol (DSKPP)", RFC 703 6063, December 2010. 705 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 706 6749, October 2012. 708 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 709 Framework: Bearer Token Usage", RFC 6750, October 2012. 711 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 712 Infrastructure Certificate and Certificate Revocation List 713 (CRL) Profile", RFC 6818, January 2013. 715 Author's Address 717 Hannes Tschofenig 718 ARM Ltd. 719 110 Fulbourn Rd 720 Cambridge CB1 9NJ 721 Great Britain 723 Email: Hannes.tschofenig@gmx.net 724 URI: http://www.tschofenig.priv.at