Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Thanks for your reply. Responses to questions below.
On 7/12/19 4:07 PM, Michael Richardson wrote:
>
---
> §5.6
>> {
>> "ietf-voucher:voucher": {
>> "nonce": "62a2e7693d82fcda2624de58fb6722e5",
>> "assertion": "logging"
>> "pinned-domain-cert": "base64encodedvalue=="
>> "serial-number": "JADA123456789"
>> }
>> }
> This JSON is syntactically invalid. Please run this example and all other
> instances of JSON in this document through a validation tool.
I have moved all of our examples json into separate files in our directory so
that we can validate them better, and added the validation to the Makefile.
I see that "FALSE" is not valid, but "false" is.
Please note that we know we have to renumber the figures.
In the appendix, we have examples of the JSON that is inside the CMS.
These are from real examples, and we have the private keys so that implementors
can make sure they can produce the same outputs.
The pinned-domain-cert has base64 in it, and it's more than 60 characters
wide. I noticed it wasn't wrapped at all in -22, and just fixed that to be
wrapped at 60 characters, but then, it isn't valid JSON, because it has
LF in the "". I shall leave a note, but maybe you have a better suggestion
here.
Your approach is fine. Many other protocols make the same kind of note
when they need to break the syntax for RFC format purposes. The only
other thing I've seen done is taking the whole message and bas64
encoding it, but that makes it less useful as an illustration in this
case, so I would advise against it.
> §5.8.1:
>> Distribution of a large log is less than ideal. This structure can
>> be optimized as follows: Nonced or Nonceless entries for the same
>> domainID MAY be truncated from the log leaving only the single most
> Nit: "truncate" means to shorten something by removing only the
beginning or
> only the end. I believe that you mean "omitted" (here and elsewhere in
this
> section).
How about*abridged*? I also used omitted where it referred to a single entry.
"Abridged" seems a bit awkward: the *structure* is abridged, but the
*entries* are omitted or elided or removed or excised or suppressed.
You have two other queries, but they're addressed to other people. Let
me know if you'd like my perspective on them.
/a
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Max and Toerless, please search for your name.
Adam Roach via Datatracker wrote:
> §2.1
>> |+--v---+
>> || (5) Enroll |<---+ (non-error HTTP codes )
>> ^+ |\___/ (e.g. 201 'Retry-After')
>> | Enroll +--+---+
>> | Failure |
> I can't work out what a "Retry-After" would mean in a "201 Created"
response.
> As noted above, section 5.6 of this document does indicate the use of a
> "Retry-After" header field with a 202 response, so I presume this diagram
> should say 202?
Thank you. It should say 202.
>
---
> §5:
>> BRSKI uses existing CMS message formats for existing EST operations.
>> BRSKI uses JSON [RFC7159] for all new operations defined here, and
>> voucher formats.
> RFC 7159 has been obsoleted by RFC 8259.
updated.
>
---
> §5.2
>> The pledge SHOULD include an [RFC7231] section 5.3.2 "Accept" header
>> indicating the acceptable media type for the voucher response. The
> Nit: ..."Accept" header field indicating...
fixed.
>
---
> §5.5
>> The Registrar SHOULD include an [RFC7231] section 5.3.2 "Accept"
>> header indicating the response media types that are acceptable. This
> Nit: ..."Accept" header field indicating...
fixed.
>> field and appropriate 'Accept header' field values from the physical
> Nit: ...'Accept header field' values...
fixed.
>
---
> §5.6
>> pledge would keep track of the appropriate Retry-After header values
> Nit: "...Retry-After header field values..."
fixed.
>> desired type or using the desired algorithms (as indicated by the
>> Accept: headers, and algorithms used in the signature) cannot be
> Nit: "...Accept: header fields, ..."
fixed.
>> The voucher response format is as indicated in the submitted accept
>> header or based on the MASA's prior understanding of proper format
> Nit: "...Accept header field..."
fixed.
>
---
> §5.6
>> {
>> "ietf-voucher:voucher": {
>> "nonce": "62a2e7693d82fcda2624de58fb6722e5",
>> "assertion": "logging"
>> "pinned-domain-cert": "base64encodedvalue=="
>> "serial-number": "JADA123456789"
>> }
>> }
> This JSON is syntactically invalid. Please run this example and all other
> instances of JSON in this document through a validation tool.
I have moved all of our examples json into separate files in our directory so
that we can validate them better, and added the validation to the Makefile.
I see that "FALSE" is not valid, but "false" is.
Please note that we know we have to renumber the figures.
In the appendix, we have examples of the JSON that is inside the CMS.
These are from real examples, and we have the private keys so that implementors
can make sure they can produce the same outputs.
The pinned-domain-cert has base64 in it, and it's more than 60 characters
wide. I noticed it wasn't wrapped at all in -22, and just fixed that to be
wrapped at 60 characters, but then, it isn't valid JSON, because it has
LF in the "". I shall leave a note, but maybe you have a better suggestion
here.
>
---
> §5.8:
>> A MASA that returns a code 200 MAY also include a Location: header
>> for future reference by the registrar.
> Nit: "Location: header field"
> Also, it's not 100% clear what the registrar would use this URI for.
Please
> explain in the document.
okay.
> §5.8.1:
>> Distribution of a large log is less than ideal. This structure can
>> be optimized as follows: Nonced or Nonceless entries for the same
>> domainID MAY be truncated from the log leaving only the single most
> Nit: "truncate" means to shorten something by removing only the beginning
or
> only the end. I believe that you mean "omitted" (here and elsewhere in
this
> section).
How about *abridged*? I also used omitted where it referred to a single entry.
>
---
> §6:
>> In the BRSKI context, the EST "Content-Transfer-Encoding" header if
>> present, SHOULD be ignored. This header does not need to included.
> Nit: "...header field, if present..."
> Nit: "This header field does not..."
done.
>
---
> §8.1:
>> This document extends the definitions of "est" (so far defined via
>> RFC7030) in the
Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
FYI what you all are discussing are potential changes to the normative language of https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-22#section-7.2 Probably strengthening this paragraph from MAY/SHOULD to a MUST: 3. The pledge MAY have an operational mode where it skips voucher validation one time. For example if a physical button is depressed during the bootstrapping operation. This can be useful if the manufacturer service is unavailable. This behavior SHOULD be available via local configuration or physical presence methods (such as use of a serial/craft console) to ensure new entities can always be deployed even when autonomic methods fail. This allows for unsecured imprint. If this is a suggested change please comment on the subsequent paragraph which reads: It is RECOMMENDED that "trust on first use" or any method of skipping voucher validation (including use of craft serial console) only be available if hardware assisted Network Endpoint Assessment [RFC5209] is supported. This recommendation ensures that domain network monitoring can detect innappropriate use of offline or emergency deployment procedures when voucher-based bootstrapping is not used. The use of SHOULD and RECOMMEND are strong indicators of how this should be done. As much so as a MUST "security requirements we write into our specs, we'll have no means of enforcement”. Since Eliot has brought up other options like being able to replace the MASA trust anchors or some form of “self emitted” voucher here are the current thoughts along those lines: If one possessed a nonceless voucher then one possesses a permanent token to enable bootstrapping of the device. This is the very first point in section 7.2 discussed above: 1. The pledge MUST accept nonceless vouchers. This allows for a use case where the registrar can not connect to the MASA at the deployment time. Logging and validity periods address the security considerations of supporting these use cases. There are two ways to leverage this. Predominately his means that after a single BRSKI exchange any domain owner can opt out of any future BRSKI stuff and still be able to (re)perform over-the-wire bootstrapping (this is of course captured in the audit log). Additionally the privacy protections mean that this voucher can be tied to a transient keypair that could be distributed with the device for resale. So this can be passed on to entities further down the supply chain or during a resale of the device. These two methods hit a large percentage of use cases being discussed while maintaining the audit log. - max On Jul 12, 2019, at 1:27 AM, Eliot Lear mailto:l...@cisco.com>> wrote: Hi Adam On 12 Jul 2019, at 00:25, Adam Roach mailto:a...@nostrum.com>> wrote: The smallest change that would satisfy my concern would be a statement that says that devices conformant to this specification MUST contain a local means of bootstrapping that does not rely on any specific server being available. As with the security requirements we write into our specs, we'll have no means of enforcement. But as with the security requirements we write into our specs, we'll give interested parties just that little bit more leverage that might tip the scales towards the correct behavior. I think this is easily possible within the paradigm of the document after the device has first been onboarded. At this stage, I would also suggest that the MUST be a SHOULD for another reason: there may be cases where it is in the customer best interest to prevent onboarding of a device just through proof of possession. I am thinking of anti-theft mechanisms. Having a discussion of this and the risks of not having any on-prem method ever seems like a reasonable add. Eliot ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Hi Adam > On 12 Jul 2019, at 00:25, Adam Roach wrote: > > > The smallest change that would satisfy my concern would be a statement that > says that devices conformant to this specification MUST contain a local means > of bootstrapping that does not rely on any specific server being available. > As with the security requirements we write into our specs, we'll have no > means of enforcement. But as with the security requirements we write into our > specs, we'll give interested parties just that little bit more leverage that > might tip the scales towards the correct behavior. I think this is easily possible within the paradigm of the document after the device has first been onboarded. At this stage, I would also suggest that the MUST be a SHOULD for another reason: there may be cases where it is in the customer best interest to prevent onboarding of a device just through proof of possession. I am thinking of anti-theft mechanisms. Having a discussion of this and the risks of not having any on-prem method ever seems like a reasonable add. Eliot signature.asc Description: Message signed with OpenPGP ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
