One document matched: draft-tschofenig-ace-overview-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.seitz-ace-usecases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.seitz-ace-usecases.xml">
<!ENTITY I-D.ietf-oauth-v2-http-mac SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-v2-http-mac.xml">
<!ENTITY I-D.tschofenig-oauth-hotk SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tschofenig-oauth-hotk.xml">
<!ENTITY I-D.ietf-oauth-json-web-token SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-json-web-token.xml">
<!ENTITY I-D.seitz-ace-usecases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.seitz-ace-usecases.xml">
<!ENTITY I-D.ietf-abfab-arch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-abfab-arch.xml">
<!ENTITY I-D.ietf-lwig-terminology SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lwig-terminology.xml">
<!ENTITY I-D.ietf-kitten-sasl-oauth SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-kitten-sasl-oauth.xml">
<!ENTITY I-D.nourse-scep SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.nourse-scep.xml">
<!ENTITY RFC6818 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6818.xml">
<!ENTITY RFC2315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2315.xml">
<!ENTITY RFC2986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2986.xml">
<!ENTITY RFC5272 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5272.xml">
<!ENTITY RFC4210 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4210.xml">
<!ENTITY RFC6749 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6749.xml">
<!ENTITY RFC6750 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6750.xml">
<!ENTITY RFC5247 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5247.xml">
<!ENTITY RFC4120 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml">
<!ENTITY RFC6063 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6063.xml">
<!ENTITY RFC2704 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2704.xml">
<!ENTITY RFC5934 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5934.xml">
<!ENTITY RFC6030 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6030.xml">
<!ENTITY RFC3281 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3281.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="no"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="bcp" ipr="trust200902" docName="draft-tschofenig-ace-overview-00.txt">
<front>
<title abbrev="ACE Overview">Authentication and Authorization for Constrained Environments (ACE): Overview of Existing Security Protocols</title>
<author initials="H.T." surname="Tschofenig" fullname="Hannes Tschofenig ">
<organization>ARM Ltd.</organization>
<address>
<postal>
<street>110 Fulbourn Rd</street>
<city>Cambridge</city>
<code> CB1 9NJ </code>
<country>Great Britain</country>
</postal>
<email>Hannes.tschofenig@gmx.net </email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<date year="2014"/>
<area>IETF</area>
<workgroup>Network Working Group</workgroup>
<abstract>
<t>
This document surveys existing three party authentication and authorization protocols for use with Internet of Things use cases. The discussed protocol frameworks are Kerberos, OAuth, ABFAB, and the certificate model. The aim is to understand whether any of the available standardized security protocols are re-usable for constrained environments. A future version of this document will provide a more detailed analysis against the requirements.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><xref target="I-D.seitz-ace-usecases"/> introduces a number of use cases that require device-to-device authentication whereby both devices may be constrained. <xref target="I-D.ietf-lwig-terminology"/> discusses the different types of constraints of these devices.</t>
<t>This document aims to raise the high-level question about the possible re-use of existing three party authentication and key exchange protocols for use in IoT environments. This version of the document does not aim to map requirements derived from the use cases against these protocols. Such a detailed analysis is premature at this point when use case descriptions are still in flux. </t>
<t>The starting assumption for the architectures in this document is that a device (a client) wants to access some resource (referred as service in this document). It unfortunately does not have any relationship with the server offering that service. <xref target="two-party"/> shows the scenario graphically.</t>
<t><figure title="Two Party Scenario." anchor="two-party">
<artwork>
<![CDATA[
+-----------+ no prior +-----------+
| Client | relationship | Service |
| | | |
+-----------+ +-----------+
]]>
</artwork>
</figure>
</t>
<t>Imagine that the client is a light-switch and the service is a light-bulb.</t>
<t>Today, companies solve this case by using a pairing protocol (at the link layer typically) where the two
devices execute a special imprinting/pairing protocol to establish an initial key
by using out-of-band (OOB) channel. This OOB channel can come in many forms:
<list style="symbols">
<t>Using an alternative communication channel, such as a USB stick, Ethernet cable</t>
<t>Human involvement by comparing hashed keys, entering passkeys, scanning QR codes</t>
<t>Second wireless connectivity (e.g., infrared)</t>
<t>Proximity-based information</t>
</list>
</t>
<t>The pairing is a suitable approach where wireless communication replaces a wired communication technology previously used. For example, a headset connected to a music player using a wired connection is replaced with the wireless version. Not all use cases do, however, allow users to pair their device with other devices upfront. Consider an enterprise with electronic door locks. It is hard to imagine an employee who has to pair their digital key with every door in the building first before they use the system. </t>
<t>Requiring every device to pair with every other device upfront is often inconvenient or not feasible. Hence, this document does not explore pairing solutions further. To offer an improved user experience with better scalability properties a device might either share credentials with some trusted third party. There are various ways how credentials can be shared with these trusted third parties. For example, credentials may be provisioned during the manufacturing process or devices may have been paired with the trusted third party (in case the trusted third party is local to the user). In fact, today is it very common for IoT devices to have at least credentials pre-provisioned for use with the vendor / manufacturer of the device to allow software updates to be provided securely.</t>
<t>Thus, we move to a model where the device (client) shares some credentials with a trusted third party. This trusted third party does not need to be a server on the Internet; ideally it could also be operated locally within someones' home, within an enterprise, or within a factory. </t>
<t>This three party architecture is shown in <xref target="three-party"/>.</t>
<t>
<figure title="Three Party Scenario." anchor="three-party">
<artwork>
<![CDATA[
+-----------+
| Trusted |
+--------------------------->|Third Party|
| Key +-----------+
| ^
| |
| |
| | Key
| |
| |
| |
v v
+-----------+ no prior +-----+-----+
| | relationship | |
| Client | <..................>| Service |
+-----------+ +-----------+
]]>
</artwork>
</figure>
</t>
<t>This three party architecture and messaging pattern has been explored with prior IETF work and this document lists the most relevant efforts (on a high level).</t>
<t>The goal of the communication exchange is that the client has been authorized to access the service, and
is able to secure the exchange of information. The client and the service may, optionally, possess keying material for future use of the service with the benefit of better performance for future interactions.</t>
<t>Note: This document does not aim to cover the use cases in their entirety. First, we assume that the security protocol interaction for link layer authentication is outside the scope. The focus of this document is on the application layer interactions when accessing services. Second, this document does not survey access control policy languages and mechanisms for managing these access control policies. These policies are important since many of the systems described below only provide an answer to the question 'Who is the holder of this key?' and standards for answering the question 'Can this key be used for this purpose?' (authorization) are often realized in a proprietary way.</t>
<t>While <xref target="two-party"/> shows three parties the protocols described in <xref target="frameworks"/> have been generalized to four or even multi-party scenario.
The result is shown in <xref target="three-party"/>.</t>
<t>
<figure title="Generalization of Three Party Scenario." anchor="generalized">
<artwork>
<![CDATA[
+-----------+ +-----------+
| Trusted | Agreement w/key | Trusted |
| Third |<-------------------->| Third |
| Party A | | Party B |
+-----------+ +-----------+
^ ^
| |
| Key | Key
| |
| |
| |
| |
v v
+-----------+ no prior +-----+-----+
| | relationship | |
| Client | <..................>| Service |
+-----------+ +-----------+
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="frameworks" title="Three Party Security Frameworks">
<t>This section introduces four authentication and authorization frameworks standardized in the IETF. The description is intentionally kept at a high level and a reader is encouraged to consult the referenced documents for details and various options these protocols offer. The terminology with each of these protocols is lightly different and appropriate mappings have been applied.</t>
<t>To demonstrate the level of maturity of these frameworks availability of products, source code, and deployment experience is mentioned for each of these frameworks. Note, however, that this experience does not imply suitability for use with the IoT environment.</t>
<section title="Application Bridging for Federated Access Beyond Web Architecture">
<t>This section describes the Application Bridging for Federated Access Beyond Web architecture <xref target="I-D.ietf-abfab-arch"/>, which builds on the Authentication, Authorization and Accounting (AAA) framework. The AAA framework re-uses the Extensible Authentication Protocol (EAP) <xref target="RFC5247"/> and EAP methods for the authentication protocol capabilities. A detailed description of the AAA keying framework can be found in <xref target="RFC5247"/>.</t>
<t>
<figure title="ABFAB Architecture." anchor="abfab">
<artwork>
<![CDATA[
+--------------+
| Identity |
| Provider |
| (IdP) |
+-^----------^-+
* EAP o RADIUS
* o
* o
+-------------+ +-v----------v--+
| | | |
| Client | EAP/EAP Method | Relying |
| |<****************>| Party |
| | GSS-API | |
| |<---------------->| |
| | Application | |
| | Data | |
| |<================>| |
+-------------+ +---------------+
Terminology Mapping:
- The term 'Relying Party' corresponds to the 'service'.
- The term 'Identity Provider' corresponds to the
'trusted third party'.
]]>
</artwork>
</figure>
</t>
<t>With the message exchange shown in <xref target="abfab"/> the client wants to obtain access to a service and starts interacting with
that service. Since no prior relationship between the client and the service is assumed the EAP message exchanges is relayed by the service and the EAP server component of the IdP. Between the client and the service these EAP payloads are encapsulated within the GSS-API. After a successful authentication and
authorization session keys are delivered from the IdP to the service and can then be used to secure the application layer data exchange between the client and the service.</t>
<t>While the use of EAP and the AAA architecture has mostly found use for network access authentication
the work on ABFAB applies this architecture to application layer services. </t>
<t>Pros:
<list style="symbols">
<t>Re-uses existing protocols: RADIUS, GSS-API, EAP, EAP methods.</t>
<t>Security properties of the AAA / EAP framework well studied and large deployments of the AAA framework exist.</t>
<t>Products and open source code exists for EAP, EAP methods, RADIUS, and the GSS-API. The extensions needed for ABFAB also have been implemented but they are less mature compared to the EAP/AAA deployment. </t>
<t>Large range of EAP methods available offering all possible authentication and key exchange protocols
for authentication between the client and the AAA server. These mechanisms have been deployed and are in widespread use today. While many EAP methods have been standardized only a few are in widespread use in non-IoT environments. However, there are many (open source) implementations available such that further experience concerning IoT suitability can be gathered. </t>
<t>IoT devices might use the AAA/EAP architecture for network
access authentication (e.g., WLAN-based, IEEE 802.15.4-based ZigBee-IP deployments).</t>
<t>The AAA framework also supports authentication in a federated environment.</t>
<t>Authorization information is conveyed within RADIUS (and potentially in SAML assertions, as envisioned by ABFAB).</t>
</list>
</t>
<t>
Cons:
<list style="symbols">
<t>The initial authentication and authorization exchange requires real-time interaction between the AAA server and the
service. </t>
<t> Deployments have so far used this architecture mainly for network access and for
specific applications (VoIP) only. Experience with other applications, as ABFAB envisions, is rather limited.</t>
<t>ABFAB architecture uses layering of EAP within the GSS-API, which adds additional overhead.
A binding for the transport of EAP payloads in CoAP, for example, does not exist.</t>
<t>No unified authorization policy language has been defined for the AAA/EAP architecture. Instead, RADIUS attributes carry information about access control decisions.</t>
</list>
</t>
</section>
<section title="Kerberos">
<t>Kerberos <xref target="RFC4120"/> is authentication system for distributed environments that has enjoyed deployment for more than three decades. The security properties have been extensively studied and various implementations exist. </t>
<t>
<figure title="Kerberos." anchor="kerberos">
<artwork>
<![CDATA[
+----------------+
| Authentication |
| Server (AS) |
+----------------+
^ /
Request / /
Ticket / /
/ /Ticket
/ /{SK}C-KDC
/ /
/ /
/ /
/ v
+-----------+ +-----------+
| | Ticket + Authenticator | |
| Client |---------------------------->| Server |
| |<===========================>| |
+-----------+ Application Data +-----------+
Terminology Mapping:
- The term AS corresponds to the 'trusted third party.'
- The term Server corresponds to the 'service'.
]]>
</artwork>
</figure>
</t>
<t>The Kerberos exchange shown in <xref target="kerberos"/> illustrates a client who
wants to get access to a server. It first has to interact with the
Authentication Server (AS) to request a ticket.
In response, the AS provides a ticket, which is a data structure encrypted
with a key known only between the server and the AS. This ticket includes
information about the client, a session key (SK) for later use, and various other security
relevant information elements. The client also obtains the session key encrypted with a key it shares with the AS.</t>
<t>When a service access is required then the client interacts with the server and presents the ticket along with an Authenticator.
The Authenticator demonstrates that the client was able to decrypt the
session key with the key it shares with the AS and that it was able
to apply this key to compute a keyed message digest over several fields, including a time-stamp, when accessing
the service. The time-stamp avoids replay attacks.</t>
<t>Pros:
<list style="symbols">
<t> Re-uses existing protocol: Kerberos </t>
<t> Security properties well studied and large deployments exist.</t>
<t> Products and open source service exist. </t>
<t> Most parts of Kerberos, particularly the ticket concept, are designed with symmetric key cryptography, which improves performance. The
Kerberos ticket is consequently fairly small and uses a
binary encoding.</t>
<t> Kerberos also supports cross-realm authentication for scalable deployments.</t>
<t> Kerberos also specifies a UDP-based transport. </t>
<t> The message exchanges between the client and the service can be tailored to the need of the
application.</t>
</list>
</t>
<t>Cons:
<list style="symbols">
<t> Each ticket is only usable for a single service (intentionally). As such, new tickets have to be requested
whenever the client wants to access a new service or when the ticket expired.</t>
<t> For the authentication between the client and the KDC a limited number of authentication protocols
have been specified. </t>
<t> Kerberos uses ASN.1 for encoding of the ticket and various messages. This may increase implementation complexity but the binary encoding is more efficient than other encodings, like XML or JSON.</t>
<t> No standardized access control policy has been standardized for inclusion inside a ticket. Proprietary policies
are, however, used in real-world deployments. </t>
<t>A CoAP binding for the KRB_PRIV and the KRB_SAFE message exchanges used to secure application data between the client and the service have not been defined.</t>
</list>
</t>
</section>
<section title="OAuth">
<t>
The OAuth protocol is a recent development for the Web, which re-uses the Kerberos interaction pattern with influences from the Web / mobile app space.
It initially aimed to solve the problem of delegated access to protected resources where websites asked users to share their long-term password.
Over time OAuth has been used in other use cases that require delegated access.</t>
<t>
<figure title="Simplified OAuth Architecture." anchor="oauth">
<artwork>
<![CDATA[
+-------------+
|Authorization|
|Server (AS) |
+-------------+
^ /
Request / /
Access / /
Token / /Access Token
/ /
/ /
/ /
/ /
O / v
/|\ +-----------+ +-----------+
| -----> | | Access Token | Resource |
/ \ <----- | Client |----------------->| Server |
Resource | |<================>| (RS) |
Owner +-----------+ Application Data +-----------+
Terminology Mapping:
- The term AS corresponds to the 'trusted third party'.
- The term RS corresponds to the 'service'.
]]>
</artwork>
</figure>
</t>
<t><xref target="oauth"/> shows the high-level OAuth message exchange. The canonical OAuth example allows a web user (resource owner) to grant a printing service (client) access to her private photos stored at a photo sharing service (resource server), without sharing her username and password. Instead, she authenticates directly with the authorization server which issues the printing service delegation-specific credentials.</t>
<!--
<t>While the resource owner is shown in <xref target="oauth"/> the OAuth protocol does not actually involve the resource owner directly, i.e., the OAuth protocol does not aim to standardize the authentication protocol executed between the resource owners software (such as a web browser or a mobile phone app) and the authorization server.</t> -->
<t>Pros:
<list style="symbols">
<t> Re-uses existing protocols: OAuth Core <xref target="RFC6749"/>, OAuth Bearer Token <xref target="RFC6750"/> OAuth MAC Token <xref target="I-D.ietf-oauth-v2-http-mac"/>/ HOTK <xref target="I-D.tschofenig-oauth-hotk"/>, JWT <xref target="I-D.ietf-oauth-json-web-token"/>.</t>
<t> Large deployments in the Web environment exist, which use the OAuth Bearer Token.</t>
<t> Products and open source service exist. </t>
<t> OAuth is flexible with regard to the used cryptography. A standardized format for the
access token has been described with the JSON Web Token (JWT).
For security protection of the JWT various specifications from the JOSE working group
are available. </t>
<t>The message exchanges between the client and the service can be tailored to the need of the
application. Bindings are available for HTTPS and SASL <xref target="I-D.ietf-kitten-sasl-oauth"/>. </t>
<t> With regard to the offered security mechanism the interaction between the client and the resource
server gives several choices: The OAuth Bearer Token requires a TLS exchange between the client
and the resource server. The MAC Token specification is conceptually similar to Kerberos; a
version based on asymmetric cryptography exists as well (see HOTK). </t>
</list>
</t>
<t>Cons:
<list style="symbols">
<t>For an environment with more than one authorization server or where the authorization server is
located in a different domain than the resource server the standardization work is still in progress.
Efforts have mostly be done in Kantara with the User-Managed-Access (UMA) working group. </t>
<t>A binding for CoAP does not exist for the client to authorization server nor for the client to resource
server.</t>
<t>The OAuth architecture does not standardize the authentication procedure of the resource owner to the authorization
server itself. This is a common approach for the Web environment where a number of different authentication protocols
are in use in the browser. As such, the protocol works with any authentication mechanism. </t>
</list>
</t>
</section>
<section title="Certificate Model">
<t>Prior work on the Public Key Infrastructure, certificate formats, certificate extensions, and various certificate management protocols can be re-used in the IoT context. With respect to the use cases described in <xref target="I-D.seitz-ace-usecases"/> certificates may be
short-lived and might need to contain attributes (which may be used for making access control decisions) rather than purely relying on the identity of users and their devices.</t>
<t>For the purpose of dynamic provisioning short-lived certificates, this document envisions to re-use a subset of the functionality offered by protocols like the Certificate Management over CMS (CMC) <xref target="RFC5272"/>, the Certificate Management Protocol (CMP) <xref target="RFC4210"/>, the Simple Certificate Enrollment Protocol <xref target="I-D.nourse-scep"/>, Certification Request Syntax Standard - PKCS#10 <xref target="RFC2315"/> (with TLS or with PKCS#7 <xref target="RFC2986"/> ). While these protocols offer slightly different features, on a high-level the all fulfill the same function. Note that the management of trust anchors may be provided by a different protocol, such as Trust Anchor Management Protocol (TAMP) <xref target="RFC5934"/>.</t>
<t>Of course, certificates do not necessarily need to be short-lived and could even be provisioned during the manufacturing process and never changed during the lifetime of the device. The drawback of such an approach is, however, that mechanisms for certificate revocation have to be provided. Furthermore, privacy concerns might be arise since the same client certificate content will be shown to every service rather than information that is only relevant for a specific purpose.</t>
<t>
<figure title="Certificate Model." anchor="cert">
<artwork>
<![CDATA[
+-------------+
|Certification|
| Authority |
+-------------+
^ /
Request / /
(Short) / /
Lived / /(Short) Lived
Cert / / Certificate
/ /
/ /
/ /
/ v
+-----------+ +-----------+
| | DTLS with certificate | |
| | or app layer msg w/cert | |
| Client |---------------------------->| Service |
| |<===========================>| |
+-----------+ Application Data +-----------+
]]>
</artwork>
</figure>
</t>
<t>
Pros:
<list style="symbols">
<t> Re-uses existing protocols: DTLS (or application protocol), CMP/CMC/PKCS#10/SCEP, specifications (certificate format - RFC 6818 <xref target="RFC6818"/>), and concepts (PKI).</t>
<t> Large deployments on the Web and with enterprise system exist.</t>
<t> Products and open source code exists. </t>
<t> The certificate format offers flexibility in terms of content. New extensions have been defined over time. </t>
<t> Certificates can be used with DTLS without any additional modifications. Certificates can also used with application security mechanisms.</t>
<t> Authorization information may be placed in an extension of a public key certificate or in a separate attribute certificate <xref target="RFC3281"/>. Earlier work on KeyNote <xref target="RFC2704"/>could be re-used as it provides a more flexible authorization policy language.</t>
<t> A single certificate can be used with a number of different services. </t>
<t> Various PKI management protocols have been defined and they offer some flexibility. The properties vary on the specific use cases.</t>
</list>
</t>
<t> Cons:
<list style="symbols">
<t> The certificate format and the PKI management protocols use ASN.1. </t>
<t> No UDP or CoAP transport is defined for CMC/CMP/SCEP. For PKCS#10 no transport is defined at all. </t>
<t> The public key infrastructure only focuses on asymmetric cryptography. A separate body of work is available for provisioning symmetric keys (like one-time-keys), such as the Portable Symmetric Key Container (PSKC) <xref target="RFC6030"/> and Dynamic Symmetric Key Provisioning Protocol (DSKPP) (<xref target="RFC6063"/>).</t>
<t> Protocols for certificate enrollment are in use but many deployments use their own strategy for distributing certificates (typically long-lived) to their users.</t>
<t>Asymmetric cryptography is computationally more expensive than symmetric cryptography but offers additional security benefits.</t>
</list>
</t>
</section>
</section>
<section title="Conclusion">
<t>Several existing protocols can be used to meet the use cases outlined in <xref target="I-D.seitz-ace-usecases"/>. Each technology presented here
offers a number of possibilities for profiling to make them work on for constrained devices. Despite the range of available security protocols, the use cases suggest that there is a need to profile and to extend those in order to make them fit for the constrained environment.</t>
<t>The right choice of authentication and authorization protocol will heavily depend on the envisioned usage environment.</t>
<t>It is, however, also worth noting that several aspects that are not discussed in this document although they appear as requirements in the use case document, namely
<list style="symbols">
<t> a language for describing access control policies, </t>
<t> the encoding of these policies, and </t>
<t> the container for associating these policies with keying material.</t>
</list>
</t>
</section>
<section title="Security Considerations">
<t>This entire document is about security.</t>
</section>
<section title="IANA Considerations">
<t>This document does not require any actions by IANA.</t>
</section>
<section title="Acknowledgements">
<t>The author would like to thank Stefanie Gerdes for her review comments.</t>
</section>
</middle>
<back>
<references title="Informative References">
&I-D.seitz-ace-usecases;
&RFC5272;
&RFC5934;
&RFC2704;
&RFC4210;
&RFC6749;
&I-D.ietf-oauth-v2-http-mac;
&I-D.tschofenig-oauth-hotk;
&I-D.ietf-oauth-json-web-token;
&I-D.ietf-lwig-terminology;
&I-D.ietf-kitten-sasl-oauth;
&RFC6750;
&RFC5247;
&RFC4120;
&I-D.ietf-abfab-arch;
&RFC2986;
&RFC2315;
&I-D.nourse-scep;
&RFC6063;
&RFC6030;
&RFC3281;
&RFC6818;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:09:19 |