Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

> For the current EAP-TLS based methods, the "service" of putting on the
> harness and hooking you in is not provided. And that is exactly what I want to
> achieve with the TLS part of EAP-FIDO. The users shoulnd't see any of the
> certificate check parameters, it should be implicit and that is where we
> improve the security of the EAP-TLS based method (Details:
> see last paragraph of this mail)

Playing Devil's Advocate and going a bit OT: this is an excellent goal, so why 
stop at EAP-FIDO?

We could define a similar validation logic for the existing TLS-based methods 
to obtain the same benefit. For example:
* The value of the EAP-Identity/Response NAI realm is a well-formed FQDN
* The phase 1 server certificate is issued by the WebPKI
* The phase 1 server certificate's name takes a value that corresponds to the 
NAI realm

The supplicant trusts the server if the certificate is valid and the realm 
matches (hand-wave) the certificate name. I think this is the moral equivalent 
of section 4.2.5 with Option B in Appendix B. The same validation logic could 
be used in phase 1 of the existing tunnel methods, and the inner method (e.g. 
EAP-FIDO) executed in phase 2 as usual.

It makes no sense to update the existing methods, but perhaps it could be 
offered as guidance for existing named methods (and referenced in new methods 
where it makes sense).

WPA3-Enterprise already defines requirements for server certificate validation 
by supplicants, and Windows 11 applies the same validation logic for all native 
EAP methods and lower layers, so there is precedent (I believe the main 
difference between Windows 11 and the approach outlined above is that Windows 
11 does not require validation of the server name (although this can be 
configured), instead requiring CA pinning).

Josh 



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

> From: Alan DeKok 
> On Oct 30, 2023, at 9:53 AM, josh.howl...@gmail.com wrote:
> > It would be very interesting if the initial registration could be
> > performed in-band of EAP (using WebPKI).
> 
>   That would be very useful.  It's a balance between making the draft
useful
> (large, long delay), or getting it done quickly, but perhaps missing
features.
> 
>   I think the ideal approach is for EAP-FIDO to allow:
> 
> * authentication via FIDO as discussed
> 
> * provisioning of FIDO credentials

I am in favour of this. Authentication will be useful without in-band
provisioning.


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

>   It's almost 2024, and MDM is still difficult.  There are a large number
of
> companies who are happy to charge recurring monthly fees, per user, for
> MDM solutions.  That's bad for everyone but them.

This is true, but EAP-FIDO is still not a free lunch:
- EAP-FIDO implies the existence of a web-service to perform the initial
registration
- That web-service needs to share state with the RADIUS server

Today's turnkey EAP provisioning solutions are not *conceptually* dissimilar
to this (often using self-signed CAs with EAP-TLS for mutual authn; and LDAP
to the Enterprise directory to authz the client cert's SAN). The onboarding
would just be transparent for an end-user because of the browser/OS/TPM
integration (so no "installer" to download and execute).

It would be very interesting if the initial registration could be performed
in-band of EAP (using WebPKI).

>   We've had ~20+ years of relying on end users to carry the burden of
> supplicant configuration.  That practice is a failure, and should be
replaced
> with something better,

+1

Josh


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

>   If you can do an onboarding SSID, there are many simpler things which
can
> be done, too.  e.g. downloading configuration files from a  captive
portal.

Yes, but not with a managed Chromebook... My point being that bootstrapping
EAP configuration provisioning is not just a problem for BYOD.

Steering the conversation back to EAP-FIDO: both it and the captive portal
use WebPKI for provisioning, so there's an equivalence that arguably makes
my handwringing around WebPKI moot. Perhaps it is an acceptable price to pay
for the convenience.



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

> As a goal, we need to migrate to more use of EAP-TLS in home environments.
 
I discovered recently that you can't provision a client cert for EAP-TLS onto a 
Chromebook using the Google MDM. Instead, you configure the MDM with 
information that enables the Chromebook to obtain one using SCEP from an 
Enterprise CA. But the user needs to log into the Chromebook to obtain the 
certificate over SCEP and, of course, the user can't log in without network 
access. The "solution" is to stand-up an onboarding SSID can reach Google and 
the SCEP endpoint.

(The organisation decided to provision the devices with EAP-PEAP/MSCHAPv2 and a 
shared AD account instead, using RADIUS and Google logs to correlate users to 
Chromebooks)

I'm not bashing EAP-TLS but highlighting that an apparently trivial 
configuration can involve a disproportionate amount of infrastructure and 
complexity...

Josh



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

> From: Alan DeKok 
> On Oct 24, 2023, at 8:56 AM, josh.howl...@gmail.com wrote:
> > To be clear, what I mean is whether there is another IETF protocol that
> > *mandates* the use of WebPKI?
> 
>   All of them.
> 
>   Not explicitly, but implicitly.
> 
>   I think the way out here is to not mandate the use of WebPKI.  Instead,
we
> can just say that the EAP certificate should be issues by the same (or
> equivalent CA) to the one which was used to provision the initial FIDO
> credentials.

That is an interesting idea, but it might be tricky for the supplicant to
validate because provisioning is performed through a browser? 

Jan-Fred and I have previously discussed the option of provisioning the
supplicant (through the browser) with a credential for the server at the
time of initial PIDO provisioning. This was also looking tricky, but I think
the idea also has merit.

Josh


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

> >   So I see this as two new methods:
> >
> > 1) tunnelled FIDO - for use in TTLS, PEAP, or other TLS-based EAP
methods.
> >
> > 2) TLS-based method with tunnelled FIDO - it can make new / stronger
> > requirements on CA validation, server identity, etc.
> 
> So (2) would be the moral equivalent of (1) inside an existing tunnelled
> method where WebPKI is mandated for server cert validation?
> 
> I have worked with organisations who run AD Certificate Services for the
sole
> purpose of issuing a single server certificate for their NPS cluster, so I
am very
> much in favour of making server certificate validation simpler.
> However, I think we need to be very circumspect about out-sourcing that to
> the WebPKI. Is there another IETF protocol that does this?

