| Internet-Draft | BRSKI for ACE | July 2023 |
| Amsüss | Expires 8 January 2024 | [Page] |
The autonomous onboarding mechanisms defined in ANIMA's voucher artifact and the BRSKI protocol provide a means of onboarding a device (the pledge) onto a PKI managed domain. This document extends the voucher with expressions for onboarding it into a domain managed through ACE.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the Authentication and Authorization for Constrained Environments Working Group mailing list (ace@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ace/.¶
Source for this draft and an issue tracker can be found at https://gitlab.com/chrysn/brski-ace.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 8 January 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[ See abstract. ]¶
The main application pattern considered for this kind of enrollment is [authz]: After basic networking services (possibly link-local when used in combination with CoJP as in Appendix A of [authz]) are available, the pledge initiates EDHOC to the lake-authz.arpa anycast address, sending an encrypted identifier for its MASA (party W) in EAD_1.¶
While ACE in general does not constrain the type of tokens used, or how the authorization space is split up, using the extensions of this document introduces additional conditions:¶
The key used to authenticate the token is a COSE key, and [CWT] are used as tokens.¶
The alternative to this constraint is to declare this a blob of some key; what it is depends would be preconfigured in the RS. While this is the general approach of ACE, the author considers it unsuitable for this particular case where a concrete identifier is assigned and thus should have concrete semantics. Users of any other key format may use this document as scaffolding for declaring an own YANG leaf instead.¶
While this does allow symmetric keys in theory (and they are used in ACE, for example in the [ace-oscore]) profile), they should not be used in BRSKI deployments, as the secret key would be shared with the MASA as it signs the voucher. [ See also the Open Questions section. ]¶
The pledge is identified with a single audience value. (More precisely, there is an "aud" claim conveyed in the CWTs that can be checked for equality against a configured value).¶
This rules out setups in which multiple security systems coinhabit the pledge, are enrolled in a single step to a single AS, but act independently at runtime.¶
Future iterations of this document may relax this, but will always need to express a condition based on which the pledge will know whether or not it may act on a token.¶
Using these extensions introduces no constraints on the type of scope values used with tokens. The structure of scope values needs to be agreed between the AS and the RS out of band. Typically, the AS will have configured knowledge of how to generate scope values that match the hard-coded model of the RS's firmware from authorizations of its native model.¶
This specification adds two leaf nodes to the voucher artifact defined in Section 6.1 of [_8366bis] [ this is currently done in a monkey-sees-monkey-does fashion, rather than having the yang files standalone and using pyang to build the tree as is done in 8366bis ]:¶
module: ietf-voucher
augment voucher:
+-- ace-as-key? binary
+-- ace-aud? string
¶
<CODE BEGINS> file "ietf-ace-brski-ace@2023-07-07.yang"
module ietf-ace-brski-ace {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ace-brski-ace";
prefix vch-ace;
import ietf-voucher {
prefix vch;
reference "I-D.ietf-anima-rfc8366bis-07";
}
organization
"IETF ACE (Authentication and Authorization for Constrained Environments)
Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/ace/>
WG List: <mailto:ace@ietf.org>
Editor: Christian Amsüss
<mailto:christian@amsuess.com>";
description
"This module augments the voucher artifact for bootstrapping
(onboarding) with mechanisms for onboarding onto ACE (Authentication
and Authorization for Constrained Environments) Authorization
Servers.
Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices.";
revision 2023-07-07 {
description
"Initial revision.";
reference
"I-D.amsuess-ace-brski-ace, Provisioning ACE credentials through
BRSKI";
}
uses "vch:voucher-artifact-grouping" {
augment "voucher" {
description
"Mechanisms for onboarding onto ACE (Authentication and Authorization
for Constrained Environments) Authorization Servers";
leaf ace-as-key {
type binary;
description
"Key(s) held by the ACE Authorization Server by which it
authenticates (and the Resource Server verifies) tokens.
It is a CBOR encoded COSE_KeySet.";
reference
"I-D.amsuess-ace-brski-ace, Provisioning ACE credentials
through BRSKI";
}
leaf ace-aud {
type string;
description
"Audience identifier by which the ACE Authorization Server
will be the pledge that is enrolled as an ACE Resource
Server.";
reference
"I-D.amsuess-ace-brski-ace, Provisioning ACE credentials
through BRSKI";
}
}
}
}
<CODE ENDS>¶
A device accepting this voucher will accept tokens signed with the credials expressed as a COSE key in the ace-as-pubk field, provided they are issued with an audience value of "jada89".¶
[ TBD; in particular the open question on symmetric keys. ]¶
[ TBD: Request this for the YANG Module Names Registry; the module itself is registered differently. ]¶
Is there a shorter route to the same result I missed (and should take instead)?¶
Is there a longer route (doing EST style onboarding into a PKI, and then obtain AS data by using those certificates) that I missed (and could reference and learn from)?¶
Is there existing YANG terminology for ACE (or just OAuth) to use?¶
There was some OAuth in the YANG of draft-kwatsen-netconf-http-client-server-03, but that was just FIXMEs, and later removed.¶
This document currently only describes expressing the ACE details in YANG for an ACE voucher.¶
For use with more EST-like enrollments, it could define resources equivalent to the rt=ace.est.sen resources.¶
Alternatively, such setups could use COMI to manipulate the AS. (But in the EST direction, would this need "pull mode COMI"?)¶
TODO acknowledge.¶