Re: [Ace] Proposed document: draft-amsuess-t2trg-raytime-01
Christian Amsüss wrote:
> Hello T2TRG (because of its researchy character), hello ACE (because
> this is applied to your ecosystem),
I don't think this belongs in t2trg, but I don't object.
maybe it goes into ACE or IOTOPS.
> 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.
I like your document.
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!
You are just advancing the raytime based upon verified information from the
AS. I definitely like that.
{There is a Doctor Who and/or Blakes Seven and/or Stargate plot here though.}
> 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.
I opened an issue in your gitlab.
--
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
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] 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
[Ace] LAKE @ IETF 117: Draft Agenda
Hi all, As you could notice from the IETF 117 agenda, LAKE will be meeting on Monday, 24 July 2023 at 16:30 UTC. We will be sharing a 2-hour slot with ACE in the following format: - LAKE session will take place during the first hour, 16:30-17:30 UTC - ACE session will take place during the second hour, 17:30-18:30 UTC We have just published a draft agenda for the LAKE meeting at IETF 117 [1]. We have 10 minutes of flex time at the end so if you would like to raise a topic, please reach out to lake-cha...@ietf.org. Mališa, on behalf of LAKE chairs [1] https://datatracker.ietf.org/doc/agenda-117-lake/ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