To be clear, what I mean is whether there is another IETF protocol that
*mandates* the use of WebPKI?


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

>   So I see this as two new methods:
> 
> 1) tunnelled FIDO - for use in TTLS, PEAP, or other TLS-based EAP methods.
> 
> 2) TLS-based method with tunnelled FIDO - it can make new / stronger
> requirements on CA validation, server identity, etc.

So (2) would be the moral equivalent of (1) inside an existing tunnelled
method where WebPKI is mandated for server cert validation?

I have worked with organisations who run AD Certificate Services for the
sole purpose of issuing a single server certificate for their NPS cluster,
so I am very much in favour of making server certificate validation simpler.
However, I think we need to be very circumspect about out-sourcing that to
the WebPKI. Is there another IETF protocol that does this?

Josh


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

> > 2. I am not persuaded by the two arguments given in section 6.3 for not
> > reusing existing tunnelled methods.
> 
> I'm open to discuss this with an open mind, the first draft is just the
> way that I imagined it, if there are reasons to do it another way, I'm
> not set on the current spec.
> 
> > * Misconfiguration of server certificate validation parameters: perhaps I am
> missing something, but in terms of the UI can't this be solved by disabling 
> the
> parameter options/fields if the EAP-FIDO inner method is selected?
> 
> Definitely this could be done. Maybe I'm just too pessimistic here to
> expect that UIs will get it wrong.

Ok -- just checking my understanding was correct :)

> > * Export of TLS material: I thought this TLS material is often required by
> phase 2 of other tunnelled methods? E.g. for validating cryptobindings.
> 
> I don't know exactly what you mean by that?
> The current spec uses exported TLS material to generate the FIDO
> challenge, so the FIDO-Auth is bound to the TLS tunnel.

Most tunnel methods bind phases 1 and 2; I don't believe this should be a 
problem.

> One question would be if we can achieve the opoosite, that is: binding
> the exported MSPPE-Keys to the FIDO auth too, not just the TLS tunnel.

What would be the goal for this?

> > 3. I have unsure about tying this specification so tightly to the WebPKI. 
> > There
> is a tremendous convenience in using the WebPKI for validating the server
> certificate, but the WebPKI is not a well-defined concept. In practice, it is 
> the
> bucket of CAs that my OS vendor preinstalls on my device. The conflation of
> protocol design (fixed in code) with operational choices taken by 
> third-parties
> (so subject to change) could lead to unexpected outcomes.
> 
> I agree with your last sentence, we definitely introduce a third party
> that we cannot control (or even anticipate their actions).
> But the idea here is to build a system where we have a default way of
> configuration that is somewhat secure, and since we can't really
> establish a trusted EAP-FIDO CA that every device will trust, leveraging
> the WebPKI for that is the next best thing.

When you say "default", would this permit other user-provisioned trust anchors 
as well?

Josh


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[josh.howlett]

Hi Jan-Fred,

It is good to see this work progressing.

1. I agree with Hannes' observation that it isn't necessary to premise EAP-FIDO 
on the claimed weaknesses of other EAP methods.  I suggest replacing paragraphs 
2-5 with content summarising the proposal. In particular I am surprised that 
the document doesn't discuss (what I would consider to be) the main benefit of 
using FIDO: the ease of provisioning a credential to the supplicant.

