[Ace] Re: AIF extending models vs. composite scopes
On Tue, Jul 02, 2024 at 02:10:17PM +0200, Christian Amsüss wrote: > 1. Wrap the AIF and some indicators for the extra data in some kind of >"bag" structure. With how tokens spanning groups was described in today's session, there might be overlap for these items: let's see if the work coming up in draft-ietf-ace-group-oscore-profile solves this thread's issue as well. BR c -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature ___ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
[Ace] AIF extending models vs. composite scopes
Hello AIF experts and ACE group, looking into AIF (in particular the REST-specific model) for use on embedded (RIOT OS based) systems, there are properties I'd like to express additional properties in a token, eg: a. "When responses are sent to a client authorized with this token, the server may place non-confidential but possibly attack relevant data in problem-details." (Like, stack traces with program counters and/or line numbers, not the content of the stack). b. "Under memory load, evict state from this token last." (In particular, a server may have an LRU cache of OSCORE/EDHOC contexts, but this context will only be evicted from there by another context established from a token with the same authorization). There are two approaches I see that would still retain usability with AIF: 1. Wrap the AIF and some indicators for the extra data in some kind of "bag" structure. 2. Extend AIF such that a structure like this is permissible: [["/s/temp", 1/GET/], ["/a/led", 5/GET|PUT/], [CPA12345(null)/access error details/, true]] 3. Make up resources that represent the permissions. This is kind of viable for the error case (when assigning error instances a la /err/0001, permission to read through the indirection can imply permission to get it served directly), but I wouldn't know how to explain this for use case b. All have in common that an AS that is unaware of the extra features can still deal out the regular authorizations; 3 is even easy to add to any AS that supports regular AIF. Is any of those patterns already established, or has been explored in parts? Thanks Christian -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature ___ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
[Ace] Re: PoA based Device Registration (draft-vattaparambil-ace-wg-poa-device-reg): Support, suggestions
Hello Sree, On Fri, May 17, 2024 at 02:57:24PM +0200, sree lakshmi wrote: > In this draft, we have assumed a pre-established mutual authentication > step between the DO and the AS. We haven’t explained it in detail > because it is an assumption. The assumption I've been working on is that DO is enrolled to the AS as a C. Either the authorizations the AS associates with the DO have a "this may be delegated" flag on them, or the AS simply treats itself as an RS, where some C (such as the DO) are authorized to utilize the "register more clients and transfer some authorizations" interface. As I understand the interfaces we lack, the OAuth dynamic client registration covers both the creation of a client and giving it the right scope; for ACE I hope we can do something much slimmer. > I read a new alternative protocol flow of ACE (L1), this will even > decrease the load on the client side. We can discuss. I will look into the > CoRE dynlink you mentioned. Will see how we can use it. The alternative flow can certainly be a good simplification in some cases. It would be a *great* simplification if by the mere request from the DO it could already issue the token and install it on the RS, and refresh it on expiry (for this would free the C from the need to ever actually perform the C-AS protocol). Some prior chats indicate that this would contradict the ACE architecture where the AS needs to prove that C actually has that key, but let's discuss that more. (Personally I don't see anything wrong with the AS issuing a token to C blindly -- the token will be bound to the key included, and success of EDHOC proves possession of that key to the RS). If that larger simplification is possible, the data the C receives from the DO would not even include AS details any more, but instead would contain details of the token response (eg. rs_cnf). > We also do not like to send the credentials in plaintext, we can go with > EDHOC with key identifiers, but I am not well aware of how this works and > how to show this in the protocol flow diagram. We can have a discussion on > this. The credentials are not sent in plain text in EDHOC: the initiator's credentials (ie. the token) would only be revealed to the RS after C has verified that the RS just presented the right rs_cnf. > The problem with bundling of the AS URI, AS credentials, audience, scope; > we haven’t thought about it in this way. We had a small thought on multiple > entities and the scalability of the solution. Multiple entities definitely make this more complex. If the RSes can be expresed as a group audience, tools like rs_cnf2 (also from ace-workflow-and-params) could help. > We can meet in Paris, me and Olov will participate in person:) Looking forward to that! BR c -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature ___ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
[Ace] PoA based Device Registration (draft-vattaparambil-ace-wg-poa-device-reg): Support, suggestions
Hello Sreelakshmi, authors, ACE, I've read draft-vattaparambil-ace-wg-poa-device-reg-00 and think it provides a valuable contribution to ACE, especially if it grows to actually propose an interface to the client registration problem. I am not sure that the proposed solution has the ideal work flow, but nonetheless, the WG should concern itself with this. (In particular, looking at figure 5, I'd rather have the DO talk to the AS rather than send a relatively large signed statement to the client that the client then relays to the AS -- the client needs to stay small and carry little data). The use case I'm looking into it for is to enable CoRE dynlink [1] (yes it's long expired, but I still think we should go on with it), where a constrained device is told to act as a CoAP client and pull or push data from one resource to another resource, possibly even without understanding the role of that resource. (My favorite example is that it'd be used to tell a physical temperature control dial to PUT its value to a heating control's set-point resource). In practice, picking up PoA terminology, the device owner POSTs a link pointing to the RS into the binding site resource of the Client, annotated with some additional metadata. As the Client is previously unaware of the RS or its AS, with PoA, the owner would register the Client at the AS, and then add AS metadata into that POST. (At least) in this case, the AS validation problem has an almost trivial solution: As part of the POSTed link (which points to the RS resource), the DO would include a bundle of the AS URI, the AS's credential, the audience and scope that it should request and possibly also a key ID that the AS assigned to the client credentials the DO obtained from the AS during client registration (as an optimization to not make the client send its credentials by value -- in my scenario this is all run on EDHOC, and KIDs make it really really compact). This way, the unencrypted pre-flight request is completely avoided, and we don't need any of the two solutions proposed in 4.2 -- instead, the (AS URI, AS credentials, audience, scope) bundle is conveyed to the client as part of its mandate to perform some specific task on the RS. It may even be dangerous *not* to bundle those, if the DO is not just "the" device owner but just a user that has some control over the client: If there were multiple such users that both have some authority over the AS different ASes (or within the same AS), then a less privileged user might install some low-authorization PoA into the client, but then direct the client to an RS resource where the unauthorized initial request redirects the client to use the high-authorization PoA installed by a different user. Best regards Christian [1]: https://datatracker.ietf.org/doc/html/draft-ietf-core-dynlink-14 -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature ___ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
Re: [Ace] [Anima] Proposing document draft-amsuess-ace-brski-ace-00
Hi Carsten, On Sun, Jul 23, 2023 at 03:10:43PM +0200, Carsten Bormann wrote: > Whether anyone whose statements you are willing to base your > authorization on is willing to endorse the manufacturer’s claims is > one of the authorization questions hidden in attestation… As I understand there can also be other valuable statements in the voucher: For example, I may not make much of the vendor's statement that this is actually a device they produced running firmware version X. But provided I trust them to the point that if they say it's version X it really is (possibly aided by by any RATS things through which the silicon vendor confirms that claim), I'd put much value in an escrow agent's attestation that says that they hold firmware and firmware signing keys, and that they will be escrowed as soon as the vendor stops providing updates. At any rate, I think that the next iteration of the document will be more ACE EST, and for EST it doesn't matter too much whether that initial all-privileged device owner is established through EST, TOFU or something like EAP-NOOB. BR c -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Proposing document draft-amsuess-ace-brski-ace-00
Hello Michael,
(Group(s): See especially PS at the bottom)
thanks for your feedback, that's the very kind I was hoping for.
On Wed, Jul 12, 2023 at 05:52:30PM -0400, Michael Richardson wrote:
> IN section 1.1, without having given a picture of what you are doing
> you start to say:
> "The alternative to this constraint is to declare this a blob"
> and this is really distracting to understanding what you *ARE* doing.
I think it's important, when limiting a reader's options, to point them
at what else they could do. I've created issue [1] for the time being to
not lose this, for I want to both resolve it for smooth reading and keep
all the pointers around.
[1]: https://gitlab.com/chrysn/brski-ace/-/issues/1
> "the pledge initiates EDHOC to the lake-authz.arpa anycast address, sending
> an encrypted identifier for its MASA (party W) in EAD_1."
>
> This sounds like it's a new thing, but I think it's just the lake-authz step
> one, right?
It is; a wording enhancement will be in the editor's copy soon.
> You did a bunch of YANG:
> uses "vch:voucher-artifact-grouping" {
> augment "voucher" {
>
> And I really wish that it worked that way.
> But, it just doesn't.
>
> https://play.conf.meetecho.com/Playout/?session=IETF116-NETMOD-20230331-0030
> Start at 1:53:00.
Thanks for the good pointer, I've enjoyed your cake example very much.
My takeaway is that not only would we need to linearize all
augmentations (something that'd be doable if additions required an
"updates" on the first document), but even then the updated versions
would be mutually incompatible.
If this is pursued in its YANG form (even partially), then I suppose
that the draft would only serve as a staging ground for the extra YANG
statements, with hopes to be sufficiently mature in time to be merged
into constrained-voucher before the batch is through. (No clue how
realistic that is right now).
> My impression is that you don't really want the *MANUFACTURER* (authorized)
> to send down some ACE keying material. That is, Volvo shouldn't be sending
> your car a key to open your building garage door, rather, your building owner
> should be.
>
> So, augmenting the voucher, which comes from the Manufacuter (MASA, aka W) to
> your pledge is wrong. You want the ACE Authorization Server, aka V, to
> actually send the right keys.
>
> I think that either you want to use the new V/W relationship that EDHOC,
> lake-authz setup to send the keys in message 4, or you want to do a new FETCH
> on some some new resource to get them.
My hope has been that like with BRSKI where a domain CA public key can
be shipped right with the voucher, so I hoped to replicate the same
slimness here. IIUC, a device can use BRSKI to enroll DTLS credentials
without the need to do GETs to the registrar's /crts and the /s(r)en
interactions.
Revisiting what cBRSKI can do, maybe I was wrong, and only the /crts
(and not the /s(r)en) part has an equivalence in BRSKI. Is that an
equivalence (between /crts and pinned-domain-cert)? And if so: Why can
the registrar not take a certificate request in the PVR and send the
result of /sen on to the pledge through the RVR?
Or did I get things so wrong that everything in the voucher was only to
establish the first secure connection, and getting /crts etc is a
necessary next step anyway?
If so, a next good step for me would be major rewrite in which data is
not transported in the voucher, but equivalent resources to /crts and
/sen are defined for ACE.
But then, looking at CoJP-over-authz, how does the pledge learn any
further keys and identities? Would it follow up the message_3 CoJP
request and the CoJP response with more requests in the same OSCORE
context that est-oscore requests (to get a DTLS context), or the next
version of this document's exchange? That'd mean that party V needs to
serve both as a JRC and DTLS/OSCORE data -- nothing I'd rule out, just
something that wouldn't have been apparent to me from the documents
I've read so far.
BR
Christian
PS. It may make sense to meet on IETF117 hallways and chat on this some
more. It's too narrow a topic for a side meeting, but if there is anyone
else who may join in, we may want to pick a time for when and where to
chat. (I'm only there remotely this time).
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Proposed document: draft-amsuess-t2trg-raytime-01
Hello Michael,
On Wed, Jul 12, 2023 at 06:57:38PM -0400, Michael Richardson wrote:
> I don't think this belongs in t2trg, but I don't object.
> maybe it goes into ACE or IOTOPS.
I'll appreciate if any of those wanted it; first people I've talked to
about it pointed me to T2TRG. I'll try to get a hold of the chairs on
the virtual hallways.
> We wrote something similiar for RFC8366 or 8995, but I think we ripped most
> of it out. For instance, if a device had a valid IDevID with a notBefore of
> 2021-02-01, and the RTC said 1980-01-01 [good old DOS epoch], then one could
> be sure it was at least 2021-02-01!
Does either of those have a versioned history? Without a change log in
them, and no mention of the example DOS epoch discoverable in either, I
couldn't find what was there.
(8366 has a section on clock sensitivity, but that is explicitly listing
required-verification-of-expiry, nonce-based and
never-expiring-vouchers, without touching the middle ground.)
> {There is a Doctor Who and/or Blakes Seven and/or Stargate plot here though.}
Yes, but I think I only get away with one toy reference per document ;-)
Thanks for your points and the issue
Christian
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
[Ace] Proposed document: draft-amsuess-t2trg-raytime-01
Hello T2TRG (because of its researchy character), hello ACE (because this is applied to your ecosystem), motivated by project requirements, I've written a draft[1] on how devices without reliable Internet connectivity (and thus time source) can deal with time limited tokens. > Abstract: >When devices are deployed in locations with no real-time access to >the Internet, obtaining a trusted time for validation of time limited >tokens and certificates is sometimes not possible. This document >explores the options for deployments in which the trade-off between >availability and security needs to be made in favor of availability. >While considerations are general, terminology and examples primarily >focus on the ACE framework. The concept and trade-offs will not be surprising to many, but to my knowledge they have not been written up. In addition, this document lists the mechanisms a device can use to reject outdated tokens on a best effort base. I'd appreciate the group's input on the document, in particular in the area of previous work there. Best regards Christian PS. It's a -01 because Carsten already provided some fixes. [1]: https://datatracker.ietf.org/doc/draft-amsuess-t2trg-raytime/ -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Proposing document draft-amsuess-ace-brski-ace-00
Hello ACE and ANIMA groups, hello Ben, Michael and Russ, taking input from the "ANIMA and ACE, IDevID terminology" thread[1], where the discussion was lacking a concrete proposal, I've written up things at [2]. I'd appreciate the one or other pair of eyes, and feedback both on the direction and the execution (my first YANG module...). Known shortcomings are the lack of announcing the AS's URI (fixed in the editor's copy[3]) and the lack of SIDs for constrained-voucher style use (I'll need them, just didn't get around to them yet). Best regards Christian [1]: https://mailarchive.ietf.org/arch/msg/ace/5N_scwkcAL2_Frwwtsxrwm6f5gA [2]: https://datatracker.ietf.org/doc/draft-amsuess-ace-brski-ace/ [3]: https://gitlab.com/chrysn/brski-ace/-/commit/9898266f0c8a9a19a4224152472c69bc2dcb2001 signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Anima] ANIMA and ACE, IDevID terminology (was: Re: cBRSKI)
Hi Ben,
On Mon, May 01, 2023 at 10:41:32PM -0700, Benjamin Kaduk wrote:
> > * Does pinned-domain-pubk work also for COSE keys as used for signed
> > CWTs? (If so, is there a key identifier to go with it?)
>
> COSE key identifiers ('kid') are not exactly what you would typically call
> a "key identifier" in unconstrained spaces. In particular, they are just
> for optimizing lookup over trial decryption, and you have to associate your
> authorization data with the full key entry, not with the 'kid'. COSE 'kid'
> are not globally unique, and you might run into a lot of places using kid
> of '0' and relying on context to infer which one is meant.
Yes, that's the way I'd hope they could be used. For example, if a
device were onboarded into an ACE domain with three AS that's using the
ACE-OSCORE profile with the devices, they'd obtain three symmetric keys
with a key identifier h'00', h'01' and h'02' respectively, so that when
the device receives a token, it'll try the one key and not any.
> It makes me nervous, but just because of the normal shared-key threat
> model.
That'd make me nervous too, but see above -- with shared keys, it'd be
at least my expectation that there's a key for every AS.
... which also means that there'd be a need to update data that
originally came in on an ANIMA voucher, and I don't know whether that's
better done through ANIMA again or through ACE.
> > * Once onboarding onto ACE has completed, all the device's identity
> > would be ACE (except for the IDevID that's left in place for a factory
> > reset). Is that fine with an ANIMA setup?
>
> Without the full context of the preceding thread, it's hard to be sure I
> understand properly, but I think yes, ANIMA expects LDevID for onboarded
> devices, so if you're building ACP using ACE crypto it should be fine.
I'm not sure the thread context will help, but I can rephrase the
question now (assuming it's using ACE-OSCORE for simplicity):
The identity a device (after onboarding onto an AS through ANIMA means)
will have as its operational identity the (AS-URI, audience) tuple,
confirmed by the shared key(s) it has obtained. It would not receive any
certificate, and not use the IDevID unless onboarding is started anew.
Is that identity now an LDevID (even though it has a completely
different shape than the IDevID), or is a certificate based LDevID still
created as part of the process, or can the device happily complete the
ANIMA processes without an LDevID?
Thanks
Christian
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
[Ace] ANIMA and ACE, IDevID terminology (was: Re: cBRSKI)
Hi Michael, (CC'ing ACE list because what I think will be the larger part of the thread is hopefully relevant) > > there a generalization of the IEEE identifiers that also makes > > sense for constrained but more general-purpose-oriented devices, > > for which the ANIMA products can still be used? > > Yes, I agree: replacing the IDevID makes a lot of sense if the control over > the software-update trust anchor changes. When talking about such processes, can we still use the IDevID term (even though an IDevID is "stored in a way that protects it from modification"), or is the use of the term OK because we're not modifying but replacing it, or do we need to use a more general term, or do we not care? > > * Is there any document that describes (or has an example of) how ANIMA > > onboarding interacts with ACE's AS? My current -- maybe naive -- > > assumption is that a voucher in this countext would contain a > > pinned-domain-pubk which is the public key the AS will use to sign ACE > > tokens, and the est-domain would indicate the AS URI, but with the > > pinned-domain-pubk being described in TLS terms (whereas an ACE AS > > uses COSE keys), this may be skipping a step. > > Yeah, that makes sense to me. > I think that ace-ake-authz intended to describe things in terms of ACE. In the current document, the only ACE reference is in an older version's asssigned group. And I think that's good, for using-ANIMA-with-ACE is orthogonal to doing-ANIMA-over-EDHOC. It just may mean we need another document, unless we cram things together in one (which, apart from any good-practice discussions, is hard to convey to the initial reader, who'll need to understand that they can use either part w/o the other). > The AS == Registrar, I think. > Or, perhaps the AS uses a key that the local CA (mediated by the Registrar as > a trust anchor, /cacerts) has blessed in some way. How that works is TBD. So, what'd we need? * Does pinned-domain-pubk work also for COSE keys as used for signed CWTs? (If so, is there a key identifier to go with it?) * Some ACE profiles (eg. ACE-OSCORE, RFC9203) are typically used with a symmetric key shared between AS and RS (and that may be the only key material). Is it fine from an ANIMA PoV to only have such key material? (When such a key is used, it obviously needs to be encrypted; at least some methods of ANIMA, eg. EST, can do that). * (At least) When AS is used with asymmetric tokens, the RS needs to be told its audience identifier; I'd guess that'd be a new leaf. * Once onboarding onto ACE has completed, all the device's identity would be ACE (except for the IDevID that's left in place for a factory reset). Is that fine with an ANIMA setup? I figure that the alternative is to have a dedicated registrar that then hands out certificates to the AS that allow the AS to (temporarily) speak for the CA, but this probably just shifts the questions above down to how those points above would be expressed in a certificate. Skipping that middle step would allow implementing devices that have ANIMA-style onboarding (cBRSKI with ake-authz, maybe), but (eg. using ACE-OSCORE) don't ever need asymmetric operations at runtime. Or do I get the boundaries all wrong, and an ACE device would rather express the concepts of a voucher in a CWT? (But ANIMA already did all the hard work, and given such a device likely needs some CORECONF and thus YANG anyway, reducing extra weight). If not: Shall we just start a small and sleek document that registers some values, and evolve it with some help from Mr. Cunningham? BR Christian -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Call for adoption: draft-selander-ace-edhoc-oscore-profile-00
Hello group, On Mon, Sep 12, 2022 at 06:04:18PM +0200, Christian Amsüss wrote: > I've read this document and can review it in its working group phase. as I was asked off-list to clarify: I very much do support this document for adoption into this working group. BR c signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Call for adoption: draft-selander-ace-edhoc-oscore-profile-00
Hello chairs, group, On Mon, Sep 12, 2022 at 11:26:21AM -0400, Daniel Migault wrote: > This work stats a Call for adoption of the following document: > Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for > Constrained Environments (OSCORE) Profile for Authentication and > Authorization for Constrained Environments (ACE) [1]. I've read this document and can review it in its working group phase. I'd have a slight preference for the document to offer fewer options, or making recommendations as to what to use and what not (like, do we need several pages of text on using /authz-info, when EAD_1 can be used? Does comb_req need to be optional? Does osc_ms_len need to be negotiated?) -- but that's the kind of comments well suitable for work inside the WG, and should not impede adoption.. Best regards, and thanks to the authors for providing this work Christian -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] About securing last exchange CoAP-EAP
Hi, sorry for spreading this out over the sub-threads[1], just to get the pointers right and everything addressed: On Fri, Sep 03, 2021 at 08:32:59PM +0200, Rafa Marin-Lopez wrote: > 2) When the CoAP message contains the OSCORE ID that hits the OSCORE > context without any key material, we would have to assume this is > CoAP-EAP: the OSCORE implementation should not discard or give a > fail for this coap message but "pass the control" to CoAP-EAP so > that we send a altAccept to the EAP state machine so we get the MSK. It's not because the context is without key material -- it's because that context was created by EAP and that software component, rather than giving a key, gave a "callback" (however it's precisely implemented) that tells the OSCORE context to rather ask for a key with metadata from the last message. (OSCORE appendix B.2 needs something similar to implement, so this shouldn't be new to OSCORE implementations). > 3) From the MSK, we derive the OSCORE key material for the OSCORE > context with the corresponding ID and update the OSCORE context with > this key material The key IDs need to be preconfigured for this to work, see [2] -- but that's best practice anyway. BR c [1]: https://mailarchive.ietf.org/arch/msg/emu/nb8zGGDJ3d4fUaCW8QMkf6rkhVs/ [2]: https://mailarchive.ietf.org/arch/msg/core/AK8Wxy64tXofocdRHm5HNew8dpE/ -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] About securing last exchange CoAP-EAP ( and EAP state machine - RFC 4137)
Hello Rafa, that's the mail I missed in our previous discussion -- and yes, it largely describes already just what I think can work, see comments below. On Sat, Sep 04, 2021 at 09:19:35PM +0200, Rafa Marin-Lopez wrote: > I think that is not possible because that would move the EAP peer > state machine to a final state SUCCESS without any chance to withdraw. Does there need to be? If a request arrives at an OSCORE context and the validation *fails*, the most probable explanation is that someone got the key derivation wrong -- no point in allowing another attempt. Or, of course, an attacker has been listening, and either attempting to guess a key (giving them several attempts is questionable) or trying to disturb the negotiation (which they can already do more easily by sending unsuccessful CoAP responses). > However, the MSK required to create the OSCORE context, which allows > deciphering the message, is not available yet (even though eapKeyData > variable has content). The reason is that, according to EAP state > machine (RFC 4137) Figure 3, the MSK becomes available > (eapKeyAvailable = TRUE) when EAP success (rxSuccess or altSuccess > from the EAP lower layer) is sent to EAP state machine. The OSCORE context can be partially initialized, or updated over its lifetime. This is odd if you think of the context as a Recipient ID to key mapping, but that's not generally the case in OSCORE, and the construction of its RFC8613 B.2 also depends on data about requests being fed "live" into the key derivation before the actual key is there. With agreed-on recipient IDs[1], what happens as the "last" message EAP is involved in can be this: * OSCORE message is received * OSCORE library looks into OSCORE option, finds an ID placed there by EAP * OSCORE library asks EAP for key material for that ID (this is a callback, not a dictionary lookup) * EAP sees that and declares altSuccess based on the receiption of the message alone, and then extracts the key material from the state machine * EAP returns the context key material to the OSCORE library * Message is decrypted That message does not even need to go up to the EAP resource any more -- it's just as fine if that is already usable data. (If there is no request pending and you prefer to have such a message just to clean out the EAP state even though it has no timeouts, any encrypted message would do, including a POST to the EAP resource). BR c [1]: https://mailarchive.ietf.org/arch/msg/core/AK8Wxy64tXofocdRHm5HNew8dpE/ -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] CoAP-EAP draft
Hello Dan & Rafa, On Fri, Sep 10, 2021 at 10:42:56AM +0200, Dan Garcia Carrillo wrote: > > * OSCORE ID derivation: > > > > * Randomly assigned full-length ideas look like an odd choice. > > [...] > > > > Any chance something like that can still make it in? > > [Authors] Did not see that as random but parametrised according to the > crypto suite. We will try to make this as straightforward as possible > following your comments. the construction we recently discussed (where both peers decide actively on the OSCORE Recipient IDs (or client ID for DTLS) they'd later want to use as inputs to EAP) would resolve this issue conveniently. (See coming follow-up in "About securing last exchange CoAP-EAP"[1] on how this makes things easier over there). BR c [1]: https://mailarchive.ietf.org/arch/msg/emu/bnMFV4_1uTW7sSwVOp7WzVZZCAI/ -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] CoAP-EAP draft
Hello, (picking some easy targets to advance, not touching parallel or earlier discussion), On Fri, Sep 10, 2021 at 10:42:56AM +0200, Dan Garcia Carrillo wrote: > > IoT device Controller > > ++ ++ > > | EAP peer/ | | EAP auth./ |+-+[ AAA infra. ] > > | CoAP server|+--+| CoAP client|+-+[ EAP server?] > > ++ CoAP ++ EAP? > > \_ Scope of this document _/ > > > > Figure 1: CoAP-EAP Architecture > > > [Authors] This is a good point. We did not include it at first, as having a > AAA infrastructure is not mandatory. But the optionality can also be > expressed in the figure. We will consider using this for the next version. > Please also be aware that this architecture including AAA is assuming > something called EAP authenticator in pass-through mode. Nevertheless, an > EAP authenticator in standalone mode is also possible, where no AAA exists. Maybe it helps to emphasize the components then (which I probably got wrong in the image) -- there's the (existing / unmodifed) EAP server in the controller, which now gains the CoAP transport, and optionally passes on the data to some AAA infrastructure: | IoT device Controller AAA infrastructure | ++ +++ (optional) | | EAP peer/ | | EAP auth./ | EAP| | | CoAP server|+--+| CoAP client| server |+-+[ ...] | ++ CoAP +++ | \___ Scope of this document ___/ | | Figure 1: CoAP-EAP Architecture > > * (Bycatch of suggesting URIs): It may be worth mentioning that the > > NON's source address can easily be spoofed. Thus, any device on the > > network can trigger what the authenticator may think of as a > > device-triggered reauthentication, and the device may think of as an > > authenticator-triggered reauthentication (provided it works that way, > > see below when reauthentication is mentioned again). > > [Authors] But this case would not be possible since we mention that (re) > authentication is initiated by the device. Thus, when the device sees an > authenticator triggered re-authentication will discard that. If authenticators don't reauthenticate, then fine. (But I wonder: What happens to an established context if, for example, the authenticator finds that a used credential just wound up on a CRL?). > > * Proxying: As it is right now, this protocol just barely works across > > proxies, and only if they support CoAP-EAP explicitly. (And while it > > may sound odd to even consider that, bear in mind that they are used > > in a very similar way in RFC9031). > > > > While it's a bit open whether all CoAP-based protocols should > > reasonably be expected to work across proxies or not, a remark (maybe > > before 3.1?) that "If CoAP proxies are used between EAP peer and EAP > > authenticator, they must be configured with knowledge of this > > specification, or the operations will fail after step 0." > > [Authors] Based on your comment, it seems there is no guarantee that any > CoAP-based protocol would work across proxies. Our question is whether there > is any adaptation or change that would favour working through proxies. At > the research level, we worked with proxy and you are right, our assumption > is that proxies support CoAP-EAP explicitly > (https://ieeexplore.ieee.org/document/8467302). Since we are trying > to avoid right now anything tailored to CoAP-EAP and only using CoAP > as a means of transport for the exchange, why do you think this would > not work with proxies? A CoAP-based protocol in general works across proxies if it doesn't use any of the following: * Options that are not safe-to-forward * The role-reversal address (without a means to indicate an address more explicitly) This document does not use new options, but the initiation step uses the role-reversal address. The part where the controller is the CoAP client and the device is the CoAP server should work through any proxy -- but the initial step means that the initial CoAP server (the controller) looks at its role-reversal address (the source of the request). As it is now, a proxy that facilitates EAP-CoAP would need to recognize that first message and send it from a port dedicated to forwarding to that client. Allowing the client to set its address would not do away with all the issues, but at least paint a way out. > > > * 3.3.1: "after the maximum retransmission attempts, the CoAP client > > > will remove the state from its side". > > > > > > So the device that's being kicked from the network can delay its own > > > eviction for about a minute as long as it doesn't answer? > > > > [Authors] This is an interesting use case. To avoid this, we may
Re: [Ace] About securing last exchange CoAP-EAP
Hello, On Sat, Aug 14, 2021 at 01:37:06PM +0200, Dan Garcia Carrillo wrote: > As such, CoAP server (left side) could not see the content of the CoAP > message (message 7) without deciphering it. Moreover, as the URI-path is > also ciphered we cannot point to the right application to process the > message to achieve an alternate indication of success. If the recipient ID were available a bit earlier (and not derived from the MSK), would it then be viable to infer from the OSCORE ID that this is the last message, process an "EAP success", and start derivation just to extract the session lifetime (and thereby confirm the keys)? (That'd be all assuming that the "EAP success" contains really just the EAP success code and no further information, which would be "compressed" into the "some OSCORE is sent on this" information, and that the Session-Lifetime does not need to be known to advance the EAP state machine). BR c -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] CoAP-EAP draft
Hello CoAP-EAP authors and involved groups, (CC'ing core@ as this is a review on CoAP usage), I've read the -03 draft and accumulated a few comments; largely in sequence of occurrence. Over all, the protocol has improved a lot since I've last had my eyes on it. Several comments below are about how prescriptive the message types are. I believe that this should be resolved towards generality, or else the usability of this protocol with generic CoAP components will be limited (or, worse, still implemented and then surprisingly incompatible). * Figure 1: For readers new to the topic of EAP, I think that it might be useful to extend this to cover also the EAP server or AAA infrastructure, if that can be covered without too much complication. Suggestion (without illusions of correctness): IoT deviceController ++++ | EAP peer/ || EAP auth./ |+-+[ AAA infra. ] | CoAP server|+--+| CoAP client|+-+[ EAP server?] ++ CoAP ++ EAP? \_ Scope of this document _/ Figure 1: CoAP-EAP Architecture * `/.well-known/a`: [note: May be irrelevant, see next two items] If the designated experts don't go along with a very-short option (I'd kind of doubt you'd get anything shorter than `/.well-known/eap`) and if that puts you up against practical limits, using a short-hand option might be viable. So far there's no document for it and I've only pitched the idea briefly at an interim[1] (slides at [2]), but if push comes to shove and you need the compactness, let me know and that work can be expedited. [1]: https://datatracker.ietf.org/meeting/interim-2021-core-05/session/core [2]: https://datatracker.ietf.org/meeting/interim-2021-core-05/materials/slides-interim-2021-core-05-sessa-core-option-for-well-known-resources-00 * Discovering the Controller is described rather generically, but with CoAP discovery as an example. As long as CoAP discovery (as per RFC6690/7252) is used, that already produces a URI, which can contain any path the server picked. It has thus no need for a well-known path. Are there other discovery options envisioned that'd only result in a network address? Only for these, a well-known path would make sense. (And then it's up to the envisioned client complexity if one is warranted). For comparison, RD[3] explores some of the options. A path may be discovered using CoAP discovery as `?rt=core.rd*` right away from multicast. Or an address may be discovered using an IPv6 RA option, with CoAP discovery acting on that address. Only for cases of very simple endpoints, it also defines a `/.well-known/rd` name that can be used without CoAP discovery (and thus link parsing) happening beforehand. The same rationales may apply for EAP (the devices using the resource are mostly servers, otherwise, and send a very simple request to start things), but again that's only if the address was discovered through something that's not CoAP discovery already. [3]: https://www.ietf.org/archive/id/draft-ietf-core-resource-directory-28.html#name-rd-discovery-and-other-inte * For message 1, why does this need to go to a fixed resource? There has been previous communication in message 0 in which the resource could have been transported. Granted, it's not as easy as in messages 2-to-3 etc where the Location-* options are around, but the original message 0 POST could just as well contain the path in the payload. There are options as to how to do that precisely (just the URI reference in text form, or a RFC6690 link, or a CBOR list of path segments, or a CRI reference[4] -- if the latter were in WGLC already I'd recommend it wholeheartedly), but either of them would stay more true to the style of the other messages in that the earlier message informs the path choice of the next ones. An upside of this would be that it allows better behavior in presence of proxies (see later), even though it may be practical to not spec that out in full here. (But the path would be open for further specs, and they'd just need some setting down of paving stones). [4]: https://datatracker.ietf.org/doc/draft-ietf-core-href/ * (Bycatch of suggesting URIs): It may be worth mentioning that the NON's source address can easily be spoofed. Thus, any device on the network can trigger what the authenticator may think of as a device-triggered reauthentication, and the device may think of as an authenticator-triggered reauthentication (provided it works that way, see below when reauthentication is mentioned again). Even sending full URIs in message 0 would be no worse than the current source spoofing. Sending URI paths in message 0 would make this minimally better because the attacker would need to guess (or observe from the network) the CoAP server
Re: [Ace] Proposed charter for ACE (EAP over CoAP?)
Hello ACE, On Thu, Dec 03, 2020 at 01:20:08PM +, Daniel Migault wrote: > 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. If nothing else, I'd be curious to see EAP-over-CoAP this sketched out; interactions with NOOB. (The "film a blinking LED to get mutual authentication" sounds particularly promising). Care would need to be taken to follow CoRE best practices (not that we'd have a good set of standard recommendations, but at least on concrete points we usually manage consensus), both because anything built on CoAP coming from the IETF will be seen as something of a reference example, and also to leverage its full optimization potential. CCs to core when this is put on the agenda for ACE interims might be a good idea. Go for it :-) Christian -- Es ist nicht deine Schuld, dass die Welt ist, wie sie ist -- es wär' nur deine Schuld, wenn sie so bleibt. (You are not to blame for the state of the world, but you would be if that state persisted.) -- Die Ärzte signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] oauth-authz: Introspection endpoint method
Hello ACE-OAuth authors, authors of revoked-token-notifcation, and ACE group in general, while trying to understand the necessity for revoked-token-notification, I was looking into the introspection parts of ACE (draft-ietf-ace-oauth-authz-35 Section 5.7.1) and was confused at the method used there: Given the introspection endpoint is used for querying, why is it using the POST method? This indicates that the request may not be safe (in REST terminology), which seems not the case. This would have the nice properties of indicating its safeness to the rest of the stack (ie. the CoAP library can forego request deduplication). Also, it'd keep the door open for caching (where obviously `exi` would be inapplicable, but `Max-Age: ...` would be used instead), and observing a particular introspection would be possible. This sure wouldn't make revoked- obsolete, but I think it'd make the path there smoother, and help sharpen what the TRL adds. If there's no particular reason to keep POST and it's early enough for such a change, the change to the document would be minimal, and unless any implementation is built on a CoAP stack without support for RFC8132, changes there should be trivial. Best regards Christian Bycatch: The example in figure 13/14, the Uri-Path should probably be in Figure 14 instead, along with the inner code (which is suggested to change above). Given figure 15 is shown as the full protected message, the same format may work well for a single figure 13/14 as well (with just a note that this is an encrypted exchange). -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] OSCORE Profile status update and way forward
Hello Francesca, hello ACE group, On Mon, Sep 21, 2020 at 01:48:33PM +, Francesca Palombini wrote: > - clarified that Appendix B.2 of OSCORE can be used with this profile, > and what implementers need to think about if they do. I understand B.2 to be something that the involved parties need to agree on beforehand; after all, the ID context may be something the server relies on (at least for the initial attempt) to find the right key, especially when multiple AS are involved. (For example, the RS could have an agreement that the AS may issue any KID as long as they use a particular ID context). If the server expects B.2 to happen (which, as it is put now, it can as long as it supports it in general), it needs to shard its KID space for the ASs it uses. (Generally, B.2 is mutually exclusive with ID contexts's use of namespacing KIDs). Is the expectation that clients that do not anticipate B.2 by the time they are configured with their AS just don't offer B.2 to their peers? Given B.2 is in its current form client-initiated only (AFAIR we had versions where ID1 could be empty in draft versions, but currently it reads as client-initialized), does B.2 have any benefits for ACE-OSCORE clients? After all, they could just as well post the token with a new nonce1 to the same effect. Kind Regards Christian -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Assignment of OSCORE Sender and Recipient IDS - was RE: Review of draft-ietf-ace-oscore-profile
Hello John, Jim, and ACE in general, I agree with Jim that namespacing is the obvious solution to this problem; we've had a brief discussion in a WG meeting shared with OCF earlier this year. However, the namespacing of KIDs is a difficult matter[1] and moreover little understood so far. I'm unaware of any document describing how the association between a device and an AS comes to be, let alone how the device indicates to the AS which shard of its recipient IDs it may use. (And is that a prefix or a suffix to the KID? Is it by bits or by bytes?) Having multiple AS involved with a device is a situation we should be prepared for, especially when considering that even in a closed system under single administration, the AS may be distributed for reasons of reliability. Managing those (as well as other sources of OSCORE contexts like LAKE) would be easier if the device didn't have to think through its namespacing, especially given that there might be ad-hoc decisions to be made: A server may be OK with giving out a short recipient ID to a device on the network (where it can use the source IP to pick the right context), but would pick a longer KID for a client ringing in through a proxy that has no information in its source address. At the same, time, getting endpoint chosen KIDs right is a bit harder than it is with AS-provided ones: An scenario that came up in a recent chat with John showed that if RS and C would happen to both pick the same KID and a MITM modifies the token POST, both would derive identical security contexts. Then, it suddenly becomes crucial for the security of the whole construct that the RS first verifies a request coming from C before sending any message whatsoever with that context. So to summarize, I like the idea, and I'd like to see it thought through (preferably before we even have to work out how that namespacing is manged precisely), but I'm not sure that that all the questions that'd come up in the process are realistic to address at this stage. KR Christian [1]: See https://tools.ietf.org/html/draft-amsuess-lwig-oscore-00#section-4 for a poem and some notes -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] 4.01 Get A Token From There, discovery-/form-driven applications and tokens opaque to the client
Hello ACE, piecing together parts of the big picture of Resource Directory, CoRAL forms and ACE, I was wondering where in the whole story the client should tie its intention to the key material it uses to authorize an action. Take this -- admittedly contrived, but hopefully illustrative example: * We have a device (C) inside example.com that coordinates a lot of actions (and thus has a good standing with the AS and gets almost all the tokens it asks for. * The device would ike to register its management interface with the RD. * A malicious attacker intercepts the discovery process, and tells C that there is an RD at `;rt=core.rd` (which is a perfectly legitimate service we're running there for commercial purposes; its interface is that you submit POST a link there in link-format, and then it ties up the link target with endless requests). * The device tries to register to the local RD by POSTing some data there, but as it has no token to the attack server, it receives a 4.01 Unauthorized Get your token from coap://as.example.com, scope launch-attack, audience attack.example.com * The client takes those pieces to the AS, which grants it a token (after all, C would be authorized to launch an attack, given it's known to be a coordinator -- it just doesn't mean to). * C sends the token to the RS attack, and sends its POST again, with th link to its own management interface. * The attack server brings C to a grinding halt, because it was tricked to shoot its own foot. (Admittedly it's good practice for foot- and other guns to not just silently ignore query parameters like ep=the-coordinator<=3600, but A) other interfaces may be more accidentally-compatible, and B) CoRAL forms would widen the range of craftable requests enormously). My question here is: Where did this go wrong? Should C have verified with attack.example.com that it really has the resource type core.rd? Should it have understood the scope of the action? Should it have a different security association with the AS for every action it asks tokens for? And does the answer still hold if it has already obtained a token to launch attacks (but just didn't notice that the RD it was sent to happens to have the very URI its attack forces use)? Kind regards Christian -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Call for adoption draft-tiloca-ace-oscore-gm-admin (with some review items)
Hello ACE, I've read through draft-tiloca-ace-oscore-gm-admin. Its value is in that it fixes a gap in the set of current drafts on the topic: Without (something like) this, group deployment applications need application specific group managers, and as the GM is not trivial to implement, I'd expect that they would bundle the GM with their on-at-deployment-time tools rather than ship a constrained and well-specified always-on GM that's just managed by their deployment tools -- leading to much more error prone deployments that can't leverage OSCORE group communication in full. I don't quite see myself in a position to advocate adoption in this WG I haven't actively contributed to before, but I do support this document being processed somewhere in the IETF. Best regards Christian PS: Small by-catch issues for the authors: The pct-encoded names in the group name sound odd to me. What do those names have to do with URI components? The "is fixed" and "is a default name" terminology around resources is probably confusing to people who don't know ahead of time what it's supposed to mean; moreover, demanding that the URI be fixed is a pretty harsh requirement for something that may move around in the network; furthermore, while an I-D should avoid creating URI aliasing, it shouldn't rule out that the server may do that either. (And if it supports different transports, right now it needs to). Later in 2.5.3, it even sounds like the path is prescribed. Other than this being an ACE document, is there a particular reason "Getting Access to the Group Manager" is prescribed to use ACE? The whole 2.1 section sounds quite repetitive when read in the context of ACE, and unnecessary when different methods are employed. Maybe if there were talk about different admins and whether they may change each other's groups that'd be conveniently be expressed in terms of ACE scopes (not sure), but as of now it isn't. Why is "Update a Group Configuration" a PUT and not a PATCH? It does not replace the resource, it just modifies it. -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
