]>

Austria christian@amsuess.com

ace ace brski est onboarding 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. Discussion Venues 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 . Source for this draft and an issue tracker can be found at .

Introduction [ See abstract. ] The main application pattern considered for this kind of enrollment is : After basic networking services (possibly link-local when used in combination with CoJP as in ) 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.

Applicability preconditions 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 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 ) 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.

Voucher extensions This specification adds two leaf nodes to the voucher artifact defined in [ 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 ]:

YANG Module WG List: Editor: Christian Amsüss "; 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"; } } } } ]]> 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".

Security Considerations [ TBD; in particular the open question on symmetric keys. ]

IANA Considerations [ TBD: Request this for the YANG Module Names Registry; the module itself is registered differently. ]

Open questions

• There are probably missing steps in this specification; the current draft's intention is primarily to start discussion.
• 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.
• AIU the voucher artifact data assembled by the registrar travels to the MASA to be signed during BRSKI. That's fine when we're shipping a pinned-domain-cert, and also when we're shipping as-public-key and an audience identifier (for the ACE EDHOC profile), but not when shipping a shared key (for the ACE OSCORE profile).
• Is this suitable use of BRSKI and the voucher?
• 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"?)

References Normative References Watsen Networks Sandelman Software Cisco Systems Futurewei Technologies Inc. Huawei This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON or CBOR document that has been signed using a variety of cryptographic systems. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document updates RFC8366, merging a number of extensions into the YANG. The RFC8995 voucher request is also merged into this document. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. Informative References Ericsson AB Ericsson AB INRIA Sandelman Software Works Institute of Embedded Systems, ZHAW This document describes a procedure for augmenting the lightweight authenticated Diffie-Hellman key exchange protocol EDHOC with third party assisted authorization, targeting constrained IoT deployments (RFC 7228). Ericsson AB Combitech Ericsson AB RISE This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token.

Acknowledgments TODO acknowledge.