Subject: [Ace] Secdir last call review of draft-ietf-ace-oauth-authz-27

From: Stephen Kent via Datatracker <[email-masked]>
Date: Sun, 08 Dec 2019 10:18:53 -0800

Reviewer: Stephen Kent
Review result: Has Issues

SECDIR review of draft-ietf-ace-oauth-authz-27

The summary of the review is almost ready, but needs some revisions.

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving security requirements and
considerations in IETF drafts.  Comments not addressed in last call may be
included in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

This is a long document- 86 pages! It is a proposal for how to use OAuth 2.0
and CoAP to provide authorization security for Internet of Things (IoT)
devices. IoT devices are often criticized as not being very secure, so this
seems like a useful initiative. RFC 7228 (Technology for Constrained-Node
Networks, and Informational document) is cited as inspiration and reference for
this work. CoAP (RFC 7252) is expressly designed for the sort of environment
that characterizes many IoT devices, hence is seems a natural choice for this
authorization-focused framework. OAuth is not as obvious a candidate building
block in this context, e.g., it is expressly designed for the HTTP context, yet
CoAP is cited as the replacement for HTTP. This document adapts OAuth for the
CoAp context.

This document has an extensive, 6-page Security Considerations section,
appropriate for a document specifying an authorization framework. It begins by
citing the OAuth 2.0 specification, the OAuth 2.0 threat model (RFC 6819), and
OAuth 2.0 Token Introspection (RFC 7662).  All three of these documents are
relevant, and they contain substantial Security Consideration sections.

Section 6.1 deals with security for the tokens that are transmitted to convey
authorization information. In general the requirements and advice provided here
are good; I would prefer to see the admonition against use of a shared secret
key for a group of serves to be a MUST NOT, as opposed to just NOT RECOMMENDED.
I am not convinced that the suggestion for short lifetime tokens is necessary;
we have seen how short duration certificate lifetimes and frequent CRL issuance
in PKI contexts often is neither required nor advisable. This section ends by
noting that only client-initiated revocation of tokens is addressed by RFC
7009. The authors note that revocation of long lifetime token remains an open
issue. If this is likely to be a common case for IoT devices, leaving this as a
TBD is not great.

Section 6.2 addresses communication security issues. The section opens by
requiring an authorization server to offer confidentiality for client
interactions, but the wording implies that a client need not make use of such
protection. The reader is reminded that security requirements expressed in
Section 5 of this document (a 25-page long section) MUST be addressed by a
profile. I’d prefer to see references to specific parts of Section 5 that
expressly addresses confidentiality, so that a reader can better understand
when it is safe to reject the offer of confidentiality by a server. Encryption
of CWTs is used as an example, which is appropriate because CBOR CWT is the
default token format. The final paragraph of this section says that “developers
MUST ensure that … ephemeral credentials … are not leaked to third parties.”
This is good advice, but since adversaries are assumed to have physical access
to IoT devices, the scope of this mandate is not clear. For example, is this
text arguing for use of tamper-resistant hardware for storing private or
session keys in IoT devices?

Section 6.3 focuses on long-term credentials. The sections begins by noting the
challenges associated with providing protection for such credentials in devices
in publicly-accessible locations, explicitly referring to specialized hardware.
This a good, clear statement, not like the ambiguous MUST at the end of 6.2.
The text requires that compromise of a credential at one device MUST NOT lead
to compromise of other credentials not linked to the device in question.
However, the next sentence says that sharing of secret (and, presumably,
private) keys is NOT RECOMMENDED. This is a somewhat inconsistent pair of
statements; if secret keys are shared, then the MUST NOT will be violated,
right? Why not just say that secret keys MUST NIOT be shared across devices?
The section states that operators should have procedures to replace credentials
that have been (or are suspected to have been) compromised. Why is this
admonition not a SHOULD? The mildly-worded (“… also need to …) advice about
decommissioning devices seems minimally helpful. If this is important than make
it a SHOULD, if it’s not, then RECOMMEND it.

Section 6.4 discusses the challenges associated with securing initial
communication  between a client and a resource server (RS). This communication
makes use of the (appropriately-named) Creation Hints message defined in 5.1.2.
 The basis mechanism suggested here is use of a (possibly hard coded) list of
