Re: [Ace] Proposing document draft-amsuess-ace-brski-ace-00
Christian =?iso-8859-1?Q?Ams=FCss?= wrote: > On Thu, Jul 20, 2023 at 02:35:09PM -0400, Michael Richardson wrote: >> So draft-ietf-anima-constrained-voucher, has some optimizations that >> can sometimes let the pledge skip the /crts, but why is that >> interaction so expensive? Note that in lake-authz, the voucher isn't >> actually sent, rather just the signature on what we expected to see in >> the voucher so extensions to the voucher would be difficult to do. > My impression was that this was not just an optimization that saves an > initial request, but that the voucher (in all its augmentation that it > gets when the registrar turns the PVR into an RVR) could serve as the > one way the credentials are provisioned through. Packing everything There are some things which quite reasonably could go into the PVR/RVR+voucher. One example is remote attestation: the pledge is the Attester, the Registrar is the RP, and the MASA is the Verifier. This makes sense because the manufacturer has all the golden values (the endorsements). > So in a sketch, we'd do just as in authz+CoJP, and in the msg_3 request > (or even a later regular OSCORE request if we use CoJP too) ask the > registrar for the relevant AS data. Yes. > I'll try to estavblish that as a new baseline. (Not sure yet whether > that'd better be a -01, or an ace-est-ace as it's not really depending > on BRSKI any more). An upside of that scenario is that it has a Agreed: it's not BRSKI, just ... start with a secure channel. > In such a scenario I'd only come back to PRM if there's good reason to > actually do PRM (i.e. there are stairs, not just because it looks > suitable), or when that rollover is AS initialized. PRM has some innovation that allows the CSR to be created at the same time as the voucher, and then some cross-checking. > That handover gets me thinking: In authz-for-CoJP, the authenticator > plays the role of the JRC (I figure it'll play reverse proxy for the > actual one). Does that mean that the authenticator needs to stay around > (and keep its EDHOC created OSCORE session / roll it over as described > in CoJP), or can it ever hand the device off to a JRC directly? If the OSCORE session can be moved, then I think yes, it could hand it off. In particular on 802.15.4 (6tisch/CoJP) networks, then network rekeys have to be handled carefully, and can take some time to get done. > That was supposed to be an either-or; I don't suppose I'd have a device > that takes both. (Should actually have been cert/AS data). But having > the registar serve both JRC data and AS details sounds realistic to me. Ah, yes. Agreed. The registrar has to cope with it all. >> pick a "morning" in gather.town. I'm also remote. Maybe Wednesday >> before ANIMA. > Wednesday before at gather.town sounds great, looking forward to it! Table "A" for Anima. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide 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
On Thu, Jul 20, 2023 at 02:35:09PM -0400, Michael Richardson wrote:
> So draft-ietf-anima-constrained-voucher, has some optimizations that can
> sometimes let the pledge skip the /crts, but why is that interaction so
> expensive?
> Note that in lake-authz, the voucher isn't actually sent, rather just the
> signature on what we expected to see in the voucher so extensions to the
> voucher would be difficult to do.
My impression was that this was not just an optimization that saves an
initial request, but that the voucher (in all its augmentation that it
gets when the registrar turns the PVR into an RVR) could serve as the
one way the credentials are provisioned through. Packing everything into
the voucher was not motivated by saving round-trips, but by reducing
code paths.
> So if I understand you, you'd like to avoid additional round trips by
> stacking the certificate request with the PVR. BRSKI-PRM does *exactly*
> that, because in the store-and-forward ("DTN") nature of PRM, round trips
> involve people walking up/down stairs.
I think a good next direction would be to skip the "stuffing things
into the voucher" part and instead focus on just doing the /cert /
/s(r)en equivalent of certificate based authentication.
So in a sketch, we'd do just as in authz+CoJP, and in the msg_3 request
(or even a later regular OSCORE request if we use CoJP too) ask the
registrar for the relevant AS data.
I'll try to estavblish that as a new baseline. (Not sure yet whether
that'd better be a -01, or an ace-est-ace as it's not really depending
on BRSKI any more). An upside of that scenario is that it has a
relatively straightforward story for rollover of the AS keys
(corresponding to the rollover of CA keys in EST where the device can
query for the newest values).
In such a scenario I'd only come back to PRM if there's good reason to
actually do PRM (i.e. there are stairs, not just because it looks
suitable), or when that rollover is AS initialized.
That handover gets me thinking: In authz-for-CoJP, the authenticator
plays the role of the JRC (I figure it'll play reverse proxy for the
actual one). Does that mean that the authenticator needs to stay around
(and keep its EDHOC created OSCORE session / roll it over as described
in CoJP), or can it ever hand the device off to a JRC directly?
> > 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.
>
> Why would you need a DTLS context?
That was supposed to be an either-or; I don't suppose I'd have a device
that takes both. (Should actually have been cert/AS data). But having
the registar serve both JRC data and AS details sounds realistic to me.
> pick a "morning" in gather.town.
> I'm also remote. Maybe Wednesday before ANIMA.
Wednesday before at gather.town sounds great, looking forward to it!
Thx
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
Christian Amsüss wrote:
> 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.
All I'm saying is that it's an objection/diversion of thought essentially
mid-sentence.
I'm not saying to remove it, I'm saying that is seriously distracts the reader.
> [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.
Good.
> 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).
Basically what I get from OPSAWG's publication of YANG modules is that they
go into a new RFC, with *JUST* the YANG module and when we need to revise the
YANG in anyway, a new RFC is published.
For instance https://datatracker.ietf.org/doc/rfc9418/ and RFC9417.
>> 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.
So draft-ietf-anima-constrained-voucher, has some optimizations that can
sometimes let the pledge skip the /crts, but why is that interaction so
expensive?
Note that in lake-authz, the voucher isn't actually sent, rather just the
signature on what we expected to see in the voucher so extensions to the
voucher would be difficult to do.
> 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?
So if I understand you, you'd like to avoid additional round trips by
stacking the certificate request with the PVR. BRSKI-PRM does *exactly*
that, because in the store-and-forward ("DTN") nature of PRM, round trips
involve people walking up/down stairs.
In PRM we assume HTTP(S), and TCP and networks without much in the way of
challenge. So transfering a few tens of kilobytes shouldn't be a concern,
and of course it will take multiple TCP segments.
In a challenged network I don't understand making any step of the transaction
bigger than 1200, or even close to that, rather than just doing a second
transaction. Block mode seems less reliable from a state machine point of
view than a second transaction.
> 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?
Yes, in general, that's the case.
https://www.sandelman.ca/SSW/talks/brski/brski-animation.pdf
slide 117. Screencasts linked from https://brski.org/brski-impls.html
> 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 --
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] Proposing document draft-amsuess-ace-brski-ace-00
Hi Christian, I'm excited by your document.
First some editorial suggestions. 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.
"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?
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.
My repo of examples is at: https://github.com/mcr/yang-augment-test
I can chase down the ML posts about this if it helpful.
--- on to your problem.
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.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
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
