Re: [Anima] [Ace] ANIMA and ACE, IDevID terminology (was: Re: cBRSKI)
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.
> > > * Is there any document that describes (or has an example of) how
> > ANIMA
> > > onboarding interacts with ACE's AS? My current -- maybe naive --
> > > assumption is that a voucher in this countext would contain a
> > > pinned-domain-pubk which is the public key the AS will use to sign ACE
> > > tokens, and the est-domain would indicate the AS URI, but with the
> > > pinned-domain-pubk being described in TLS terms (whereas an ACE AS
> > > uses COSE keys), this may be skipping a step.
> >
> > Yeah, that makes sense to me.
> > I think that ace-ake-authz intended to describe things in terms of ACE.
>
> In the current document, the only ACE reference is in an older version's
> asssigned group. And I think that's good, for using-ANIMA-with-ACE is
> orthogonal to doing-ANIMA-over-EDHOC.
>
> It just may mean we need another document, unless we cram things
> together in one (which, apart from any good-practice discussions, is
> hard to convey to the initial reader, who'll need to understand that
> they can use either part w/o the other).
>
> > The AS == Registrar, I think.
> > Or, perhaps the AS uses a key that the local CA (mediated by the Registrar
> > as
> > a trust anchor, /cacerts) has blessed in some way. How that works is TBD.
>
> So, what'd we need?
>
> * Does pinned-domain-pubk work also for COSE keys as used for signed
> CWTs? (If so, is there a key identifier to go with it?)
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.
> * 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.)
> * (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.
-Ben
> I figure that the alternative is to have a dedicated registrar that
> then hands out certificates to the AS that allow the AS to
> (temporarily) speak for the CA, but this probably just shifts the
> questions above down to how those points above would be expressed in a
> certificate. Skipping that middle step would allow implementing
> devices that have ANIMA-style onboarding (cBRSKI with ake-authz,
> maybe), but (eg. using ACE-OSCORE) don't ever need asymmetric
> operations at runtime.
>
> Or do I get the boundaries all wrong, and an ACE device would rather
> express the concepts of a voucher in a CWT? (But ANIMA already did all
> the hard work, and given such a device likely needs some CORECONF and
> thus YANG anyway, reducing extra weight).
>
> If not: Shall we just start a small and sleek document that registers
> some values, and evolve it with some help from Mr. Cunningham?
>
> BR
> Christian
>
> --
> To use raw power is to make yourself infinit
Re: [Anima] [COSE] [OAUTH-WG] .well-known/jwks.json and constrained-voucher and RFC7517
On Tue, Jul 12, 2022 at 09:46:01PM +0200, Warren Parad wrote: > I don't know if this is relevant, but jwks.json isn't registered, because > it doesn't have to be at that location. The > /.well-known/openid-configuration discovery document, which is registered, > uses the jwks_uri property to specify the location of the jwks. For > instance, our product doesn't have the jwks at /.well-known/jwks.json for a > lot of different reasons. Having a discovery document that points to your > jwks makes sense, ideally you would be able to use the known discovery > document at /openid-configuration, but I don't know if that is viable or > makes sense for your context. Hmm, perhaps we need to give stronger guidance to site operators that the contents of /.well-known/* belong to "the protocol" and that they pick arbitrary new (unregistered) names their at their own risk. (If "you" are serving content at /.well-known/jwks.json and I go register that URI with different semantics, clients that know about my new and try it against "your" server will encounter unexpected behavior.) (I assume that you, Warren, don't control the baeldung.com pages.) -Ben ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [lamps] /.well-known/brski reference to brski-registry
On Sun, Apr 03, 2022 at 10:36:01PM -0400, Sean Turner wrote: > > > > On Apr 1, 2022, at 02:25, Brockhaus, Hendrik > > wrote: > > > > > >> Von: Russ Housley > >> Gesendet: Donnerstag, 31. März 2022 19:53 > >> > >>> On Mar 31, 2022, at 12:20 PM, Brockhaus, Hendrik > >> wrote: > >>> > >>> Thank you Michael for rising the questions. > >>> > Von: Anima Im Auftrag von Michael Richardson > Gesendet: Donnerstag, 31. März 2022 17:48 > > > We were discussing the /.well-known/cmp that is in being proposed in > draft-ietf- lamps-cmp-updates, We were comparing it to > /.well-known/brski and /.well- known/est. > > Question 2) > Should the CMP document be establishing a registry or not? > > >>> As discussed during IETF 113 I plan to do these things in CMP Updates > >>> - register 'cmp' in the "Well-Known URIs" registry > >>> - define a protocol registry group "Certificate Management Protocol (CMP)" > >>> - define a registry for "CMP Well-Known Arbitrary Label URI Segments" > >> defining 'p' to be followed by a . > >>> In addition I would define a registry for "CMP Well-Known Operation Label > >>> URI > >> Segments" in Lightweight CMP Profile containing the path segments defined > >> three for http and coap use. > >>> > >>> Does this makes sense? > >> > >> Hendrik: > >> > >> That is consistent with the discussion lat week. > >> > >> Russ > > > > Would it also be sufficient to have only one additional registry "CMP > > Well-Known URI Path Segments" containing the arbitrary label 'p' and the > > operation labels? > > > > Hendrik > > When the /.well-known/est/ was registered we only did the top level, i.e., > /est/. There are no registries for the /.well-known/est/*this part*. It’s > not clear to me that you need to do anything more than get /.well-known/cmp. > > What will be the registration policy [0] for the ‘p’ values? I assume FCFS > (first come first served)? I had assumed that we were just registering the value 'p' in a single combined registry of CMP operations and path labels, but that the stuff after 'p' was site-local and did not need to be registered. (Though a FCFS registry for them is not wrong.) -Ben ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] Benjamin Kaduk's No Objection on draft-ietf-anima-asa-guidelines-06: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-asa-guidelines-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-asa-guidelines/ -- COMMENT: -- Thanks for the updates in the -06; by and large they look good (especially the resolution to my Discuss). I may still have some lingering confusion about Installation Hosts, though -- in Section 6.1.1 we write: * [ASA_placement_function] specifies how the installation phase will meet the operator's needs and objectives for the provision of the infrastructure. This function is only useful in the decoupled mode. It can be as simple as an explicit list of Installation Hosts, or it could consist of operator-defined criteria and constraints. But I think, in light of the context in which this appears, it would make more sense to say "can be as simple as an explicit list of hosts on which the ASAs are to be installed" (or perhaps a variant that uses the "[List_of_hosts]" spelling of the following paragraph). On the other hand, I could just be suffering from having previously confused myself by reading the -05, and maybe this is actually fine for someone reading it for the first time. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Éric Vyncke's No Objection on draft-ietf-anima-asa-guidelines-05: (with COMMENT)
On Wed, Jan 19, 2022 at 10:46:42AM +1300, Brian E Carpenter wrote: > On 19-Jan-22 06:02, Éric Vyncke via Datatracker wrote: [...] > > Should there be any linkage with SUIT WG ? > > As noted above, IoT (constrained) devices are considered out of scope, > so formally, no. However, a designer would IMHO be pretty silly not > to consider SUIT, especially when designing a manifest. But I don't > see anything useful to add to the draft about this: suggestions > welcome, of course. For what little it's worth, I considered making a similar comment, but decided not to, on the grounds that despite "software updates" being in the WG name, the actual charter covers only firmware update, with the implicit assumption that existing software lifecycle techniques are suit-able (pun intended) for higher layers of the deployment stack. That said, the SUIT techniques seem like they would be usable for this purpose if someone chose to use them in that way. -Ben ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-asa-guidelines-05: (with DISCUSS and COMMENT)
Hi Brian, On Thu, Jan 20, 2022 at 01:38:42PM +1300, Brian E Carpenter wrote: > Hi Ben, > ... > > > -- > > DISCUSS: > > -- > > > > It looks like the indentation in the example MAIN PROGRAM in Appendix C > > is incorrect, or at least confusing, in the "do forever" loop therein. > > Specifically, assuming semantic whitespace as in Python, we never > > actually perform grasp negotiation for the "good_peer in peers" case. > > Additionally, I think we may have a risk of getting stuck in a loop > > making no progress so long as good_peer remains in the set of discovered > > peers but does not have enough resources available for our > > request/negotiation to succeed. I think we want to clear out good_peer > > if a negotiation fails, to avoid that scenario. > > I'll have to check on that by comparing with the Python code, which > definitely doesn't have those problems. Probably a bit too much was > elided when simplifying it into pseudocode. Will fix. That makes sense. [lots of other stuff snipped] I have no other replies, and the datatracker will let me know when the revised I-D is posted, so I can take a look. Thanks! -Ben ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-asa-guidelines-05: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-asa-guidelines-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-asa-guidelines/ -- DISCUSS: -- It looks like the indentation in the example MAIN PROGRAM in Appendix C is incorrect, or at least confusing, in the "do forever" loop therein. Specifically, assuming semantic whitespace as in Python, we never actually perform grasp negotiation for the "good_peer in peers" case. Additionally, I think we may have a risk of getting stuck in a loop making no progress so long as good_peer remains in the set of discovered peers but does not have enough resources available for our request/negotiation to succeed. I think we want to clear out good_peer if a negotiation fails, to avoid that scenario. -- COMMENT: -- Section 1 management services to network operators and administrators. For example, the services envisaged for network function virtualisation [RFC8568] or for service function chaining [RFC7665] might be managed by an ASA rather than by traditional configuration tools. RFC 8568 is an IRTF document on "Network Virtualization Research Challenges"; is that really the best reference for this concept? I note that RFC 8014 exists (IETF, Informational) on "An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3)", which admittedly is not exactly the same thing, but might still be suitable. Section 2 A typical ASA will have a main thread that performs various initial housekeeping actions such as: [...] * Define data structures for relevant GRASP objectives. I may just be confused, but wouldn't defining a GRASP objective/data structure mapping be a matter of protocol design, not something that requires ongoing activity in a housekeeping or startup thread of a running ASA? If the intent was just that the values in a predetermined data structure template should be populated at this step, I would be much less confused. * Obtain authorization credentials, if needed. In a non-autonomic context, I would say that getting credentials needs to be a periodic task, not something done once on startup and retained indefinitely. It seems that in the ASA context, the situation may be difference, since the authorization credentials in question are likely to be (or be derived from) the device's LDevID, which might reasonbly have a very long lifetime. On the other hand, there might also be scenarios where LDevID lifetime is short-lived and certificate renewal occurs often, so that the ASA would benefit from having credential management be a periodic task. Do you think it's better to list this item in the initial housekeeping or in the main loop tasks? Section 3.3 Section 2. However, if ASAs require additional communication between themselves, they can do so using any desired protocol, such as a TLS session over the ACP if that meets their needs. One option is to use GRASP discovery and synchronization as a rendez-vous mechanism between two ASAs, passing communication parameters such as a TCP port number via GRASP. As noted above, the ACP should be used to secure such communications. I agree that there is earlier text suggesting that the ACP should be used for normal inter-ASA communications. I'm commenting here specifically on the phrase "used to secure such communications". If the ACP is providing secure communications, then why would there be a need to use an additional TLS session on top of it (which is specifically called out as an option in the quoted text)? It seems that there is some additional subtlety here, in that the ACP provides some baseline security property of "the communications peer belongs to the ACP" but that in some cases there is a need for additional protection such that the data being exchanged is visible only to the two communicating endpoints in the ACP and not to any intermediate ACP nodes that it traverses. That's a long bit of discussion to just suggest s/used to secure/used for/, but I think it's important to treat use of the word "secure" carefully, as it can be interpreted in many different ways by different readers when used without further qualification. Section 4
Re: [Anima] Benjamin Kaduk's No Objection on draft-ietf-anima-grasp-api-08: (with COMMENT)
Hi Brian,
On Thu, Dec 03, 2020 at 05:50:25PM +1300, Brian E Carpenter wrote:
> Thanks Ben. Some comments below (no comment means I agree with you):
>
> On 03-Dec-20 15:03, Benjamin Kaduk via Datatracker wrote:
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-anima-grasp-api-08: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-anima-grasp-api/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > I have two comments in particular that I would like to call your
> > attention to: my comment on cache flushing in Section 2.3.4, and my
> > comment on the CBOR data model used for validation in Appendix A.
> >
> > Section 1
> >
> >An ASA runs in an ACP node and therefore inherits all its security
> >properties, i.e., message integrity, message confidentiality and the
> >fact that unauthorized nodes cannot join the ACP. All ASAs within a
> >
> > I agree with Roman's comment that the "it" whose security properties are
> > inhereited is the ACP *node*, not the ACP itself, and thus that some
> > rewording is appropriate.
> >
> >The GRASP API library would need to communicate with the GRASP core
> >via an inter-process communication (IPC) mechanism. The details of
> >
> > Hmm, if the GRASP core is in kernel-space and the API library in
> > userspace, wouldn't we normally refer to that exchange as a system call
> > rather than IPC? (Figure 1 also labels this interaction "IPC".)
>
> That could be, and it possibly depends on the terminology used by the
> language and/or operating system in use. However, it isn't clear to
> me that the GRASP core *needs* to be kernel space. Its lowest level
> operations are socket calls and whatever it uses to support asynchronous
> operations. So I think the text should be non-commital on this.
I agree that the GRASP core does not strictly need to reside in
kernelspace, and that non-committal text is wise.
That said, my reading of the current text is that the "In many
implementations [...] split between user space and kernel space" qualifier
continues to apply for the entire paragraph, including "would need to
communicate [...] via [IPC]". I surveyed several of my colleagues, and all
agreed that IPC is not a good term for a userspace/kernelspace interaction.
("syscall" is not going to cover all such cases, of cousre, but probably
covers most of them.)
> > Section 2.1
> >
> >* Authorization of ASAs is not defined as part of GRASP and is not
> > supported.
> >
> > Any chance I could interest you in s/not supported/a subject for future
> > work/? It is looking somewhat likely since such a statement is already
> > present in the security considerations...
> >
> >* User-supplied explicit locators for an objective are not
> > supported. The GRASP core will supply the locator, using the ACP
> > address of the node concerned.
> >
> > This would seem to prevent any non-ACP use of GRASP; I suggest adding
> > some language with a caveat about "for example" or similar, unless the
> > intent is to limit the API usage to ACP (or DULL) scenarios.
> >
> > Section 2.2.1
> >
> > I think that the possibility for a single outbound message to get a
> > sequence of incoming replies (at different times) further complicates
> > the design of an asynchronous mechanism, and we would do well to discuss
> > how such scenarios (e.g., broadcast discovery messages) would be handled
> > by the implementation and API. (I see that we do end up using a timeout
> > in practice to resolve this topic, but would probably still mention it
> > as an issue that has been resolved, here.)
>
> There's quite a lot of text in the main GRASP spec about that, because
> indeed a discovery message may get an unpredictable number of replies.
> Some of that text is a direct result of prototyping experience. I think
> the summary is that discovery is not
[Anima] Benjamin Kaduk's No Objection on draft-ietf-anima-grasp-api-08: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-grasp-api-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-grasp-api/ -- COMMENT: -- I have two comments in particular that I would like to call your attention to: my comment on cache flushing in Section 2.3.4, and my comment on the CBOR data model used for validation in Appendix A. Section 1 An ASA runs in an ACP node and therefore inherits all its security properties, i.e., message integrity, message confidentiality and the fact that unauthorized nodes cannot join the ACP. All ASAs within a I agree with Roman's comment that the "it" whose security properties are inhereited is the ACP *node*, not the ACP itself, and thus that some rewording is appropriate. The GRASP API library would need to communicate with the GRASP core via an inter-process communication (IPC) mechanism. The details of Hmm, if the GRASP core is in kernel-space and the API library in userspace, wouldn't we normally refer to that exchange as a system call rather than IPC? (Figure 1 also labels this interaction "IPC".) Section 2.1 * Authorization of ASAs is not defined as part of GRASP and is not supported. Any chance I could interest you in s/not supported/a subject for future work/? It is looking somewhat likely since such a statement is already present in the security considerations... * User-supplied explicit locators for an objective are not supported. The GRASP core will supply the locator, using the ACP address of the node concerned. This would seem to prevent any non-ACP use of GRASP; I suggest adding some language with a caveat about "for example" or similar, unless the intent is to limit the API usage to ACP (or DULL) scenarios. Section 2.2.1 I think that the possibility for a single outbound message to get a sequence of incoming replies (at different times) further complicates the design of an asynchronous mechanism, and we would do well to discuss how such scenarios (e.g., broadcast discovery messages) would be handled by the implementation and API. (I see that we do end up using a timeout in practice to resolve this topic, but would probably still mention it as an issue that has been resolved, here.) Section 2.2.2 ports rather than a separate port per session. Hence the GRASP design includes a session identifier. Thus, when necessary, a 'session_nonce' parameter is used in the API to distinguish simultaneous GRASP sessions from each other, so that any number of sessions may proceed asynchronously in parallel. I do see that there was previous discussion on the 'nonce' terminology here, and I am unsure why there is need to move away from the "session ID" terminology used in GRASP itself. In particular, the "session_nonce" is not a number used *once*, rather, it is used only for one session (but potentially multiple times within that session). That, to me, makes it a (short-lived) identifier, not a nonce. Roman's proposal of 'handle' would resolve this apparent disparity. Section 2.2.3 On the first call in a new GRASP session, the API returns a 'session_nonce' value based on the GRASP session identifier. This What does "based on" mean? Does there need to be a one-to-one correspondence? Or just in one direction? Are we going to be constrained by the (IMO, too limited) 32 bits of randomness limit of the GRASP Session ID? Section 2.3.2.3 - Note 3: In a language such as C the preferred implementation may be to represent the Boolean flags as bits in a single byte, Which aspect(s) of C are relevant for the "such as"? An essential requirement for all language mappings and all implementations is that, regardless of what other options exist for a language-specific representation of the value, there is always an option to use a raw CBOR data item as the value. The API will then wrap this with CBOR Tag 24 as an encoded CBOR data item [RFC7049] for transmission via GRASP, and unwrap it after reception. I'm not sure I understand why the bstr wrapping is mandatory -- I would have thought that the attraction of using a raw encoded CBOR data item would be that it could be used directly, without additional wrapping. int loop_count; int value_size; // size of
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-28: (with DISCUSS and COMMENT)
Hi Toerless, On Fri, Oct 02, 2020 at 10:06:14AM +0200, Toerless Eckert wrote: > Thanks, Ben > > Let me just comment on possible AI for you, i will do my AI in a few > days when i have more time. I guess I took more than a few days for mine :( > On Thu, Oct 01, 2020 at 03:32:44PM -0700, Benjamin Kaduk wrote: > > I think A.6 is an interesting idea and don't want to drop the idea, but the > > current state of the text in A.6 is better suited for a separate doc than > > inclusion in this one. I suppose I could try to do a shorter rewrite that > > might be a better fit for this doc if you want; let me know. > > A separate doc would have to be an actual spec of the mechanism IMHO, > and alas i do not have the time right now to start it (and after > we have an ACP RFC maybe i can also find other WG participants to > contribute ;-)). So i do not want to loose the thought and think an > appendix is the best reminder for the problem and solution directions. > > Aka: Yes: If you want to send replacement text, please send it, > and i will replace A.6 with it verbatim. Here's a first crack. I'll set a reminder to read over it again in a few weeks to see if it still looks okay (and presumably we can get some other eyes on it in the intervening period, too). The discovery procedure in this specification for low-level ACP channel support by layer-2 peers involves DULL GRASP and attempting (usually in parallel) to establish all supported channel types, learning the peer ACP address and correspondingly the assignment of Decider and Follower roles, and tearing down all channels other than the one preferred by the Decider. This procedure, in general, becomes resource intensive as the number of possible secure channels grows; even worse, under some threat models, the security of the discovery result is only as strong as the weakest supported secure channel protocol. Furthermore, the unilateral determination of "best" channel type by the Decider does not result in the optimal outcome in all possible scenarios. This situation is tolerable at present, with only two secure channels (DTLS and IPsec) defined, but long-term agility in the vein of [BCP201] will require the introduction of an alternate discovery/negotiation procedure. While IKEv2 is the IETF standard protocol for negotiating security associations, it currently does not have a defined mechanism flexible enough to negotiate the parameters needed for, e.g., an ACP DTLS channel, let alone for allowing ACP peers to indicate their preference metrics for channel selection. Such a mechanism or mechanisms could be defined, but if ACP agility requires introducing a new channel type, for example MacSec, IKEv2 would again need to be extended in order to negotiate an ACP MacSec association. Making ACP channel agility dependent on updates to IKEv2 is likely to result in obstacles due to differeng timescales of evolution, since IKEv2 implementations help form the core of Internet-scale security infrastructure and must accordingly be robust and thoroughly tested. Accordingly, a dedicated ACP channel negotiation mechanism is appropriate as a way to provide long-term algorithm and secure-channel protocol agility. Such a mechanism is not currently defined, but one possible design is as follows. A new DULL GRASP objective is defined to indicate the GRASP-over-TLS channel, which is by definition preferred to other channel types (including DTLS and IPsec). When both peers advertise support for GRASP-over-TLS, GRASP-over-TLS must run to completion before other channel types are attempted. The GRASP-over-TLS channel performs the necessary negotiation by establishing a TLS connection between the peers and using that connection to secure a dedicated GRASP instance for negotiating supported channel types and preference metrics. This provides a rich language for determining what secure channel protocol to use for the ACP link while taking into account the capabilities and preferences of the ACP peers, all protected by the security of the TLS channel. > > > End-to-end communication (inside or outside the ACP) will use the > > > ACP address, and it could authenticate its IPv6 address (the ACP > > > address) by using the ACP certificate during end-to-end authentication, > > > but this spec does not mandate that. > > > > I would like (and will put in my forthcoming COMMENT) to at least mention > > that there are cases where you could do this sort of check, even though it > > is definitely impossible in some cases (such as the secure channel) and > > even if it is not mandated. I think I can live with not requiring it, > > though. > > What do you think would be achieved with such a check ? If we write anything, > we should know (if not write down) the most obvious/relevant attack vector > prohibited:
Re: [Anima] Benjamin Kaduk's Yes on draft-ietf-anima-autonomic-control-plane-29: (with COMMENT)
On Tue, Oct 06, 2020 at 04:43:31PM -0400, Michael Richardson wrote: > On 2020-10-01 6:36 p.m., Benjamin Kaduk via Datatracker wrote: > > A couple of the new bits in the -29 might benefit from targeted review > > (noted > > inline), e.g., for CDDL, TSV, or INT-specific aspects. > > Carsten has already done that for CDDL. (If you have a link handy, I'd love to have it. I couldn't quite convince myself that RFC 8610 actually said that CDDL has the "first successful match" nature of a PEG, with respect to the method-params and extensions. Maybe I was just reading too quickly.) > I'm unclear what TSV and INT specific things you have in mind. Sorry; this was: Attackers on a subnet may be able to inject malicious DULL GRASP messages that are indistinguishable from non-malicious DULL GRASP messages to create Denial-of-Service (DoS) attacks that force ACP nodes to attempt many unsuccessful ACP secure channel connections. When an ACP node sees multiple AN_ACP objectives for the same secure channel protocol on different transport addresses, it SHOULD prefer connecting via the well-known transport address if the secure channel method has one (such as UDP port 500 for IKEv2). This new text should probably be run by some TSV-area reviewer (e.g., AD). (Specifically, the use of the well-known port as a signal.) and If public CA are to be used, ACP registrars would need to prove ownership of the domain-name of AcpNodeNames to the public CA. However, maintaining the ULA based address allocation when using a public CA might be considered to be a violation of the private allocation expectation of ULA prefixes. To avoid this issue, further changes to registrar address allocation procedures might be needed, for example using global IPv6 address prefixes owned by the public CA instead of ULA. I don't expect any problems here, but it might be good to get some INT-area (e.g., AD) eyes on this text. (The ULA usage here is IIUC a bit different than previous revs of the draft.) > > > ACP nodes MUST NOT support certificates with RSA public keys whose > > modulus is less than 2048 bits, or certificates whose ECC public keys > > are in groups whose order is less than 256 bits. RSA signing > > certificates with 2048-bit public keys MUST be supported, and such > > > > I think I mentioned this previously (and sorry for the repetition if I > > did), but just in case I didn't: this 256-bit group order requirement > > excludes Ed25519 and friends. If you're fine with that, that's okay; I > > just want to make sure it's an informed choice. > > Right, Ed25519 is considered to be a curve of 128-bits of equivalent > strength. My understanding is that secp256*, while having 256-bit > curves, is also 128-bits of strength. > And RSA keys of 2048 bits is also of that relative strength. > > I think that this is what Toerless is trying to say, but he didn't get > the wording right. Can you advise what the correct way to ask for this This one is a bit awkward, since we need to allow 2048-bit RSA based on our understanding of the TPM ecosystem, but 2048-bit RSA is currently thought to have roughly 112 bits of strength (you need 3072-bit RSA to get 128-bit strength). RFC 8032 hedges a little bit to say that "Ed25519 is intended to operate at around the 128-bit security level" (i.e., just below). The smallest possible change here would be s/256/254/, I think, but it could be restructured a bit to be genericized if we want, perhaps: % The ACP aims to provide authentication at around the 128-bit security % level or stronger. Accordingly, ACP nodes MUST NOT support certificates % whose ECC public keys are in groups providing weaker security than this % 128-bit level. In order to accomodate limitations of TPM hardware % modules, this requirement is slightly weakened for RSA certificates; ACP % nodes MUST NOT support certificates with RSA public keys whose modulus is % less than 2048 bits (which corresponds to roughly a 112-bit security % level). RSA signing certificates with [...] A parenthetical note that "(this explicitly permits Ed25519 keys)" is possible, but probably optional. > is? Can we just point elsewhere? I am not thinking of anything offhand that we can just refer to, unfortunately. > > I think I may have failed to think about and comment on this previously, > > but doing direct ECDH with the (static) key in the certificate is pretty > > uncommon
[Anima] Benjamin Kaduk's Yes on draft-ietf-anima-autonomic-control-plane-29: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-autonomic-control-plane-29: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ -- COMMENT: -- We're down to largely editorial stuff at this point, and I'm happy with the overall state of things. A couple of the new bits in the -29 might benefit from targeted review (noted inline), e.g., for CDDL, TSV, or INT-specific aspects. Section 6.1 TLS MUST offer TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer options with less than 256 bit symmetric key strength or hash strength of less than SHA384. When TLS 1.3 is supported, TLS_AES_256_GCM_SHA384 One could potentially say "hash strength of less than 384 bits" instead of anchoring the reference point at SHA384, but I'm not terribly concerned about it. TLS MUST also include the "Supported Elliptic Curves" extension, it MUST support the NIST P-256 (secp256r1(22)) and P-384 (secp384r1(24)) curves [RFC4492]. In addition, TLS clients SHOULD send an ec_point_formats extension with a single element, "uncompressed". We can say "TLS 1.2 clients" for the ec_point_format extension (nit: no 's'). Section 6.2.1 Thank you for clarifying the "serialNumber" attribute; I think that will be helpful for a lot of people. ACP nodes MUST NOT support certificates with RSA public keys whose modulus is less than 2048 bits, or certificates whose ECC public keys are in groups whose order is less than 256 bits. RSA signing certificates with 2048-bit public keys MUST be supported, and such I think I mentioned this previously (and sorry for the repetition if I did), but just in case I didn't: this 256-bit group order requirement excludes Ed25519 and friends. If you're fine with that, that's okay; I just want to make sure it's an informed choice. ACP nodes MUST support RSA certificates that are signed by RSA signatures over the SHA-256 digest of the contents, and SHOULD additionally support SHA-384 and SHA-512 digests in such signatures. The same requirements for certificate signatures apply to ECDSA certificates, and additionally, ACP nodes MUST support ECDSA signatures on ECDSA certificates. I think "same requirements for digest usage in certificate signatures" is more accurate. In support of ECDH key establishment, ACP certificates with ECC keys MUST indicate to be Elliptic Curve Diffie-Hellman capable (ECDH): If the X.509v3 keyUsage extension is present, the keyAgreement bit MUST be set. I think I may have failed to think about and comment on this previously, but doing direct ECDH with the (static) key in the certificate is pretty uncommon -- as I understand it you don't need this bit set in order to use the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ciphersuite, for example. To be clear, I'm not saying it's inherently wrong to make this requirement, just that I don't think it's needed for the use-cases presented in this document. (It may also make it harder to get such certificates issued in the future, though it's hard to predict what path CA policies will take in the future.) Section 6.2.3 It might be nice to say something about in what cases the transport address used to reach the peer can/cannot be validated against the acp-address in the peer's ACP certificate. I think there are some classes of interactions for which that check can be done and would add value, even though there are definitely some classes of interaction for which it is not viable. Section 6.2.5.3 When using a private PKI for ACP certificates, the CRL may be need- to-know, for example to prohibit insight into the operational practices of the domain by tracking the growth of the CRL. In this case, HTTPS may be chosen to provide confidentiality, especially when making the CRL available via the Data-Plane. Authentication and authorization SHOULD use ACP certificates and ACP domain membership check. [...] (I assume that the SHOULD here is still only in the case where the CRL is need-to-know; no text changes needed if that's correct.) Section 6.2.5.5 To prohibit attacks that attempt to force the ACP node to forget its prior (expired) certificate and TA, the ACP node should alternate bet
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-28: (with DISCUSS and COMMENT)
Hi Toerless, Also inline, but I think we're in pretty good shape overall. On Fri, Sep 11, 2020 at 02:59:56PM +0200, Toerless Eckert wrote: > Thanks, Ben > > On Wed, Aug 12, 2020 at 04:46:31PM -0700, Benjamin Kaduk via Datatracker > wrote: > > > > -- > > DISCUSS: > > -- > > > > Hopefully just a couple easy ones... > > > > I made a pass over Ekr's ballot comments (nominally on the -16, though > > some of the quoted text doesn't seem to match up with that version). > > We're generally in good shape there, but I wanted to check on the point > > regarding a "downgrade defense on the meta-negotiation between the > > protocols", which in theory would allow an attacker to force the use of > > IPsec or DTLS or whatever other protocol has a weakness. It seems like > > there may have been some confusion about DULL vs ACP GRASP in play here, > > especially with respect to when there might be the possibility of > > multiple secure channels. My current understanding is that there is not > > a major issue here, but let's confirm that: DULL GRASP runs only over a > > local link (using link-local addresses), > > When DULL GRASP runs "autonomously" it would indeed only run link-local. > It would also run across a manually crafted tunnels (section 8.2.2) > to get over a non-autonomic island. That is the least desirable > workaround option (8.2.1 is preferred). And you did add special consideration of controlling what secure channel is used over such tunnels; good idea. > > and as currently defined has > > the option of flooding advertisements that use either DTLS or IKEv2 to > > establish the ACP secure channel. > > Yes. And of course when other protocols are added (e.g.: MacSec), > those would be signalled too. > > > DULL GRASP has no cryptographic > > protections at all, so if there is somehow (e.g., on a multi-access > > link) an attacker on the link, they could drop or rewrite some > > announcements to force either DTLS or IKEv2 to be used for secure > > channel establishment even if the other would normally have been > > preferred. > > Yes. > > > On directly-connected wired links, such tampering may be > > unlikely (but not beyond the capabilities of, e.g., a nation-state or > > well-funded attacker, especially for, e.g., long fiber runs.) > > IMHO quote the opposite: > a) This is not a relevant attack (see below) > b) This is easy to do, e.g.: not only by nation states. > > If the ACP runs across the universities network in e.g.: a student dorm > building > , i don't need nation state attackers. Every CS student could do it. > Likewise in a multi-company office building, etc. pp. > Aka: intercepted wires can and will happen everywhere. > > Aka: I propose "dorm student" as the new meme in addition to nation-states ;-) Arguably a more motivated attacker, even, in some sense -- I like it :) > > By itself, this is not useful, since both DTLS and IKEv2+ESP are believed > > to be secure, but if some future vulnerability is discovered the > > downgrade might allow for the vulnerability to be exploited in cases it > > would not otherwise have been usable. Countermeasures to allow > > detection of this kind of tampering are possible -- include as part of > > the DTLS or IKEv2 exchange (or the first operation after it) a > > preference-ordered list of supported secure channel mechanisms, and bail > > out if the mechanism being used is not the most-preferred shared > > mechanism -- but will still fail if the vulnerability in question is > > sufficiently severe to allow handshake forgery. > > I am surprised this discuss did not come up in before during IESG review. To be clear, this is something that I think Ekr raised in his original ballot, but there was a communication mixup about what the actual issue was (including if it affected DULL vs ACP GRASP), and it didn't get much follow-up discussion or attention until now. > Vor many revisions, aCP draft did NOT announce the supported protocol > options via GRASP exactly because of the concern about downgrade attack, > but then we changed it because a) it provide benefits, b) the downgrade > attack vector IMHO does not exist: > > a) Why signaling protocol option is beneficial: > > When we only signal via DULL GRASP the network layer address but > not the transport address of a supported security protocol, then all > protols we wanted to support would have to be able to run ONLY on well-known > tran
Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-autonomic-control-plane-27: (with DISCUSS and COMMENT)
On Tue, Aug 11, 2020 at 01:22:22AM +, Roman Danyliw wrote: > > > > > ** Section 6.11.1.1.2. A mechanism for failed ACP detected using a > > > secure channel protocol is noted for IPSec (with IKEv2 Dead Peer > > > Detection). What is the equivalent for DTLS? > > > > Good question. If you know someone who could suggest an equivalent, please > > bring her in. Given how this is a performance optimization, i don't think we > > need to bother too much. I hope we can learn from > > implementation/deployment experience (i only hve that for IPsec) and then > > write update text later with such refinements. > > Sorry, I too don't have citable reference. Let's leave it as is. DTLS heartbeats (RFC 6520) would probably be the closest thing to IKE dead peer detection, but it's not a perfect match. (Also, openssl removed all support for heartbeats recently-ish, even for DTLS; I guess heartbleed left too many painful memories.) -Ben ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-28: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-autonomic-control-plane-28: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ -- DISCUSS: -- Hopefully just a couple easy ones... I made a pass over Ekr's ballot comments (nominally on the -16, though some of the quoted text doesn't seem to match up with that version). We're generally in good shape there, but I wanted to check on the point regarding a "downgrade defense on the meta-negotiation between the protocols", which in theory would allow an attacker to force the use of IPsec or DTLS or whatever other protocol has a weakness. It seems like there may have been some confusion about DULL vs ACP GRASP in play here, especially with respect to when there might be the possibility of multiple secure channels. My current understanding is that there is not a major issue here, but let's confirm that: DULL GRASP runs only over a local link (using link-local addresses), and as currently defined has the option of flooding advertisements that use either DTLS or IKEv2 to establish the ACP secure channel. DULL GRASP has no cryptographic protections at all, so if there is somehow (e.g., on a multi-access link) an attacker on the link, they could drop or rewrite some announcements to force either DTLS or IKEv2 to be used for secure channel establishment even if the other would normally have been preferred. On directly-connected wired links, such tampering may be unlikely (but not beyond the capabilities of, e.g., a nation-state or well-funded attacker, especially for, e.g., long fiber runs.) By itself, this is not useful, since both DTLS and IKEv2+ESP are believed to be secure, but if some future vulnerability is discovered the downgrade might allow for the vulnerability to be exploited in cases it would not otherwise have been usable. Countermeasures to allow detection of this kind of tampering are possible -- include as part of the DTLS or IKEv2 exchange (or the first operation after it) a preference-ordered list of supported secure channel mechanisms, and bail out if the mechanism being used is not the most-preferred shared mechanism -- but will still fail if the vulnerability in question is sufficiently severe to allow handshake forgery. ACP GRASP is different, in that it (1) runs over the ACP, so any on-path attack to drop/rewrite GRASP would have as a prerequisite an attacker in the ACP, and (2) unicast GRASP is protected end-to-end by TLS. However, it seems like broadcast/flooded ACP GRASP objectives will only have the hop-by-hop ACP protection and so would in theory also be subject to a downgrade attack if there was an in-ACP on-path attacker. It also seems like there's a general expectation that ACP services will run over TLS, and the option of "TLS *or* DTLS (or something else)" is not expected to be common, so the existence of a downgrade to a different protocol is rare as well. While I would like to be able to defend against downgrade attacks by an in-ACP on-path attacker, I recognize that it's a defensible position to take that we assume all entities in the ACP to remain secure and just accept the corresponding risks in the case of compromise. Similarly, for "big iron" router deployments, physical links are the norm and the DULL GRASP downgrade attack may not be a practical concern; I would again like to have the mechanisms in place to be able to detect downgrade if, for example, deployments broaden to the use of radio technologies, but the absence of such a mechanism does not seem like a critical flaw at this time. So, to be clear, the DISCUSS here is just to be sure that we're all on the same page as to what point Ekr was making and the current state of affairs; given my current understanding, I'm not holding a DISCUSS point for "add the downgrade-detection mechanism" (though I do encourage it). It looks like Section 6.1.3 is missing a "rule 6: verify that the acp-address/prefix in the certificate matches the address being used to talk to the peer", if I'm reading between the lines properly. (If not, and this is just skew introduced by editing, my comments about references to a non-existent rule 6 apply, see COMMENT.) -- COMMENT: -- Th
[Anima] Benjamin Kaduk's No Record on draft-ietf-anima-autonomic-control-plane-27: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-autonomic-control-plane-27: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ -- COMMENT: -- Moving back to No Record as an intermediate state, to note that the issues in the Discuss position I filed on the -19 have all been resolved. (My review of the -27 remains in progress.) Thank you for the extensive efforts you put in to respond to the previous rounds of feedback! I especially appreciate that you were able to continue discussions with Russ and Barry (and others) even when I myself was not being particularly responsive due to other pressing issues. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] ACP RPL root
On Tue, Jul 07, 2020 at 09:47:59PM -0400, Michael Richardson wrote:
>
> Ben, is this DISCUSS comment still alive?
>From memory, I think it's been resolved.
I'm sure that a discuss about whether/how the RPL root is automatically
determined got resolved for *some* document, but am not 100% sure if it was
this one or one of the 6TiSCH ones. In any case, the discussions that
preceded that resolution also served to educate me about some of the finer
points that I had completely missed with my original comment, and that
education (combined with your description below) convinced me that there's
not a (certainly discuss-level, and probably not any) issue here.
-Ben
> > Section 6.11.1.14 places a normative ("SHOULD") requirement on the RPL
> > root, but if I understand correctly the RPL root is automatically
> > determined within the ACP, and thus the operator does not a priori know
> > which node will become the RPL root. Am I misunderstanding, or is this
> > effectively placing this requirement on all ACP nodes?
>
> In LLNs, it is common to designate a specific, high-capacity node as the RPL
> root.
>
> In particular, in non-storing mode, the RPL root has to keep a RIB and FIB
> for every single node, while the other nodes need only three to five FIB
> entries to keep track of parents and active children.
>
> We are using storing mode, so every node already has to have the capacity to
> have a RIB and FIB on the order of the number of ACP nodes.
> This is not arduous for an Enterprise or ISP class router.
> That's the major cost of being the root: the root has to have a complete
> table. (But, in storing mode, we only have next-hop, not the full path)
>
> As originally envisioned, the automonic network should be self-forming and
> self-healing, which means that partitions of the network should recognize
> that there is no root, and choose one. That level of autonomy is not
> reached in this document, or in the ANIMA architecture. In fact, that
> level of autonomy got spun off as the SUPA WG.
>
> So, yes, in theory, all ACP nodes could be the RPL root, and when they do,
> they need to install blackhole route for ULA space fd00::/10 in order to
> prevent loops. This shouldn't be a big deal.
>
> The RPL DODOG root will in mature situations be the ACP registrar,
> and while the market is less mature, in an router designated as the
> ACP-connect.
>
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document
My apologies for commenting before having caught up on the whole thread (I've been pretty sluggish all week and don't want to get even further behind.) On Sat, Jun 27, 2020 at 03:58:21PM -0700, Eric Rescorla wrote: > > Taking a step back from the substantive issue, it seems to me that to the > extent to which their is debate about the meaning of 5280, this is a > discussion which cannot be resolved entirely on this list, but instead > needs to involve the LAMPS WG. This has been a key point that I've (apparently) been failing to make very well so far. E.g., while the ANIMA WG has presumably reached consensus on the use of rfc822Name years ago, I think we also need consensus from LAMPS before we can be confident that there is IETF consensus. Also, making even another step back, it seems that there is a key issue of the CA model in play here, namely "know what you sign". If we are asking a CA to sign an rfc822Name, which the CA treats as having email semantics, but we assign different semantics to that name, then the CA is not actually in knowledge of what it's signing. Accordingly, the CA incurs significant (e.g., legal and financial) risk by making those signatures, and defining the field in this way gives the impression that we are trying to make an end-run around CA policies. -Ben ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Moving forward with draft-ietf-anima-autonomic-control-plane
Hi Éric, On Mon, Jun 22, 2020 at 10:43:00AM +, Eric Vyncke (evyncke) wrote: > As the shepherding AD for this document, I am happy to see recent technical > discussions on this document. OTOH, I do not observe any convergence to > remove the pending DISCUSS. > > > > The 2nd IETF Last Call was completed 2 months ago in April 2020. Joel Halpern > did the review for routing directorate and found a couple of issues (zone-ID, > loopback definition) and it seems that there is now an agreement within the > community for updated the text. > > > > In order to progress the document, a revised I-D is needed to fix Ben’s > DISCUSS points: > > - Use of rfc822Name rather than otherName: the ‘easy’ fix is indeed to use > otherName (even with the section 6.1.2 justifications) Russ has been helping reach out to more of the PKIX community; one suggestion that came up so far is to consider defining a dedicated URI scheme and using a uniformResourceIdentifier SAN -- did the WG consider that in the initial discussions? > - “MTI cryptographic mechanisms are under-specified” that should not be > controversial and easy to fix Toerless has been doing an incredible job reaching out to the IPsec community and getting this text nailed down. There are still a couple points still under discussion but I'm confident that we will have something good here (and IIRC the TLS stuff has already been polished). > - Clarification about the RPL root I'm pretty sure this is already done -- note that my latest ballot position is only for the -19, so I think I just didn't update it yet. > > > Unsure whether Eric Rescola’s DISCUSS are still applicable (as they were on > -16); but, this would be a plus to fix these points. Indeed. I expect the current SEC ADs to review those when the document comes up on a telechat again. > > > I understand that the authors have worked on this for 6 years and may be > bored but I would love to see this I-D going forward. Again, as many others I > fail to see the reason of using rfc822Name and the fix would be to use > otherName. I do not want to put words in anyone's mouth, but my understanding is that the "obvious alternatives" to otherName are believed to suffer from strong deployment difficulties, whether one attempts to use an existing (commercial, or so-called "public" CA) or COTS CA software to run one's own CA. (There is some question as to whether the "public CA" route is advisable at all, given the legal agreements and policy documents surrounding such CAs and whether issuing certificates intended for ACP use is compatible with those policy documents. Sean's review alluded to some of these topics, and if you manage to catch Ryan Sleevi when he has time, he can talk about them at length.) -Ben > > > May I also suggest to the authors to add new co-authors in order to have > ‘fresh blood’ and energy ? > > > > Regards > > > > -éric > > > > > > ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] rfc822Name use in Autonomic Control Plane document
On Sun, Jun 21, 2020 at 12:28:25PM -0400, Michael Richardson wrote: > > Russ Housley wrote: > > One cannot send email to the character string in this specification, so > > it should not be carried in the rfc822name. > > You can send email to that character string if you configure the MX. > It was designed specifically to accomodate that. > > I objected at the time: I thought it was a stupid feature, that no sensible > IKEv2 daemon > was going to have to send/receive email. > > But, Toerless was paranoid that if we did anything at all out of the > ordinary, that the corporate CA people, in order to protect their fiefdom, > would freak out and throw some huge roadblock in the way of deploying the ACP. I note that the -24 discusses creating a single mailbox rfcSELF@, which receives mail for *all* ACP identities in the domain, yet we are in other parts of the document claiming that these identities are distinct and in many cases will be granted different authorizations. If these identities are supposed to be equivalent in the "RFC 822" sense, then it seems inconsistent to use the rfc822Name field (which sees them as equivalent) yet treat them as distinct entitites. -Ben ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] rfc822Name use in Autonomic Control Plane document
Hi Brian, On Fri, Jun 19, 2020 at 05:11:30PM +1200, Brian E Carpenter wrote: > Hi Ben, > > (Back on line after a couple of days spent moving apartments.) (and me after getting slowed down by being sick) > On 17-Jun-20 14:44, Benjamin Kaduk wrote: > > Hi Brian, Michael, > > > > On Tue, Jun 16, 2020 at 02:14:24PM +1200, Brian E Carpenter wrote: > >> On 16-Jun-20 12:20, Michael Richardson wrote: > >>> > >>> Hi, I have had a few conversations with Toerless who is trying to deal > >>> with > >>> the feedback on the ACP document. > >>> > >>> An item that has come up is the use, or claimed abuse of the rfc822Name > >>> SAN. > >>> > >>> We already had this debate. > >>> Some time ago. The WG decided. > > > > With all due respect, this is not the sole decision of the ANIMA WG to > > make. If WGs had such authority then why bother with cross-area review? > > Yes, but that was exactly the reason we had the discussion a year ago. I think the expansion of the "we" is important, here -- who did you have in mind? > >>> Three or four years ago, I think. > >> > >> Yes, this is relitigating an issue that was resolved a long time ago in > >> discussing Ben's DISCUSS: > > > > I'm not sure I understand why you use the word "resolved" here: > > > >> https://mailarchive.ietf.org/arch/msg/anima/lnZ-ykqas487qih86sYNVsUGbsc > > > > In this message, I say that "I still feel like this is not the best > > architectural choice" and that I will provide a sketch of an alternative in > > my (then-)forthcoming ballot position; that ballot position retains the > > Discuss-level concern about rfc822Name usage along with the promised > > alternative. > "Not the best choice" is not a DISCUSS criterion according to the IESG's own > rules at > https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-undisc > > It was exactly this sort of endless debate over "best choice" disagreements > that caused the IESG to adopt the DISCUSS criteria rules in the first place. > > If you are saying that one of the criteria in > https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-disc > applies, that's a different matter, of course. But really, no AD should hold > a DISCUSS over "not the best choice". Sorry, that was the second round of Discuss and my politness filter may have been overactive. Allow me to rephrase: I think that the use of rfc822Name in this document is inconsistent with the specification for that field given in RFC 5280. I do not believe that there is IETF consensus (specifically, including the IETF PKIX community, e.g., the LAMPS WG) for this deviation from the RFC 5280 behavior, and it is not documented (and consensus obtained for it) as such a deviation from RFC 5280. I believe there are several ways in which the necessary functionality for this specification can be obtained that remain consistent with RFC 5280; specifying the use of any of them would suffice to resolve the Discuss point. The "smallest diff to the text" option would be to define an otherName OID to carry the same contents currently specified for rfc822Name, but other options involving splitting the semantic components into EKU/iPAddress SAN/extension/etc. are possible. I could probably even accept a non-normative note saying that some legacy deployments used the rfc822Name field, though given Sean's review there would probably need to be a pretty strong disclaimer of the risks of doing so. [one more note at the end] > Not to mention that this is only a Proposed Standard discussion; perfection > not required. > > I don't consider myself enough of a subject matter expert to comment on the > technical issue itself. > > Regards > Brian > > > > >> The explanation is at > >> https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-24#page-26 > > > > I appreciate that the attempted justification is clearly written; however, > > I do not find it compelling. Russ did not, either, and I just heard back > > from Sean Turner a few days ago to confirm that he supports Russ's > > comments. (There should be a few other editorial-ish comments that came > > out of that review that are still pending.) > > > >> I believe it is incorrect IETF process to rediscuss this point yet again. > > > > (I'm not sure if the "yet again" refers to "after the WG decided" or "after > > the (alleged) resolution of my first Discuss p
Re: [Anima] rfc822Name use in Autonomic Control Plane document
Hi Brian, Michael, On Tue, Jun 16, 2020 at 02:14:24PM +1200, Brian E Carpenter wrote: > On 16-Jun-20 12:20, Michael Richardson wrote: > > > > Hi, I have had a few conversations with Toerless who is trying to deal with > > the feedback on the ACP document. > > > > An item that has come up is the use, or claimed abuse of the rfc822Name SAN. > > > > We already had this debate. > > Some time ago. The WG decided. With all due respect, this is not the sole decision of the ANIMA WG to make. If WGs had such authority then why bother with cross-area review? > > Three or four years ago, I think. > > Yes, this is relitigating an issue that was resolved a long time ago in > discussing Ben's DISCUSS: I'm not sure I understand why you use the word "resolved" here: > https://mailarchive.ietf.org/arch/msg/anima/lnZ-ykqas487qih86sYNVsUGbsc In this message, I say that "I still feel like this is not the best architectural choice" and that I will provide a sketch of an alternative in my (then-)forthcoming ballot position; that ballot position retains the Discuss-level concern about rfc822Name usage along with the promised alternative. > The explanation is at > https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-24#page-26 I appreciate that the attempted justification is clearly written; however, I do not find it compelling. Russ did not, either, and I just heard back from Sean Turner a few days ago to confirm that he supports Russ's comments. (There should be a few other editorial-ish comments that came out of that review that are still pending.) > I believe it is incorrect IETF process to rediscuss this point yet again. (I'm not sure if the "yet again" refers to "after the WG decided" or "after the (alleged) resolution of my first Discuss point".) If you believe the technical answer is clear and that I am in error to continue to hold my Discuss point for it, are there not also clear IETF processes to follow? E.g., asking for the "Single Discuss" ballot procedure described at https://www.ietf.org/standards/process/iesg-ballots/? I believe I have mentioned this option to Toerless previously; my apologies if that is not the case. While I'm willing to continue discussing the topic and pull in additional PKIX experts to weigh in, there is perhaps some consideration to matters of expediency. > > > > I sure wish that we could use something else. > > But, CAs and CA software make that very difficult. > > > > Given that the era of publically anchored Enterprise CAs is dead, there are > > only two ways an (Enterprise) ACP Registrar is going to occur. > > > > 1) by running a private CA. > >Sure anything is possible if you are writing your own code, but > >most will not be doing that. (I've supported otherName in my code for > >other purposes, and it's not that difficult, but it's not trivial either) > >My experience with COTS CA systems it that it's really hard to > >get them to do it.Please prove me wrong. (Sadly, I have zero experience with COTS CA systems; I know too much about openssl at this point and would presumably be writing my own, in this position.) > >The most popular Enterprise CA software is the Microsoft CA. > > > > 2) by using ACME to speak to a hosted CA. Maybe WebPKI, maybe not. > >Either way, getting otherName supported is even harder, because > >nobody else uses it. Is the concern the ACME protocol support or just getting the hosted CA to cope with it? The former seems like something that we could make happen in the IETF, and the latter seems to have high overlap with point (1). > > If we can't depend upon otherName being filled in, then we have to look for > > two things. That means more code paths (two more) to test, more test > > vectors, and what exactly does an end point do when both are present, BUT > > THEY DO NOT MATCH? So three more pages of text there. > > Remember, that just rejecting the certificate means that we have to send out > > a truck, which is what ACP aims to avoid, so that won't be popular. > > And of course, there could also be bugs (maybe even CVEs) in the code that > > tries to deal with the tie. To be honest, this argument feels like a stronger one to me than the bits in the -24. I'm still not willing to accept into the RFC Series a document that violates the rules set down by the specification for the technology it's making use of, but the refocus on the "running code" aspect is appreciated. -Ben ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] Benjamin Kaduk's Yes on draft-ietf-anima-bootstrapping-keyinfra-40: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-40: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ -- COMMENT: -- Thanks for putting in all the work to get this over the finish line! I did a final read-through before entering my YES, which produced some non-blocking comments. Section 5.1 The signatures in the certificate MUST be validated even if a signing nit: just "signature" singular? Section 5.2 assertion: The pledge indicates support for the mechanism described in this document, by putting the value "proximity" in the voucher- request, and MUST include the "proximity-registrar-cert" field (below). Sorry if I asked this already, but is the "MUST include" only when the "proximity" assertion is used? The current text could be read that it applies always. Section 5.4 It's too bad we can't mention SCRAM in addition to Basic and Digest, but I guess that ship has sailed. Section 5.5 The voucher media type "application/voucher-cms+json" is defined in [RFC8366] and is also used for the registrar voucher-request. It is a JSON document that has been signed using a CMS structure. The registrar MUST sign the registrar voucher-request. [...] [...] [...] MASA impementations SHOULD anticipate future media types but of course will simply fail the request if those types are not yet known. I think these two paragraphs were originally next to each other but with the large amount of intervening text it seems like the transition could be improved. Section 5.5.2 A certificate chain is extracted from the Registrar's signed CMS container. This chain may be as short as a single End-Entity (I guess technically the CMS structure is an unordered set of certificates, not a chain, but we're using it as a chain so I don't mind this usage.) The MASA MAY use the highest certificate from the certificate chain that it received from the Registrar, as determined by MASA policy. A "highest certificate" is not a particularly common usage; "farthest in the chain from the end entity" might be more conventional. Section 5.5.3 As described in Section 5.5.2, the MASA has extracted Registrar's domain CA. This is used to validate the CMS signature ([RFC5652]) on the voucher-request. Normal PKIX revocation checking is assumed during voucher-request signature validation. This CA certificate MAY have Certificate Revocation List distribution points, or Online Certificate Status Protocol (OCSP) information ([RFC6960]). If they are present, the We could maybe wordsmith this a bit to only cover the case when the pinned-domain-cert is a CA cert (vs. end entity). Section 5.5.4 This section mentions that checking for the presence of id-kp-cmcRA in the registrar's cert protects the domain in some cases, but that protection is probably weakend in cases when the pinned-domain-cert is not the domain's root CA. That said, the failure mode is not catastrophic, since the registrar still has to authenticate to the MASA somehow, and the MASA logic can account for the different cases. Section 5.6 correct registrar, the pledge MUST NOT follow more than one redirection (3xx code) to another web origins. EST supports s/web origins/web origin/ Section 5.6.1 missing close parenthesis for "(according to local policy[...]" Section 5.8.2 The domainID is determined from the certificate chain associated with the pinned-domain-cert and is used to update the audit-log. Is it determined from the "chain associated with" or just the "pinned-domain-cert" itself? Section 7.1 Join Proxy: Provides proxy functionalities but is not involved in security considerations. The Join Proxy is not involved in crypto, as noted here, but could drop or delay traffic. Section 7.3 X.509 IDevID factory installed credential. New Entities without an X.509 IDevID credential MAY form the Section 5.2 request using the Section 5.5 format to ensure the pledge's serial number information is provided to the registrar (this includes the IDevID AuthorityKeyIdentifier value, which would be statically configured on the pledge.) The pledge MAY refuse to provide a It&#
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)
On Wed, Apr 01, 2020 at 02:25:30PM -0400, Michael Richardson wrote: > > Hi, I had a discussion with Max this morning. He reminded me of the back and > forth that we made on what thing would be pinned. > We have come up with the following text changes. > > There are three pieces: the Registrar, to the MASA, and re-inforcing the > RFC8366 process at the Pledge as it applies to provisional TLS connection. > > I haven't read the rest of this thread. > I will do that this afternoon, and I may polish this diff based upon comments > there. Thanks, this seems like it will hit all the right spots. A few aids to polishing inline. > > https://tinyurl.com/uek8a66 > > @@ -2043,8 +2044,39 @@ locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, > nil]]]> > The voucher media type "application/voucher-cms+json" is defined > in > and is also used for the registrar > voucher-request. It is a JSON document that has been >signed using a CMS structure. > - The registrar MUST sign the registrar voucher-request. The entire > registrar certificate chain, > - up to and including the Domain CA, MUST be included in the CMS > structure. > + The registrar MUST sign the registrar voucher-request. > + > + > + is quite flexible in what may be put into > + the 'pinned-domain-cert': it may range from the End Entity (EE) The transition from "registrar voucher request" to "pinned-domain-cert" is pretty abrupt; maybe something like "the voucher-request CMS object includes some number of certificates that are input to the MASA as it populates the "pinned-domain-cert" field of the voucher."? > + Certificate that the Registrar uses, to the entire private > + Enterprise CA certificate. > + More specific certificates result in a tighter binding, while less > + specific certificates result in more flexibility. This leaves what exactly is tightly bound/flexible a bit vague (which may be good!); if I did want to be more specific it might be "tigher binding of pledge to authorized entity in the Domain", which ... doesn't exactly roll of the tongue. > + > + > + A Registrar which is seeking a nonceless voucher for later offline > use > + benefits from a less specific certificate, as it permits the actual > + keypair used by a future Registrar to be determined by the pinned > + certificate authority. > + > + > + A less specific certificate, such a public WebPKI certificate > authority, would be Maybe "In some cases a less specific certificate, [...], could be too open"? (Add "In some cases" and s/would/could/.) > + too open, and could permit any entity that can receive a > + certificate from that authority to assume ownership of a device Maybe "any entity issued a certificate by that authority"? > + that has a voucher pinned. > + Future work may provide a solution to pin both a certificate and a > + name. ", that would reduce such risk of malicious ownership assertions"? > + > + > + The Registrar SHOULD request a voucher with the most specificity > + consistent with the mode that it is operating in. > + In order to do this, when the Registrar prepares the CMS structure > + for the signed voucher-request, it SHOULD include only certificates > + which are part of the chain that it wishes the MASA to pin. > + This MAY be as small as only the End-Entity certificate (with > cmcRC set) that Hmm, we do use a bare "cmcRC" exactly once in the -39, but id-kp-cmcRA appears twice. (I'm not sure whether it matters which one to write.) > + it uses as it's TLS Server Certificate, or it MAY be the entire > + chain, including the Domain CA. > > > MASA impementations SHOULD anticipate future media > @@ -2140,19 +2172,29 @@ locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, > nil]]]> > > > > -The registrar's certificate chain is extracted from the signature > -method. The entire registrar certificate chain was > -included in the CMS structure, as specified in target="RequestVoucherFromMASA" />. > -This CA certificate will be used to populate the > -"pinned-domain-cert" of the voucher being issued. > +A certificate chain is extracted from the Registrar's signed CMS > container. > +This chain may be as short as a single End-Entity Certificate, up > +to the entire registrar certificate chain, including the Domain > +CA certificate, > +as specified in . > > > -If this domain CA is unknown to the MASA, then it is to be > +If the domain's CA is unknown to the MASA, then it is to be > considered a temporary
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)
On Tue, Mar 31, 2020 at 08:02:07AM -0700, Benjamin Kaduk wrote: > > I am even willing to produce an updated example voucher artifact myself, if > that would help expedite things -- I believe I already have the needed > keys/certs locally from my review of the -39. As an alternate option, if I think I managed to do this (though I didn't adjust my clock to try to reproduce the signing time); attached. -Ben MIIHWgYJKoZIhvcNAQcCoIIHSzCCB0cCAQExDTALBglghkgBZQMEAgEwggQMBgkqhkiG9w0BBwGg ggP9BIID+XsiaWV0Zi12b3VjaGVyOnZvdWNoZXIiOnsiYXNzZXJ0aW9uIjoibG9nZ2VkIiwiY3Jl YXRlZC1vbiI6IjIwMjAtMDItMjVUMTg6MDQ6NDkuMzAzLTA1OjAwIiwic2VyaWFsLW51bWJlciI6 IjAwLUQwLUU1LUYyLTAwLTAyIiwibm9uY2UiOiJhTWpndWVLVVQtMjJ3VmltajZ6MjdRIiwicGlu bmVkLWRvbWFpbi1jZXJ0IjoiTUlJQ2F6Q0NBZktnQXdJQkFnSUVLV3NHV1RBS0JnZ3Foa2pPUFFR REFqQnRNUkl3RUFZS0NaSW1pWlB5TEdRQkdSWUNZMkV4R1RBWEJnb0praWFKay9Jc1pBRVpGZ2x6 WVc1a1pXeHRZVzR4UERBNkJnTlZCQU1NTTJadmRXNTBZV2x1TFhSbGMzUXVaWGhoYlhCc1pTNWpi MjBnVlc1emRISjFibWNnUm05MWJuUmhhVzRnVW05dmRDQkRRVEFlRncweU1EQXlNalV5TVRNeE5E VmFGdzB5TWpBeU1qUXlNVE14TkRWYU1HMHhFakFRQmdvSmtpYUprL0lzWkFFWkZnSmpZVEVaTUJj R0NnbVNKb21UOGl4a0FSa1dDWE5oYm1SbGJHMWhiakU4TURvR0ExVUVBd3d6Wm05MWJuUmhhVzR0 ZEdWemRDNWxlR0Z0Y0d4bExtTnZiU0JWYm5OMGNuVnVaeUJHYjNWdWRHRnBiaUJTYjI5MElFTkJN SFl3RUFZSEtvWkl6ajBDQVFZRks0RUVBQ0lEWWdBRUczOVp1aGZER3J4bWpZeHM0TVA2TVhFUFpm WWlrYjIzVm9BSDI5KzRlcVZGVFhtS1JwY1pXWll4c1k5cGZUSytQTWcrVzJPMVJ2YW8xVytiK2NE ejA3a1VQM0pIVWFSMjNkTHd2L1hLanpBQmYvakNYOVAxSUFORWk0dnlCMnkwbzJNd1lUQVBCZ05W SFJNQkFmOEVCVEFEQVFIL01BNEdBMVVkRHdFQi93UUVBd0lCQmpBZEJnTlZIUTRFRmdRVXVhWDJ5 eEhoQjZSSkxLY0l4bndRdkllemRDWXdId1lEVlIwakJCZ3dGb0FVdWFYMnl4SGhCNlJKTEtjSXhu d1F2SWV6ZENZd0NnWUlLb1pJemowRUF3SURad0F3WkFJd0lJTUd6bzJZcEZSNlpreEtPbkRDVWpa YVVvMVpmU0NiS21rVVdJYzQyRlY1M2YwcE9KVWVrWk4ydFBWbUtVUzBBakJ2T1BtdkV1MHcxWVVw ZkxFV1dMMW5rVVBFRFRENTJCeXNMd2Jkdk5VR1FpeUVvZ1RxQXFSZkYxRW0rOWt2MGx3PSJ9faCC AeMwggHfMIIBZKADAgECAgQbmV9UMAoGCCqGSM49BAMCMF0xDzANBgNVBAYTBkNhbmFkYTEQMA4G A1UECAwHT250YXJpbzESMBAGA1UECwwJU2FuZGVsbWFuMSQwIgYDVQQDDBtoaWdod2F5LXRlc3Qu ZXhhbXBsZS5jb20gQ0EwHhcNMTkwMjEyMjIyMjQxWhcNMjEwMjExMjIyMjQxWjBfMQ8wDQYDVQQG EwZDYW5hZGExEDAOBgNVBAgMB09udGFyaW8xEjAQBgNVBAsMCVNhbmRlbG1hbjEmMCQGA1UEAwwd aGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIE1BU0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASq BBWjRLniRPjJ+RsHG6Z0c5weumyps6kwqaIyWfegHUcBbbkwlX6CqLi0wV9InSITC3ySzN9Zcris uAlLaaeloxAwDjAMBgNVHRMBAf8EAjAAMAoGCCqGSM49BAMCA2kAMGYCMQC9VeWbDvv8XpUp44Gz FTWqkxiiBL5EcrJRfU1t69HVwRA6sjl7Vz/FzLCjDueZRroCMQD2f0R9txT60Wdq1BHDS67m+5qY VvqFIS5cSEzwP/KbP66IIKeu+XL/W/l4aM8PSMkxggE6MIIBNgIBATBlMF0xDzANBgNVBAYTBkNh bmFkYTEQMA4GA1UECAwHT250YXJpbzESMBAGA1UECwwJU2FuZGVsbWFuMSQwIgYDVQQDDBtoaWdo d2F5LXRlc3QuZXhhbXBsZS5jb20gQ0ECBBuZX1QwCwYJYIZIAWUDBAIBoGkwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMzMxMTUzNjI0WjAvBgkqhkiG9w0BCQQx IgQgV6/9LkRYNQgQ0oT8+HZYJO7HUJFwz61YtYUr6doRW+wwCgYIKoZIzj0EAwIERjBEAiAfULwy RfQSVri94NG0IPjuQobKL8IFrsRAwZ3BF+XaUgIgZpF/riwqsn6g81fNV0YQbJ9TMB5iCvHYRUom f4rmtXs= ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)
Hi Michael, On Mon, Mar 30, 2020 at 10:10:52PM -0400, Michael Richardson wrote: > > > Benjamin Kaduk via Datatracker wrote: > > Unfortunately, it seems that the "pinned-domain-cert" in the issued > voucher > > is the registrar's cert, not the CA cert. (Given that the documented > > workflow is > > That's entirely correct. > The thing in the voucher validates the TLS connection that the pledge sees. I'm not quite sure if the "that" that is entirely correct is intended to be "the voucher artifact in the -39" or "pinned-domain-cert should be the CA cert that signed the registrar's cert". I agree that the primary role of the pinned-domain-cert is to validate the provisional TLS connection to the registrar, but validating a TLS connection can be done by indicating that any certificate in the chain is trusted, from leaf/end-entity up to root CA. If the pledge goes on to perform full EST (which is currently listed as optional), then the exact contents of the pinned-domain-cert don't matter in practice very much other than validating the provisional TLS connection, but for the case where the pledge stops after BRSKI and does not do full EST, having a domain CA certificate seems much more useful than just knowing that the registrar's end-entity certificate is trusted. My interpretation of "pinned-domain-cert is always a CA certificate" seems to have persistent support throughout the text: Section 5.5.2: The registrar's certificate chain is extracted from the signature method. The entire registrar certificate chain was included in the CMS structure, as specified in Section 5.5. This CA certificate will be used to populate the "pinned-domain-cert" of the voucher being issued. Section 5.6: pinned-domain-cert: The domain CA cert. See Section 5.5.2. This figure is illustrative, for an example, see Appendix C.2 Section 5.6.2: The 'pinned-domain-cert' element of the voucher contains the domain CA's public key. The pledge MUST use the 'pinned-domain-cert' trust anchor to immediately complete authentication of the provisional TLS connection. [...] The pinned-domain-cert MAY be installed as an trust anchor for future operations such as enrollment (e.g. [RFC7030] as recommended) or trust anchor management or raw protocols that do not need full PKI based key management. It can be used to authenticate any dynamically discovered EST server that contain the id-kp-cmcRA extended key usage extension as detailed in EST RFC7030 section 3.6.1; but to reduce system complexity the pledge SHOULD avoid additional discovery operations. Instead the pledge SHOULD communicate directly with the [...] but I'd be happy to learn why I'm misreading things. As far as the bigger picture goes, I think that the BRSKI document as a whole is essentially done, and only know of the last issues (noted in my ballot position on the -39) that, given my current understanding of the document, seems to be factual errors where the document is internally inconsistent with itself. Once they get resolved (whether by educating me on my improper understanding or by updating the text), I expect to change my ballot position to YES so the document can get approved for publication. (With Ignas having cycled off the IESG, it currently does not have a YES.) I am even willing to produce an updated example voucher artifact myself, if that would help expedite things -- I believe I already have the needed keys/certs locally from my review of the -39. As an alternate option, if more expedient, I could probably even accept just adding a note to the example that says that the pledge goes on to perform full EST, so the pinned-domain-cert is only needed to validate the provisional TLS connection. Please let me know if I'm missing anything here. Thanks, Ben ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-39: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ -- DISCUSS: -- Thanks for the updates leading to the -39; I believe we're almost there! Unfortunately, it seems that the "pinned-domain-cert" in the issued voucher is the registrar's cert, not the CA cert. (Given that the documented workflow is to extract this CA cert from the registrar-voucher-request CMS object, and the registrar-voucher-request in our examples does include both the registrar cert and the CA cert, I wonder if this reflects a bug in the code itself used to generate the examples, in that it picks the wrong cert?) My understanding is that the protocol requires this field to be populated by a CA cert, and the registrar's cert is not a CA cert. I am very hopeful that we can just regenerate the voucher without having to redo the rest of the examples, since we have all the keys and certificate enshrined in the document already, and my apologies for not noticing whether this issue was present in previous revisions as well. -- COMMENT: -- I would make this a Discuss point but I think I already had my chance at the text and missed it: Section C.1.5 says that "The public key is used by the registrar to find the MASA", but it's really the certificate (via the "MASA URL" extension) and not the public key that is so used. I would suggest noting in C.2 that the asn1parse output is truncated at $number columns, and specifically calling out that this makes it hard to differentiate between organizationally related name components, specifically "highway-test.example.com CA" and "highway-test.example.com MASA". (The full asn1parse output from the live openssl CLI is much clearer about the distinction.) ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] We want BRSKI and ACP!
To confirm: I should not be waiting for any other reviews before I look at the -38? (What with it being outgoing-AD-season I can't promise an exact date, but can bump it up the list a bit.) Thanks, Ben ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] We want BRSKI and ACP!
Hi Toerless, On Wed, Mar 11, 2020 at 04:17:44PM +0100, Toerless Eckert wrote: > Thanks, Michael > > Brian, > > At IETF106 i thought if Bens review would remove all discuss, we would have > finished IESG review, but that is not the case because two of the > IESG members that had approved ACP draft have since left office, so > their votes do not count. I did report that at ANIMA WG @IETF106. > > At IETF106 we had both the ACP report from me of -21, as well as Ben's > presentation on the main issue he saw, the encoding of the ACP > domain information field in the certificate. > > While i had hoped that the in-person discuss about that issue would > resolve that discuss because we did explain all the argments for it, > his discuss of -21 on 12/30/2019 did i think not change his position, I had also hoped that, though it did at least give me a better understanding of the situation and the interplay amongst the various pieces. > instead it also mentioned IPsec experts supporting that view, but > without a technical explanation why, or who all those experts where. I think it's more of a matter for PKIX experts (e.g., LAMPS WG) than IPsec, since it relates to X.509 certificate contents. I've asked Russ Housley to take a closer look and produce some comments, and have a todo item to get another expert or two to opine. > In January, i worked on -22 to answer to Bens review of -21. which i > published 02/03/2020. For the encoding issue i rewrote the bullet > points justifying the choice of encoding, primarily pointing to the > fact that rfc822 names are nowadays quite common identifiers in a > lot of e.g.: web systems, in addition to all the benefits of avoiding > new or extensions to certificate parsing libraries and the like. > > Through IETF106 and writeup of -22 i even think more this > is a pragmatic, prudent and logical choice, and i couldn't find > anything in the cert related RFCs i read that seemed to contradict this for > me. I'll also mention again that there are procedures in place that can allow a document to proceed even with a "holdout" Discuss position such as mine: per https://www.ietf.org/standards/process/iesg-ballots/ the sponsoring AD can request the "Single Discuss" procedure be used, or ask the chair to invoke the "Alternate" ballot procedure. > In February, Ben had told me, that -22 resolves his other points, > except that that he continues on his position re. the encoding. > But there was also security profile work improved in -22. I'm very happy to see those improvements and the exchanges with the IPSECME WG; thank you again for driving that! -Ben > Shortly after IETF 106, Eric Vyncke took over as sponsoring AD for > ACP. He provided a review with 72 comments in january to the authors. > After i finished -22, i worked on these 72 points through february and posted > -23/24 last week. > > In addition, during february, i also started to reach out to IPsec > mailing list to further discuss details of the proposed enhancements > to the IPsec profile. I ran out of time last week, and plan to > finalize those fixes quickly (together with the WG fix sugestions i > received for -24). > > In addition, i will also reach out directly to the IPsec experts > i know and ask for the rfc822name encoding. I did that already > last year, but never received replies. > > Eric told me, he wants to put ACP back onto the IESG agenda for April, > and this would result in a new IETF review. > > Thats all i know. > > Cheers > Toerless > > On Wed, Mar 11, 2020 at 09:57:56AM -0400, Michael Richardson wrote: > > > > Brian E Carpenter wrote: > > > Could those on the hook for the ACP and BRSKI drafts, which have been > > > very seriously delayed, update the WG with the plan for getting them > > > approved? It seems to me that there has been endless nitpicking, of > > the > > > kind that is appropriate for full Standard status, but very surprising > > > for Proposed Standard where there is no expectation of perfection. > > > > I don't know what kind of plan I can relate: It seems to be above my pay > > grade. > > > > For BRSKI, since IETF106, all DISCUSSes, except Ben Kaduk's desire to have > > the examples redone have been cleared. I had originally tagged redoing that > > for AUTH48 time, since all IANA allocations would be done by then. > > All allocations have been done at this point, and in January I redid the > > examples in the non-normative Appendix with the right OIDs. Ben found some > > errors (one repeated certificate), and so I generated the examples again. > > > > I then asked Jim Schaad and Max Pritikin (a BRSKI co-author, who has been > > redirected on other important Cisco work), to validate. Max reviewed, and > > this resulted in an additional clarifiying sentence committed to the github. > > (I thought I posted it on Monday, I don't seem to have. I will do that now. > > > > Warren Kumari has taken over as the sponsoring AD. > > > > > Can we ex
[Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-35: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-35: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ -- DISCUSS: -- Thanks for the updated examples using the allocated MASA URL extension OID! Unfortunately, I think there are still some inconsistencies in the examples to resolve: The MASA cert/key is identical to the "manufacturer key pair for IDevID signatures" (C.1.1 and C.1.2). (It shows the MASA Subject CN, so maybe just the included file was typo'd?) The example IDevID cert shows an issuer name that doesn't match the cert given. (Also the MASA cert doesn't have a randomized serial number but the registrar one does.) The registrar-to-MASA voucher request in C.2.2 seems to have a CMS SignedData with the SignerIdentifier identifying the "Unstrung Fountain Root" (i.e,. the root CA used for these examples) instead of the expected "fountain-test.example.com". Am I misreading the ASN.1 dump? (We do seem to send both certificates.) The voucher response from MASA to Registrar seems to be signed by the "highway-test.example.com CA" (which would be the "manufacturer key pair for IDevID signatures" that we don't have in the -35 since the MASA certificate is repeated), not the MASA's cert from C.1.1. -- COMMENT: -- [trimming presumably stale comments] ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-31: (with DISCUSS and COMMENT)
On Tue, Dec 31, 2019 at 03:15:53PM -0500, Michael Richardson wrote: > > A diff against -31 is at: https://tinyurl.com/vuls2ge > and will be posted as -32 in a few minutes. > Commit with edits here: > https://github.com/anima-wg/anima-bootstrap/commit/0bdd9aaf206b0f2d70c51a7c9636a8249fd1366f > > BTW: I haven't heard from Roman since IETF107. > I am also converting to v3 format now, so there are some slight formatting > changes. (*->o, some extra spaces in places) > > I have addressed all of your comments, and I've checked that all the -29 > comments have been addressed. > > Benjamin Kaduk via Datatracker wrote: > > -- > > DISCUSS: > > -- > > > Thanks for providing a clear specification of the /enrollstatus EST > > endpoint in the -30. The following two points still seem unaddressed, > > though. > > > The -29 reworks the definition of the 'nonce' field to be: > > > strong random or pseudo-random number nonce (see [RFC4086] > > section 6.2). As the nonce is usually generated very early in the boot > > sequence there is a concern that the same nonce might generated across > > multiple boots, or after a factory reset. Difference nonces MUST NOT > > generated for each bootstrapping attempt, whether in series or > > concurrently. The freshness of this nonce mitigates against the lack > > of real-time clock as explained in Section 2.6.1. > > > This needs to either be "Different nonces MUST be generated" or "the > > same nonce MUST NOT be reused"; this mashup is no good. > > Fixed. > > > Email exchange with mcr notes: > >> > An RFC Editor note about the RFC 8366 assignment of OID > > >> 1.2.840.113549.1.9.16.1.40 was removed from -23 to -28; do the > >> examples > properly use that assigned OID now? > >> > >> We got a MASA URL Extension OID for: 1.3.6.1.5.5.7.1.32 > >> > >> the examples date from before that, and do not use it yet. > > > We need to fix the examples before publication. > > Yes, I believe that there will be time to update them while in RFC editor > queue. I want the examples to be produced by code that has interoperated. That's a reasonable desire, but not a compelling reason why the document has to go to the RFC Editor before the examples are correct. Perhaps adding an RFC Editor note that the extension OID used must be the one allocated by IANA, akin to what's done in https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-08#page-10 , would be appropriate? > > -- > > COMMENT: > > -- > > > A few new comments on the -30 and -31 to start. I think some of my > > comments on the -29 are still valid, and will try to remove ones that > > have been addressed. To reiterate: to the best of my knowledge, all > > the comments in this ballot position are actionable and have not been > > overtaken by events. > > okay. > > > In Section 5.9.4: > > >In the case of a FAIL, the same TLS connection MUST be used. The > > Reason string indicates why the most recent enrollment failed. > > > I'd suggest something more like "In the case of a failed enrollment, > > the client MUST send the telemetry information over the same TLS > > connection that was used for the enrollment attempt, with a Reason > > string indicating why the most recent enrollment failed. (For failed > > attempts, the TLS connection is the most reliable way to correlate > > server-side information with what the client provides.)" (Also, why is > > "FAIL" capitalized?) > > I have used your text. The fail was capitalized because bold is not > available. > Further down, we capitalize SUCCESS. > > > Thanks for the text in Section 11.2 about second-preimage-resistance of > > DomainID calculation; the grammar needs a tweak or two, though. My > > suggestion would be to either drop "The consequences of" or add "be to" > > to make "would be to allow" (but not both). > > Done. > > > Section 11.3 has gone back to just "Devices which are reset to factory > > default in order to perform a second bootstrap with
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-19: (with DISCUSS and COMMENT)
strong-arm Valery Smyslov into taking a look, and I digested his comments into a pull request at https://github.com/anima-wg/autonomic-control-plane/pull/9 . Note that I marked it as "WIP", as Valery's preferences are to defer to the existing usage guidelines RFCs as much as possible, so that we don't need to say anything at all about several of the parameters. I also wanted to check one last time that the goal is still to go for the 256-bit security level across the board, as a couple things might get tweaked otherwise. > 3. RPL root provisions for logging unknown destinations Just to be concrete, the updated text does address my last discuss point -- thanks! Sorry again for the delay -- I really needed some time to try to digest the rfc822Name topic. -Ben > Appended below our last exchange. > > On Tue, Jul 23, 2019 at 01:22:43AM +0200, Toerless Eckert wrote: > > --- Context: > > > > I hope i am correctly restating, that this reply is as follows: > > -> After finishing second round of replies for -16, Ben Kaduk provided a > > reply > >that is now also his new DISCUS position on datsatracker. this is my > > reply > >to that DISCUS. > > > > -> The diff for the changes discussed in this email is: > > > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.19.2.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.19.3.txt > > They are also summarized under section (3) of the -20 changelog. > > > > -> The total changes -19 to -20 are of course: > > > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-19.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-20.txt > > > > > On Tue, Jul 16, 2019 at 03:54:42PM -0700, Benjamin Kaduk via Datatracker > wrote: > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-anima-autonomic-control-plane-19: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ > > > > > > > > -- > > DISCUSS: > > -- > > > > [trimming to just the topics still under discussion; no change to the > > text of the remaining items even though some changes have been made > > to the document] > > > > I think there needs to be some justification of why rfc822Name is chosen > > over a more conventional structure in the otherName portion of the > > subjectAltName, which is explicitly designed to be extensible. > > Let me but the compromise proposal and conditions on top: > > Compromise proposal (not integrated into current text yet): > >The document defines a new otherName like ACPdomainIdentity, type IA5String > >I can figure out how to write the the necessary formal text for this, >stealing from e.g.: rfc8398 or the like (asking for IANA registration > etc..) > i will whine for help (from you) when i fail with that text > formalisms/ASN1. stuff. > >The encoding of the string is the existing domain-information > >The length limitation of 64 for the local part is lifted (yeah). > >The rest of the text (justification for formatting etc.) is appropriately >fixed up. I will remove all the text suggesting this could be an actual >rfc822 address and just escribe it in terms of below reasoning (nice format >to express domain based identities "local+policies@domain" or the like. > > Condition: > >Sufficient support in WG (tomorrow meeting) wrt. the following key aspects: >-> Belief that even the most stupid existing libraries to > deparse certificates can give access to this information without rev'ing > such libraries (we assume this is true for rfc822Name). >-> Abi
[Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-31: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-31: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ -- DISCUSS: -- Thanks for providing a clear specification of the /enrollstatus EST endpoint in the -30. The following two points still seem unaddressed, though. The -29 reworks the definition of the 'nonce' field to be: strong random or pseudo-random number nonce (see [RFC4086] section 6.2). As the nonce is usually generated very early in the boot sequence there is a concern that the same nonce might generated across multiple boots, or after a factory reset. Difference nonces MUST NOT generated for each bootstrapping attempt, whether in series or concurrently. The freshness of this nonce mitigates against the lack of real-time clock as explained in Section 2.6.1. This needs to either be "Different nonces MUST be generated" or "the same nonce MUST NOT be reused"; this mashup is no good. Email exchange with mcr notes: > > An RFC Editor note about the RFC 8366 assignment of OID > > 1.2.840.113549.1.9.16.1.40 was removed from -23 to -28; do the examples > > properly use that assigned OID now? > > We got a MASA URL Extension OID for: >1.3.6.1.5.5.7.1.32 > > the examples date from before that, and do not use it yet. We need to fix the examples before publication. -- COMMENT: -- A few new comments on the -30 and -31 to start. I think some of my comments on the -29 are still valid, and will try to remove ones that have been addressed. To reiterate: to the best of my knowledge, all the comments in this ballot position are actionable and have not been overtaken by events. In Section 5.9.4: In the case of a FAIL, the same TLS connection MUST be used. The Reason string indicates why the most recent enrollment failed. I'd suggest something more like "In the case of a failed enrollment, the client MUST send the telemetry information over the same TLS connection that was used for the enrollment attempt, with a Reason string indicating why the most recent enrollment failed. (For failed attempts, the TLS connection is the most reliable way to correlate server-side information with what the client provides.)" (Also, why is "FAIL" capitalized?) Thanks for the text in Section 11.2 about second-preimage-resistance of DomainID calculation; the grammar needs a tweak or two, though. My suggestion would be to either drop "The consequences of" or add "be to" to make "would be to allow" (but not both). Section 11.3 has gone back to just "Devices which are reset to factory default in order to perform a second bootstrap with a new owner MUST NOT use idential seeds", but I think it's important to be clear about what the scope of uniqueness is. The text in Section 5.2 is pretty good in this regard, with respect to the nonces (which are generally derived from the seed); I wonder if we might want to restructure this text to be more like "The random seed used by a device at boot MUST be unique across all devices and all bootstraps. Resetting a device to factory default state does not obviate this requirement." (FWIW, I think the text in the -29 was that way because of my request.) [A few comments on the -29, some of which I think might be repeats of ones I made on a WIP interim draft; sorry if I say something again that was already debunked. The comment section from the -28 is preserved later.] In Section 3.3, we now cite RFC 4648; I note that RFC 4648 specifies both base64 and base64url, so a section reference is usually appropriate (and in Section 5 we do give a section reference into RFC 4648). Section 9.1 Other use cases likely have similar, but MAY different requirements. nit: ", but MAY have different, requirements" Section 9.1.1 Authentication process. The MASA creates signed voucher artifacts according to a it's internally defined policies. nit: s/a it's/its/ Section 9.1.3 (Do we need to say "DULL" specifically again here for Join Proxy discovery? Maybe not...) [All new comments for the -28] Please respond to the se
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)
Trimming heavily, with great thanks for the numerous updates... On Mon, Oct 28, 2019 at 05:50:10PM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > > I also have some more comments that didn't make it into my ballot > position; > > please consider them as well. I will put them in the datatracker for > > posterity, but will have it not generate an additional mail since the > > mostly-duplicate contents would be confusing. > [...] > > doc> o The registrar forwards the voucher to the pledge when requested. > > > I suggest "validates and forwards" to cover the case where the registrar > > applies policy. > > the whole text is: > The registrar requests and validates the voucher from the > MASA. > > The registrar forwards the voucher to the pledge when > requested. > > so validates is already in the previous point, I think. Indeed. Apparently the page break caused me to forget; sorry for the noise :( > > Section 5.8 > > doc> although it results in additional network traffic. The relying MASA > doc> implementation MAY leverage internal state to associate this request > doc> with the original, and by now already validated, voucher-request so > doc> as to avoid an extra crypto validation. > > > It seems that doing so would turn the voucher-request into a bearer > > token for retrieving audit-log information (if the MASA accepts > > unauthenticated clients). > > That's what's intended. I can see why that functionality is needed, but it seems likely to introduce some privacy and/or security considerations to document. It's a bit too late in the day for me to reason through them, though. > > Section 11 > > > I am somewhat embarassed that I did not previously note that the > > mechanism used to generate the domainID needs to be > > second-preimage-resistant or an attacker can claim to be a registrar for > > a domain that already exists. > > Right now, that's in: > > 5.8.2. Calculation of domainID > >The domainID is a binary value (a BIT STRING) that uniquely >identifies a Registrar by the "pinned-domain-cert" > >If the "pinned-domain-cert" certificate includes the >SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be >used as the domainID. If not, the SPKI Fingerprint as described in >[RFC7469] section 2.4 is to be used. This value needs to be >calculated by both MASA (to populate the audit-log), and by the >Registrar (to recognize itself). > > We tried hard and found a way not to say SHA-1 directly, allowing SHA256 to > replace it appropriately. That's all good and admirable; I'm suggesting that we add a note in the security considerations of this document noting that we rely on the domainID (however determined) to be second-preimage-resistant. > > Section 11.2 > > doc> Although the nonce used by the Pledge in the voucher-request does not > doc> require a strong cryptographic randomness, the use of TLS in all of > doc> the protocols in this document does. > > > We discuss the need for strong randomness in the nonce in Section 11.3, > > so it's not clear this is actually true. > > We don't think that the voucher nonce has to be of the same quality as > something that > goes into a KDF. It is at the level of TCP Sequeunce number, not seed for > generating a private key... I mean, we literally say "Reducing the possibility of this is why the pledge is mandated to generate a strong random or pseudo-random number nonce." So to also say "the nonce [...] does not require a strong cryptographic randomness" seems to be in conflict with the former statement. Are you saying that "strong random" and "strong cryptographic random" mean different things, or am I misreading the document in some other way? Thanks, Ben ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) [COMMENTS]
On Tue, Oct 22, 2019 at 04:23:57PM -0400, Michael Richardson wrote: > > Hi, this got quite long. > I've split this up into nits and substantive comments. > This email is about the substantive comments. > Please see a diff at: https://tinyurl.com/y5l4xz3z Thanks; I'll put some editorial nits at the end of this message. > Benjamin Kaduk via Datatracker wrote: > > Thanks for the time and attention to detail put into addressing my > > previous Discuss and Comment points. I have one new Discuss-level > > point and one that I think may have been missed (probably because I > > inadvertently numbered two points with the same number). > > > (16) The audit log response (Section 5.8.1) describes the nonce as a > > JSON string, but the RFC 8366 nonce is a binary value. I think we need > > to describe some mapping procedure (such as always base64-encoding as > > is done for domainID, even if the original nonce is itself > > base64-encoded random data) in order to be fully functional. > > In the JSON mapping of the YANG, binary values are always base64 encoded, as > JSON does not support binary values. I apparently forgot that we were going through a YANG->JSON encoding when I wrote the above, sorry for that. But thank you for the extra reminders about base64-encoding that are in the latest copy. > This would be an issue in the constrained-voucher CBOR mapping through. > > > % (1) The text of the document suffers from lack of clarity throughout > > about % whether the nonce-ful operation is mandatory or not, with > > several % figures and discussions making declarative statements about > > nonce usage % and others saying that nonce usage is optional. (See > > COMMENT.) > > > > > [keep in mind when reading] > > > % (5.1) the new /enrollstatus EST endpoint seems under-specified. > > > Shame on me, I reused (5) for two points and have renumbered this to > > (5.1) so we don't miss it again. We don't anywhere give a formal > > description of the contents of the POST body; there's just an example > > JSON object. > > Agreed, and there is a comment about the subjectKeyInfo. > > I had opened issue: https://github.com/anima-wg/anima-bootstrap/issues/141 > last week when I started writing this. > > We have resolved this ticket as follows: > >The original purpose of the subjectKeyIdentifier was to indicate which >keypair the client (pledge) had attempted to enroll. Upon successful >enrollment, a new TLS connection is started (usually), which proves that > the >enrollment is success, and so no KeyIdentifier is needed. >In the case of a failure, the existing TLS connection is maintained, so >the server (Registrar) can associate the failure with the previous attempt >to enroll. >This change (removing the subjectKeyIdentifier) was made in -05, but the >prose was not updated. The use of a subjectKeyIdentifier, which might no >longer be a SHA-1 hash of a public key, is problematic, as the CSR does >not include an appropriate KeyIdentifier, so the server would be left >trying to calculate it, using the default (and now obsolete) SHA-1 >mechanism. Including the KeyIdentifier has proved more trouble than >benefit. The removal of SKI seems okay, but I'm still looking for something like "the body of the POST is a JSON object with the following [whoops, I forget the right terminology for name/value pairs]" > Esko has complained that we have 14 open issues; that's probably negligence > on my part about not closing them as we solved the issues. > So we also closed all but three "auth48" tickets that had been opened. > > > Section 2.5.1 > > >The pledge is the device that is attempting to join. The pledge can > > talk to the Join Proxy using link-local network connectivity. In most > > cases, the pledge has no other connectivity until the pledge completes > > the enrollment process and receives some kind of network credential. > > > I'd consider s/can talk to/is assumed to talk to/. > > okay. some have complained this isn't strong enough. > Maybe MUST talk to? I don't have a strong opinion on this, but it feels like something that will probably be different for ACP vs. other deployments -- MUST feels right for ACP but is probably not universal. > > Section 3 > > > In my previous comment, I said: > > > % The "proximity-registrar-cert" leaf is used in the pledge voucher- % > > requests. This provides a method for the pledge t
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
While recovering from today's telechat, I noticed that I seem to have never replied to this one! (Luckily, there's not much to say...) On Mon, Sep 16, 2019 at 05:46:37PM -0400, Michael Richardson wrote: > > Combining your August 9 and September 3 emails, and removing resolved items. > > https://tinyurl.com/y2kmjqmm for diffs aginst -26. > (also includes changes for Alexey) > Submitting -27 in process. > > Benjamin Kaduk wrote: > >> This was asked by Eric as well. > >> It's the Subject Key Identifier that we want. > >> https://tools.ietf.org/html/rfc5280#section-4.2.1.2 > >> > >> It's only guaranteed to exist in CA certificates. > >> Do you think we can demand that the extension be present in IDevID? > > > I'm doubtful that we have enough leverage to make that stick. > > Subsequent discussion with my co-authors has pointed out that the > certificate that will be pinned in the voucher (as pinned-domain-cert) is the > *domain cert*, that is, the domain's CA. As a CA, will most likely have the > right SubjectKeyIdentifier calculated already. Maybe I've just been reading too many copies of different text in flux, but I'm not sure that the current text gives me a clear picture of who picks what will be pinned and how much choice they have in the matter. But, if it's the "root" (last certificate in the chain) presented by the registrar for the provisional TLS connection, I think things are pretty self-consistent about it. > We had updated section 5.8.2 in -26 to clarify things. > We moved the domainID definition out of the terminology section (which is > where the SHA-1 stuff was), to point at 5.8.2, and point to rfc7469, which > provides an algorithm agile definition. > > >> > 5. Enroll. After imprint an authenticated TLS (HTTPS) connection > >> > exists between pledge and registrar. Enrollment over Secure > >> > Transport (EST) [RFC7030] is then used to obtain a domain > >> > certificate from a registrar. > >> > >> > Isn't this step optional? > >> > >> so, I can change the word to "can" rather than "is" > > > (and fix up the grammar, but) sure > > missing "be" added to section 2.1, point 5. > > doc> 1. Uniquely identifying the pledge by the Distinguished Name (DN) > doc> and subjectAltName (SAN) parameters in the IDevID. The unique > doc> identification of a pledge in the voucher objects are derived > doc> from those parameters as described below. > > >> > These unique identifiers can (by design) be used for tracking, so > let's > >> > be sure that we talk about any privacy considerations with them, > later. > >> > I see a mention in passing in Section 10.2, at least... > > >> Are you asking for a forward reference to 10.2? I will add this. > >> I think that section 10.2 is pretty clear about this. > >> I don't think it's mentioned just in passing. > > > It looks like the main coverage here is: > > > o the identity of the device being enrolled (down to the serial- > > number!). > > > and the discussion in the last three paragraphs or so. > > I do appreciate the importance of distinguishing between the high-end > > router and the human users (and we will have a long hard think about it > > again when BRSKI profiles for IoT use come through, I'm sure), so thank > you > > for that. But I'm not sure that we clearly draw the connection to "the > > manufacturer knows the identity of the device being enrolled" to "and > can > > guess where it is, and definitely knows who the owner is, and can > > potentially follow that over time if the device has to reenroll". Now, > for > > the high-end router case there is literally nothing new here -- the > vendor > > is assumed to already be doing inventory tracking of which customers > have > > which routers! But I think it's important to make the connection from > > "knows identity" to "tracking", since this topic will come up for any > use > > of BRSKI in other situations. > > I've tweaked some text, in section 10.3, but I feel I am just moving the > chairs around on the Titanic here. > > doc> 3. Secure auto-discovery of the pledge's MASA by the registrar (see > doc> Section 2.8). > > ben> I don't think this is an
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)
On Thu, Oct 17, 2019 at 07:08:49AM -0700, Benjamin Kaduk via Datatracker wrote:
>
>
> --
> DISCUSS:
> --
>
> % (1) The text of the document suffers from lack of clarity throughout about
> % whether the nonce-ful operation is mandatory or not, with several
> % figures and discussions making declarative statements about nonce usage
> % and others saying that nonce usage is optional. (See COMMENT.)
>
> [keep in mind when reading]
This was just supposed to be a note to myself and should be ignored; I was
in a hurry and forgot to trim it before pushing "send". Sorry about that.
I also have some more comments that didn't make it into my ballot position;
please consider them as well. I will put them in the datatracker for
posterity, but will have it not generate an additional mail since the
mostly-duplicate contents would be confusing.
Section 2
Should the "Drop Ship" arrow in Figure 1 be unidirectional instead of
bidirectional?
3. Request to join the discovered registrar. A unique nonce is
included ensuring that any responses can be associated with this
particular bootstrapping attempt.
This still seems to assume nonce-ful operation, which IIUC remains
required for pledge voucher-requests; only registrar-voucher-requests
have the option of being nonceless. So, this seems okay as-is, right?
4. Imprint on the registrar. This requires verification of the
manufacturer service provided voucher. A voucher contains
nit: hyphenate "manufacturer-service-provided"
Section 2.3.1
The serialNumber fields is defined in [RFC5280], and is a SHOULD
field in [IDevID]. IDevID certificates for use with this protocol
MUST include the "serialNumber" attribute with the device's unique
serial number (from [IDevID] section 7.2.8, and [RFC5280] section
4.1.2.4's list of standard attributes).
This is 4.1.2.2 (or just 4.1.2) from RFC 5280.
Section 2.4
I note that both Figure 2 and Figure 4 have a step labeled "Identity",
but the description accompanying Figure 2 describes the step as
"Identify itself"; perhaps the 'f' form is more appropriate everywhere?
Section 2.8
Note that the registrar can only select the configured MASA URL based
on the trust anchor -- so manufacturers can only leverage this
approach if they ensure a single MASA URL works for all pledge's
associated with each trust anchor.
nit: s/pledge's/pledges/
Section 3
Voucher-requests are how vouchers are requested. The semantics of
the vouchers are described below, in the YANG model.
nit: semantics of vouchers, or voucher requests?
Section 3.3
Figure 6: JSON representation of example Voucher-Request
I suggest adding "(unsigned)" or "prior to CMS wrapping".
Section 3.4
refine "voucher/assertion" {
mandatory false;
description "Any assertion included in voucher
requests SHOULD be ignored by the MASA.";
If this is true, why do we propagate the assertion from pledge
voucher-request to registrar voucher-request?
Section 4.1
Each possible proxy offer SHOULD be attempted up to the point where a
voucher is received: while there are many ways in which the attempt
may fail, it does not succeed until the voucher has been validated.
nit: I suggest "valid voucher is received".
Section 5
o The pledge requests and validates a voucher using the new REST
calls described below.
nit: I think the validation is local and does not use the REST call.
o The registrar forwards the voucher to the pledge when requested.
I suggest "validates and forwards" to cover the case where the registrar
applies policy.
Section 5.2
nonce: The pledge voucher-request MUST contain a cryptographically
strong random or pseudo-random number nonce. (see [RFC4086]) Doing
so ensures Section 2.6.1 functionality. The nonce MUST NOT be
This section reference reads kind of strangely. (Also, full stop after
parenthetical, not before.)
proximity-registrar-cert: In a pledge voucher-request this is the
first certificate in the TLS server 'certificate_list' sequence
(see [RFC5246]) presented by the registrar to the pledge. That
is, it is the end-entity certificate. This MUST be populated in a
pledge voucher-request if the "proximity" assertion is populated.
nit: there is no "proximity" field to be populated; it's the "assertion"
field that's populated with the value "proximity".
Section 5.5
serial-number: The serial number of the pledge the registrar would
like a voucher for. The registrar determines this value by
[Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-28: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ -- DISCUSS: -- Thanks for the time and attention to detail put into addressing my previous Discuss and Comment points. I have one new Discuss-level point and one that I think may have been missed (probably because I inadvertently numbered two points with the same number). (16) The audit log response (Section 5.8.1) describes the nonce as a JSON string, but the RFC 8366 nonce is a binary value. I think we need to describe some mapping procedure (such as always base64-encoding as is done for domainID, even if the original nonce is itself base64-encoded random data) in order to be fully functional. % (1) The text of the document suffers from lack of clarity throughout about % whether the nonce-ful operation is mandatory or not, with several % figures and discussions making declarative statements about nonce usage % and others saying that nonce usage is optional. (See COMMENT.) [keep in mind when reading] % (5.1) the new /enrollstatus EST endpoint seems under-specified. Shame on me, I reused (5) for two points and have renumbered this to (5.1) so we don't miss it again. We don't anywhere give a formal description of the contents of the POST body; there's just an example JSON object. -- COMMENT: -- [All new comments for the -28] Please respond to the secdir re-review. Abstract nit: hyphenate "manufacturer-installed" or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for nit: maybe "deployment models with less-stringent security requirements"? Section 1 [I-D.ietf-anima-autonomic-control-plane]. This bootstrap process satisfies the [RFC7575] section 3.3 of making all operations secure by default. Other users of the BRSKI protocol will need to provide nit: missing "requirement" between manufacturer and owner: in it's default modes it provides a cryptographic transfer of control to the initial owner. In it's strongest modes, it leverages sales channel information to identify nit: s/it's/its/ Section 1.2 domainID: The domain IDentity is a unique hash based upon the Registrar CA's certificate. Section 5.8.2 specifies how it is calculated. nit: the grammar here is weird; I'd suggest s/hash based upon/value derived from/ MASA Audit-Log: A list of previous owners maintained by the MASA on a per device (per pledge) basis. Described in Section 5.8.1. nit: maybe "anonymized list" since the MASA doesn't really track owners directly? Ownership Tracker: An Ownership Tracker service on the global Internet. The Ownership Tracker uses business processes to accurately track ownership of all devices shipped against domains that have purchased them. Although optional, this component allows vendors to provide additional value in cases where their sales and distribution channels allow for accurately tracking of such ownership. Ownership tracking information is indicated in nit: either "accurate tracking of" or "accurately tracking" ANI: The Autonomic Network Infrastructure as defined by [I-D.ietf-anima-reference-model]. This document details specific requirements for pledges, proxies and registrars when they are part of an ANI. Maybe refer to section 9 specifically? Section 2.3.1 The serialNumber fields is defined in [RFC5280], and is a SHOULD field in [IDevID]. IDevID certificates for use with this protocol nit: s/fields/field/ Section 2.5.1 The pledge is the device that is attempting to join. The pledge can talk to the Join Proxy using link-local network connectivity. In most cases, the pledge has no other connectivity until the pledge completes the enrollment process and receives some kind of network credential. I'd consider s/can talk to/is assumed to talk to/. Section 2.5.3 The registrar uses an Implicit Trust Anchor database for authenticating the BRSKI-MASA TLS connection MASA certificate. The registrar uses a different
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Whoops, this one apparently got skipped over amid some other deluge in my inbox; sorry. On Sun, Aug 18, 2019 at 04:09:50PM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > > That specific construction would seem like an "optional feature" per > > > https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/ > > ... > > I re-read this, and this as to do with References, and so anything optional > referenced in section 7 would still need to be a Normative Reference. > > The stickler I see right now is [I-D.ietf-netconf-keystore]. > I don't want to hang on MISREF on that document; it's just one of many that > could be used, and I do not want to tell manufacturers that they have > to use this specific protocol to update trust anchors. > There are many other protocols that they presently support which they could > use, in particular, a CLI interface would be fine. > > I think that this 7.4.3 section that creates a factory default which isn't > the default from the factory should be worry people who care about remote > attestation of software. > > Adam has been particularly vocal about the need to specify something > normative that manufacturers have to provide in order to resale and operation > with the availability of the MASA. > > It seems that we might need another round of discussion on this topic. > I feel that we are being pushed to describe the entire security lifetime of > the device; that we need to solve the entire management problem of devices in > our document. (i.e. the 25 years of SNMPv3, plus YANG...) Maybe I just don't > understand what would be a reasonable answer, if what I've written is not > enough. > > Maybe a virtual interim discussion! If so, please let me know. I think I'm going to have to leave this one to Adam et al. > ANIMA/Iot-Onboarding has some time booked already: > > https://datatracker.ietf.org/meeting/interim-2019-anima-01/materials/agenda-interim-2019-anima-01-anima-01 > > ps: (s/IPv6 NAT44/IPv4 NAT44/ for section 7.4.2, btw) > > > >> section 9: > >> In recognition of this, some mechanisms are presented in > >> Section 7.2. The manufacturer MUST provide at least one of the one- > >> touch mechanisms described that permit enrollment to be proceed > >> without availability of any manufacturer server (such as the MASA). > > > ... but this is a somewhat different construction. In isolation, it > looks > > more like "MUST do at least one of X, Y, Z" without condition on "wish > to > > do W", and if X, Y, and Z are all in the same place, that place seems > > normative to me. (I will confess I've rather lost track of exactly why > > we're debating if this is normative or not; I guess it's just the > > disclaimer in Section 7 about "considered non-normative in the > generality > > of the protocol".) > > Yes, it's MUST do one of X,Y,Z. > So that implies: MAY do X, MAY do Y, MAY do Z, but not the case of all being > false. If "ignore all of Section 7.2" is not an option, then at least some part of it is normative. "You just get to choose which part" :) -Ben ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On Thu, Aug 15, 2019 at 12:58:45PM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > >> + directly. This is because BRSKI pledges MUST use the CSR Attributes > > > (This may not need to be a 2119 MUST since we cite 7030.) > > It turns out, in pracice, that many EST clients do not use the CSR > Attributes, so I need this line as a hammer. Fair enough. > >> > "intended" implies that the EST server has some knowledge of what > >> the > pledge is expected to be doing in the network, right? > >> > >> Yes. The ACP document is quite specific about the (rfc822Name) > >> attributes to assign. Certainly the attributes could include stuff > >> like "ve608.core1.tor1.example.net" if the Registrar knew how this > >> device was to be used, but more likely that would be set up > >> afterwards. > > > Hmm, maybe later when we say "the local infrastructure (EST server) > > informs the pledge of the proper fields to include in the generated > > CSR" we could reiterate that the EST server has local configuration > > information to inform this messaging, though it's probably not > > necessary. > > I've added the (). > > + fields to include in the generated CSR (such as rfc822Name). > > doc> To alleviate these operational difficulties, the pledge MUST request > doc> the EST "CSR Attributes" from the EST server and the EST server > doc> needs to be able to reply with the attributes necessary for use of > doc> the certificate in its intended protocols/services. This approach > doc> allows for minimal CA integrations and instead the local > doc> infrastructure (EST server) informs the pledge of the proper fields > doc> to include in the generated CSR. This approach is beneficial to > doc> automated boostrapping in the widest number of environments. > >> > >> > This is convenient, but has some security considerations in that it > >> > implies that the validation policy on the CA is somewhat lax, since > >> the > EST server is expected to be doing most of the policy controls. > >> Thus, > a compromised pledge/device could send a CSR with unauthorized > >> fields > and it is likely to be signed, allowing for some level of > >> privilege > escalation. When the registrar acts as a proxy to the CA > >> as well as > its EST role, as described later, this risk is > >> diminished. > >> > >> I don't really understand. EST servers are Registration Authorities, > >> and they have some kind of priviledged access to the CA, and are > >> mandated to check the CSR. I expected to find a statement to this > >> effect in RFC7030, in section 4.2.1, but I don't see any particularly > >> strong language. This seems like a quality of implementation issue in > >> the Registrar. > > > The high-level intended workflow described here is roughly "(1) pledge > > asks registrar for config; (2) pledge puts that config in a CSR, signs > > the CSR, and sends the CSR to registrar; (3) registrar passes CSR to CA > > using registrar's implicit authority. We don't describe any crypto to > > check that (2) happens as intended, as opposed to the pledge > > dishonestly claiming "oh, and I'm a CA" or "I can provide all ACP > > services, even privileged ones", so that has to be done by policy in > > the registrar, as you note. I'm wary of suggesting the workflow that > > relies on the registrar's implicit authority at the CA without also > > noting the registrar's policy enforcement obligations. Though it's > > possible this is covered elsewhere and doesn't need to be duplicated > > here. > > I think it goes back to the RA and more specifically, the CA, being boss of > what going into a certificate. To the point where it generally seems really > hard to deploy new extensions in the public WebPKI. > > It does say: > > The registrar MUST also confirm that the resulting CSR is > formatted as > indicated before forwarding the request to a CA. If the registrar is > communicating with the CA using a protocol such as full CMC, which > provides mechanisms to override the CSR attributes, then these > mechanisms MAY be used even if the client ignores CSR Attribute >
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On Thu, Aug 15, 2019 at 12:17:22PM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > doc> The MASA and the registrars SHOULD be prepared to support TLS client > doc> certificate authentication and/or HTTP Basic or Digest > doc> authentication as described in [RFC7030] for EST clients. This > doc> connection MAY also have no client authentication at all (Section > doc> 7.4) > > >> > I don't see discussion of skipping client authentication in Section > >> 7.4. > It would be great to have some, there! > > >> It's buried in point 2. > > > Oh, the "not verifying ownership" part? I somehow was interpreting > > that as "we still require client authentication, but don't have a fancy > > database mapping owner to hardware, so any authenticated registrar can > > get a voucher for any device". > > There are multiple models on how to operate a MASA. > We think that which one is right depends a lot on the value of the device > (in the ACP space, $100K routers vs $100 CPE devices), and also at the degree > of sales channel integration. > There is value in authenticating the Registrar, even if one does not know > which device has been deployed. In particular, this model supports the <4h > SLA on service repair that most vendors have, and which they support by > stocking spares in the local city, but not for a specific customer. Understood. To be clear, this was only ever intended to be an editorial question (to be more explicit about not using client authentication), so use your editorial discretion. -Ben ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On Wed, Aug 14, 2019 at 09:10:26PM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > >> Are you asking for a forward reference to 10.2? I will add this. > >> I think that section 10.2 is pretty clear about this. > >> I don't think it's mentioned just in passing. > > > It looks like the main coverage here is: > > > o the identity of the device being enrolled (down to the serial- > > number!). > > > and the discussion in the last three paragraphs or so. > > I do appreciate the importance of distinguishing between the high-end > > router and the human users (and we will have a long hard think about it > > again when BRSKI profiles for IoT use come through, I'm sure), so thank > you > > for that. But I'm not sure that we clearly draw the connection to "the > > manufacturer knows the identity of the device being enrolled" to "and > can > > guess where it is, and definitely knows who the owner is, and can > > potentially follow that over time if the device has to reenroll". Now, > for > > the high-end router case there is literally nothing new here -- the > vendor > > is assumed to already be doing inventory tracking of which customers > have > > which routers! But I think it's important to make the connection from > > "knows identity" to "tracking", since this topic will come up for any > use > > of BRSKI in other situations. > > we added the following to the end of the point list: > > Based upon the above information, the manufacturer is able to > track a specific device from pseudonymous domain identity to the > next pseudonymous domain identity. If there is sales-channel > integration, then the identities are not pseudonymous. > Thanks! > >> > 3. Secure auto-discovery of the pledge's MASA by the registrar (see > >> > Section 2.8). > >> > >> > I don't think this is an ironclad property, since the crypto chain is > >> > slightly limited and you are in effect trusting the pledge to hand > you > >> > something that says "use this issuer" but without as much crypto to > back > >> > that up as we might want. We have to know that the given > manufacturer > >> > that signed the IDevID actually is associated with the device we're > >> > trying to bootstrap, which can probably be arranged but I don't > remember > >> > being called out explicitly. > >> > >> There are two issues here. > >> > >> One is the question of what is the list of acceptable manufacturers > (below). > >> The second part is whether a pledge could provide a fake IDevID to > >> the Registrar. The pledge is doing TLS ClientCertificate, so the TLS > >> has proven that the pledge has the private key corresponding to the > >> certificate presented. I conclude that an arbitrary IDevID can not be > >> provided by the Pledge; it has to be linked to SOME manufacturer. Some > > > Well, it has to be linked to some entity that signed the IDevID. That > may > > or may not be a manufacturer, but the Registrar does have the > capability to > > look at what signed the IDevID and apply a whitelist of known, verified, > > manufacturers. > > One either has a list of trusted manufacturers or one does not. > This can be done via a list of trust anchors for the IDevID signing entity, > or can be done via a list of trust anchors for the MASA URL. > > If not (in a residential use of BRSKI perhaps), then there has to be some > process by which a not previously known manufacturer can become trusted. > There are a great number of layer-8 or layer-9 solutions for this, > perhaps involving new industry CAs or attestations, or ... I think it is out > of scope. > (for instance RFC5280 section 4.2.2.1 could provide the right references, > but this section has not been well used as yet. Or we could extend the > MASA EST to include additional information) I agree that we don't need to talk about all the different ways by which a previously unknown manufacturer could become trusted. Mostly just the word "secure" caught me up. > >> The question then becomes how the Registrar comes to trust/verify the > >> pledge's IDevID. We had a long discussion about this during the > directorate > >>
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On Thu, Aug 15, 2019 at 01:02:45PM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > >> There does not otherwise seem to be any risk from this compromise to > >> devices which are already deployed, or which are sitting locally in > >> boxes waiting for deployment (local spares). The issue is that > > > (That is, if the boxes are already in local storage at the time of > > first compromise) > > yes. If you have physical care of them, then nobody could have tried an > attack while the MASA signing key was compromised. I guess that makes the "under physical control of the owner" the relevant property, so emphasizing that in the text might be good. > >> The authors are unable to come up with an attack scenario where a > >> compromised voucher signature enables an attacker to introduce a > >> compromised pledge into an existing operator's network. This is the > >> case because the operator controls the communication between Registrar > >> and MASA, and there is no opportunity to introduce the fake voucher > >> through that conduit. > > > This seems predicated on the attacker having the MASA signing key but > > not persistent control of the (formerly?) legitimate MASA service, > > right? > > yes, that's right. Assume the key was generated in a deterministic way > (the way the SSH keys were), or brute-forced, or something like that. I was initiall confused about this, so it might be worth adding some text. (But then again, sometimes I'm easily confused...) > >> A key operational recommendation is for manufacturers to sign > >> nonceless, long-lived vouchers with a different key that they sign > >> short-lived vouchers. That key needs significantly better protection. > >> If both keys come from a common trust-anchor (the manufacturer's CA), > >> then a compromise of the manufacturer's CA would be a bigger problem. > > > (probably some wordsmithing options for "be a bigger problem") > > how about: > If both keys come from a common trust-anchor > (the manufacturer's CA), then a compromise of the > manufacturer's CA would compromise both keys. Such a > compromise of the manufacturer's CA likely compromises > all keys outlined in this section. WFM. Thanks, Ben ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Apparently I only have one comment buried inline. We must be making progress :) On Tue, Aug 13, 2019 at 05:07:46PM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > doc> The authentication of the BRSKI-MASA connection does not affect the > doc> voucher-request process, as voucher-requests are already signed by > doc> the registrar. Instead, this authentication provides access control > doc> to the audit log. > >> > >> > I don't understand what "access control to the audit log" means. Is > the > >> > idea that the TLS client identity in the BSRKI-MASA connection is > only > >> > used when processing requests to the requestauditlog endpoint and > that > >> > some clients might be denied access? > >> > >> The audit log reveals who owns what. Revealing it to strangers would > be a problem. > >> So in order to get access to the audit log for device FOO, one > presents a > >> voucher-request for FOO. Since the request contains a serial-number > and a > >> mapping to an owner, we use that as an access key to get the audit-log. > >> The identity that the MASA sees in the HTTPS request (ClientCertificate > >> preferred), says who is asking. > >> > >> What can I fix here? > > > Well, I think a lot of my confusion stemmed from the lack of advance > > definition of "MASA Audit Log" as a protocol element, which you already > > fixed. So what's left would seem to mostly be a question of whether > > something about "access control" vs. "authorization to access the > relevant > > subset of the audit log" is a more accurate description of what's going > on. > > That is, whether "access control" is something done by a server > (MASA)-side > > agent applying policy, or ... something else that I don't know how to > > describe well. > > I have added a forward reference in section 5.4 to section 5.8 around the > the access control question. > > doc> created-on: Registrars are RECOMMENDED to populate this field. This > doc> provides additional information to the MASA. > > >> > Earlier we said that this field would be propagated from the pledge > >> > voucher-request; we should probably say something like "populate this > >> > field; if it was present in the pledge voucher-request it is copied > >> > unchanged to the registrar voucher-request; otherwise the current > time > >> > is used". > >> > >> That create-on is the time on the Registrar, not on the pledge. It > currently > >> says: > >> > >> The registrar populates the voucher-request fields as follows: > >> > >> created-on: The Registrars SHOULD populate this field with the > >> current date and time when the Registrar formed this voucher > >> request. This field provides additional information to the MASA. > > > Hmm, I'm trying to look for why I claimed that "earlier we said that > this > > field would be propagated". Section 3.3 (of the -22)'s Example (2) says > > "[t]he nonce, created-on and assertion is carried forward", and Section > 5.2 > > wants pledges to populate it as well. So the idea is that the MASA is > only > > going to get the pledge's created-on via the > prior-signed-voucher-request > > (if present)? > > > I'm confused about what it means to "carry forward" the created-on if > the > > registrar is populating it anew, though. > > I have changed the text: > > -here it must be base64 encoded. The nonce, created-on and > -assertion is carried forward. The serial-number is extracted > -from > +here it must be base64 encoded. The nonce and > +assertion MAY be carried forward from the pledge request to > +the registrar request. > +The serial-number is extracted from > > It is a MAY, because in a case where the Registrar wants a nonceless voucher, > then it won't include a nonce. > > >> > There is no "idevid-issuer" field in the pledge certificate; I assume > >> > this is supposed to be the Issuer Name of the IDevID certificate. > >> > >> Changed to: >
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On Mon, Aug 12, 2019 at 04:23:54PM -0400, Michael Richardson wrote: > > Benjamin Kaduk via Datatracker wrote: > > Section 13.2 > > > I think CDDL needs to be a normative reference, as does RFC 7231. RFC > > 2473 is listed but not referenced in the text, as are RFC 2663, RFC > > 7217, and RFC 7575. > > CDDL->RFC8610, now normative. (Glad that got published) > RFC2473 removed, we no longer attempt to document a stateless IPIP proxy > mechanism. > > RFC2663 (NAT terminology) reference was for Join Proxy, and I've restored > a reference in section 4. > > RFC7217 was thought to be relevant to Pledge use of SLAAC, but actually it's > not, removed. > > You are right that we don't reference RFC7575, which is the architecture of > ANIMA. I have added a sentence to the Intro, referencing RFC7575's > goal of "secure by default" > > > Appendix B > > doc>Discovery of registrar MAY also be performed with DNS-based > service > doc> discovery by searching for the service "_brski- > doc> registrar._tcp.example.com". In this case the domain "example.com" > is > doc> discovered as described in [RFC6763] section 11 (Appendix A.2 > suggests > doc> the use of DHCP parameters). > > > I'd suggest using "" per 6763 rather than "example.com". > > okay. > > doc>If no local proxy or registrar service is located using the GRASP > doc> mechanisms or the above mentioned DNS-based Service Discovery methods > doc> the pledge MAY contact a well known manufacturer provided > bootstrapping > doc> server by performing a DNS lookup using a well known URI such as > doc> "brski-registrar.manufacturer.example.com". The details of the URI > are > doc> manufacturer specific. Manufacturers that leverage this method on > the > doc> pledge are responsible for providing the registrar service. Also see > doc> Section 2.7. > > > It seems like there are some security considerations for device owners > > that may wish to prevent such registrars from being used. Do we need > > to direct them to run a firewall or similar? > > If they are doing ANIMA ACP bootstrapping, then there would ideally be no > IPv4 available, and so this won't work anyway. > I'd rather not get into too much of this here. I'm not sure I see how v6-only prevents URI dereference or obviates the usecase for a firewall. Perhaps you mean that there would be no non-link-local available? > > Appendix C > > > I don't know how important file "ietf-mud-extens...@2018-02-14.yang" > > is, but it seems a tad generic. > > Renamed already. > > Ben, I'm posting the -25, and then moving on back to the responses to > my responses, including Adam's concerns. Okay, thanks. -Ben ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On Mon, Aug 12, 2019 at 03:30:13PM -0400, Michael Richardson wrote:
>
> WG: there is a chunk of Security Considerations text here that I hope
> many will read.
>
>
> Benjamin Kaduk via Datatracker wrote:
> > Section 11.4
>
> > It is not entirely clear to me whether device manufacturers are set up
> > with incentives to maintain a well-run secure CA with strong hardware
> > protections on the offline signing key for the root CA, cycling through
> > various levels of intermediates, etc., that CAs in the Web PKI do
> > today. If the manufacturer uses a less stringent process, that would
> > leave the manufacturer's key as a more tempting attack surface, and it
> > may be worth some discussion here about what damage could be done with
> > a compromised MASA signing key. E.g., would an attack require
> > restoring devices to factory defaults or otherwise waiting for natural
> > bootstrapping events to occur? Would the attacker need to be on-path?
> > Etc.
>
> I wanted to add that I think that there are some interesting economic
> discussions about these incentives. I wonder how to interest some people
> into doing some analysis of a monetary rather that technical manner.
>
> I have added:
> 11.4. Manufacturer Maintenance of trust anchors . . . . . . . 75
>11.4.1. Compromise of Manufacturer IDevID signing keys . . . 77
>11.4.2. Compromise of MASA signing keys . . . . . . . . . . 77
>11.4.3. Compromise of MASA web service . . . . . . . . . . . 79
>
> and this text is rough, and as yet unreviewed by anyone, and I
(not sure if there was supposed to be much more to that sentence).
It's rough, sure, but generally looks quite good in terms of content coverage.
> 11.4. Manufacturer Maintenance of trust anchors
>
>BRSKI depends upon the manufacturer building in trust anchors to the
>pledge device. The voucher artifact which is signed by the MASA will
>be validated by the pledge using that anchor. This implies that the
>manufacturer needs to maintain access to a signing key that the
>pledge can validate.
>
>The manufacturer will need to maintain the ability to make signatures
>that can be validated for the lifetime that the device could be
>onboarded. Whether this onboarding lifetime is less than the device
>
>lifetime depends upon how the device is used. An inventory of
>devices kept in a warehouse as spares might not be onboarded for many
>decades.
>
>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 certificate
>authority 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 issues in non-constrained environments.
>
>There are a few other operational variations that manufacturers could
>consider. For instance, there is no reason that every device need
>have the same set of trust anchors pre-installed. Devices built in
>different factories, or on different days, or any other consideration
>could have different trust anchors built in, and the record of which
>batch the device is in would be recorded in the asset database. The
>manufacturer would then know which anchor to sign an artifact
>against.
>
>Aside from the concern about long-term access to private keys, a
>major limiting factor for the shelf-life of many devices will be the
>age of the cryptographic algorithms included. A device produced in
>2019 will have hardware and software capable of validating algorithms
>common in 2019, and will have no defense against attacks (both
>quantum and von-neuman brute force attacks) which have not yet been
>invented. This concern is orthogonal to the concern about access to
>private keys, but this concern likely dominates and limits the
>lifespan of a device in a warehouse. If any update to firmware to
>support new cryptographic mechanism were possible (while the device
>was in a warehouse), updates to trust anchors would also be done at
>the same time.
>
>The set of standard operating proceedures for maintaining high value
>private keys is well documented. For instance, the WebPKI provides a
>number of options for audits at {{cabforumaudit}}, and the DNSSEC
>root operations are well documented at {{dnssecroot}}.
>
>It is not clear if Manufacturers will
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On Wed, Aug 14, 2019 at 10:05:13AM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > >> domainID: The domain IDentity is a unique hash based upon a > >> Registrar's certificate. If the certificate includes the > >> SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be > >> used as the domainID. If not, then the 160-bit SHA-1 hash as > >> described in that section is to be used. This value needs to be > >> calculated by both MASA (to populate the audit log), and by the > >> Registrar (to recognize itself). > >> > >> Does this work? We are only using SHA-1 (for identification, btw, not > >> for resistence to pre-image attacks) as a last resort. > > > Sorry, I'm still not seeing the justification for using SHA-1 as the > > fallback instead of (e.g.) SHA-256. If the SKI is present, then > > definitely use that. But if it's not present, we can define whatever > > we want, can't we? It's not like "The keyIdentifier is composed of the > > 256-bit SHA-256 > > hash of the value of the BIT STRING subjectPublicKey (excluding the tag, > > length, and number of unused bits)" is an unreasonable amount of text ot > > include in the document. Now, if there's some backwards compatibility > > need > > or implementation challenge, we can talk about that, but all I'm seeing > so > > far is blind adherence to an 11-year-old document for consistency's > sake, > > and in this case I don't think consistency outweighs cryptographic > > modernization. > > Hi, we have revised the text, making use of section 2.4 from rfc7469, which > has a similar need. > > We added a new section 5.8.2, calculation of domainID: > > 5.8.2. Calculation of domainID > >The domainID is a binary value (a BIT STRING) that uniquely >identifies a Registrar by the "pinned-domain-cert" > >If the "pinned-domain-cert" certificate includes the >SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be >used as the domainID. If not, then it is the SPKI Fingerprint as >described in [RFC7469] section 2.4 is to be used. This value needs >to be calculated by both MASA (to populate the audit-log), and by the >Registrar (to recognize itself). > >[RFC5280] section 4.2.1.2 does not mandate that the >SubjectKeyIdentifier extension be present in non-CA certificates. It >is RECOMMENDED that Registrar certificates (even if self-signed), >always include the SubjectKeyIdentifier to be used as a domainID. > >The domainID is determined from the certificate chain associated with >the pinned-domain-cert and is used to update the audit-log. > > and referenced this section in the terminology. This eliminates all > references to SHA-1. RFC7469 section 2.4 uses SHA-256. Thank you! > We also strengthened our statement that the SubjectKeyIdentifier SHOULD > exist. In the process, we recognized that we had some mismatch in > (MY) thinking about pinned-domain-cert, thinking it was always the > Registrar End-Entity Certificate, when in fact it is the Registrar's > CA certificate. As a CA certificate, it SHOULD always have the > SubjectKeyIdentifier. My recollection was that it was expected to be a certificate in the Registrar's chain, probably a CA certificate but possibly an intermediate one (i.e., not self-signed). (And I see in 5280 "this extension MUST appear in all conforming CA certificates".) > We are presenting discussing whether the EE Registrar cert should get > audited. Okay, sounds good. -Ben ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On Mon, Aug 12, 2019 at 03:05:44PM -0400, Michael Richardson wrote: > > https://tinyurl.com/yylruorn contains a diff against -24. > > Benjamin Kaduk via Datatracker wrote: > > Section 5.8.1 > > doc>A log data file is returned consisting of all log entries > associated > doc> with the the device selected by the IDevID presented in the request. > doc> The audit log may be truncated of old or repeated values as explained > doc> below. The returned data is in JSON format ([RFC7951]), and the > doc> Content-Type SHOULD be "application/json". For example: > > > If RFC 7951 is to be used, I'd suggest "is JSON-encoded YANG data". > > Typo, it should be 7159. (Well, 8529, but I think we covered that already.) > doc>This document specifies a simple log format as provided by the > MASA > doc> service to the registrar. This format could be improved by > distributed > doc> consensus technologies that integrate vouchers with technologies such > doc> as block-chain or hash trees or optimized logging approaches. Doing > so > doc> is out of the scope of this document but is an anticipated > improvement > doc> for future work. As such, the registrar client SHOULD anticipate new > doc> kinds of responses, and SHOULD provide operator controls to indicate > doc> how to process unknown responses. > > > This would be a great place to talk about the "version" field that's > > otherwise ignored. > > As in, what should occur if the "version" is not 1? Exactly so! > How about: > > > A registrar that sees a version value greater than 1 indicates > an audit log format that has been enhanced with additional > information. No information will be removed in future > versions; should an incompatible change be desired in the future, > then a new HTTP end point will be used. > > > > doc>anticipated improvement for future work. As such, the registrar > doc> client SHOULD anticipate new kinds of responses, and SHOULD provide > doc> operator controls to indicate how to process unknown responses. > > > Is "registrar client" intended to be both words or just one? > > Probably not, removed. > > doc>A registrar SHOULD use the log information to make an informed > doc> decision regarding the continued bootstrapping of the pledge. The > > > I may be confused, but I thought the registrar was asking for the log > > after the voucher had already been issued. Are these check supposed to > > keep the registrar from forwarding the voucher to the pledge, or just > > as a check for future renewal operations? > > The voucher can be returned to the Pledge immediately, as there is never > any issue about whether the Pledge should join. The MASA has already made > that decision. > > The Registrar could avoid passing the voucher on until after the audit log > checks are done, or could do that concurrently. What matters is that the > audit log checks are done prior to the Registrar accepting an enroll > request.This is down in (what is now) Figure 4. Thinking about it that way is very helpful; thank you. > The Registrar may do additional checks of the audit log at later times, > but I don't think we have any good advice on this yet. Okay. > doc>A relatively simple policy is to white list known (internal or > doc> external) domainIDs and to require all vouchers to have a nonce and/ > or > doc> require that all nonceless vouchers be from a subset (e.g. only > doc> internal) domainIDs. A simple action is to revoke any locally issued > > > nit: missing "of" > > I don't know where the "of" that is missing goes. "subset of" (though possibly split by the parenthetical) > While investigating, I broke the big sentence up, and discovered that the > 5209 reference was not coded as XML. Please clue me in what you mean... > > > A relatively simple policy is to white list known (internal or > external) domainIDs. > To require all vouchers to have a nonce. > Alternatively to require that all nonceless vouchers be from a > subset (e.g. only internal) domainIDs. > If the policy is violated a simple action is to revoke any > locally issued credentials for the pledge in question or to > refuse to forward the voucher. The Regis
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On Sun, Aug 11, 2019 at 12:06:07AM -0400, Michael Richardson wrote:
>
> https://tinyurl.com/yylruorn contains an updated diff against -24.
>
> Benjamin Kaduk via Datatracker wrote:
> > Section 5.2
>
> > application/voucher-cms+json The request is a "YANG-defined JSON
> > document that has been signed using a CMS structure" as described
> > in Section 3 using the JSON encoding described in [RFC7951]. This
>
> > Section 3 does not describe any "sign[ing] using a CMS structure"
> > operation.
>
> Yes, I see, the sentence structure is wrong. I have changed it:
>
>
> - application/voucher-cms+json The request is a "YANG-defined JSON
> - document that has been signed using a CMS structure" as described
> - in Section 3 using the JSON encoding described in [RFC7951]. This
> - voucher media type is defined in [RFC8366] and is also used for
> - the pledge voucher-request. The pledge SHOULD sign the request
> - using the Section 2.3 credential.
>
> + application/voucher-cms+json [RFC8366] defines a "YANG-defined JSON
> + document that has been signed using a CMS structure", and the
> + voucher-request described in Section 3 is created in the same way.
> + The media type is the same as defined in [RFC8366]. and is also
> + used for the pledge voucher-request. The pledge MUST sign the
> + request using the Section 2.3 credential.
>
>
> > To be clear, this is MUST sign, but SHOULD use IDevID (vs. some other
> > credential) to sign?
>
> It was SHOULD, because we supported unsigned voucher requests, but we removed
> that option. It is now MUST.
>
> > constrained voucher formats are expected in the future. Registrar's
> > and MASA's are expected to be flexible in what they accept.
>
> > nits: no apostrophes for plurals.
>
> done.
>
> > proximity-registrar-cert: In a pledge voucher-request this is the
> > first certificate in the TLS server 'certificate_list' sequence
> > (see [RFC5246]) presented by the registrar to the pledge. This
> > MUST be populated in a pledge voucher-request if the "proximity"
> > assertion is populated.
>
> > [same comment as above about "end-entity certificate"]
>
> done.
>
> > The registrar validates the client identity as described in EST
> > [RFC7030] section 3.3.2. The registrar confirms that the 'proximity'
> > assertion and associated 'proximity-registrar-cert' are correct.
>
> > what 'proximity' assertion?
> > Does verifying proximity-registrar-cert just mean checking that it's the
> > same leaf certificate that the registrar presented? What happens if the
> > validation fails?
>
> Yes, it means confirming that the pinned certificate is one's own.
> If it fails, then there is a MITM, and the connection should be closed.
> {I will use "MITM" until someone tells if me we are using a different term}
>
> I've split that paragraph up, as there are two thoughts, one is about the
> ClientCertificate, and the other is about the pinned certificate.
>
> The registrar validates the client identity as described in EST
> - [RFC7030] section 3.3.2. The registrar confirms that the 'proximity'
> - assertion and associated 'proximity-registrar-cert' are correct.
> + [RFC7030] section 3.3.2.
> +
> + The registrar confirms that the assertion is 'proximity' and that
> + pinned 'proximity-registrar-cert' is the Registrar's certificate. If
> + this validation fails, then there a On-Path Attacker (MITM), and the
> + connection MUST be closed after the returning an HTTP 401 error code.
>
> > Section 5.3
>
> doc> A Registrar accepts or declines a request to join the domain, based
> doc> on the authenticated identity presented. Automated acceptance
> doc> criteria include:
>
> > I suggest "for different networks, examples of automated acceptance
> > criteria may include".
>
> doc> If these validations fail the registrar SHOULD respond with an
> doc> appropriate HTTP error code.
>
> > Similarly, "If validation fails".
>
> done.
>
> > Section 5.4
>
> doc> The BRSKI-MASA TLS connection is a 'normal' TLS connection
> doc> appropriate for HTTPS REST interfaces. The registrar initiates the
> doc> connection and uses the MASA URL obtained as d
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On Fri, Aug 09, 2019 at 04:17:17PM -0400, Michael Richardson wrote:
>
> https://tinyurl.com/yylruorn contains a diff against -24.
>
> Benjamin Kaduk via Datatracker wrote:
> > [disclaimer: some of these comments get pretty blunt at the end; it's a
> > long document and I'm tired. Please try not to get too annoyed if I'm
> > failing to see something that's right in front of me.]
>
> > I concur with the directorate reviewers that expected a
> > high-level security analysis of what information flows where, and what
> > policy choices can be made that affect it. At a *very* high level
> > (skipping over a lot of things that I would expect to see), this would
> > be structured like:
>
> > On initial bootstrap, a new device uses local service autodiscovery to
> > locate a (proxy to a) local registrar. Having found a candidate
>
> I have included an edited version of this text. It was very well done, thank
> you!
>
> > Abstract
>
> > (side note?) Is there a quick explanation of why bootstrapping can
> > complete with just installation of the PKI (trust anchor?) and
> > provisioning a locally issued certificate is not mandatory?
>
> I don't think that we can fit a quick explanation into the Abstract.
> I did split up the last sentence.
This was a side note, so for my own edification more than the good of the
document...
> The hard thing that BRSKI provides is the trust of the network by the pledge.
> The trust of the device by the network is generally an "easy" problem solved
> by use of 802.1AR/IDevID. This is presently done in many existing EST and CMP
> users.
> So I'm not sure what further to do here.
and this helps; thank you!
> > Section 1
>
> > This document describes how pledges discover (or be discovered by) an
> > element of the network domain to which the pledge belongs to perform
> > the bootstrap. [...]
>
> > nit: s/be/are/, IIUC.
> > I think there's also something funky with the wording of "to perform the
> > bootstrap"; we may be looking for an element "that will perform the
> > bootstrap".
>
> yes, done.
>
> > 4. Pledge authorizing the registrar: "Should I join it?"
>
> > nit: what is "it"? Surely not the registrar, and presumably the
> > "network domain" in question?
>
> yes, it = "network"
>
> > This document details protocols and messages to answer the above
> > questions. It uses a TLS connection and an PKIX (X.509v3)
> > certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer
> > points 1 and 2. It uses a new artifact called a "voucher" that the
>
> > I'm kind of confused by "[IDevID] LDevID", since my understanding was
> > that the LDevID is issued only after all four steps are complete.
>
> Yes, that seems to be a typo.
>
> > Also, following the IDevID link lands me at a page that claims to be for
> > a standard of status "superseded".
>
> Yes, the IEEE apparently put out 802.1AR-2018 replacing -2009 last year.
> I don't have a copy, and the getieee program just goes in loops of logging
> in, or results in servlet errors.
> I even emailed support, and they were basically useless.
> {fetching coffee to avoid rant}
>
> > nit: one can use X.509v3 without being PKIX, and it's not entirely clear
> > that the IDevIDs will chain up to the Internet PKI.
>
> You didn't respond to my suggestion that PKIX!=Internet PKI.
> I do think that we want many things the IETF PKIX WG has produced
> since X.509v3, so I don't think that X.509v3 is an appropriate noun
> to describe things.
I think this discussion is continuing in the other thread, right?
> > Section 1.2
>
> > RFC 8174 has an updated version of the BCP 14 boilerplate.
>
> done already.
>
> > I'd suggest adding "MASA Audit Log" as a defined term to give advance
> > warning that this is an explicit protocol feature.
>
> added.
>
> > domainID: The domain IDentity is the 160-bit SHA-1 hash of the BIT
> > STRING of the subjectPublicKey of the pinned-domain-cert leaf,
> > i.e. the Registrars' certificate. This is consistent with the
> > subject key identifier (Section 4.2.1.2 [RFC5280]).
>
> > What would it take to move away from SHA-1 for this purpose? It's
> > unclear how long it will be before finding a second
Re: [Anima] What does PKIX refer to: Re: Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On Fri, Aug 09, 2019 at 02:24:51PM -0400, Michael Richardson wrote: > > Michael Richardson wrote: > > I hoping for some discussion about this comment that I previously > > responded to, but it probably got buried. > > Actually, you did respond on July 20, in an email that I thought to re-read > after pushing send. > > In it you said: > > mcr> I would never call the Internet PKI "PKIX". > mcr> I'd call it WebPKI, or CAB. > mcr> PKIX is the set of IETF specifications that made X509v3 useful. > mcr> (And why I try never to use "X509"...) > mcr> > mcr> I couldn't find a reference to private PKI, so maybe I mis-understand. > >doc> This document details protocols and messages to answer the above >doc> questions. It uses a TLS connection and an PKIX (X.509v3) >doc> certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer >doc> points 1 and 2. It uses a new artifact called a "voucher" that the >doc> [...] >doc> Pledge authentication and pledge voucher-request signing is via a >doc> PKIX certificate installed during the manufacturing process. This is > > bk> The comment about private PKI was me making an assumption; I could be > bk> wrong. But I don't really expect all manufacturers that do this to have > bk> their IDevID signing CA be part of the Internet PKI; I expect them to be > bk> standalone CAs with the root baked into hardware and nothing else that > bk> uses that root. Does that help clarify? > > It helps to clarify where you think I'm referring to the Internet PKI. > > I don't think of "PKIX" as referring to the Internet PKI/WebPKI as managed by > the CAB-Forum. Yes, it will be a private CA 96% of the time. > A 1988 era X509v3 certificate isn't good enough; it has to be the IETF PKIX > WG profile of X509v3. 801.1AR mostly says that. I mean, PKIX closed before I was really doing much of anything in the IETF, so all I have are vague impressions shaped by what I've picked up from inferences made observing discourse among others. So I did have to check with someone who was actually there to confirm my sense that PKIX is the Internet PKI. (Not SPKI!) And sure, anything can be connected to the Internet, and presumably the BRSKI cases will be talking to the MASA over the Internet in some fashion, but it's hard to say that the PKI used to do so is a core part of the capital-I Internet. > If you feel that my use of PKIX here is too confusing, I will change it. I'm still open to pushback, but something like "PKIX-compatible" or "PKIX-conformant" would make me happier. -Ben ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On Tue, Jul 16, 2019 at 06:14:37PM -0400, Michael Richardson wrote: > > I have responded to DISCUSSes from: > Alissa Cooper: > https://mailarchive.ietf.org/arch/msg/anima/QZn8UnsNxtE3MCHm_gPVBl5uSrU > Roman Danyli: > https://mailarchive.ietf.org/arch/msg/anima/mff9ZyGBk4EflTqYS6fENWOFRpI > Alexey Melnikov > https://mailarchive.ietf.org/arch/msg/anima/Ul0yfnf4UlQhoI0UtlJVZ9otY7M > Adam Roach: > https://mailarchive.ietf.org/arch/msg/anima/6AAD9mwsKEsbIUmXRVOAV0N83yA > Eric Vyncke: > https://mailarchive.ietf.org/arch/msg/anima/O860UBbY4p3iNOZUdEYF_iNKMvs > > plus comments: > Mirja Kühlewind > https://mailarchive.ietf.org/arch/msg/anima/jFuz6ugS-_1bf0HG46vMjf3UNaw > Magnus Westlund: > https://mailarchive.ietf.org/arch/msg/anima/g1c17bHiBUMuhCmw4RDoHoN_1zE > and noted comments from Barry and Warren. > > and this is for Ben Kaduk's DISCUSS, which got buried, and I think is the > last. (You can always consult the datatracker page, too: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ballot/ I guess there's a couple No Objection with COMMENT that aren't mentioned above but maybe not that need replies.) > I'm going to use this email to deal with Ben's comments which I think we > already dealt with other edits, then I'll deal with low-hanging fruit, and > then decide how to deal with the desire for a high-level security analysis. > > Benjamin Kaduk via Datatracker wrote: > > (5) RFC7951 is cited for the audit log response, but I cannot find the > > underlying YANG module that is JSON-encoded using the RFC 7951 > > procedures. Furthermore, I don't think the "nonce" handling (with > > explicit "NULL" string where base64-encoded binary data might be > > expected) would be consistent with the 7951 rules. > > We did not resort to a YANG data model for the auditlog responses, so I spent > a few minutes mystified by your complaint... then: > We referenced 7951 (YANG->JSON), but we should have just referenced RFC7159 > (JSON)! Oh! That would make a lot more sense... (but 7159 is obsoleted by 8259, of course) > (Those numbers are annoyingly similar. And we actually made this mistake > before, I wonder if this was collatoral damage from a global search and > replace) > > > (6) In Section 7.2: > > >The pledge can choose to accept vouchers using less secure methods. > > These methods enable offline and emergency (touch based) deployment use > > cases: > > >1. The pledge MUST accept nonceless vouchers. This allows for a > > use > > > It's very unclear to me what this "MUST" means, especially so given > > that the entire section 7 is declared to be non-normative. Is it that > > the client "can choose" whether it "MUST accept nonceless vouchers"? > > That would seem to make the MUST basically ineffective. > > > > > > More broadly, if the entire Section 6 is non-normative, why is there > > any normative language in it? > > First, I think you mean section 7? I think you're right and that was a typo; sorry. > If so, the reason for normative language is because, we want to say, "if you > do X, then you MUST do it this way". > > Second, we have referenced some pieces of section 7.2 from section 9. > We think that there are significant security issues by accepting nonceless > vouchers, which we discuss in 11.1. A variation of the protocol is when > the manufacturer programs the pledge to ALWAYS accept nonceless vouchers. > There could otherwise be some more complex (proprietary, or documented later > on) evaluation of whether to accept a nonceless voucher. For instance, the > MASA could sign them with a different key, perhaps one stored in an HSM. Okay, so it is that the client (well, manufacturer?) chooses whether or not to accept nonceless vouchers. So we could change the introduction to the enumerated list to be saying that this is a list of exclusive candidate behaviors that could be chosen independently of each other, and not a collection of behaviors all of which are expected to be implemented. > A key point is that the Manufacturer/MASA knows exactly the rules that the > Pledge has been coded to, and we don't need to agree on all these rules to > get interoperability. Originally, we didn't even think we needed to > standardize the voucher, just the voucher-request; but it was the desire to > audit them on the Registrar that changed our mind. > > > (7) the new /enrollstatus and /voucher_status well-known EST endpoints > > are not registered in Section
Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT)
Not Eric, but playing that role for a bit... On Mon, Mar 11, 2019 at 04:31:45PM +0100, Toerless Eckert wrote: > Thanks Eric, inline > > This file is: > https://github.com/anima-wg/autonomic-control-plane/blob/master/draft-ietf-anima-autonomic-control-plane/16-eric-rescorla-reply.txt > > The following inline answers to your discuss have been integrated > into -19 of the draft which i just submitted. It also includes the > feedback to the comments by Eric and Ben. I was backlogged, and > after your review of -16 i had first responded to other reviewers > with -16/-17. > > Note that this includes a hopefully more comprehensive section 6.1.3 > explaining the Trust Anchor details required for the ACP, resulting from the > variety of discuss of the reviewers on this topic. > > Bens and Erics review where very good and comprehensive but alas > didn't make it easy for me to answer to them as quickly as i would have > wanted to. Unfortunately, i also had to go back and forth between > them, so i couldn't create a separate checkpoint version > showing ONLY changes for each of them. So the following diffs are > hopefully useful: > > -18 to -19: Changes made for Ben and Eric > > http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-18.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-19.txt > > Note that this includes a hopefully more comprehensive section 6.1.3 > explaining the Trust Anchor details required for the ACP, resulting from the > variety of discuss of the reviewers on this topic. > > -16 to -19: Changes since your last review (includes Alissa Coopers review) > > http://tools.ietf.org//rfcdiff?url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-19.txt > > Cheers > Toerless > > On Wed, Aug 01, 2018 at 04:56:38PM -0700, Eric Rescorla wrote: > > Eric Rescorla has entered the following ballot position for > > draft-ietf-anima-autonomic-control-plane-16: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ > > > > > > > > -- > > DISCUSS: > > -- > > > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D9959 > > > > > > I found this document extremely hard to follow due to a large number > > of grammar errors. It really needs a very thorough copy-edit pass, > > which I believe is beyond the RFC-editor's usual process. Ideally, the > > WG would do this. > > > > > > DETAIL > > S 6.1.1. > > > each other. See Section 6.1.2. Acp-domain-name SHOULD be the FQDN > > > of a DNS domain owned by the operator assigning the certificate. > > > This is a simple method to ensure that the domain is globally unique > > > and collision of ACP addresses would therefore only happen due to ULA > > > hash collisions. If the operator does not own any FQDN, it should > > > choose a string (in FQDN format) that intends to be equally unique. > > > > These rules do not seem to be strong enough. Unless you have disjoint > > trust anchors, there is a potential for cross-domain attac. > > Yes, two independent operators would use their own separate trust anchors. > > If you are are owning the PKI root for multiple independent ACP networks, > you COULD also establish a process by which you validate that there is no > SHA256 hash collision between the different ACP domain names that want > to use your one trust anchor. > > So, i am not sure what your point is. I think there's enough about trust points and trust anchors to be clear that we provide the property Eric was looking for that avoids the cross-domain attack. > > S 6.1.2. > > > See section 4.2.1.6 of [RFC5280] for details on the subjectAltName > > > field. > > > > > > 6.1.2. ACP domain membership check > > > > > > The following points constitute the ACP domain membership check of a > > > > What is the relationship of these rules to the existing 5280 rules? > > Note that there where already i hope good improvements in this text from -16 > you reviewed to -18. My read here is that we could address this by "we use the standard PKIX [RFC 5280] certificate validation rules with some additional ACP-specific procedures. In particular: [...]". That is, have a statement about the relationship of this procedure to th
[Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-19: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-anima-autonomic-control-plane-19: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/
--
DISCUSS:
--
[trimming to just the topics still under discussion; no change to the
text of the remaining items even though some changes have been made
to the document]
I think there needs to be some justification of why rfc822Name is chosen
over a more conventional structure in the otherName portion of the
subjectAltName, which is explicitly designed to be extensible.
In a few places, the MTI cryptographic mechanisms are under-specified,
whether the cipher mode for IKE or the TLS ciphersuites. I have attempted
to note these locations in my section-by-section comments.
Section 6.11.1.14 places a normative ("SHOULD") requirement on the RPL
root, but if I understand correctly the RPL root is automatically
determined within the ACP, and thus the operator does not a priori know
which node will become the RPL root. Am I misunderstanding, or is this
effectively placing this requirement on all ACP nodes?
--
COMMENT:
--
Thank you for adding the implementation experience note to the shepherd
writeup; it is helpful to understand the maturity level of the document.
The comments here are probably best understood in the context of my
previous ballot position, specifically with respect to certain topics
being "speculative" or a matter for "future work".
One somewhat general comment that occurred to me on the reread is that
by encoding the ACP address into a node's LDevID, we are on the face of
things locking it into a given addressing model, though in practice it
should be fairly straightforward to issue a new certificate through
regular update/renewal mechanisms. I forget if we have discussion of
this non-issue already.
Section 1
Combining ACP with Bootstrapping Remote Secure Key Infrastructures
(BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the
"Autonomic Network Infrastructure" as defined in
[I-D.ietf-anima-reference-model], which provides autonomic
connectivity (from ACP) with fully secure zero-touch (automated)
bootstrap from BRSKI. The ANI itself does not constitute an
nit: It's unclear that there's universal agreement about what "fully
secure" might mean, so I'd suggest just using "secure".
Section 2
ACP (ANI/AN) Domain Certificate: A provisioned [RFC5280] certificate
(LDevID) carrying the domain information field which is used by
nit: I think the reference is for "certificate", not "provisioned".
ACP secure channel: A cryptographically authenticated and encrypted
data connection established between (normally) adjacent ACP nodes
to carry traffic of the ACP VRF secure and isolated from Data-
Plane traffic in-band over the same link/path as the Data-Plane.
nit: I'm not sure if "secure" or "securely" is better (but what does
"secure from" mean?)
Enrollment: The process where a node presents identification (for
example through keying material such as the private key of an
IDevID) to a network and acquires a network specific identity and
trust anchor such as an LDevID.
nit: the LDevID is the identity; it's not a trust anchor.
Section 5
3. For each node in the candidate peer list, it authenticates that
node (according to Section 6.1.2) and negotiates a mutually
acceptable channel type.
4. For each node in the candidate peer list, it then establishes a
secure tunnel of the negotiated type. The resulting tunnels are
then placed into the previously set up VRF. This creates an
overlay network with hop-by-hop tunnels.
nit: the "channel type" of (3) is the "negotiated type" of the "secure
tunnel" in (4), right? It might be nice to use the same word in
both items, to help tie the language together.
Section 6
nit: "must have it's ACP domain certificate" gained an apostrophe in "it's"
but the original "its" was correct.
Section 6.1
members. The LDevID is used to cryptographically authenticate the
membership o
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT)
Hi Toerless, On Mon, Mar 11, 2019 at 04:32:14PM +0100, Toerless Eckert wrote: > Thanks Benjamin, > > This file is: > https://github.com/anima-wg/autonomic-control-plane/blob/master/draft-ietf-anima-autonomic-control-plane/16-ben-kaduk-reply.txt > > The following inline answers to your discuss have been integrated > into -19 of the draft which i just submitted. It also includes the > feedback to the comments by Eric and Ben. I was backlogged, and > after your review of -16 i had first responded to other reviewers > with -16/-17. Thanks for the updates. I'm sorry it took so long to get feedback on them -- it took me a while to get a free day to review the whole document while I've been moving across the country and with my family's schedule. I've prepared comments on the -19 and will update my ballot position with them. I will leave unchanged the Discuss section text for a couple of points, with the understanding that we have an ongoing discussion here and that our email discussion is authoritative -- the ballot position is just to keep a note that the discussion is ongoing. > Note that this includes a hopefully more comprehensive section 6.1.3 > explaining the Trust Anchor details required for the ACP, resulting from the > variety of discuss of the reviewers on this topic. A welcome clarification, thanks. > Bens and Erics review where very good and comprehensive but alas > didn't make it easy for me to answer to them as quickly as i would have > wanted to. Unfortunately, i also had to go back and forth between > them, so i couldn't create a separate checkpoint version > showing ONLY changes for each of them. So the following diffs are > hopefully useful: > > -18 to -19: Changes made for Ben and Eric > > http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-18.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-19.txt > > -16 to -19: Changes since your last review (includes Alissa Coopers review) > > http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-19.txt > > Cheers > Toerless > > On Wed, Aug 01, 2018 at 05:30:10PM -0700, Benjamin Kaduk wrote: > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-anima-autonomic-control-plane-16: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ > > > > -- > > DISCUSS: > > -- > > > > This is a really exciting protocol to read about -- the prospect of > > dropping a bunch of just-manufactured devices in place, spinning up a > > registrar (and maybe a MASA), and getting a control plane like magic is > > pretty impressive. > > Thanks ;-) > > > That said, I don't believe that this document is ready > > to publish as-is. I have a list of specific points below for discussion, > > but it may be more effective to strip down the document a lot (providing a > > well-defined core protocol and leaving out speculative future work, along > > the lines of Alissa's comments) and only then start to work on specific > > rough spots. > > Thanks. I hope that the fixes to the document done in response to you > and other reviewers feedback will satisfy you. > > Let me give you some IMHO good technical arguments for the necessity of > the size of the document. there are also other charter and process arguments > but maybe better taken offline to explain. > > - You review was for -16 for -17/18, document already restructured > all speculative text into appendix A. All text in A is not unsolicited > but results of discuss/questions in the WG for this doc. > > - Section 10 (operations) is IMHO mandatory to be main text. ANIMA is an OPS > group, and overall about operational simplification, so the node-local > behavior is crucial to achieve this. Not only the interop affecting aspects > (normative sections). IMHO, this section is not speculative. > > - Stripping
Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On Thu, Jul 11, 2019 at 11:44:55PM +0200, Eliot Lear wrote: > One thought: > > I think the simplest way to address the bulk of both Adam’s and Warren’s > concern is to require the device to emit via whatever management interface > exists, upon request, a voucher that it has signed with its own iDevID. It > would have to be nonceless with perhaps a long expiry, and that would cover a > number of other use cases as well. That way if the manufacturer goes out of > business, or if the owner wants to transfer the device without manufacturer > consent, there is a way forward. An interesting thought. Would there be a way (or a need) to usefully audit such voucher issuance? -Ben ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-22: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ -- DISCUSS: -- (1) The text of the document suffers from lack of clarity throughout about whether the nonce-ful operation is mandatory or not, with several figures and discussions making declarative statements about nonce usage and others saying that nonce usage is optional. (See COMMENT.) (2) There also seems to be internal inconsistency about the proximity assertion process (and, any sort of assertion in a voucher-request at all, it seems). I've tried to note some locations in the Comment section. (3) There are other internal inconsistencies as well, including about section references for when various behaviors occur (see COMMENT). (4) In Section 5.6.1 The pledge MUST verify that the voucher nonce field is accurate and matches the nonce the pledge submitted to this registrar, or that the voucher is nonceless (see Section 7.2). Is the pledge supposed to accept a nonceless voucher in response to a nonce-ful voucher request? (5) RFC7951 is cited for the audit log response, but I cannot find the underlying YANG module that is JSON-encoded using the RFC 7951 procedures. Furthermore, I don't think the "nonce" handling (with explicit "NULL" string where base64-encoded binary data might be expected) would be consistent with the 7951 rules. (5) the new /enrollstatus EST endpoint seems under-specified. (6) In Section 7.2: The pledge can choose to accept vouchers using less secure methods. These methods enable offline and emergency (touch based) deployment use cases: 1. The pledge MUST accept nonceless vouchers. This allows for a use It's very unclear to me what this "MUST" means, especially so given that the entire section 7 is declared to be non-normative. Is it that the client "can choose" whether it "MUST accept nonceless vouchers"? That would seem to make the MUST basically ineffective. More broadly, if the entire Section 6 is non-normative, why is there any normative language in it? (7) the new /enrollstatus and /voucher_status well-known EST endpoints are not registered in Section 8.1 (7.1) I think we also need to register the "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa" XML namespace. (8) The versioning mechanism for Pledge BRSKI Status Telemetry is underspecified, including the interaction with new registered values. (9) The versioning mechainsm for the MASA audit log response is underspecified, including whether a registry of field names is appropriate. (10) The term PKIX seems to be incorrectly used a few times; it refers to the Internet PKI, and so things like a private PKI internal to a manufacturer would probably not be best described as such. Such private PKIs can of course still reuse the protocols and mechanisms developed for PKIX, and it's accurate to describe them as such. (11) In a few places we describe the voucher-request in terms of its YANG structure but do not say that it has to be wrapped in a signed CMS object as is done for the RFC 8366 voucher. (12) Maybe this is a "discuss discuss", but why do we need SHA-1 in the domainID calculation? (13) In Section 5.5.1: As described in [RFC8366] vouchers are normally short lived to avoid revocation issues. If the request is for a previous (expired) voucher using the same registrar then the request for a renewed voucher SHOULD be automatically authorized. The MASA has sufficient I don't understand what "for a previous (expired) voucher" means. Is it something like "containing the same content as a previous voucher request for which a voucher was issued", with the presumption that the voucher expired before the pledge could successfully imprint, so it needs to try again? Or does this extend to longer timescales, like a device that gets deployed for a couple years and is then reset to factory settings and has to rebootstrap but is still by the same registrar? (14) In Section 5.6: The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616] error code when a problem occurs. In this case, the response data from the MASA MUST be a plaintext human- readable (ASCII, English) error message containing explanatory information de
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT)
On Thu, Aug 02, 2018 at 02:09:08PM +1200, Brian E Carpenter wrote: > On 02/08/2018 12:30, Benjamin Kaduk wrote: > > > -- > > DISCUSS: > > -- > > > In particular, in its current form, it's not clear to me why this document > > is targeting the standards-track -- there are lots of places where > > determinations of what works best or how to do some things is left for > > future work. > > We had no choice, because this is a normative reference for GRASP, since > GRASP requires at least one secure transport substrate. That seems like a pretty specious argument -- it assumes as a prior that GRASP also must be standards-track, and ignores the well-established downref process. On the other hand, the ANIMA milestones do say to "submit autonomic control plane solution to the IESG (Standards Track)". (The charter itself does not say anything about document status.) On the gripping hand, the IESG does have the authority to determine the track on which a document is published. > It's true, I think, that the draft could do a better job of > separating the well-defined normative requirements from the issues > that are to a considerable extent implementation-dependent. But I But I'd prefer to see these improvements made than debate the above. > don't agree that it's at the Experimental stage, because it has a > pedigree in proprietary code. Please consider that it is only > asking for *Proposed* Standard status. Could you enlighten me about this pedigree? Is it just the Autonomic Networking project from Cisco, or is there more (or even indepnedent implementations)? > > I also think the document needs to be more clear about what security > > properties it does or does not intend to provide: > > I agree that this could be more clearly stated. By implication, > it's this: > https://tools.ietf.org/html/draft-ietf-anima-grasp-15#section-2.5.1 Thanks, that's a great start. -Benjamin ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-anima-autonomic-control-plane-16: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/
--
DISCUSS:
--
This is a really exciting protocol to read about -- the prospect of
dropping a bunch of just-manufactured devices in place, spinning up a
registrar (and maybe a MASA), and getting a control plane like magic is
pretty impressive. That said, I don't believe that this document is ready
to publish as-is. I have a list of specific points below for discussion,
but it may be more effective to strip down the document a lot (providing a
well-defined core protocol and leaving out speculative future work, along
the lines of Alissa's comments) and only then start to work on specific
rough spots.
In particular, in its current form, it's not clear to me why this document
is targeting the standards-track -- there are lots of places where
determinations of what works best or how to do some things is left for
future work. Are there lots of implementations or consumers clamoring for
this stuff that it makes sense to go for PS as opposed to Experimental (so
as to figure out what works and nail down a slimmer protocol for the
standards track)? I see in A.4 that the choice of RPL was motivated by
experience with a pre-standard version of ACP; it would have been great to
hear more about those deployments in an Implementation Status section (per
RFC 7942) or the Shepherd writeup.
I also think the document needs to be more clear about what security
properties it does or does not intend to provide: we hear in the abstract
and introduction that ACP will be "secure" (and similar platitudes are
repeated throughout), but we don't really get a sense of the specifics
until Section 4, with ACP5. This has a MUST for authenticated and "SHOULD
(very strong SHOULD)" be encrypted. But text elsewhere in the document
seems to be using "secure" to also mean encrypted, and there is even one
place that flatly asserts that "ACP mandates the use of encryption". This
internal inconsistency needs to be resolved, at a minimum, and ideally the
intended posture more clearly conveyed. (It's also not really stated under
what cases encryption would not be used, so that the "very strong SHOULD"
could not be a MUST.)
Section 3.2 claims that the ACP provides "additional security" for
bootstrap mechanisms due to the hop-by-hop encryption. But in what sense
is actual additional security gained? Against an attacker with what
capabilities? If there is security gain from such hop-by-hop encryption,
doesn't that point to a weakness in the bootstrap scheme?
I think there needs to be some justification of why rfc822Name is chosen
over a more conventional structure in the otherName portion of the
subjectAltName, which is explicitly designed to be extensible.
The requirement in Section 6.1.2 for CRL and OCSP checks seem impossible to
satisfy for a greenfield node without non-ACP connectivity, as it must join
the ACP domain (and supposedly validate the CRL and OCSP validity before
doing so) before establishing an ACP link with its peer, but cannot
validate anything with no connectivity.
Throughout, the document seems to implicitly conflate authentication with
authorization. I understand that the main authorization check is just the
domain membership test in Section 6.1.2; nonetheless, as a pedagogical
matter I cannot support propagating their conflation.
In a few places, the MTI cryptographic mechanisms are under-specified,
whether the cipher mode for IKE or the TLS ciphersuites. I have attempted
to note these locations in my section-by-section comments.
Section 6.11.1.14 places a normative ("SHOULD") requirement on the RPL
root, but if I understand correctly the RPL root is automatically
determined within the ACP, and thus the operator does not a priori know
which node will become the RPL root. Am I misunderstanding, or is this
effectively placing this requirement on all ACP nodes?
The IANA considerations specifically do register SRV.est in the GRASP
Objective Names Table, and then follows up with a paragraph that this is
only a "proposed update". I don't know if there's actually anything
problematic here, but the document does need clarity on what is proposed
for