2. I am not persuaded by the two arguments given in section 6.3 for not reusing 
existing tunnelled methods.

* Misconfiguration of server certificate validation parameters: perhaps I am 
missing something, but in terms of the UI can't this be solved by disabling the 
parameter options/fields if the EAP-FIDO inner method is selected? 

* Export of TLS material: I thought this TLS material is often required by 
phase 2 of other tunnelled methods? E.g. for validating cryptobindings.

I think there is an argument that defining EAP-FIDO as a method that could be 
used within PEAP, TTLS and TEAP could drive adoption.

3. I have unsure about tying this specification so tightly to the WebPKI. There 
is a tremendous convenience in using the WebPKI for validating the server 
certificate, but the WebPKI is not a well-defined concept. In practice, it is 
the bucket of CAs that my OS vendor preinstalls on my device. The conflation of 
protocol design (fixed in code) with operational choices taken by third-parties 
(so subject to change) could lead to unexpected outcomes.

Josh

> -Original Message-
> From: Emu  On Behalf Of Jan-Frederik Rieckers
> Sent: Monday, October 23, 2023 11:38 PM
> To: emu@ietf.org
> Subject: [Emu] New I-D: A new EAP method called EAP-FIDO
> 
> Hi emu folks,
> 
> as already teased at the last IETF, we finally have a first I-D ready for EAP-
> FIDO.[1]
> 
> The basic idea:
> Password-based network authentication is not really state-of-the-art any
> more and, due to failure to verify the server certificate, sometimes even
> completely broken.
> Almost every device nowadays has a TPM chip or something similar, that is
> able to speak FIDO, either with the help of the OS or generically.
> So, why not use FIDO to log in to networks?
> 
> There is a proof-of-concept implementation (not compatible with the spec in
> the draft yet, just to show that "It works™") that was used to perform an
> eduroam login at a conference with an EAP-FIDO key.
> 
> We will hold a side-meeting on Monday evening, 18:00 in Room Karlin 4, to
> discuss some of the open design questions and to gather feedback on what
> else may be needed in the specification.
> 
> We have also requested a time slot at the emu session on Tuesday, to shortly
> present the work.
> 
> Any feedback is welcome.
> 
> Cheers
> Janfred
> 
> [1]: https://datatracker.ietf.org/doc/draft-janfred-eap-fido/
> 
> --
> Herr Jan-Frederik Rieckers
> Security, Trust & Identity Services
> 
> E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
> Pronomen: er/sein | Pronouns: he/him
> ___
> ___
> 
> DFN - Deutsches Forschungsnetz | German National Research and Education
> Network Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
> Alexanderplatz 1 | 10178 Berlin
> www.dfn.de
> 
> Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | Christian
> Zens
> Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch VR AG
> Charlottenburg 7729B | USt.-ID. DE 1366/23822

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Network Access Authentication and Attestation

[josh.howlett]

The Network Endpoint Assessment (NEA) Working Group worked on this problem:
https://datatracker.ietf.org/wg/nea/about/

Josh

> -Original Message-
> From: Emu  On Behalf Of Hannes Tschofenig
> Sent: Friday, October 13, 2023 9:16 AM
> To: emu@ietf.org
> Subject: [Emu] Network Access Authentication and Attestation
> 
> Hi all,
> 
> in the AD review of the SUIT MUD draft, see
> https://datatracker.ietf.org/doc/draft-ietf-suit-mud/ and
> https://mailarchive.ietf.org/arch/msg/suit/xRT55NR6fAQuuSYmApXAdC-
> zO8U/,
> Roman noted that we are assuming that an EAT-based attestation mechanism
> is available for network access authentication protocols.
> 
> While there has been talk about adding attestation to EAP methods, I am
not
> aware of any work specifically in the EMU group.
> 
> Coincidently, we are working on a solution for adding attestation to TLS,
see
> https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/, where we
> define an extension that can be added on a need-by-need basis. It could
also
> be incorporated into TLS-based EAP methods.
> 
> Has someone in the group considered the use of attestation for network
> access and as part of TLS-based EAP methods in particular?
> 
> The use case is described in Section 2.1 of RFC 9334, see
> https://datatracker.ietf.org/doc/html/rfc9334#name-network-endpoint-
> assessment
> The main benefit is there described as follows: "Remote attestation is
desired
> to prevent vulnerable or compromised devices from getting access to the
> network and potentially harming others."
> 
> We are happy to give a presentation or show our prototype at the
hackathon.
> 
> Ciao
> Hannes
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] [Ace] [suspect] Re: Iotdir early review of draft-ietf-ace-wg-coap-eap-08

