On 2019-12-08 19:18, Stephen Kent via Datatracker wrote:
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.
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
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.
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.
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.
Ok, will fix.
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.
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 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.
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
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.
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 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?
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?
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?
Agreed, will fix.
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.
Ageed, I will make both a SHOULD.
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 rewriting of 6.2 should fix this inconsistency.
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.”
I'll try to rephrase to make it more readable.
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.
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.
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.
I added a sentence instead that also points out the option that active attackers may manipulate unprotected information to induce incorrect behavior. /Ludwig -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