trusted authorization servers (AS’s) and associated credentials, e.g.,
certificate fingerprints. The discussion here notes the potential for a DoS
attack against an AS by a compromised RS, by having clients sends requests to
the targeted AS. This is a useful comment, after noting that compromise of an
RS would not cause an AS to grant requests to clients that it is not serving.

Section 6.5 summarizes the “minimal” communication security requirements for
the elements of the system described in this document (clients, AS’s and RS’s).
I think it’s useful to collect these requirements in one place, although they
have been described in various parts of Section 5. Unfortunately, the first
sub-section seems to contradict Section 6.2! Specifically the text here says
that all communication between a client and an AS MUST be encrypted, where as
6.2 requires only that an AS offer confidentiality. This inconsistency needs to
be reconciled. The next subsection seems to be consistent. The final subsection
(C-RS) notes the challenges of initial C/RS communication, and offers some
suggested approaches. Some of the wording here is awkward. For example, the
text notes that DTLS with server-side authentication “can be possible and are
RECOMMENDED if supported by both parties.”  It would be better to state that
“DTLS with server-side authentication is a RECOMMENDED mechanism for use in
this context, and SHOULD be employed if supported by both the C and the RS.”

Section 6.6 deals with token lifetimes. The section begins by suggesting use of
nonces (as described in 5.1.2) to counter replay attacks in the event of “clock
drift” between an RS and an AS. I appreciate the analysis of mechanisms that
can be used to address the clock drift issue, including the discussion of
potential problems associated with using nonces in the face of a reboot.
However, the text provides no indication of how much “drift” is tolerable, vs.
when use of nonces is needed, and 5.1.2 does not even mention clock drift.
Perhaps the text can be revised to provide additional advice re clock drift.

Section 6.7 very briefly discussed the issue of combining profiles. The bottom
line is that the security of a profile MUST NOT depend on the assumption that
the profile is used exclusively throughout a given deployment. That’s a nice,
straightforward warning!

Section 6.8 discusses circumstances in which data is transmitted and may not
encrypted, e.g., error messages. The discussion here is fairly clear, and
includes a RECOMMENTATION and a MUST, as well as an analysis of potential risks
associated with transmitting different types of information w/o confidentiality
protection. The section title says “unprotected” but this discussion focuses
only on confidentiality, so a more descriptive title might help.

Section 6.9 provides guidance on how to deal with the ambiguity of how to match
an “audience” value to a specific resource server. The authors admit that the
Section 5 discussion about the (optional) audience parameter in the OAuth token
is vague. They note that this is intentional, to accommodate a wide range of
deployment scenarios.  Thus the discussion in this section provides guidance
for several scenarios. This is a reasonable way to deal with the ambiguity from
Section 5.

Section 6.10 examines denial of service attacks in the context of
“introspection,” an optional aspect of OAuth which may be employed in this
framework. The text examines two DoS attacks, one against resource servers and
one against authorization servers, and suggests mitigations for both.

Section 7 discusses privacy implications of the proposed framework. The
discussion here is useful, addressing a set of concerns that arise due to
client interactions with the AS and RS elements of the framework.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 10 Dec 2019 22:39:04 -0800

Hi Steve,

Thanks for the thoughtful and in-depth commentary; I look forward to seeing
the authors' response.  I'll make a few notes inline in the interim...

> CoAP is cited as the replacement for HTTP. This document adapts OAuth for the

The WG did consider a variety of options before settling on the OAuth
architecture, so we can probably say that "the other extant options were
worse".

> issue. If this is likely to be a common case for IoT devices, leaving this as a

I think that there's a significant difference between the PKIX and OAuth
workflows as deployed here, that's relevant -- in PKIX the CA has the
"one-time" certification decision with some follow-on revocation status
information that many things don't make use of or don't put in the critical
path; in the OAuth world most deployments have the AS regularly involved in
authentication decisions, whether that's the RS querying "is this token
still valid?" or having a refresh token periodically refreshed into a new
access token on a timescale of hours.  There's more of an expectation that
the AS can actively break these ongoing/recurring authorization flows when
something goes wrong, whereas when the CA issues a CRL it sometimes feels
more like "toss it over the wall and hope that the relying party bothers to
check".  That's not to say that the OAuth way is perfect, of course, but
hopefully gives some sense of why it feels more natural to the authors/WG.