[josh.howlett]

The fragmentation issue that Heikki mentions is specific to EAP over RADIUS, 
where RADIUS is using UDP transport. It isn’t a property of EAP itself, and so 
I don’t follow why this makes EAP impractical for IoT.

 

Josh

 

From: Emu  On Behalf Of Behcet Sarikaya
Sent: Thursday, July 27, 2023 9:39 PM
To: Heikki Vatiainen 
Cc: iot-director...@ietf.org; draft-ietf-ace-wg-coap-eap@ietf.org; 
emu@ietf.org; a...@ietf.org
Subject: Re: [Emu] [Ace] [suspect] Re: Iotdir early review of 
draft-ietf-ace-wg-coap-eap-08

 

+1 to Heikki.

 

I think the use of AAA, in particular EAP for IoT is simply not practical, 
thanks to Heikki for making this specific.

It could be theoretically beautiful though :)

 

Behcet

 

On Thu, Jul 27, 2023 at 7:08 AM Heikki Vatiainen mailto:h...@radiatorsoftware.com> > wrote:

On Wed, 19 Jul 2023 at 11:45, Dan Garcia Carrillo mailto:garcia...@uniovi.es> > wrote:

 

On 5/7/23 15:36, Alan DeKok wrote:

 

>Given that the EAP packets can be forced to be no more than 1024 octets, 
> the only difference between EAP methods is the number of packets exchanged, 
> and the total amount of data exchanged.  Current EAP supplicants and 
> authenticators limit the total number of exchanges to 50 or 100, depending on 
> various factors.
>
>Is there a similar limit for CoAP?  i.e. will CoAP go fail if there is 64K 
> of data being exchanged in EAP?


We tried not to go there in the document, just to acknowledge that CoAP 
fits the requirements for an EAP lower layer. In any case, EAP messages 
larger than 1024 could be sent using CoAP Block-wise transfer, that will 
seamlessly take care of sending payloads larger than CoAP Minimum MTU.

 

A couple of additional notes about EAP authentication exchange and its data use.

 

First, if look at EAP-TTLS and PEAP but not EAP-TLS, it may seem that the 
authentication exchange is very asymmetric in how it uses data. The EAP server 
sends a long certificate chain and the client sends very little with many of 
client responses being just simple ACKs that tell the server to continue.

 

EAP-TLS, especially with TLSv1.2 and earlier, uses plenty of data for both 
directions. EAP servers know how to fragment the data but clients sometimes may 
attempt to send messages that get fragmented by the lower layer and may get 
lost in transit (firewalls etc. being a problem). The problem with clients is 
typically that there may not be a setting or a method that tells the client to 
use a certain EAP message size. In other words, EAP-TLS, for example, supports 
fragmentation, but the clients especially may now know how small the fragment 
needs to be when they send out their client certificate and its associated CA 
certificate chain.

 

Some EAP methods, such as PEAP and EAP-TTLS allow running EAP-TLS as the inner 
authentication method, which means you have TLS within TLS and client 
fragmentation becomes even more complex. Servers typically know how to handle 
this too. This is not the most common thing to do, but with TLSv1.2 is the 
method to hide client certificate information when using EAP-TLS.

 

To summarise: with EAP-TLS there is typically large amount of data transferred 
in both directions.

 

With TLSv1.3 it's possible to omit the CA certificates: 

https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2

 

... a certificate that specifies a trust anchor MAY be

   omitted from the chain ...

 

This can be a large size saver, but please see the whole paragraph too. The CA 
certificates (trust anchors) would need to be know be the other TLS endpoint if 
this is done. This is yet another good reason to use TLSv1.3 even though 
TLSv1.2 and earlier still remain in wide use with TLS based EAP methods.

 

-- 

Heikki Vatiainen
h...@radiatorsoftware.com  

___
Ace mailing list
a...@ietf.org  
https://www.ietf.org/mailman/listinfo/ace

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] System level forward secrecy for EAP+AAA

[josh.howlett]

>   I would suggest that these attacks aren't very relevant.  Or if they
are, there
> is very little which can be done about them.

+1

An AAA infrastructure is a logical extension of the NAS that enables
authentication, key derivation and other security functions to be
externalised. That externalisation yields a distributed AAA architecture,
and its security depends on a set of assumptions between the participating
actors.

It is not a weakness of the architecture if one or more of those assumptions
are not appropriate for a particular environment. It just means that the
architecture is not the right tool for that case. It only becomes a weakness
of the architecture if the assumption(s) become untenable for the important
use cases. Personally, I don't think that is the case here.

