Re: [Anima] [media-types] Thoughts on suffixes, single and multiple
Mark Nottingham wrote:
>> On 5 Apr 2024, at 07:21, Michael Richardson
>> wrote:
>>
>> We in ANIMA have been struggling because we have an artifact, a
>> voucher (YANG defined in RFC8366, being revised/extended in 8366bis),
>> which can be in two major formats: JSON and CBOR (in theory, XML too),
>> but can be signed by three formats (CMS, JWS, COSE).
>>
>> That gives us three major variations today: 1)
>> application/voucher-cms+json aka voucher+json+cms? 2)
>> application/voucher+cose or? voucher+cbor+cose? 3)
>> application/voucher-jwt+json aka voucher+json+jwt?
>>
>> (because CMS signing CBOR seems dumb, as does mixing {JSON,CBOR} X
>> {JWS,COSE})
> It would be very helpful if you could give us insight into why it's
> important to surface the signature format (CMS, JWS, COSE) in the media
> type **in a manner that's apparent to consumers who don't understand
> the semantics of the specific media type**. If it only needs to be
> apparent to the application-specific software processing the voucher,
> you could easily use application/voucher-cms+json -- and you may even
> be able to use application/voucher+json if the format is capable of
> distinguishing between signature formats internally.
I don't think that it matters to surface the signature format at all for
normal usage of vouchers in BRSKI. The media types are just blobs.
(And on CoAP, they are Content-Formats, which are a single integer)
The utility to the community is that if a dissector (debug tool) can see it's
a signature, then it can, even without verifying the signature, dig down into
the payload to show a developer what's what. It seems reasonable to common
tools will evolve to decode JWS and COSE, but not necessarily know what a
voucher is.
Or maybe I should reverse this: in order for common tools to evolve, we need
clear signals about the encoding of the signature blob.
> Your question also highlights the confusion and a problem around
> suffixes. If you use application/voucher+json+cms, it means that
> generic software that expects to see +json as the last component of the
> media type suffix (for an example, a web browser that can display
> "pretty" JSON, which at this point is theoretical, but it's the best
> example we have for suffixes) will not recognise it. However, if you
> use application/voucher+cms+json, generic software that expects +cms to
> be the final suffix won't function correction.
Yes, that does summarize things.
I think that application/voucher-cms+json in RFC8366 was in the wrong.
It should have been application/voucher-json+cms
(and then application/voucher-json+jws )
>> Also, +gzip makes it pretty clear you can maybe do something with it,
>> if you just know how to decompress.
> But what does it imply? For example, if I see application/foo+xml+gzip,
> can I assume that application/foo+xml is also registered, and that
> decompressing will result in something that conforms to it? If so, that
> gets us back into the processing model mess that's bedevilled the WG
> for a long time.
Yes, I think that foo+xml should also have be registered.
It might be that application/foo is nonsense though.
>> So, +jwt and +cose says, "this is a signed object, and if you look in
>> the payload slot, you might find something you might know how to
>> decode" (or not)
>>
>> But, for many formats they only appear in a signed form in the wild,
>> so maybe this just doesn't matter.
> To ask the questions above in a slightly different way: To whom are
> +jwt and +cose speaking to here, other than the code handling the
> specific media type?
To my format capable decoder/pretty-printer. For JSON and XML, which are
fundamentally text, thinking of that as my editor is reasonable. For CMS
(ASN.1),
COSE, CBOR and other binary encodings, then it's not text, but there might be
a text-like content within.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [media-types] Fwd: Thoughts on suffixes, single and multiple
Michael Jones wrote: > Michael R., you wrote: >> 1) application/voucher-cms+json aka voucher+json+cms? > I don't think these make sense since CMS is X.509 - not JSON. You > could reasonably use application/voucher-cms or > application/voucher+cms. CMS signed JSON is in RFC8366. It's useful to people who have a CMS library that has gone through FIPS, but not a JWS or COSE library. This was more important in 2016 when the spec ws written. >> 2) application/voucher+cose or? voucher+cbor+cose? > application/voucher+cose would make sense. I don't think the +cbor > adds anything useful here. I agree, I don't think it adds anything. >> 3) application/voucher-jwt+json aka voucher+json+jwt? > Neither of the above make sense. JWTs are sequences of > base64url-encoded characters separated by periods. They are not JSON. Neither is image/svg+xml+gzip actually XML, until you decode the GZIP. > application/voucher+jwt would make sense. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Fwd: [media-types] Thoughts on suffixes, single and multiple
original, entire thread, for ANIMA people:
https://mailarchive.ietf.org/arch/msg/media-types/iWc8TLcWOyO0jyqeiuF9VCZClIs/
mnot> After the meeting in Brisbane, some of us went aside to continue to
mnot> the multiple suffixes discussion. There, we quickly came to the
mnot> conclusion that we should deprecate the concept of suffixes in
mnot> media subtypes -- i.e., they would still be syntactically allowed,
mnot> but would have no meaning or registry. Martin Thomson and I took an
mnot> action to write something down about this.
uhm. okay.
We in ANIMA have been struggling because we have an artifact, a voucher
(YANG defined in RFC8366, being revised/extended in 8366bis), which can be in
two major formats: JSON and CBOR (in theory, XML too), but can be signed by
three formats (CMS, JWS, COSE).
That gives us three major variations today:
1) application/voucher-cms+json aka voucher+json+cms?
2) application/voucher+cose or? voucher+cbor+cose?
3) application/voucher-jwt+json aka voucher+json+jwt?
(because CMS signing CBOR seems dumb, as does mixing {JSON,CBOR} X {JWS,COSE})
We didn't know if we should resort to multiple suffixes or not, and the lack
of apparent progress on this has been a pain. So, thank you for the decision
as it takes the options off the table, I guess, even if I'm bit surprised by
it.
mnot> The widespread use of +xml and +json in particular made me more
mnot> cautious about deprecating suffixes altogether -- especially since
mnot> we still sort-of believe that they are indeed used by (or at least
mnot> potentially useful to) things like editors to hint syntactic
mnot> conventions.
Also, +gzip makes it pretty clear you can maybe do something with it, if you
just know how to decompress.
mnot> 1) Disallow more than one "+" sign in media subtypes, as floated at
mnot> the meeting. This would put a fair amount of pressure on the
mnot> registry's ability to reflect reality, depending on how widely
mnot> deployed some things get (although we could grandfather some types
mnot> in to ease the pressure here).
I suggest keeping +gzip and +xml.
mnot> 2) Syntactically allow suffixes before the last one, but not assign
mnot> them any meaning or register them; e.g., application/foo+bar+xml
mnot> would be an XML format, but who knows what bar is; effectively,
mnot> it's just part of "foo+bar". This would allow people to define
mnot> suffix-like things, but wouldn't give them any recognition or
mnot> coordination -- potentially leading to the need to formalise things
mnot> more down the road, just as we did in the first round of suffixes.
It doesn't seem any different than foo-bar+xml to me.
mnot> 3) Consider multiple suffixes, when they occur, to be unrelated
mnot> hints as to the syntax of the format -- i.e., there is no
mnot> processing model, there is no ordering (although a registrant would
mnot> have to choose an order; registrations with different orderings
mnot> should be refused). Effectively, suffixes would just be a 'bag of
mnot> hints' about the format being used.
Not that useful, but I could live with it.
mnot> ### Defining What Suffixes Are For (no matter how many there are)
mnot> After the discussion in Brisbane, I strongly believe that suffixes
mnot> should ONLY be for hinting about the syntax or format convention in
mnot> use, as an aid eg to editors, syntax highlighters, etc. This is the
mnot> proven use case for media type suffixes. Suffixes should not be
mnot> used to hint semantics; only syntax. We should have strong language
mnot> about the dangers of using suffixes to hint particular kinds of
mnot> processing; cf the previous discussion on the 'polyglot problem'
mnot> and the potential security issues around performing processing
mnot> based upon suffixes.
Well, it also helps forensics and dissectors; but I accept that in essence,
those are just specialized kinds of "editors"
mnot> The suffix registration process should be designed to assure that
mnot> only such suffixes are registered.
mnot> Note that in this view, "+ld" is very likely unregistrable.
!
mnot> ### Cleaning Up Existing Suffixes
mnot> +gzip and +zstd are problematic; the former should be disallowed
mnot> for new registrations, and the latter should be removed or
mnot> obsoleted in the registry. Likewise, I am highly suspicious of +jwt
mnot> and +cose. +zip _is_ a format convention, so I suppose it's OK?
So, +jwt and +cose says, "this is a signed object, and if you look in the
payload slot, you might find something you might know how to decode" (or not)
But, for many formats they only appear in a signed form in the wild, s
Re: [Anima] RFC 8995, Voucher Signing, MASA Certificate Chain provisioning
William Atwood wrote: > Given that I see no IETF meeting scheduled for Paris, what did you > intend by "Paris Hackathon"? INRIA is hosting a IoT / LAKE hackathon in May. Some BRSKI people are going as well. https://mailarchive.ietf.org/arch/msg/ace/sCqopwlWA3sHHOibvigq2rY4ImU/ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] RFC 8995, Voucher Signing, MASA Certificate Chain provisioning
Esko Dijk wrote: > The requirement for the Pledge in RFC 8995 is (5.6.1): The pledge MUST > verify the voucher signature using the manufacturer-installed trust > anchor(s) associated with the manufacturer's MASA > This leaves quite some vendor flexibility I think on how exactly to > verify: against 1 public key, against multiple public keys, against a > chain baked into the device, against a single root CA cert, against a > single root CA cert taken from the chain baked into the device, etc > etc. Thank you for expounding on the variations. We have the advantage that pledges are controlled by manufacturers and they can decide how simple or complex they want to make their process. The gotcha is registrars that want to verify the resulting voucher. It's not entirely required by RFC8995, but maybe enouraged. So I'd love to collect more of this kind of consideration in the masa-considerations or the registrar-considerations. >> I would propose to also allow the submission of the certificate chain >> of the MASA signing certificate in the SignedData part of the CMS >> container of the voucher. > I expect this is already allowed by RFC 8995, given the text in 11.6: Yes, it's not just allowed, but I would say, encouraged. The question is how do we do it on a constrained voucher. The cbrski document says some things already about this. > There are good cryptographic hygiene reasons why a manufacturer would > not want to maintain access to a private key for many decades. A > manufacturer in that situation can leverage a long-term CA anchor, > built-in to the pledge, and then a certificate chain may be > incorporated using the normal CMS certificate set. This may increase > the size of the voucher artifacts, but that is not a significant issue > in non-constrained > environments.¶<https://datatracker.ietf.org/doc/html/rfc8995#section-11.6-3> > So this effectively says a vendor may want to not use the "simplest > solution" for security reasons, and include a cert chain of the signer. I think that we have not done enough interoperability testing lately. Particularly between Registrar and MASA. I'd like to change this, and I'm thinking that the Paris hackathon might be a good target date. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] ANIMA@IETF119 - call for agenda items
I will need to update the WG on RFC8366bis (which I will repost today!) and the plan to finish this work. I will need 7 minutes. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Errata 6642: Re: Registrar to MASA connections: SNI required
Esko Dijk wrote: > Small addendum: Even if RFC 6066 would allow IP literals in a SNI > (which it doesn't), then it still could not be used by a Pledge. Reason > is that a Pledge would discover only the IP literal of a Proxy and not > the one of the Registrar. So the Registrar would receive SNI with an > incorrect IP address in it in that hypothetical case. So it wouldn't > work anyway. Complete agreement. I don't know if client libraries are smart enough to omit SNI when the connection is to an IP address, or if they just include the string expression of the IP address. As you say, it won't work, so the Registrar, being defensive, needs to just ignore any SNI. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Errata 6642: Re: Registrar to MASA connections: SNI required
I have opened to pull requests in github against the text that was there.
The goal is not to merge this, it's an RFC already, but rather to permit
github to be used for wordsmithing efforts.
https://www.rfc-editor.org/errata/eid6648
https://github.com/anima-wg/anima-bootstrap/pull/151/files
Pledge->Registrar:
Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is
REQUIRED on the pledge side. TLS 1.3 (or newer) SHOULD be available
on the registrar server interface, and the registrar client
interface, but TLS 1.2 MAY be used. When TLS 1.3 is used the use of
Server Name Indicator (SNI, [RFC6066]) is not required, per RFC8446
section 9.2, this specification is an application profile specification.
A pledge connects to the Registrar using only an IP address and it will
not have any idea of a correct SNI value.
This also implies that the Registrar interface may not be virtual \
hosted using SNI.
{I have no problem with changing "not required" in 6648 to say, "is ignored
by Registrar upon receipt", as brski-cloud requires the pledge to include the
SNI}
{note that the errata says it is to section 5.4, but it's to section 5.1!}
https://www.rfc-editor.org/errata/eid6642
https://github.com/anima-wg/anima-bootstrap/pull/150/files
Registrar->MASA:
TLS 1.2 [RFC5246] with SNI support [RFC6066] is REQUIRED if
TLS 1.3 is not available.
The Server Name Indicator (SNI) is required when the Registrar
communicates with the MASA in order for the MASA to be hosted in
a modern multi-tenant TLS infrastructure.
This way, you can use the github "Suggest" text.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] RFC8994's IPsec tunnel description
{clearing out inbox}
Toerless Eckert wrote:
>> I know that we did many rounds to get this right, but I feel that
>> maybe we did it wrong.
>>
>> The goal are packets that look like:
>>
>> (a) IPv6-LL ESP[nh=41] IPv6-ULA[1] ULP
> What is "ULP" ?
If I didn't answer somewhere, it's "Upper Layer Protocol" (e.g., "TCP")
>> The TS are "everything", so one in fact needs policy based routing on
>> top of this in order to make anything work.
> What you want to have is some form of virtual IPsec interface, which in
> Cisco IOS was introduced in 2007, e.g.:
Yes, the kicker is how packets from that interface are fit into the PAD/SPD.
Ideally, they skip the PAD entirely, and have a (pair of) linked SPD (IPsec
SA) entries. One for outgoing. And the incoming one is linked so that
anything coming out appears to come out the Interface. There should be no
enforcement of Traffic Selectors (TS). I think Cisco got this right all
those years ago.
> In Linux this is less clear to me. There where much later IPsec VTI
> interfaces, but they seemed to have some limitations.
The VTI and XFRM Tunnel interfaces are seemingly identical in most ways,
except that VTI is created/managed by ioctl (which are a pain from languages
other than C), while XFRM Tunnel ocurrs via the NETLINK socket.
The problem that I see is that the packets still seems to go through the
PAD, when it really shouldn't.
> Given how ACP is designed to support different secure channel option,
> worst case we have to amend our stack with one more IPsec option, if
> thats what's easier in Linux. But it would be quite annoying if Linux
> choose a different stack option than what commercial routers had for a
> decade.
Agreed.
> If on the other hand we made a mistake and didn't match what the
> commercial router implementations use, then of course, we can obsolete
> our currently documented option and replace it. But i don't think/hope
> that that is the case.
WHen someone shows up with hardware that can't be used, we should have this
discussion.
I will attempt to put together some slides for 119 that address the ULA
addressing on the ACP DULL side that I am attempting to implement.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Errata 6642: Re: Registrar to MASA connections: SNI required
Toerless Eckert wrote: >> I'm fine with this. But, since it's hold for document update, we >> don't have to wordsmith it now, as long as we get across the right >> idea in the patch. > Well, my understanding is that Rob simply wants a replacement text for > the Errata that we both agree on so he can update the Errata with it. All of the text you have proposed is fine with me in the end. Short of it: all parties always send SNI. (Registrar must often ignore SNI upon receipt) -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Errata 6642: Re: Registrar to MASA connections: SNI required
Toerless Eckert wrote: >> agile. But SNI is one such >> example, where the pledge does need to >> signal the right info (SNI) >> to enable "cheaper" cloud registrars, aka: >> those not owning a >> separate IPv4 address. See e.g.: AWS cost for IPv4 > address. On Mon, Feb 12, 2024 at 09:01:50AM -0500, Michael Richardson wrote: >> Right, but it's self-righting. A manufacturer that uses an SNI-only >> cloud registrar and does not do SNI will fail immediately: they won't >> get out of the lab. And the manufacturer controls both initial sides >> of this. tte> Just to double check: in this thread we're only talking registrar to tte> MASA (no pledges). The text I quote from you above, says, "pledge" > Then the biggest risk is when there are a lot of Registrar instances > out in the field and the company wants to make the MASA service cheaper > by putting it into some cloud service data center from a third party, > and only then wake up and see that that cloud data center (opposed to > the vendors original own data center) does require SNI. So now, the > vendor needs to update all Registrars in the field. I really think you are overthinking this. SNI is mandatory to send. > Aka: IMHO serious enough that it justifies the one sentence we can > write upfront to avoid this. So maybe it goes here: https://www.ietf.org/archive/id/draft-richardson-anima-registrar-considerations-08.html#name-masa-client-northbound-inte > 1. the way you wrote it, you replace the whole two sentences, aka: you > remove: >Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is > REQUIRED. TLS 1.3 (or newer) SHOULD be available. >I am sure you wanted your text to be ADDED after those two > sentences. > 2. "TLS 1.2 [RFC5246] with SNI support [RFC6066] is REQUIRED if TLS 1.3 > is not available." It seems to me ethat it says that same thing. >This does not say that Registrars must send SNI/"server-name". It > just means the TLS stack on registrars/MASA needs to be able to support > SNI. And i am a fourth degree burn victim of text like this. Many > customers who could not deploy multicast appropritely because they > believed vendor text "device supports IGMPv3" was sufficient, when > instead what was required was: "(IPTV) application MUST use SSM > signalling via IGMPv3". (see also the TLS 1.3 text related to this > "server-name" support vs. application support). I'm sorry that you were burnt, but that doesn't mean you have to wear a fireman's suit everywhere. If you want it to say, "Clients must send SNI.", I'm okay with that. In general, it's rather hard to turn SNI off with most libraries. >Append to the section 5.4 text from above the following: >When the MASA is known to the registrar by its domain name, the > registrar MUST send the domain name of the MASA in the TLS "Server Name > Indicator" (SNI) option (also called "server-name") [RFC6066] whether > TLS 1.2 [RFC5246] or TLS 1.3 [RFC8446] is used. >SNI is required when the Registrar communicates with the MASA in > order for the MASA to be hosted in a modern multi-tenant TLS > infrastructure where it shares its IP/IPv6 address with other HTTPS > services. I'm fine with this. But, since it's hold for document update, we don't have to wordsmith it now, as long as we get across the right idea in the patch. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Errata 6642: Re: Registrar to MASA connections: SNI required
Toerless Eckert wrote: > agile. But SNI is one such example, where the pledge does need to > signal the right info (SNI) to enable "cheaper" cloud registrars, aka: > those not owning a separate IPv4 address. See e.g.: AWS cost for IPv4 > address. Right, but it's self-righting. A manufacturer that uses an SNI-only cloud registrar and does not do SNI will fail immediately: they won't get out of the lab. And the manufacturer controls both initial sides of this. Where we could go into trouble is when there are 307 redirects. > Lets just agree on the final text for this errata so Rob can close the > book on it. Pledges MUST include SNI for 1.2 and 1.3. (Registrar's with provisional-TLS connections MUST ignore the SNI: they can not be virtual-hosted) If you didn't like my errata text, then let's come back to that. (I wish errata was on gitlab) https://www.rfc-editor.org/errata/eid6642 says: Held for Document Update by: Rob Wilton Date Held: 2024-01-15 so we get another chance to fix the text when we do a document update. Does the text that is there upset you? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Shepherd review pls: Re: I-D Action: draft-ietf-anima-grasp-distribution-10.txt
Hi, I have updated the Shepherd review of anima-grasp-distribution.
Section 5.2.1 is much improved, thank you.
1) The DT still does not give the intended status for the draft
("Experimental"). The document has the correct status.
2) The document should say it Updates (Extends) RFC8990.
I have updated the write-up.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Adoption call on draft-eckert-anima-brski-discovery-01 by 2024/2/23rd
Sheng JIANG wrote: > This email starts a two-week adoption call on > draft-eckert-anima-brski-discovery-01. It ends by 2024/2/23rd. Yes, we need this document to complement the other mentioned documents and avoid repeating ourseles. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Errata 6642: Re: Registrar to MASA connections: SNI required
Toerless Eckert wrote: > Lets maybe finalize next tuesday during our meeting. > In general i think that whenever a TLS initiator did learn the TLS > responder through a URL with a domain name, then it needs to insert the > domain name as the SNI "server_name". > If thats not an unwritten rule, then i'd like to understand why not. I think it is. I'm not objecting to that. As you said, sometimes old/rusty TLS libraries don't do this. But, the manufacturer knows that, and this can build their MASA based upon SNI (or not) assumption, and it's fine. But, for BRSKI-EST link, we can assume enough modern TLS to allow for SNI based virtual hosting. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] MichaelR/Rob/*: RFC8995 errata concerns
Toerless Eckert wrote: > Maybe we are perceiving different issues. maybe. > The issue i am talking about is that Registrars (Cloud or Owner) and > MASA may be installed in cloud environment where the SNI "server_name" > extension in the ClientHello is necessary for the Registrar/MASA to be While a Cloud-Registrar is addressed by name, and so SNI can be used for multi-tenant hosting rather than a unique port/IP, the Owner Registrar can *NOT* do that. If a (full) Registrar is installed into a system that requires SNI, then it won't work. IPv6 addresses are really cheap, and one can even use ULA inside of an Enterprise, or inside the ACP. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Errata 6642: Re: Registrar to MASA connections: SNI required
Toerless Eckert wrote: > I think it should say: > Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED. > TLS 1.3 (or newer) SHOULD be available. Registrars MUST and MASA > SHOULD support the "server_name" extension as specified in > [RFC6066]. This is also called the Server Name Indicator > (SNI). The Registrar does not need to support SNI on it's BRSKI-EST connection. In fact, it MUST ignore any SNI that it receives. The pledge can never get it correct, so we have to do port/IP address hosting only. So I disagree with your text: it requires too much, and actually the wrong thing for the Registrar. > Registrars MUST send a valid "server_name" extension when > connecting to a MASA. Sure. > - The text "REQUIRED if not TLS 1.3" is confusing because TLS 1.3 does > actually require SNI support by the TLS stack. So the proposed text > could be read as contradicting TLS 1.3. Therefore suggested rewrite > does not mention TLS versions. uhm. okay. I don't think that this is confusing. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] MichaelR/Rob/*: RFC8995 errata concerns
Toerless Eckert wrote: > I am not sure what to do about this in general, but i think the really > important issue is that we ask for support of SNI in BRSKI cloud to > support actual cloud deployment (with shared IP address) of registrars, > when pledges only have TLS 1.2 - because RFC8995 did not require it. > So, i did open: https://github.com/anima-wg/brski-cloud/issues/134 I replied. There is no SNI issue. We actually thought it all through, and that errata was the result. There is a potential issue in 3.3.1 that reading the issue made me think about. But, it's not an SNI issue. It's a Implicit Trust Anchor or not issue. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] WG status of draft-ietf-anima-rfc8366bis
Rob Wilton (rwilton) wrote: > I wanted to check the WG status of this document. > draft-ietf-anima-jws-voucher-09 has been put on the publication > requested queue but seems to have a fairly strong dependency on > draft-ietf-anima-rfc8366bis, and hence I am wondering whether it > doesn’t make more sense to wait for draft-ietf-anima-rfc8366bis to also > be in the Pub Req queue before progressing them both together? You are right. As do all the other documents in WGLC! There are some editorial reviews with many outstanding issues (24). It's on me to finish this, and I seem to be developing the cycles to do that. We did somewhat intentionally leave this document open in the event that WGLC on other documents would reveal text that ought to have been in rfc8366bis. So, you are completely correct that we have to get them all done. We knew, a year ago, that it would become a cluster of dependancy cycles. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] AD review of draft-ietf-anima-brski-cloud-08
Thank you Rob. I've made three new issues in github for your three levels of comments, and the authors will attempt to finish this up by week of Jan.31ish. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] MichaelR/Rob/*: RFC8995 errata concerns
Rob Wilton \(rwilton\) wrote: > Was there any conclusion of what to do here, which I think applies to > errata 6648: https://www.rfc-editor.org/errata_search.php?eid=6648 > I don't think that this is an errata that can be verified, hence I'm > questioning whether "Held for document update" would be both correct > and helpful. Would it be useful to update the text of the errata at > all, or alternatively, I could just point to this thread in the notes. I wrote that errata based upon some discussion at some point about implementing things, and probably my draft-richardson-anima-registrar-considerations. **The SNI comment is really the Technical update part** I'd like the XML to be patched, so whatever gets that done. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Errata Verified] RFC8994 (7071)
RFC Errata System wrote: > -- > Status: Verified > Type: Editorial ... > Notes > - > David von Oheimb discovered [1] that section 6.2.2 is self-referential and incorrect regarding the section reference to the ASN.1 module. > The correct section number is 6.2.2.1. works for me. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Technical Errata Reported] RFC8995 (7263)
Rob Wilton (rwilton) wrote: > Okay, I can add a clarification to the errata to indicate that RFC 2119 > language is not required for the text to still be normative, and if > this text is updated, the other sections should be updated in a > consistent fashion. If you like. I don't have a strong opinion. Probably we should have used BCP14 language there. > An alternative resolution here is for me to reject the errata, > indicating that the text is still a normative requirement even though > it doesn’t use RFC 2119 language. Specifically, I don’t think that the > existing text is wrong, but consistently using RFC 2119 keywords may > add clarity. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Technical Errata Reported] RFC8995 (7263)
re: https://www.rfc-editor.org/errata/eid7263 I agree that the correct text is: idevid-issuer: The Issuer value from the pledge IDevID certificate MUST BE included to ensure unique interpretation of the serial- number. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [COSE] Intended IANA registration of "+cose" media type suffix / cBRSKI
Esko Dijk wrote: > Each media type that wants to use +cose would need to indicate what > file extension it wants to use. This could be “.cose” or “.cbor” I > think if nothing more specific is wanted. For application/voucher+cose, > it is “.vch”. What about for voucher-request+cose? Did we settle on anything there? I think that I used .vrq, but I don't know if we should standardize that. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] some minor comments on draft-ietf-anima-grasp-distribution-09
1. I have checked the xml into git, and I can send patches ("git send-email")
or git tree or just the final file, as the authors wish.
2. I don't know if moving the use cases to ... improves the document.
3. queries:
section 5.2.1 says:
> The IS module uses a syntax to index
while I think that the word syntax here is probably correct according to a
dictionary, it's probably a much less familiar term to use here.
I'm concerned about step (2) _Storing Mode Mapping_, which suggests DHT, but
doesn't require it. I guess that this is an implementation detail which does
not affect the protocol, but it more explanation of why it does not matter
might be good.
I find step 5 far too hand wavey about how the block is transfered.
At the very very least:
In this case, the IS module should support basic TCP-based
session protocols such as HTTP(s).
this seems like it needs BCP14 language: SHOULD
How do we do HTTP, and if HTTPS is implied, then how do we do certificates
for what are probably IP addresses.
It seems like step 7 is really step 0, and the process ought to just loop?
Almost all of the SHOULDs are probably MUSTs.
section 5.3, it is inaccurate to describe network policy as being in YANG.
YANG is not distributed, but serialized to JSON or XML or CBOR.
I suggest:
There are scenarios where this restriction is a problem. One case
is the distribution of network policy in lengthy YANG formats such as XML
or JSON.
Also at:
A third case might be a supervisory system
downloading a software upgrade to a network node.
is a really good case, and mentioning SUIT Manifests would be a very good
connection.
They fit quite well into 2048 bytes.
https://www.ietf.org/archive/id/draft-ietf-suit-manifest-24.html#name-b-examples
The security considerations seem wrong.
What is the TLS hop by hop security?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
[Anima] Tuesday BRSKI design team meetings
The design team will not meet on Dec.26 or Jan.2. It will resume on Jan. 9 at it's usual time of 11am EST or 1600UTC. There are calendar invites in the WG archives, or you can unicast me for details. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Review draft-ietf-anima-brski-cloud-08
Toerless Eckert wrote: > Wrt. the process: As a reviewer, keeping everything in a single file is > always easier than breaking it up into issues. Especially because the > more you revisit a document, the more you go back and forth and maybe > delete comments or change them. I don't mind it as a single file, although the parts with no comments, maybe could be removed if file size is an issue. > I think i should have created the tags for each review point that would > have allowed to auto-create github issues from them. I remember that > someone in IESG did provide such feedback, but i could not find it > again. WOuld be nice to have a very simple way to find such a preferred > tagging method documented on authors.ietf.org.. That was Lars, and the tool is https://github.com/larseggert/ietf-reviewtool As I said, it didn't work for me last time I tried, but that was many months ago. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Review draft-ietf-anima-brski-cloud-08
shment. The cloud registrar MAY include a 325 > certificate_authorities field in the message to specify the set of 326 > allowed IDevID issuing CAs that pledges may use when establishing 327 > connections with the cloud registrar. > 329 The cloud registrar MAY only allow connections from pledges that > have 330 an IDevID that is signed by one of a specific set of CAs, e.g. > 331 IDevIDs issued by certain manufacturers. > How about we upgrade this ? > To protect itself against DoS attacks, the cloud registrar SHOULD > reject TLS connections when it can determine during TLS authentication > that it can not support the pledge, for example because the plege can > not provide an IDevID signed by a CA recognized/supported by the cloud > registrar. https://github.com/anima-wg/brski-cloud/issues/69 > 334 identity certificates or using Raw Public Key [RFC7250] > certificates. > I think you're mention this because you have a good business case, such > as reduction in manufacturing cost by doing self enrolment or raw > public keys during manufacturing and capturing those into MASA and > manufacturing databases - instead of also having to bother about a > CA. It might be useful to add a paragraph about this benefit, although > it is AFAIK not really BRSKI Cloud specific - but it seems like this > could be even a more common case as peldges with non-self-signed certs. https://github.com/anima-wg/brski-cloud/issues/70 > 339 registrar and has verified the cloud registrar PKI identity, the > s/and has verified the cloud registrar PKI identity,// ?? https://github.com/anima-wg/brski-cloud/issues/71 (I disagree) > 350 * return a suitable 4xx or 5xx error response to the pledge if the > 351 registrar is unwilling or unable to handle the voucher request > call this " * error: " ? https://github.com/anima-wg/brski-cloud/issues/72 -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Voucher RFC8366-bis: support for other types/encodings of certificates?
Esko Dijk wrote: > How would the voucher / voucher-request best support such new > certificate formats/types? Two main approaches are possible: Yeah. So either way we need to do something now in RFC8366-bis to avoid rolling that module again later on. > So with option (2) the existing fields just hold binary data of some > format, by default it's X509/ASN.1 DER. If the "cert-type" field is > present it identifies the format of binary data e.g. X509, C509, etc. > If we do nothing now, we will default to option 1. TBH I'm not even > sure if option 2 is feasible with current YANG definitions and all the > legacy around it. But I still wanted to raise this question, just in > case anyone's interested :-) Are you interested in it? Are you writing code? > PS Also for discovery operations, discovering a Registrar that supports > a particular (deviating) certificate type X may then be needed. This > could be viewed as just a different type of Voucher that needs to be > supported. I was hoping (my head in the sand) you wouldn't bring this up :-) -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] RFC8994's IPsec tunnel description
RFC8994 says: 6.8.3.1. Native IPsec An ACP node that is supporting native IPsec MUST use IPsec in tunnel mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next Header of 41). It MUST use local and peer link-local IPv6 addresses for encapsulation. Manual keying MUST NOT be used, see Section 6.2. Traffic Selectors are: TSi = (0, 0-65535, :: - :::::::) TSr = (0, 0-65535, :: - :::::::) IPsec tunnel mode is required because the ACP will route and/or forward packets received from any other ACP node across the ACP secure channels, and not only its own generated ACP packets. With IPsec transport mode (and no additional encapsulation header in the ESP payload), it would only be possible to send packets originated by the ACP node itself because the IPv6 addresses of the ESP must be the same as that of the outer IPv6 header. I know that we did many rounds to get this right, but I feel that maybe we did it wrong. The goal are packets that look like: (a) IPv6-LL ESP[nh=41] IPv6-ULA[1] ULP Rather than packets that look like: (b) IPv6-LL ESP(nh=41) IPv6-LL[nh=41,4] IPv6-ULA[2] ULP The TS are "everything", so one in fact needs policy based routing on top of this in order to make anything work. What we actually want are transport-mode ESP packets that transport IPIP packets between ACP nodes. It looks identical to (a) on the wire, but it's wired into the network stack slightly differently. Why didn't we say this? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Review draft-ietf-anima-brski-cloud-08
> Earlier this year, i did a review of draft-ietf-anima-brski-cloud-05: > https://mailarchive.ietf.org/arch/msg/anima/fxFBwoUUUc31eHUcDhdTmWdkFdk I see that email refers to your review, but it is not the review itself. > The acknowledgemeent section of -08 does not mention my name. There is no > changelog in the document explaining whether or not my review was taking > into account. I tried to look through the github closed issues, but > could not figure out I will locate your previous review and work on it, as well as your comments below. > Below, i am not repeating what i wrote for the -05 review, which i think was > often editorial to improve text quality. Instead, i'll try below to raise > mostly functional issues in the core spec. Feel free to also go back to the -05 review > and check if stuff from there is still relevant. okay, thank for this. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [IANA #1287380] [Errata Verified] RFC8995 (7576)
Amanda Baber via RT wrote: > This errata report refers to Section 4.3 of RFC 8995. Section 8.7, > which registers "AN_join_registrar" in the GRASP Objective Names > registry, points readers to Section 4.3. All we have done is fix some grammar in a comment :-) > In the IANA registry, should this errata report be listed as a second > reference for "AN_join_registrar"? I suppose it doesn't hurt. Seciton 8.7 links to section 4.3 already. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-22.txt
Esko Dijk wrote: > Would it be solved by just dropping the claims that we Update / Extend > 8366bis? Instead we can just reference 8366bis and say we add something > to that format. Then we don't need to Update 8366 anymore, because > 8366bis is already doing this for us. Yes, I think so. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Discovery of renewal server / draft-eckert-anima-brski-discovery / draft-ietf-anima-brski-ae / draft-ietf-anima-brski-prim
Esko Dijk wrote: > 3) address of renewal server could be pushed into the device via a > higher-layer communication i.e. the application layer. This "push" > could happen at the moment that the device is requested to re-enroll > itself, in some application-specific way. There's currently no > standard protocol message defined AFAIK to trigger a client to start > the re-enrollment process. It's probably a bug. BRSKI-AE could support a push, and I think that each of OPC UA, and MATTER also support a push operation. CoJP (RFC9031) includes a mechanism to rekey the network that is push. The problem/reason we have no push mechanism is that we (the IETF) don't really have a standard datamodel/interface-to-device, while other SDO verticals do. So adding a new push mechanism is not a big deal. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-22.txt
Esko Dijk wrote: > This update reflects the work that was done earlier (August) to > restructure the content of "cBRSKI". Now the default, simplest flow is > highlighted and optional extras are moved into separate sections: in > particular, the extended discovery now in Section 14. Some content has Thank you for all the work on this document. I think that where it says that it updates RFC8366bis, it probably should just recap what 8366bis says (and that document should say it). I guess that requires further document coordination work. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Discovery of renewal server / draft-eckert-anima-brski-discovery / draft-ietf-anima-brski-ae / draft-ietf-anima-brski-prim
Toerless Eckert wrote: > Please also add your thoughts about this to: > https://github.com/anima-wg/brski-discovery/issues/4 (but discuss here > first). okay. > Question: How do we want to deal with certificate renewal/re-keying ? Stick head in sand, hope universe winds down before 991231 arrives :-) > Do we assume by default that any discovered BRSKI (variation) > proxy/registar is capable to do renewal ? Technically this would not Not sure why you write proxy/registrar. It would be strictly the registrar, and there should be no need for a node (not a pledge anymore) to discover a proxy to renew. I assume that nodes do EST or they do CMP, and likely not both. We put the overhead of supporting all the variations on the Registrar before, and I'm okay with continuing to do that. A node, upon receiving a 404 or 403 or 5xx when trying to renew using a Registrar that it has discovered ought to just move along to another Registrar. There could many reasons for the Registrar to have that renewal method broken, and I think it makes little sense to optimize the CMP vs EST case while leaving the "disk full" (or SSD ran out of spares and went read-only) case broken. > When writing RFC8994, we did consider that not all existing EST servers > would necessarily support BRSKI, and therefore instead of using > AN_join_registrar, renewal was recommend to use SRV.est objective. I'm not entirely sure I agreed with that at the time, but I'm happy with that. SRV.cmp would be fine too. > We > did not define an equvalent proxy objective though, because already > enrolled pledges would not need to use a proxy but could always connect > directly to a registrar. > Do we ever need renewal to go through a proxy ? It's probably wrong. If the node has lost so much network that it's no longer on the ACP (or the IoT network), then it probably should go through onboarding again. It might have moved, or something happened. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] brski-discovery vs constrained BRSKI (was: Re: I-D Action: draft-ietf-anima-constrained-join-proxy-15.txt)
Toerless Eckert wrote: > Check the GRASP text in both drafts, i think the text in > constrained-join-proxy is more harmfull to move forward than the one in > constrained-voucher. So i would definitely like to see it removed, or i > would want to raise concerns about it (which i think we don't need to > spend time on to get the constrained docs out the door): okay. I won't get rfc8366bis to/past WGLC before January-ish, so everything is going to wait for that anyway. If we can sort other things out at the same time, then I'm all for that. I want to say that the first constrained-voucher interop work was in Prague IETF... 2019. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] brski-discovery vs constrained BRSKI (was: Re: I-D Action: draft-ietf-anima-constrained-join-proxy-15.txt / draft-eckert-anima-brski-discovery-01 )
Toerless Eckert wrote: > I don't see a reason why GRASP should not work well on even further > constrained devices. I personally found GRASP way easier to implement in a constrained fashion than mDNS. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] brski-discovery vs constrained BRSKI (was: Re: I-D Action: draft-ietf-anima-constrained-join-proxy-15.txt)
Brian E Carpenter wrote: >> 5.2.2. GRASP discovery >> >> This section is normative for uses with an ANIMA ACP. > So really, is there a natural scenario where constrained-join-proxy is > used in a region of the network where an ANIMA ACP is established? And > on balance, I have to extend the question to > constrained-voucher. Certainly, GRASP was not designed for constrained > nodes. There is no logic in using GRASP discovery for its own sake. Yeah, 1) an ANIMA ACP where there are IoT gateways at the edge. 2) an network where it makes sense to use constrained (COSE/CBOR) vouchers for routers rather JSON based ones. (Whether or not they run over CoAPS or HTTPS) > To me, the conclusion is fairly obvious. Possibly the GRASP work done > in both drafts should be combined into a new draft, if you can describe > a scenario where constrained nodes participate in a full ANIMA ACP. I'm fine with that, but then let's get it done already. Code is waiting. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Editorial Errata Reported] RFC8995 (7576)
Rob Wilton \(rwilton\) wrote: > I've trivially tweaked the spacing and changed a full stop to a comma. WFM. > Does this look right? If so, I will verify this errata. > Section 4.3 says: >objective-value = text ; name of the (list of) supported ; > protocols: "EST-TLS" for RFC 7030. > It should say: >objective-value = text ; name of the supported protocol, ; e.g., > "EST-TLS" for RFC 7030. > Regards, Rob > -Original Message- From: Michael Richardson > Sent: Thursday, November 9, 2023 8:16 AM To: > Rob Wilton (rwilton) ; Rebecca VanRheenen > Cc: Max Pritikin (pritikin) > ; tte+i...@cs.fau.de; > michael.h.behrin...@gmail.com; Kent Watsen ; > anima@ietf.org; RFC Editor Subject: Re: > [Editorial Errata Reported] RFC8995 (7576) > Rebecca VanRheenen wrote: >> We are unable to verify this erratum that the submitter marked as >> editorial. Please note that we have changed the “Type” of the >> following errata report to “Technical”. As Stream Approver, please >> review and set the Status and Type accordingly (see the definitions at >> https://www.rfc-editor.org/errata-definitions/). > I filed this report after some discussion on the list. It fixes a > comment, rather than the underlying CDDL. > So I agree that it's not strictly editorial. >> You may review the report at: >> https://www.rfc-editor.org/errata/eid7576 >> Please see https://www.rfc-editor.org/how-to-verify/ for further >> information on how to verify errata reports. >> Further information on errata can be found at: >> https://www.rfc-editor.org/errata.php. >> Thank you. >> RFC Editor/rv >>> On Jul 26, 2023, at 9:33 AM, RFC Errata System >>> wrote: >>> >>> The following errata report has been submitted for RFC8995, >>> "Bootstrapping Remote Secure Key Infrastructure (BRSKI)". >>> >>> ------ >>> You may review the report below and at: >>> https://www.rfc-editor.org/errata/eid7576 >>> >>> -- >>> Type: Editorial Reported by: Michael Richardson >>> >>> >>> Section: 4.3 >>> >>> Original Text >>> - >>> objective-value = text ; name of the (list of) supported ; protocols: >>> "EST-TLS" for RFC 7030. >>> >>> >>> Corrected Text >>> -- >>> objective-value = text ; name of the supported protocols. ; e.g., >>> "EST-TLS" for RFC 7030. >>> >>> >>> Notes >>> - >>> This objective does not support a list of supported protocols. The >>> comment in the example might lead people to conclude they can do >>> that. >>> >>> Instructions: >>> - >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party can log in >>> to change the status and edit the report, if necessary. >>> >>> -- >>> RFC8995 (draft-ietf-anima-bootstrapping-keyinfra-45) >>> -- >>> Title : Bootstrapping Remote Secure Key Infrastructure (BRSKI) >>> Publication Date : May 2021 Author(s) : M. Pritikin, M. Richardson, >>> T. Eckert, M. Behringer, K. Watsen Category : PROPOSED STANDARD >>> Source : Autonomic Networking Integrated Model and Approach Area : >>> Operations and Management Stream : IETF Verifying Party : IESG >>> > -- > Michael Richardson , Sandelman Software Works -= > IPv6 IoT consulting =- *I*LIKE*TRAINS* > ___ Anima mailing list > Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Editorial Errata Reported] RFC8995 (7576)
Rebecca VanRheenen wrote: > We are unable to verify this erratum that the submitter marked as > editorial. Please note that we have changed the “Type” of the > following errata report to “Technical”. As Stream Approver, please > review and set the Status and Type accordingly (see the definitions at > https://www.rfc-editor.org/errata-definitions/). I filed this report after some discussion on the list. It fixes a comment, rather than the underlying CDDL. So I agree that it's not strictly editorial. > You may review the report at: https://www.rfc-editor.org/errata/eid7576 > Please see https://www.rfc-editor.org/how-to-verify/ for further > information on how to verify errata reports. > Further information on errata can be found at: > https://www.rfc-editor.org/errata.php. > Thank you. > RFC Editor/rv >> On Jul 26, 2023, at 9:33 AM, RFC Errata System >> wrote: >> >> The following errata report has been submitted for RFC8995, >> "Bootstrapping Remote Secure Key Infrastructure (BRSKI)". >> >> -- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid7576 >> >> -- >> Type: Editorial Reported by: Michael Richardson >> >> >> Section: 4.3 >> >> Original Text >> - >> objective-value = text ; name of the (list of) supported ; protocols: >> "EST-TLS" for RFC 7030. >> >> >> Corrected Text >> -- >> objective-value = text ; name of the supported protocols. ; e.g., >> "EST-TLS" for RFC 7030. >> >> >> Notes >> - >> This objective does not support a list of supported protocols. The >> comment in the example might lead people to conclude they can do that. >> >> Instructions: >> - >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party can log in >> to change the status and edit the report, if necessary. >> >> -- >> RFC8995 (draft-ietf-anima-bootstrapping-keyinfra-45) >> -- >> Title : Bootstrapping Remote Secure Key Infrastructure (BRSKI) >> Publication Date : May 2021 Author(s) : M. Pritikin, M. Richardson, >> T. Eckert, M. Behringer, K. Watsen Category : PROPOSED STANDARD Source >> : Autonomic Networking Integrated Model and Approach Area : Operations >> and Management Stream : IETF Verifying Party : IESG >> -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-15.txt
internet-dra...@ietf.org wrote: >Title: Join Proxy for Bootstrapping of Constrained Network Elements > Authors: Michael Richardson Peter van der Stok Panos Kampanakis Name: > draft-ietf-anima-constrained-join-proxy-15.txt Pages: 26 Dates: > 2023-11-06 ... > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-constrained-join-proxy-15 This is a repost of the I-D, because it expired. This version includes partial work on the IoT-Directorate review comments received in August, and which are still issues: https://github.com/anima-wg/constrained-join-proxy/issues So the work is just not done yet. There are a number of pull requests, some rather old, which I need to clean up and/or merge: https://github.com/anima-wg/constrained-join-proxy/pulls Your comments are of course, very welcome. It probably the case that there is need for some additional review/text based upon the new conversations about the discovery draft. It would be great if there are new eyes reading this document if they notice the mismatches. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] ANI. FYI: Re: New Version Notification for draft-eckert-anima-brski-discovery-01.txt
Toerless Eckert wrote: > We have started to put together a combined draft describing discovery > across the different BRSKI variations because after trying, it did > become more and more convoluted to try to describe these aspects > repeatedly across the different drafts individually. It seems like a good document, can we please adopt it? * It is odd to have terminology as section 1, but I guess maybe people want to use the terminology in the Overview/Introduction. Probably plan to add a term-free short Introduction. * Section 2 says When an initiator such as a proxy or pledge uses a mechanism such as _Section 1_ which is probably intended to be a reference to a specific term, but that didn't work. I was looking at: https://datatracker.ietf.org/doc/html/draft-eckert-anima-brski-discovery in case the html version has rendered differently. } Upon discovery of the available sockets, the initiator selects one, whose } supported variation(s) best match the expectations of the initiator, } including performance, security or other preferences. } Selection may also include attempting to establish a connection to the } responder socket, and upon connection failure to attempt connecting to the } next best responder socket. I wonder if this initial attempt, which is something a proxy perhaps ought to do, shouldn't actually do some kind of request to the Registrar. Perhaps one to establish and/or confirm that the Registrar supports the desired mode, or to exhaustively list all the modes it does support. It might be that the /.well-known/core?rt=brski.jp call is the right thing for CoAP connections, but could we do the same/similiar thing for HTTPS? > [ RFC editor. Please remove the following sentence. Note: This section > contains three tables according to the specifications of this document. If > it is not possible to introduce more than one table per section, then we > will modify the request accordingly for three sections, but given how the > three tables are tightly linked, that would be unfortunate. ] Just email i...@iana.org, and ask them. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] summary of design team meeting, 2023-10-24
Fries, Steffen wrote: > Thank you for the minutes. Very good to keep track of the discussion. > Some of the issues discussed yesterday have been addressed by comments > and commits already. My goal here is not to just list open issues, but all issues that were discussed. So if readers come to the linked issues and find them closed/merged, they should just know that we are making progress. Or they should protest/disagree. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] summary of design team meeting, 2023-10-24
To help with the WG keeping abreast of issues resolved by the (BRSKI) design team, we will post a summary of issues worked on during the Tuesday meetings. To remind everyone is welcome to join the design team meetings which are most Tuesdays at 11am Eastern at whereby.com/sandelman. There are calendar invites in the archives. There will be design team meeting on Oct.31 or Nov. 7. We will resume on Nov.14, and I will resend an invite for that date. Who: Toerless, Michael, Steffen, Thomas, Matthias, Marco Calipari. 1. https://github.com/anima-wg/anima-brski-prm/issues/79 discovery of registrar with BRSKI-PRM function set (one realization is that there will be Registrar/Registrar-Agent communication/configuration which likely will go beyond the standards we are defining. We have no experience here, and there will need to be experiments with running code before we can have standardization here. i.e. a Registrar and Registrar-Agent are part of a single product offering) 2. https://github.com/anima-wg/anima-brski-prm/issues/106 "registrar-agent signatures" check consistent use closed with text in section 6.3.6 3. https://github.com/anima-wg/anima-brski-prm/issues/116 Security Considerations - nonce explanation closed, everyone happy with text 4. https://github.com/anima-wg/anima-brski-prm/issues/117 Security Considerations - Misuse of Registrar-Agent Credentials nothing changed in the text, agreed that description was good enough. issue closed. 5. https://github.com/anima-wg/anima-brski-prm/issues/128 "domain/site" terminology definition and consistent usage We had a long discussion about whether or not the term "site" needs to be go into the document. Does it mean the same as "domain" or not? It has been in slides, and often was used to refer to the multiple "downstairs" sites. We also discussed that "site" is a place where multicast DNS works (which is kinda of standing the defintion on its head) We think we will remove all references to site, and try to emphasize the nomadic connectivity of the Registrar-Agent using some new term. 6. https://github.com/anima-wg/anima-brski-prm/issues/129 Need to add IANA registration for brski-pledge Probably this is redundant, and we need to move all the discovery IANA stuff to the (new) discovery document. If we keep the Agent discovery of Pledge in PRM, then we need to keep the IANA registry for the .well-known and mDNS in that document. Much conversation dealing with lack of feedback from mediaman about Media Type process. There is no dependancy from discovery document about media types, but it is a bit hidden /implicit. 7. https://github.com/anima-wg/anima-brski-prm/issues/130 product-serial-number for discovery Suggested text is now in -01 of discovery. https://www.ietf.org/archive/id/draft-ietf-anima-brski-prm-09.html#name-discovery-of-pledge-by-regi We believe that it is okay to do **discovery** by manufacturer-specific serial number without qualifying it with the manufacturer. While this results in false positives (every manufacturer has serial number 001 present), but in that unlikely result, it is okay, because the Registrar-Agent can filter through the results. More discussion about how much we can ask for, and how will this get integrated into supply processes. Definitely a topic for discussion at IETF118. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] IPR poll of for draft-ietf-anima-brski-cloud
I am not aware of any IPR against this document. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] copying from github to WG mailing list ?
Brian E Carpenter wrote: > On 25-Sep-23 07:10, Michael Richardson wrote: >> Brian E Carpenter wrote: >> > Certainly, but that depends on humans. We also need filters for github >> > messages, because if you are subscribed to a repo, you tend to get a >> > lot of trivia as well as substantive discussions. There is perhaps a way >> > to get a digest of activity on a repo. >> yes, Mark Nottingham has a script that sends a weekly summary. >> For instance: >> https://mailarchive.ietf.org/arch/msg/cellar/26oBDDCLnEXOP4y1r8iUpLje9Hc/ >> github.com/ietf-github-services/activity-summary >> I can enable this for ANIMA if desired. > If it's possible to include issues created and issues closed, that > would be great. I couldn't instantly figure out the filter syntax. I'm pretty sure that it does that, but if you want only newly created and issues closed, then we'd have to edit something. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] copying from github to WG mailing list ?
Brian E Carpenter wrote: > Certainly, but that depends on humans. We also need filters for github > messages, because if you are subscribed to a repo, you tend to get a > lot of trivia as well as substantive discussions. There is perhaps a way > to get a digest of activity on a repo. yes, Mark Nottingham has a script that sends a weekly summary. For instance: https://mailarchive.ietf.org/arch/msg/cellar/26oBDDCLnEXOP4y1r8iUpLje9Hc/ github.com/ietf-github-services/activity-summary I can enable this for ANIMA if desired. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] copying from github to WG mailing list ?
Toerless Eckert wrote: > So, i am always happy in taking recommendations how to best rectify this type of issue. > I am of course always a believer in better tooling, but i wouldn't know if/how we would > best copy e.g. relevant parts of the github discuss to the mailing list. For important > messages on the github, it would for example be lovely to create a copy to the mailing > list by some simple mechanism, such as @anima-wg or the like, but i > don't there is such a way. Any thread on github that has more than two opinions needs to come to the list. Do this *before* you reach some conclusion, in order to avoid getting exhausted. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Use of problem details in BRSKI (and other ANIMA) documents (rfc9457)
Toerless Eckert wrote: > In the weekly BRSKI calls we did discuss on and off the issue of > limited HTTP error codes returned when calling BRSKI endpoint > URIs. Especially the point that it's difficult to map all error > conditions to unique HTTP status codes. > So, i would hereby like to suggest that we revisit error codes returned > by new BRSKI work to follow what the IETF has specified and follow what > seems to be like a very simple way to apply that method, as found in > ACME (which is kinda related to our BRSKI work). Seems like it should be a new document that updates RFC8995? i.e. I don't think we have many dependancies. > Whenever an initiator should or could have two different reactions to > two different errors, such as different retries, then there MUST be two > different ErrorNameNNN. Aka: automated reactions must be possible by > only examining the ErrorNameNNN. agreed. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] title for join proxy document
https://github.com/anima-wg/constrained-join-proxy/pull/57 Fries, Steffen wrote: > A further alternative may be _Join Proxy for Bootstrapping of > Constrained Network Elements_ This seemed like the best choice, so I've used it. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] title for join proxy document
Russ points out that the title is a slightly mis-leading.
https://github.com/anima-wg/constrained-join-proxy/issues/51
The document is titled:
_Constrained Join Proxy for Bootstrapping Protocols_
--- abstract
This document extends the work of Bootstrapping Remote Secure Key
Infrastructures (BRSKI) by replacing the Circuit-proxy between
Pledge and Registrar by a stateless/stateful constrained Join
Proxy. The constrained Join Proxy is a mesh neighbor of the
Pledge and can relay a DTLS session originating from a Pledge with only
link-local
addresses to a Registrar which is not a mesh neighbor of the
Pledge.
This document defines a protocol to securely assign a Pledge to a domain,
represented by a Registrar, using an intermediary node between Pledge and
Registrar. This intermediary node is known as a "constrained Join
Proxy". An enrolled Pledge can act as a constrained Join Proxy.
{paragraph two is most definitely wrong, but paragraph one is absolutely
correct}
Russ is wrong in thinking that the join proxy machine is not constrained; it
may well be, and that's why we want to reduce/eliminate state if possible.
(Or rather, move it into the network and into the Registrar)
However, I stubbed my toe on the title while trying to fix things.
It is the (Constrained Join) Proxy for Bootstrapping Protocols.
Not, the: (Constrained Join Proxy) for Bootstrapping Protocols_
I thought about instead:
Stateless Join Proxy for Constrained Bootstrapping Protocols
Or even s/Bootstrapping/Onboarding/
but, actually we document both State and Stateless mechanisms.
Please help me fix the title and from that, the abstract.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] I-D Action: draft-ietf-anima-brski-cloud-08.txt
internet-dra...@ietf.org wrote: > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-brski-cloud-08 This is the result of WGLC review comments from Esko (THANK YOU!) There are no semantic changes to the document, just edits for consistency. Is the WGLC finished then? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] terminology for draft-ietf-anima-rfc8366bis-09.txt
internet-dra...@ietf.org wrote: > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-anima-rfc8366bis-09.html > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-rfc8366bis-09 Esko noticed that the brski-cloud YANG items did not get a SID value assigned. This was tracked down to the wrong version of pyang having been used. I needed to use the version that I had done earlier in the year that understood sx:structure. This is the only change: est-domain and additional-configuration now have SID values assigned. There are other issues that remain to be solved: specifically, establishing a common set of terminology for outer (signed), inner, etc. parts of the voucher so that other documents can use them easily. https://github.com/anima-wg/voucher/issues/27#issuecomment-1671331560 I would like to propose the following terms: voucher: the entire thing, with signature and whatever other things the cryptographic wrapper brings. May be preceeded by CMS, JWS or COSE. voucher artefact/artifact: same as above, if more clarity is needed. (artifact is USA spelling) voucher data: the raw (serialized) representation in whatever format (JSON, CBOR), without any signature. Maybe be preceeded by "JSON" or "CBOR" -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] IANA considerations for BRSKI/GRASP objective-value
https://github.com/anima-wg/constrained-voucher/pull/272/files Hi, we had some discussion on the list a few weeks ago about the lack of a IANA registry for the GRASP AN_PROXY and AN_join_registrar objective's objective-value. RFC8994 defines AN_PROXY, and RFC8995 (section 4.4.1) uses it like: [M_FLOOD, 12340815, h'fe81', 18, [["AN_Proxy", 4, 1, ""<-OBJECTIVEVALUE], [O_IPv6_LOCATOR, h'fe81', IPPROTO_TCP, 4443]]] with: objective-value = any ; none and we were a bit imprecise that "none" meant empty string, rather than CBOR null! constrained-voucher (cBRSKI) needs to extend this value to include: "DTLS-EST" while constrained-join-proxy uses it. RFC8995 defines AN_join_registrar (section 4.3) as: [M_FLOOD, 51804321, h'fda379a6f6ee02006401', 18, [["AN_join_registrar", 4, 255, "EST-TLS"], [O_IPv6_LOCATOR, h'fda379a6f6ee02006401', IPPROTO_TCP, 8443]]] objective-value = text ; name of the supported protocol. ; e.g., "EST-TLS" for RFC 7030. (after https://www.rfc-editor.org/errata/eid7576 is applied) constrained-voucher (cBRSKI) needs to extend this value to include: "BRSKI_JP" while constrained-join-proxy then extends this to include "BRSKI_RJP" (see: https://github.com/anima-wg/constrained-join-proxy/pull/46 ) we also seem to have "CMP" as a value, which I think that brski-ae will need to register, but which I don't think we do yet. One thing that I'm unsure about is whether there should be additional columns in the Registry. Specifically, we have changes in the $transport-proto for both, which can vary from IPPROTO_TCP in RFC8995, to IPPROTO_UDP for the coap methods. Should that be in the table too? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Esko: Re: Moving draft-ietf-anima-brski-cloud-06 forward
Esko Dijk wrote: > I did check just now - the review comments were addressed. I added a > few new text issues in the issue tracker #42 to #46 > (https://github.com/anima-wg/brski-cloud/issues) and a request to > change one more item for #32. This is based on reading the new text > and re-reading the old. These are things I feel that the WG needs to > fix before proceeding with the document, to avoid reviewer's confusion > further down the line. I went through them, ad there is now a PR against brski-cloud. > Overall, I also found there's still many typos and word omissions that > could be fixed before moving this document forward to IESG. Not sure if > that's needed (we can apply the lazy-fix policy and let IESG find them hah. Let's not. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] August 15 design team cancelled
The Tuesday August 15 meeting has been cancelled because it's a german public holiday. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Moving draft-ietf-anima-brski-cloud-06 forward
Owen Friel \(ofriel\) wrote: > Thanks Esko, I just merged a PR to address these: > https://github.com/anima-wg/brski-cloud/issues/40 Thanks, Owen now posted -07: https://author-tools.ietf.org/iddiff?url1=draft-ietf-anima-brski-cloud-06=draft-ietf-anima-brski-cloud-07=--html -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] on removing list-of from rfc8995
William Atwood wrote: > 1. The objective is specific to a particular supported protocol, so the > "text" contains exactly one supported protocol. In this case, if a > Registrar supports different protocols, it would need to advertise > different objectives, each containing exactly one supported protocol. This one. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] on removing list-of from rfc8995
Carsten Bormann wrote: > Do you want: >>> objective-value = text ; name of the supported protocol. ; e.g., >>> "EST-TLS" for RFC 7030. Yes, without trailing s, thank you. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] on removing list-of from rfc8995
Michael Richardson wrote: > I think it should now say: > objective-value = text ; name of the supported protocols. ; e.g., > "EST-TLS" for RFC 7030. https://www.rfc-editor.org/errata/eid7576 -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] on removing list-of from rfc8995
Toerless Eckert wrote: > Want to throw a different proposal in the room. But, here we are trying to clarify a confusion in 8995. You are trying to propose something new, which wouldn't be in errata. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] New Version of draft-eckert-anima-grasp-dnssd
Brian E Carpenter wrote: >> Since we are doing this in std >> track documents (so they get the >> ultimate considerations, of IESG >> action, in effect), the value of >> the registry is that it lets people >> find the document that goes >> with the value. > Yes, makes sense. okay, where do we register it? >> constrained-voucher? > Seems logical. https://github.com/anima-wg/constrained-voucher/pull/272/files please check this... I don't feel like I really got it right. If this is acceptable to the WG, then I'll post a new revision and ask IANA to validate our text. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] on removing list-of from rfc8995
On 26-Jul-23 09:06, Michael Richardson wrote:
> Brian E Carpenter wrote:
> > That makes sense, but it probably needs to be normatively specified,
> > which would avoid any need to change RFC 8995, except perhaps an
> > erratum to delete that "(list of)" wart.
> I didn't get the "(list of)" wart...
bc> objective-value = text ; name of the (list of) supported
bc> ; protocols: "EST-TLS" for RFC 7030.
so, errata I think.
I think it should now say:
objective-value = text ; name of the supported protocols.
; e.g., "EST-TLS" for RFC 7030.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] New Version of draft-eckert-anima-grasp-dnssd
Brian E Carpenter wrote:
> That makes sense, but it probably needs to be normatively specified,
> which would avoid any need to change RFC 8995, except perhaps an
> erratum to delete that "(list of)" wart.
I didn't get the "(list of)" wart...
>> (IP addresses could change not because different machines, but because
>> in IPv6, why not, and it also makes use of containers easier) I regret
>> we didn't write "BRSKI_EST" on the first one. I am asking now if we
>> should have a registry for this. It could be RFC Required, as at this
>> point, everything is in WG documents. Since we are doing this in std
>> track documents (so they get the ultimate considerations, of IESG
>> action, in effect), the value of the registry is that it lets people
>> find the document that goes with the value.
> Yes, makes sense.
okay, where do we register it?
constrained-voucher?
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
[Anima] cluster 472 and ANIMA
Looking at: https://www.rfc-editor.org/cluster_info.php?cid=C472 It is being held up by: draft-ietf-anima-brski-cloud NOT-RECEIVED draft-ietf-lamps-rfc7030-csrattrs NOT-RECEIVED draft-ietf-uta-rfc6125bis NOT-RECEIVED I'm responsible for 7030-csrattrs, and it's either done or gets one more tweak and then I hope will be WGLC by the end of the summer. I can't make rfc6125bis go faster, but I'll try. draft-ietf-anima-brski-cloud however, has been essentially WGLC ready for many months. I see review comments from Esko in June, and THANK YOU for that, and I've made a pull request for Owen to review. So, I would ask the chairs to consider a WGLC for brski-cloud in August. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] New Version of draft-eckert-anima-grasp-dnssd
Brian E Carpenter wrote: > Yes, but you can map them in CBOR just as > draft-eckert-anima-grasp-dnssd already describes. (Think JSON but code > CBOR.) My only real concern is how to extend the objective for the > AN_join_registrar. It seems lame to use plain text when a JSON-style > map would be much nicer for the programmer. My prototype code for > grasp-dnssd has to parse DNS records to change them into Python > maps. But once that's done, sending or receiving them as CBOR is > trivial. so far we are sending multiple objective values: https://www.ietf.org/archive/id/draft-ietf-anima-constrained-join-proxy-14.html#name-grasp-discovery and https://www.ietf.org/archive/id/draft-ietf-anima-constrained-voucher-21.html#name-grasp-discovery [M_FLOOD, 51840231, h'fda379a6f6ee02006401', 18, [["AN_join_registrar", 4, 255, ""], [O_IPv6_LOCATOR, h'fda379a6f6ee02006401', IPPROTO_TCP, 8443], ["AN_join_registrar", 4, 255, "BRSKI_JP"], [O_IPv6_LOCATOR, h'fda379a6f6ee02006401', IPPROTO_UDP, 5684], ["AN_join_registrar", 4, 255, "BRSKI_RJP"], [O_IPv6_LOCATOR, h'fda379a6f6ee02006401', IPPROTO_UDP, 5685]]] I have resisted suggestions that we put an array for the objective-value, and also that it have a string that needs to be parsed like "mode=prm,foo=1,bar=2"... This is because I think that the protocol and port numbers, and maybe even the IP addresses will be different. (IP addresses could change not because different machines, but because in IPv6, why not, and it also makes use of containers easier) I regret we didn't write "BRSKI_EST" on the first one. I am asking now if we should have a registry for this. It could be RFC Required, as at this point, everything is in WG documents. Since we are doing this in std track documents (so they get the ultimate considerations, of IESG action, in effect), the value of the registry is that it lets people find the document that goes with the value. If we do want a registry, it needs to go into one of the two above documents, I think. I don't want to drag this on longer than it needs to be, because these documents have taken too long already. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Ace] Proposing document draft-amsuess-ace-brski-ace-00
Carsten Bormann wrote: >> the manufacturer has all the golden values (the endorsements). > The manufacturer may have the reference measurements. 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… If your point is that other entities may have reference measurements/endorsements then I agree. But so what? RFC9334 says that the RP (the Registrar) needs a policy as to whose Attestation Results to trust, so that needs to be considered. If you want a choice in verifier, you have it. There is some latent fear among some people that the *Manufacturer* can only be the factory in Shenzhou, and we can't trust them. Of course, we went to some effort to say, MASA, not Manufacturer. But, I wonder if there are some linguistic thing occuring with the word Manufacturer that gets it confused with "factory". iPhones are manufacturered by Apple, even if the Factory is Foxcon. OEM = Original Equipment Manufacturer, which to my mind, is the entity that holds the private key corresponding to the firmware signing trust anchor. Anyway, *A* reason that I haven't written up an EAT-in-Voucher ID is that I've been convinced that devices need continuous assurance, and it makes no sense to me to run a remote attestation once in BRSKI, and then again in a continuous form. I think just run the continuous assurance protocol, but OTH, it would be nice to do this before the device is accepting onto the network. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [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
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] New Version Notification for draft-ietf-anima-constrained-voucher-21.txt
Carsten Bormann wrote: > If it is, please do request the registration. Firing off a request to > a random mailing list is not sufficient; iana has to know about it. Hmm, well it sure seems to suggest that we are supposed to do that. It's hardly "random" though. > As a cose WG “member”, I feel it is slightly weird for anima to > register that. But you don’t need a draft, I think; a (correctly!) > filled in registration template sent to IANA should trigger the expert I agree: it is weird. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [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 respon
Re: [Anima] New Version Notification for draft-ietf-anima-constrained-voucher-21.txt
Esko Dijk wrote: > * Is application/voucher-cose+cbor a correct name? > https://github.com/anima-wg/constrained-voucher/issues/264 -> proposal is to change name to application/voucher+cose and register -> '+cose" as a structured syntax suffix. A request has been informally -> approved by mediaman WG; and it was decided to include the formal -> request in the draft since that's the best procedure for it. Was it actually informally approved? I didn't know. https://mailarchive.ietf.org/arch/browse/media-types/?gbt=1=JxzT03Dhe7Nt8cPAfjbDx3WVQRM > * Proposed simplification and streamlining of Constrained BRSKI > https://github.com/anima-wg/constrained-voucher/issues/269 -> proposal is to simplify and streamline the draft per the PR linked to -> this issue. It separates better the default (basics) needed and -> optional Pledge features (like discovering multiple -> protocols/formats/etc and the RPK variant) > Maybe Michael is available to lead the discussion ... ? okay, I'll make a slide for each point from there. I don't mind the rewrites you intend, and I don't find them controversial, and at this point, I think you hold the lead pen, so I'd encourage you to just do them. This document is now like 6+ years old, and it would be nice to get it done already. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI
Having read through the emails and reviewed the document a bit more, I think that I see some ways in which the document could be clarified. First, this is not an extension or amendment to BRSKI. BRSKI is a way to introduce trust between Pledges and Registrars via the third-party RFC8366 voucher. In 8995, it results in a RFC7030 *EST* channel, which is literally... "Enrollment over Secure Transport". RFC7030 defines a CSR-based method to get a new certificate. CLE is not about BRSKI at all, it's about a new kind of enrollment. So, this document should be "EST-CLE", which is much akin to "BRSKI-AE" (which arguably from this point of view, should be "EST-AE" or even "EST-CMP", only it's not EST at all) The reason CMP changes BRSKI is because it does away with the (provisional) TLS connection, and RFC8995 deals primarily with how that connection is setup to be be useful. From what I can see, BRSKI-CLE does nothing to the provisional-TLS connection at all, but rather changes what occurs after the Secure Transport exists. The BRSKI-CLE document has a lot of text dealing with how the public keys are derived. I don't really understand what the credential that is created by the AC is... it looks like it's a signed object. I don't understand how it would differ from all the work in OAUTH and ACE. Second, I don't understand how to devices (having been enrolled) as depicted in section 2.3, as client and server are able to trust each other. Maybe there is some important magic that I've missed among the math. I don't think that section 3 needs to educate us about Schnorr. I learnt nothing about the trust algorithm from the math. Something about a Master Key, which really scares me. I would suggest that rather than tell us about the math, that the presentation should explain to us the use case for this work. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] how to describe JSON examples
In the JWS I-D, we have some JSON that is an example.
And the content within is BASE64URL encoded.
We could, I think, describe this in CDDL, but we aren't trying to be
authoritative. (It's a JOSE example)
We are struggling with quoting. We could write:
"payload": "BASE64URL(ietf-voucher:voucher)",
which would make it valid JSON, with the literal contents.
Or we could write:
"payload": BASE64URL(ietf-voucher:voucher),
which sorta makes it valid Javascript, assuming such a function existed.
here is an example with both variations:
{
"payload": BASE64URL(ietf-voucher:voucher),
"signatures": [
{
"protected": "BASE64URL(UTF8(JWS Protected Header))",
"signature": "base64encodedvalue=="
}
]
}
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] New Version of draft-eckert-anima-grasp-dnssd
Brian E Carpenter wrote: > I can't answer that, but note that the AN_Proxy and AN_join_registrar > GRASP objectives defined in RFC 8995 include an objective-value field. > For AN_Proxy that field is "any" so is currently undefined and could be > extended in any way we want. For AN_join_registrar it is defined as In hindsight, 8995 should have created an IANA registry for these. > I find that "(list of)" a bit unclear but again there is flexibility to > extend the semantics as we want. In fact that "(list of)" is almost > worth an errata, since I wouldn't know what to write in a program to > implement it. :-) -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [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
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Call for agenda items ANIMA@IETF117@ San Francisco
Yanlei\(Ray\) wrote: > I would like to ask for the a time slot for my new individual draft. > Topic/Title: BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI Thank you for your document. I look forward to your slides for further explanation. 1. It seems that you've missed much of the Raw Public Key support that is a key part of constrained-BRSKI. 2. Do you have a proof-of-concept implementation? 3. There seems to be a significant gap in how the vouchers would work. I didn't understand this at all. It all starts with an unsupported assumption that IoT devices can not hold certificates. Yet, they are being installed into devices by the billions today. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Technical Errata Reported] RFC8994 (7558)
RFC Errata System wrote: > Notes > - > The second paragraph in the original text appears to be a more > carefully-written version of the first paragraph. Therefore the first > paragraph should be deleted and the second paragraph retained. > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party can log in to > change the status and edit the report, if necessary. Sure, it's an improvement. It seems entirely editorial, so "Hold for Document Update" -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Idea for streamlining of draft-ietf-anima-constrained-voucher
Esko Dijk wrote: > Based on our writing and implementation experience so far for > draft-ietf-anima-constrained-voucher, I see some opportunity to > simplify and streamline the main procedure and its description. The > idea is to have one main flow description that relies a lot on sensible > defaults, and move any "alternatives" or "extras", or "special cases" > to separate sections in the end of the document. That should make it > more comprehensible for those wanting to implement the basic > constrained BRSKI method and also improve interoperability. I have no objection to doing this. I don't think I can do it though :-) The document has been sliced and diced a lot over five years, and I agree could use a total rewrite. > See https://github.com/anima-wg/constrained-voucher/issues/269 for > Github issue created for this. I could create a PR to show how it may > look like. > Any opinions on this? I prefer to get it done sooner than done better, but not everyone will agree with that. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Moving draft-ietf-anima-brski-cloud-06 forward
Esko Dijk wrote: > Because there's new text being added; I've reviewed this as well. Below > my findings. I would prefer if the WG could fix this as part of the > WGLC work. okay! https://github.com/anima-wg/brski-cloud/issues/40 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Moving draft-ietf-anima-brski-cloud-06 forward
Brian E Carpenter wrote: > Now draft-ietf-lamps-rfc7030-csrattrs is a downref, which needs to be > mentioned in the shepherd's write-up. It's unstuck as of yesterday. I think it could be WGLC by the end of the summer. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] FW: New Version Notification for draft-mohammed-anima-voucher-security-profile-00.txt
Srihari Raghavan (srihari) wrote: > Agreed that MASA is the signing authority and the draft is meant to > convey that the owner can influence the choice by way of parameterized > inputs to the MASA APIs. So, owner can be presented with a 'security > profile selector' input via the MASA external APIs and when the owner > provides the PDC and the selector input values, MASA can then go ahead > and create the voucher with appropriate security profile settings > (after verification and validation) for the device. okay, that's a entire API from Registrar to MASA which you have to design and document. And you mention SZTP, and it doesn't have that link. I think that there are better ways to do accomplish the configuration, such as extending the BRSKI-EST link with new actions. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] FW: New Version Notification for draft-mohammed-anima-voucher-security-profile-00.txt
In the ID, you write: } 5. Changes to Registrar Behavior } The Registrar is the component that authenticates the pledge, makes } authorization decisions, and distributes vouchers. If the extensions are } supported, the Registrar MAY process a security profile selector request from } owner that identifies what underlying security parameters need to be enabled } in the security-profile-selector send down to the pledge as part of these } extensions. 1. You haven't understood how vouchers are used. The Registrar does not create them. 2. Unfortunately, the result of the year+ effort to provide a way to incrementally extend RFC8366 has failed due to limitations in YANG. Under the hood, it ought to be trivial to do in the JSON or CBOR. RFC8366bis simply revises the module as a whole, and your extension would have to go into 8366bis, if it made sense. 3. 32 is not enough bits. Using bits is probably a failure. Probably you need an IANA registry of posture definitions, and it probably needs to have an integer per item. There is probably need to have vendor extensions, probably by PEN. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] FW: New Version Notification for draft-mohammed-anima-voucher-security-profile-00.txt
Hi, I'll read your I-D, but: Srihari Raghavan \(srihari\) wrote: > 2. This allows the owner to change and > customize the security posture of the device dynamically and securely > and under scale. 3. This lets the owner to selectively enable or > disable each of the underlying security parameters that make up the > security posture of the device. Hi, RFC8366 Vouchers are signed by the MASA, not the owner, so this doesn't follow. We do desperately need a configuration backup/restore mechanism that can be audited and trusted, and this does need to be wrapped up into onboarding, but I don't think it can be done WITHIN the voucher, which is what I'm guessing you have done. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Ace] ANIMA and ACE, IDevID terminology (was: Re: cBRSKI)
Russ Housley wrote: >>> 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? >> >> I wouldn't call it an LDevID. >> You don't need to do EST and ask for an LDevID. > I do not see this being prohibited. It would require: > - CA recognizes the trust anchor associated with the IDevID, > - CA can issue the LDevID, > - Client can authenticate the EST server based on something configured at the factory. I think you are speaking at cross-purposes. Christian wants to know if ANIMA/BRSKI can "complete" without asking for an LDevID. (yes) Alternatively, if some OSCORE context with a symmetric key can count. You have latched onto getting an LDevID without using EST. Agreed: you don't need EST, you can use any other enrollment protocol you want, and the BRSKI-AE document is about using CMP, for instance. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Ace] ANIMA and ACE, IDevID terminology (was: Re: cBRSKI)
Christian Amsüss wrote: > 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. No, that part does not make sense. The voucher is authenticating the (public key) identity of the Registrar (aka AS) to the Pledge. If you want to do further key derivations, then you'd have to some PRFs and/or DH (for PFS). >> 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. Has to be done through OSCORE/EDHOC. > 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. Yes, but the shared key comes from the EDHOC operation. > 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? I wouldn't call it an LDevID. You don't need to do EST and ask for an LDevID. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Ace] ANIMA and ACE, IDevID terminology (was: Re: cBRSKI)
Benjamin Kaduk wrote:
> On Mon, May 01, 2023 at 12:09:03PM +0200, Christian Amsüss wrote:
>> 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?
> I don't have much of an opinion on this at the moment but could
> probably be convinced that using IDevID is ok.
I wanted to wait for other opinions.
I begin to wonder if we should do our own 802.1AR. The document is 90%
references to IETF RFCs, many of them old or vague. Another half is a
pseudo-API, which nobody uses.
I don't really understand the concerns that Ben and Christian have raised.
>> * 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.
pinned-domain-pubk pins a specific public key, in the case of "pubk", but
*value* the COSE kid is not really involved *at all*
pinned-domain-pubk-sha256 pins by SHA256 hash, but for 256-bit ECDSA keys, that
might
not be much of an actual savings.
>> * 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).
> It makes me nervous, but just because of the normal shared-key threat
> model. (It is the group-shared threat model since you may have more
> than one instance of AS for ANIMA purposes, but it's probably okay to
> have "AS1 attacks AS2" as out of scope since the AS is assumed to be
> trusted.)
symmetric keys could be used with constrained vouchers, from the MASA to the
Pledge. They couldn't be used in the other direction, where the Registrar,
having no relationship with the Pledge, needs to validate the IDevID.
I wouldn't want to do this though, and I see no advantage, only extreme risk.
>> * (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?
> 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 see no reason the (provisional)[D}TLS connection between Pledge and Registrar
can't be used to initialize a symmetric key for OSCORE. Apply a suitable key
exporter.
The Registrar becomes (or communicates with) the AS.
If you are using EDHOC, then a suitable key was already created by EDHOC.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
[Anima] netmod virtual interim meeting
If you have been paying attention at all to the saga of RFC8366bis and the YANG which is here and then there, and then in another place, you might want to attend the NETMOD virtual interim meeting on June 5. https://datatracker.ietf.org/meeting/interim-2023-netmod-01/session/netmod Title: YANG Modelling in IETF WGs – Sharing Lessons Learned Description: Expanding on the IETF116 presentation “Lessons from Working on BGP YANG” from Jeffrey Haas and Mahesh Jethanandani. Input and experiences from people and working groups doing YANG model development are welcome. A general YANG community discussion to share some lessons and recommend some best practices. A number of IETF models are interdependent across WGs and benefit from some coordination/consultation. Consider further tools and approaches to benefit the entire community. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] northbound/southbound U interface (Re: New Version Notification for draft-richardson-anima-registrar-considerations-07.txt)
Brian E Carpenter wrote: >> The private keys from the Southbound interfaces SHOULD NOT be made >> available on the Northbound interfaces. > This new sentence reads slightly strangely, since private keys must > never be available anywhere! Sow what exactly SHOULD NOT be available > to the North? Yes, I see that someone might think the southbound interface is going to serve up the private keys, and I can rewrite that somehow. I'll go look at TLS documents or something to understand how they express this better. The private key must be available to do signatures for mechanisms running on the system containing the southbound interface. It could be embedded in a secure element, as long as it can satisfy the needs of the southbound AKE (whether that's (D)TLS or EDHOC). -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] I-D Action: draft-ietf-anima-brski-cloud-06.txt
internet-dra...@ietf.org wrote: > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-brski-cloud/ > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-anima-brski-cloud-06.html > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-brski-cloud-06 This version has the YANG additions removed (moved to rfc8633bis), as well as edits to deal with Brian's (as relayed by Esko) comments from late 2022. I think that the comments were part of the WGLC, so I suspect that the document is now done WGLC. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] northbound/southbound U interface (Re: New Version Notification for draft-richardson-anima-registrar-considerations-07.txt)
internet-dra...@ietf.org wrote: > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-richardson-anima-registrar-considerations-07 The document was due for renewal, and I tried to add some text about how a composite architecture may make PoP on the U_w/W (BRSKI-MASA) side difficult if the private key is associated only with the U_v interface(s). This relates the design team discussion we had around draft-selander-lake-authz. I wonder if some more diagrams would help, as I sensed a lot of confusion during the call. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] do we need +jose?
Esko Dijk wrote: > It could also be named +josejson or +jose-json then ? Not as nice as > +jws but at least more relatable to the original media type name. It seems like less of a good idea, but I'm not opposed to it. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] do we need +jose?
Hi, https://datatracker.ietf.org/doc/draft-ietf-anima-jws-voucher/ is in WGLC, and https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/ depends upon it. In anima-jws-voucher, we defined: https://www.ietf.org/archive/id/draft-ietf-anima-jws-voucher-06.html#name-application-voucher-jwsjson Type name: application Subtype name: voucher-jws+json which is in alignment with https://www.rfc-editor.org/rfc/rfc8366.html#section-8.3 where we defined: Type name: application Subtype name: voucher-cms+json probably this was a mistake! (JSON in a CMS envelope) I think, based upon discussion about +cose and our other documents, that we should really be doing: application/voucher+jws While jwt is given as a structured suffix in the IANA registry, jws is not. I'm not entirely sure if this matters... we are dealing with JWS, not tokens... Please advise. While we have lots of running code (since 2018) for voucher-jws, it's a change we could probably make via Postel Principal. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] registration for +cose
Esko Dijk wrote: > 1. Given the existing names of registrations in the Structured Syntax > Suffixes registry, the following name would be more appropriate > perhaps: > Name: CBOR Object Signing and Encryption (COSE) > 2. While STD96 as reference is probably correct, it would be useful to > add the latest COSE RFC (9052) as well. This is also more in line with > the other registrations that list RFC numbers. And RFCs are better > known than STDs. Or maybe this was already intended. getting used to using STD numbers is kinda important. The point of STD numbers is that they are an indirection. would this link be better: https://www.rfc-editor.org/info/std96 > 3. The security considerations should point to a section of RFC 9052 > (Section 12), also like other registrations do. I thought it did :-) > 4. Encoding considerations should mention COSE - current text looks > like it could be a copy/paste bug: > Encoding considerations: COSE is always encoded as CBOR, which is > binary Yes, that's better. as per RFC6838: Name: application/cose +suffix: +cose References: https://www.rfc-editor.org/info/std96 (RFC9052) Encoding considerations: COSE is always encoded as CBOR, which is binary Interoperability considerations: None Fragment identifier considerations: N/A Security considerations: as per RFC9052, section 12 Contact: IETF COSE WG Author/Change controller: IESG -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-14.txt
William Atwood wrote: > Could that be because its Status in the Datatracker is "I-D Exists (IESG: > Dead)"? Yeah, but "I-D Exists" It's IESG processing state is that it got dumped back to the WG. > I would hope that refreshing the document would automatically make it alive, > but that does not appear to be the case. I've asked supp...@ietf.org. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] cBRSKI
Christian Amsüss wrote: > * On devices where the IDevID can be kept safe from owners, can't the > device keep a log locally to the same effect as a MASA log on whether > that device has been owned before? It'd appear that tamper-proofness > would be the only difference to a logged voucher. (Then again, the > MASA might also tamper). It certainly could do that. and remote attestation might mean you'd trust what it tells you. However, in some scenarios, the amount of space available might not be a lot, and also in some models "factory reset" really means deleting EVERYTHING. The MASA audit log also could be subject to various witness processes, such as time stamping. >> [...] An owner might be permitted to load whatever code they want, >> and depending upon many concerns, that might include getting access to >> the IDevID private key, if it is stored on an fTPM or not secured at >> all. > * If the device can do a full firmware replacement (including the > bootloader), even if the IDevID's private key is kept in a secure > element, the new firmware could be used to sign[^1] with the IDevID in > some scenarios. I think it'd be prudent for such upgrades to remove > that IDevID. As IDevIDs are supposed to be immutable (if I read > 802.1AR correctly -- probably makes sense for the devices IEEE is > considering): Is 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. > * 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. 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. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-14.txt
internet-dra...@ietf.org wrote: > directories. This Internet-Draft is a work item of the Autonomic Networking > Integrated Model and Approach (ANIMA) WG of the IETF. > Title : Constrained Join Proxy for Bootstrapping Protocols > Authors : Michael Richardson > Peter van der Stok > Panos Kampanakis > Filename: draft-ietf-anima-constrained-join-proxy-14.txt > Pages : 26 > Date: 2023-04-26 I refreshed this document. I believe that this document is just waiting for it's turn at WGLC. Strangely, this document does not show up in the list of documents for ANIMA. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] cBRSKI
> * What's the assumption of voucher-artifacts on the the IDevID's private > key's secrecy once BRSKI has completed? The private key is private. Nothing needs to be revealed. It can be stored in a TPM/fTPM or SecureElement. Whether the LDevID certificate(s), have the same private key or a newly minted one is a topic that 802.1AR section 6. > Will the now-owner be able to read it? If so, once you see a logged > assertion you can already not trust that device again. Non-owners would have no access to the secret. In many devices, owners would also have no access, but it depends upon the device. > Or the owner still can't? Then why the logging in the first place, the > IDevID will only be used in BRSKI if the device is pristine (or has been > factory-reset). The logging is about witnessing that the device became owned. Subsequent owners can review this information to determine if they device is still useable. While we think about malware and root kits and the like, other users might also think about wear and tear, such as for a braking system. > Or is this a matter of security-in-depth, where the owner has better > chances of exploiting weaknesses, so we better make as-sure-as-we-can that > there was never an owner who could have done so? Yes, that's certainly a concern. An owner might be permitted to load whatever code they want, and depending upon many concerns, that might include getting access to the IDevID private key, if it is stored on an fTPM or not secured at all. To my mind, the smallest of IoT microcontrollers likely will be without secred storage for private keys for a few generations, but many have secure boot mechanisms, so in theory, the entire device is secured, and will not run arbitrary code. > Is delegated-voucher The (only) Way to oboard a resold device (or a device > from a domain that suffered critical infrastructure collapse) without > taking a programmer to it? No. A device could go through a controlled factory reset so that it no longer knows it's LDevID, or network credentials, at which point, it would start over. The only evidence of the previous owner would be in the MASA audit log. This could be via button push, via software command. delegated-voucher has two purposes: 1) to enable resale without talking to the original MASA (infrastructure collapse), 2) to enable aggregation of devices into sub-systems. I think, and I think that there will be regulatory processes that go with this, that in the event of infrastructure collapse one of two things will occur: a) a new MASA will be operated, and a new set of code will be produced from escrowed sources. (Back when software was expensive, in the hundreds of thousands of dollars/copy, source code escrow was a normal thing to do) If done in an orderly fashion, the old supplier would produce a new firmware image with new anchors and would deploy that before going out of business. b) the devices would be marked a regulator as no longer safe, since they have no one to patch them, and would be forced out of service. > If an owner can take complete control over a device (like, switch over the > firmware, as you can do with a PC or a device that contains GPL-3 > software), would the issuer of such a new firmware also need to provision > the device with a new IDevID? Maybe. Probably be a good idea. The MASA URL would be wrong in the existing IDevID. RFC8995 provides for the Registrar to have the ability to override that URL under operator control. That would apply to all devices from that manufacturer, probably, so it's a big hammer. Replacing the IDevID would be simpler. There are many different ways in which one can switch over the firmware. On a PC, one does not typically replace the BIOS, so it might be that one is just using a secure boot shim, or a replacing trust anchors. For a PC, my notion is that BRSKI would not be used for the main CPU, but rather for the BMC. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Result//Re: WGLC for draft-ietf-anima-brski-ae-04, ends April 3rd, 2023
Toerless Eckert wrote: > 2. I would suggest to move RFC7030 to normative references. This would make > it consistent with lightweight CMP references also being normative, and given > how the endpoint naming scheme is derived and meant to be backward compatible with > EST, and EST being explicitly mentioned several times in that context.. Do people implementing the CMP-AE need to know what EST is in detail? That doesn't jive with me. I think it can stay informative, but it's really a quibble. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