> default token format. The final paragraph of this section says that “developers

(I'll reiterate for everyone that CWTs are not necessarily encrypted,
though they can be.  In the Web/OAuth world, encrypted JWTs are hardly the
norm.)

> it a SHOULD, if it’s not, then RECOMMEND it.

Doesn't RFC 2119 say that SHOULD and RECOMMENDED are synonymous?

> this context, and SHOULD be employed if supported by both the C and the RS.”

(I'm told that there are devices for which DTLS is too heavyweight to be
implementable, and I suspect that's related to this wording.)

> Perhaps the text can be revised to provide additional advice re clock drift.

It's always hard to give concrete advice about clock drift, but worth a
re-think, as you note.  Kerberos went with 5 minutes of slop back in '93,
and that ends up being way more than you need if things are working
decently well, but still not enough for some broken systems.

Thanks again,

Ben

---

From: Ludwig Seitz <[email-masked]>
Date: Sat, 14 Dec 2019 12:58:22 +0100

> should treat these comments just like any other last call comments.

Thank you for your helpful review Stephen. I have some follow-up
questions inline.

I will submit a draft update as soon as possible, note that this may be
delayed by my affiliation change.

Regards,

Ludwig

> CoAP is cited as the replacement for HTTP. This document adapts OAuth for the

As Ben stated the ACE WG has had extensive discussions on which solution
to choose, and the OAuth model has the advantage of being able to
temporally decouple the authorization decision from the actual resource
access, which enables several use cases involving devices with
intermittent connectivity (note that several other proposals had the
same design property). Furthermore the possible re-use of OAuth
specifications was seen as favorable when the final decision was made to
go forward with this solution.

> key for a group of serves to be a MUST NOT, as opposed to just NOT RECOMMENDED.

Ok, will fix.

> in PKI contexts often is neither required nor advisable.

In constrained environments with intermittent connectivity, short token
lifetime is seen as an advantage, as it might be hard to convey
revocation decisions or other changes of access rights to offline
devices. The short token lifetime limits the window of exposure, if a
token and the corresponding proof-of-possession credentials get stolen.
I would therefore prefer to keep that paragraph as it is.

> This section ends by

The situation is the same as for OAuth 2.0. The short token lifetime is
often given as an explanation why a revocation mechanism is not really
needed.
We have however submitted a proposal for a revocation mechanism in
https://datatracker.ietf.org/doc/draft-tiloca-ace-revoked-token-notification

> when it is safe to reject the offer of confidentiality by a server.

The implication you read from the text was not intended, section 5
clearly specifies that confidentiality is mandatory.  This is addressed
in the body part of that section (4th paragraph). I'm a bit at a loss on
how to make that more apparent, so that the reader does not go an a
fruitless hunt in the subsections of section 5. Any suggestions are most
welcome.
In the meantime I will adjust the wording to clarify that
confidentiality is mandatory.
Note that Appendix C collects all requirements on profiles and lists the
specific subsection where they appears.

> Encryption

I guess it is up to the security level required by the specific
application. I physical key extraction attack is not trivial, so the
value of the protected asset has to be gauged against the additional
cost for tamper-resistant hardware.
A more simple, but less secure mitigation could e.g. be to glue over
interfaces that an attacker could use for key extraction (e.g. debug
ports) if they are not needed for normal operations.

Would you like to have such considerations added to this section?

> right? Why not just say that secret keys MUST NIOT be shared across devices?

Agreed, will fix.

> it a SHOULD, if it’s not, then RECOMMEND it.

Ageed, I will make both a SHOULD.

> be reconciled.

The rewriting of 6.2 should fix this inconsistency.

> The next subsection seems to be consistent. The final subsection

I'll try to rephrase to make it more readable.

> Perhaps the text can be revised to provide additional advice re clock drift.

I will add a paragraph about that noting that the critical factors are
the lifetime time of a token (lifetime >> clock drift), and the
criticality of timely expiration.

> only on confidentiality, so a more descriptive title might help.

I added a sentence instead that also points out the option that active
attackers may manipulate unprotected information to induce incorrect
behavior.

/Ludwig