However, I think it is still useful input as we consider ways of improving
AAA infrastructure technologies (e.g., in this case minimising the number of
intermediaries between the NAS and the EAP server) to better serve EAP.

Josh

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] [core] [Ace] Proposed charter for ACE (EAP over CoAP?)

[josh.howlett]

I support this; although I am curious in Dan’s opinion as to whether GSS on
top of CoAP is also worth considering, as a way of leveraging the GSS EAP
and other mechanisms (such as Kerberos).

 

Josh

 

From: Emu  On Behalf Of Göran Selander
Sent: 07 December 2020 14:08
To: Laurent Toutain ; Daniel Migault

Cc: EMU WG ; c...@ietf.org WG (c...@ietf.org) ;
a...@ietf.org
Subject: Re: [Emu] [core] [Ace] Proposed charter for ACE (EAP over CoAP?)

 

+1. 

 

(The recently updated ACE charter should cover this work.)

 

Göran

 

On 2020-12-03, 20:03, "core" mailto:core-boun...@ietf.org> > wrote:

Hi,

I think it is important to have EAP on top of CoAP, as Dan said it fit well
with the last charter item.

 

Laurent

 

 

On Thu, Dec 3, 2020 at 2:20 PM Daniel Migault
mailto:daniel.migault=40ericsson@dmarc.ietf.org> > wrote:

 

 

CCing emu, core

 

It seems ACE to me that ACE could be home for such a document. I am
wondering if emu core or any other WG believe there is a better place for
it. 

 

Regarding ACE I am wondering what is the WG opinion about adding this item
to the ACE charter. 

 

Yours, 

Daniel



From: Ace mailto:ace-boun...@ietf.org> > on behalf of
Dan Garcia mailto:dan.gar...@um.es> >

Sent: Thursday, December 3, 2020 6:10 AM

To: a...@ietf.org   mailto:a...@ietf.org>
>

Subject: [Ace] Proposed charter for ACE (EAP over CoAP?)  

 

Dear all:

 

Regarding the new charter, since ACE is considering the definition of CoAP
transport for CMPv2
(https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00), we
were wondering whethere it could also consider specifying EAP (Extensible
Authentication Protocol) over CoAP.

 

In this sense, we proposed this some time ago and we have implementations
about this.

 

https://datatracker.ietf.org/doc/html/draft-marin-ace-wg-coap-eap-06

https://www.mdpi.com/1424-8220/16/3/358

https://www.mdpi.com/1424-8220/17/11/2646

 

The usage of CoAP can provide a very light and link-layer independent (we
even tested in LoRa networks) EAP lower-layer (transport for EAP) suitable
for IoT enviroment. We believe this would be really useful since EAP
provides flexibility for the authentication and it is a well-known protocol.

 

Therefore, we would like to propose the following modification to the
charter:

 

"The Working Group will examine how to use Constrained Application Protocol
(CoAP) as a transport medium for certificate enrollment protocols, such as
EST and CMPv2, as well as a transport for authentication protocols such as
EAP, and standardize them as needed."

 

This modification does not necessarily mean the adoption of our draft. After
all, we completely understand that this would happen only if there is an
interest in the WG. Nevertheless, we would like to avoid that the charter is
a barrier later if there is interest in the WG to work in this transport of
EAP over CoAP:

 

Any opinion about this?

 

Best Regards.

 

El 18/11/2020 a las 8:08, Daniel Migault escribió:

 

 

Hi,  

Please find the proposed charter we agreed on during the interim meeting. If
you would like to propose any change, please use the following URL by
November 25:

 

https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDi
ptY/edit?usp=sharing

=1=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0=https%3A%2F%2Fdocs.google.com%
2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3
Dsharing>

 

 

Yours, 

Daniel

 

The Authentication and Authorization for Constrained Environments (ace) WG
has defined a standardized solution framework for authentication and
authorization to enable authorized access to resources identified by a URI
and hosted on a resource server in constrained environments. 

The access to the resource is mediated by an authorization server, which is
not considered to be constrained.

 

Profiles of this framework for application to security protocols commonly
used in constrained environments, including CoAP+DTLS and CoAP+OSCORE, have
also been standardized.  The Working Group is charged with maintenance of
the framework and existing profiles thereof, and may undertake work to
specify profiles of the framework for additional secure communications
protocols and for additional support services providing authorized access to
crypto keys (that are not necessarily limited to constrained endpoints,
though the focus remains on deployment in ecosystems with a substantial
portion of constrained devices).

 

In addition to the ongoing maintenance work, the Working Group will extend
the framework as needed for