Re: [Anima] Max/*: Re: RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

[Max Pritikin (pritikin)]

I shared my understanding of why the field exists and the language in existing 
docs supporting that understanding. As an optimist I hoped that manufacturers 
wouldn’t re-use serial numbers, although MCR followed up with examples, so I 
focussed on a rosy future where anima concepts are well established and a MASA 
service could be marketed to multiple manufacturers.

Between those two scenarios I think your suggestion of clarifying in RFC8366bis 
makes sense. Working group feedback could clarify if others feel it adds value 
or is unnecessary complexity.

- max

On Jul 26, 2021, at 11:52 AM, Toerless Eckert 
mailto:t...@cs.fau.de>> wrote:

Thanks, Max

My point was that reuse of serial number by e..: a MASA service supporting
multiple vendors is not a sufficient example why you would need this field.
The way i understand it, you would also need to assume that the two
devices with the same serial number have the same trust anchor against
which a voucher would be compared.

So, if for example the serial number is a bad format not well identifying the
vendor (VID/PID etc..), then the same serial number could happen across
different vendors served by the same MASA, but there would be no collision,
because these would have different TA.

I hope i correctly analyzed this.

Which gets us back to the case you mention, which is one and the same vendor
(shudder) reusing serial numbers.

a) Are we aware of any actual instance of this ?
b) If not, can we create an example that sounds reasonable ?

  For example, i am manufacturing cheap low-end compuate, SBC or
  constrained CPU nodes (the like of ESP32 or so). These have an
  ethrenet interface but i sell too many to actually buy unique
  MAC addresses from IEEE. But still i thought it is a great
  idea for VID/PID to include model-type, but as the numeric
  component the ethernet-MAC, because i really didn't wan to have
  a unique identification (yes, i know this sounds stupid to me,
  but i am trying to come up with an example, and i have seen all
  type of stupid industry stuff).

  So, later on this security stuff gets added, BRSKI, voucher,
  devices have no reasonable insecure serial-numer, but their
  IDevID derived from such useless insecure serial number does
  have a unique differentiar,namely that KeyIdentifier.

If something like this would be a stupid but possible case, then
i would like us to write somehing short about this into rfc8366bis
so readers can understand why this differentiation by KeyIdentifier
may be useful to have.

Cheers
   Toerless

On Fri, Jul 23, 2021 at 10:00:40PM +, Max Pritikin (pritikin) wrote:
Inline,

On Jul 23, 2021, at 11:34 AM, Toerless Eckert 
mailto:t...@cs.fau.de>> wrote:


Unfortunately, i have to pile on instead of just answering:

I can not remember that we ever constructed a case where his
field was necessary when we wrote rfc8366. At least, we did
not document it e.g. in the examples. Such an example, explanation
would now be very helpfull in answering your question. Or at leas
for me to wrap my head around it.

I for once can not come up with a case where this field would
be anything else than what is in the CMS signerInfo, aka: this
field is redundant. And creating correct interop for
a redundant field is some somewhat non-motivational.

So, if anyone can lay out an example where this field is
actually required,

Pulling from the YANG module description in s5.3 of RFC8366

This leaf is "Optional since some serial-numbers are already unique within the 
scope of a MASA” because, within the scope of a manufacturer authorized signing 
authority that is truly provided by the manufacturer one could reasonably 
expect the serial number to be unique. I mean, what kind of manufacturer would 
sell multiple devices with the same serial number? They’d just be shooting 
themselves in the foot.

So the use case here is for a MASA servicing devices that might plausibly have 
the same serial number; where "the statistically unique key identifier ensures 
statistically unique identification of the hardware”. This could obviously 
occur if a manufacture was, shudder, re-using serial numbers. It is more likely 
to occur when the MASA is a service authorized by the manufacturer that also 
handles multiple manufacturers.

For example in: 
https://datatracker.ietf.org/doc/html/draft-friel-anima-brski-cloud-04.html#section-1.2

"While a Cloud Registrar will typically handle all the devices of a
  particular product line from a particular manufacturer there are no
  restrictions on how the Cloud Registrar is horizontally (many sites)
  or vertically (more equipment at one site) scaled.  It is also
  entirely possible that all devices sold by through a particular VAR
  might be preloaded with a configuration that changes the Cloud
  Registrar URL to point to a VAR.

Now to the original question, is this the entire “AuthorityKeyIdentifier” 
SEQUENCE or the KeyIdentifier OCTET STRING?

My intuitio

Re: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

[Max Pritikin (pritikin)]

Inline,

> On Jul 23, 2021, at 11:34 AM, Toerless Eckert  wrote:
> 
> 
> Unfortunately, i have to pile on instead of just answering:
> 
> I can not remember that we ever constructed a case where his
> field was necessary when we wrote rfc8366. At least, we did
> not document it e.g. in the examples. Such an example, explanation
> would now be very helpfull in answering your question. Or at leas
> for me to wrap my head around it.
> 
> I for once can not come up with a case where this field would
> be anything else than what is in the CMS signerInfo, aka: this
> field is redundant. And creating correct interop for
> a redundant field is some somewhat non-motivational.
> 
> So, if anyone can lay out an example where this field is
> actually required,

Pulling from the YANG module description in s5.3 of RFC8366

This leaf is "Optional since some serial-numbers are already unique within the 
scope of a MASA” because, within the scope of a manufacturer authorized signing 
authority that is truly provided by the manufacturer one could reasonably 
expect the serial number to be unique. I mean, what kind of manufacturer would 
sell multiple devices with the same serial number? They’d just be shooting 
themselves in the foot. 

So the use case here is for a MASA servicing devices that might plausibly have 
the same serial number; where "the statistically unique key identifier ensures 
statistically unique identification of the hardware”. This could obviously 
occur if a manufacture was, shudder, re-using serial numbers. It is more likely 
to occur when the MASA is a service authorized by the manufacturer that also 
handles multiple manufacturers. 

For example in: 
https://datatracker.ietf.org/doc/html/draft-friel-anima-brski-cloud-04.html#section-1.2

"While a Cloud Registrar will typically handle all the devices of a
   particular product line from a particular manufacturer there are no
   restrictions on how the Cloud Registrar is horizontally (many sites)
   or vertically (more equipment at one site) scaled.  It is also
   entirely possible that all devices sold by through a particular VAR
   might be preloaded with a configuration that changes the Cloud
   Registrar URL to point to a VAR.

Now to the original question, is this the entire “AuthorityKeyIdentifier” 
SEQUENCE or the KeyIdentifier OCTET STRING?

My intuition is Interpretation #1, just the KeyIdentifier.  

- max

> i would be a lot more incentivised
> to think about an answer. But primarily i'd like tha
> type of example to be added to rfc8366bis.
> 
> Cheers
>Toerless
> 
> P.S.: I think it is [1], primarily because it would be
> strange to map a CMS structure just into a single CMS
> octet string field instead of mapping it 1:1.
> 
> On Fri, Jul 23, 2021 at 03:30:39PM +, Esko Dijk wrote:
>> Hello all,
>> 
>> From the hackathon/interop we hit an interesting difference in spec-reading 
>> viewpoints that I would like to bring to the list.
>> 
>> *** Question and context
>> The question is what is included in the ‘idevid-issuer’ field? RFC 8366 
>> states that it is binary and:
>> 
>>   The Authority Key Identifier OCTET STRING (as defined in
>>   https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.1) 
>> from the pledge's IDevID
>>   certificate.  
> 
> Sounds like at least the start for an errata against RFC8366.
> Not sure if we can start filing an errata when we agree that
> the spec is ambiguous *sigh*.
> 
>> We can look at the 4.2.1.1 RFC 5280 definition:
>> 
>>   AuthorityKeyIdentifier ::= SEQUENCE {
>>  keyIdentifier [0] KeyIdentifier   OPTIONAL,
>>  authorityCertIssuer   [1] GeneralNamesOPTIONAL,
>>  authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }
>> 
>>   KeyIdentifier ::= OCTET STRING
>> 
>> *** Interpretation #1
>> take the OCTET STRING part of the Authority Key Identifier, i.e. the " 
>> Authority Key Identifier OCTET STRING "  which is the last line == 
>> KeyIdentifier.
>> So only the ASN.1 bytes encoding 'KeyIdentifier' are included there because 
>> this is the OCTET STRING part of it as indicated. That is why OCTET STRING 
>> is written in capitals in RFC 8366.
>> 
>> Note that the keyIdentifier MUST be there for non-self-signed certs per RFC 
>> 5280:
>> “The keyIdentifier field of the authorityKeyIdentifier extension MUST
>>   be included in all certificates generated by conforming CAs to
>>   facilitate certification path construction”
>> 
>> So for this reason one can rely on purely the keyIdentifier part of the AKI; 
>> and one could think that RFC 8366 was stating this.
>> 
>> *** Interpretation #2
>> The OCTET STRING is the entire structure AuthorityKeyIdentifier , encoded in 
>> ASN.1 format (=JSON Octet String encoding in a JSON Voucher, or in CBOR 
>> voucher a ‘byte string’ CBOR type).
>> Even though the AuthorityKeyIdentifier  SEQUENCE is not labeled as “OCTET 
>> STRING” in capitals in RFC 5280, this is what is inte

Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)

[Max Pritikin (pritikin)]

On the discussion of what the ‘pinned-domain-cert’ is please refer to the 
language of RFC8366:

  leaf pinned-domain-cert {
type binary;
mandatory true;
description
  "An X.509 v3 certificate structure, as specified by RFC 5280,
   using Distinguished Encoding Rules (DER) encoding, as defined
   in ITU-T X.690.
   This certificate is used by a pledge to trust a Public Key
   Infrastructure in order to verify a domain certificate
   supplied to the pledge separately by the bootstrapping
   protocol.  The domain certificate MUST have this certificate
   somewhere in its chain of certificates.  This certificate
   MAY be an end-entity certificate, including a self-signed
   entity.";

Within that document we opted for this language as it supports a large set of 
use cases including offline voucher issuance etc. It supports pinning a 
specific end-entity and it supports pinning a CA. Each of these have 
operational benefits as discussed extensively throughout this working groups 
activities. The example voucher’s within 
draft-ietf-anima-bootstrapping-keyinfra-39 are consistent with this. 

This discussion has raises a discontinuity though. The brski draft encourages, 
actually mandates, using the CA certificate. This is too likely too strong of a 
“be conservative in what you do” as it limits use of public CA infrastructures 
and it causes confusion in the intended pledge behavior of “be generous in what 
you accept”. 

To resolve this the draft can be slightly less explicit in which certificate is 
sent from the registrar to be pinned. This is not as conservative as the 
current language but ensures all uses cases envisioned by the RFC8366 work is 
maintained. The following is a summary of changes intended but expect an actual 
diff real soon:

s 5.5. Registrar Requests Voucher from MASA
"The entire registrar certificate chain, up to and including the Domain CA, 
MUST be included in the CMS structure.”
This sentence will be softened to allow the registrar flexibility to choose how 
high up the chain to pin. This is ‘less conservative’ and admits the 
flexibility intended. 

s 5.5.2 MASA pinning of registrar
"This CA certificate will be used to populate the "pinned-domain-cert" of the 
voucher being issued.”
This sentence to clarify that the highest cert in the chain submitted by the 
registrar is used rather than the explicit CA certificate. This is being more 
“generous in what you accept”. 

s 5.6.2 Pledge authentication of provisional TLS connection
"The 'pinned-domain-cert' element of the voucher contains the domain CA's 
public key.” 
This language aligned with the RFC8366 language to ensure we maintain the 
“generous in what you accept” behavior intended by RFC8366. 

Michael is a rock star and is working on the actual text changes. 

-max

> On Apr 1, 2020, at 3:16 AM, Esko Dijk  wrote:
> 
> Michael, Could you clarify what you mean with "EE certificate" and "domain's 
> EE certificate" ? Of which entity? And how can a domain have an end entity 
> certificate - I expect this to always be a CA?
> 
> I share Ben's view that the pinned-domain-cert is a CA certificate. If not 
> the case, then the text needs to be updated in several places. 
> Based on the discussion, trying to list some practical cases we can have of 
> the pinned-domain-cert:
> 
> 1. the Registrar's certificate, which is an RA type certificate at least. (It 
> MAY be a CA certificate instead of RA, if the Registrar itself acts as CA 
> non-delegated. )
>  This is the most narrow pinned certificate that enables the Pledge to 
> validate the Registrar it's talking to. If we allow RA certificate pinning 
> then the BRSKI text needs to be updated!
> 2. the Domain CA certificate used by the EST server (=Registrar) to sign 
> newly created certificates. (This MAY equal the Registrar's certificate, 
> although it typically will not be.)
>  This is a wider pinned certificate that enables the Pledge to validate the 
> Registrar it's talking to, and also validate the Domain CA that will be used 
> later on to issue operational certificate via EST.
>  It is not necessarily a root CA certificate. This case is compatible with 
> current BRSKI text.
> 3. a Domain CA cert of a domain larger than the above EST CA.
>  It is not necessarily a root CA certificate. This case is compatible with 
> current BRSKI text.
> 4. the root CA cert of the Domain.
>  This case seems compatible with current BRSKI text, although the text 
> suggest that typically the root CA is something with wider scope, beyond the 
> pinned-domain-cert. (But not necessarily)
> 
> Also there are use cases where full PKI is used, and other use cases where a 
> "cheap" self-signed root CA (not using PKI) is used for e.g. a building 
> installation - I say that both cases need to be supported by BRSKI.
> In the latter case, the self-signed limited-scope root CA will typically be 
>

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Max Pritikin (pritikin)]

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] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Max Pritikin (pritikin)]

inline comments, 

> On Jul 10, 2019, at 6:34 PM, Michael Richardson  wrote:
> 
> 
> Roman Danyliw via Datatracker  wrote:
>> (5) Section 1.3.2.  Cite the origin of the taxonomy which defines
>> “class 2+” devices – likely RFC7228
> 
> done.
> 
>> (6) Section 1.5.  Per “Upon successfully validating a voucher artiface, a
>> status telemetry MUST be returned.”, what is a “voucher artiface”?  is
>> that just a “voucher”?
> 
> It's a typo. It should be voucher artifact.
> We used "Voucher Artifact" all over RFC8366.
> 
>> (7) Section 2.6.1.  What is a “Network Time Protocols” – specifically
>> why is protocols plural?  Is this something more than NTP?
> 
> Yes, NTPv4, but it could also be IEEE PTP, or even GSM.
> It doesn't much matter... no network ==> no network time.
> 
>> (8) Section 4.1.  Per “The communication between the pledge is over IPv6
>> Link-Local addresses”, if that is the case, why does Figure 3 show IPv4
>> and Appendix A describes an IPv5 approach?
> 
> Because some members of the WG continued to complain that IPv6 isn't
> ubiquitous, and Appendix A was the compromise.
> I would be happy to rip it out, because I think the argument is specious.
> 
>> (9) Section 5.1., Per “The pledge maintains a security paranoia
>> concerning the provisional state …”, what does it mean to “maintain a
>> security paranoia”?
> 
> I guess I don't know.
> Max?  Seems like useless words.

The intention is to warn implementers that the HTTP and other data received 
until the voucher content is verified could be from an attacker since the TLS 
connection is in a provisional mode. Perhaps this is clearer:  

-The pledge maintains a security paranoia concerning the
-provisional state, and all data received, until a voucher is
-received and verified as specified in 
-
+The pledge performs input validation of all data received
+   until a voucher is verified as specified in  and
+   the TLS connection leaves the provisional state. Until these
+   operations are complete the pledge could be communicating
+   with an attacker.


>> (10) Section 5.1.  Per “A pledge that can not maintain as many
>> connections as there are eligible proxies.”, this is an unfinished
>> sentence.  What should the pledge do?
> 
> fixed.
>A pledge that can not maintain as many connections as there are
>-   eligible proxies.  If no connection is making progess after 5 seconds
>-   then the pledge SHOULD drop the oldest connection and go on to a
>-   different proxy: the proxy that has been communicated with least
>-   recently.  If there were no other proxies discovered, the pledge MAY
>-   continue to wait, as long as it is concurrently listening for new
>-   proxy announcements.
>+   eligible proxies will need to rotate among the various choices,
>+   terminating connections that do not appear to be making progress.  If
>+   no connection is making progess after 5 seconds then the pledge
>+   SHOULD drop the oldest connection and go on to a different proxy: the
>+   proxy that has been communicated with least recently.  If there were
>+   no other proxies discovered, the pledge MAY continue to wait, as long
>+   as it is concurrently listening for new proxy announcements.
> 
>> (11) Section 5.2.  created-on.  The value to use in this field of this
>> field is not described here.
> 
> -RECOMMENDED to populate this field. This provides additional
> -information to the MASA.
> +RECOMMENDED to populate this field with the current date and
> +time in yang:date-and-time format. This provides additional
> -information to the MASA.
> 
>> (12) Section 5.2.  Per “All other fields MAY be omitted in the pledge
>> voucher-request”, should this be read as guidance that the fields
>> mentioned above this text are mandatory (i.e., created-on, nonce,
>> proximity-registrar-cert). If so, what value should pledges without
>> clocks use?
> 
> I guess:
>Pledges that have no real-time clocks MAY omit this field.
> 
>> (13) Section 5.3.  Per “If these validations fail the registrar SHOULD
>> respond
>> with an appropriate HTTP error code”, a few questions:
> 
> Ha, I kept asking for us to be specific about error codes, but I missed this
> part.
> 
> -  If these validations fail the registrar SHOULD respond with an
> -  appropriate HTTP error code.
> +  If these validations fail the registrar SHOULD respond with the
> +  HTTP 404 error code.  If the voucher-request is in an unknown
> +  format, then an HTTP 406 error code is more appropriate.
> +  A situation that could be resolved with administrative action
> +  (such as adding a vendor to a whitelist) MAY be responded with an
> +  403 HTTP error code.
> 
> 
>> ** Is this text suggesting that silent failure?  Given the text says
>

Re: [Anima] [Ace] est-coaps clarification on /att and /crts

[Max Pritikin (pritikin)]

On Dec 11, 2018, at 3:16 PM, Michael Richardson 
mailto:mcr+i...@sandelman.ca>> wrote:


Jim Schaad mailto:i...@augustcellars.com>> wrote:
Clarification requested - exactly what element is the Registrar?

It's an EST RFC7030 term, but essentially it's the server that connects to
(or is) the CA.

The Registrar terminology is from the Anima working group and is closely 
analogous to the “Registration Authority” we know and love from the PKI space.


   Join Registrar (and Coordinator):  A representative of the domain
  that is configured, perhaps autonomically, to decide whether a new

  device is allowed to join the domain.  The administrator of the


  domain interfaces with a "join registrar (and coordinator)" to
  control this process.  Typically a join registrar is "inside" its
  domain.  For simplicity this document often refers to this as just
  "registrar".  Within 
[I-D.ietf-anima-reference-model]
 this is
  refered to as the "join registrar autonomic service agent".

It terminates the BRSKI protocol from the new device and, after processing and 
decisions, forwards messages to a manufacturer authorized signing authority to 
obtain vouchers and ensure records/audit-logs are kept. It also pulls those 
audit logs to make additional decisions. It is responsible for making the 
authorization decision concerning if the new device should be allowed to join 
the network.

It also optionally doubles as a enrollment over secure transport (RFC7030) 
registration authority in the normal PKI sense. This is recommended in that 
BRSKI recommends that devices go on to enroll and obtain a certificate.

- max


The one item that I can generally think of that might be a problem is that
the answers to /att and /crts may differ based on the entity that is asking
the question.  In this case not having the entity being validated means that
the "wrong" answer may be returned or different answers would be returned
before and after validation.

Yes, I agree: it should be restricted.

I think that it should be restricted. Partly, I'm just not sure where the
text should go, or if it needs to be said at all.

--
Michael Richardson mailto:mcr+i...@sandelman.ca>>, 
Sandelman Software Works
-= IPv6 IoT consulting =-

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] unsigned voucher requests in BRSKI

[Max Pritikin (pritikin)]

> On Dec 11, 2018, at 3:23 PM, Michael Richardson  wrote:
> 
> 
> Panos Kampanakis (pkampana)  wrote:
>> I was assuming it was mandatory in the current draft, but I was wrong. As
>> you suggest it is not clear in the -17 version. I do think that an unsigned
>> voucher should make it to the MASA, like a signed one would, for
>> consistency.
> 
> okay, I'm glad that we agree that it should be consistent.
> 
> I'm not convinced it's worth having unsigned pledge requests at all.

Sadly I think we still have to respect folks that are worried about the extra 
crypto operations on the pledge. Particularly given the size/complexity of a 
CMS signature. IF we’d gone with a jwt/cwt signature I’d be more open to “just 
sign everything”. 

I respect the desire to forward the unsigned request “for consistency” but 
disagree. My reasoning is that the unsigned request is *not signed* and 
therefore can NOT provide any value to the MASA. As such including it in the 
messages is simply additional overhead and opportunity for a MASA to mess up 
and, for example, use the nonce from it even if the Registrar doesn’t want a 
nonce (or other weird bugs that would be difficult to notice until they were a 
pain). 

- max

> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [secdir] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16

[Max Pritikin (pritikin)]

Great thread you all. Some key points for response follow. Additionally we’re 
working through each numbered comment specifically.

Generally lets keep the scope of BRSKI in mind. It is a new protocol for 
bootstrapping via vouchers. It does not preclude the use of a local console for 
bootstrapping/asserting ownership. The current voucher format is a starting 
point and there is already work in progress for various additional forms of 
vouchers to address the other use cases brought up.

Re: Can vouchers be distributed directly rather than through the BRSKI-MASA 
sub-protocol

Vouchers are signed messages and there are a number of distribution models 
available. This protocol describes a predominately online model. The netconf 
zerotouch draft describes a different method using the same vouchers with 
slightly different operational trade-offs. The intention is that between these 
a good foundation is set for all use cases (with a focus on anima and netconf; 
where these documents were working group items). As described below the current 
method and current BRSKI flow work with direct distribution as envisioned by 
some of the discussion on this thread (e.g. no MASA) but that is not a primary 
use case. The existing work on more constrained voucher formats could help to 
enable those ideas a more direct use cases but will not require BRSKI protocol 
exchanges to change.

Re: Does BRSKI change the ownership model from the owner to the manufacturer?

Absolutely not. BRSKI defines a scalable method of bootstrapping remote secure 
key infrastructures via the distribution of “vouchers” from the registrar to 
the device. It specifically attempts to ensure the registrar (owner) is in 
control of decisions and attempts to minimize supply chain integrations (e.g. 
how much the vendor even knows about who actually owns a device). The structure 
is such that a 3rd party could provide all the Manufacturer Authorized Signing 
Authority (MASA) responsibilities — thus enabling complete vendor independence 
from a BRSKI protocol perspective. It specifically supports models wherein the 
voucher is distributed in advance, on a 2d barcode or in sales material or 
whatever. There is no expectation of a secure connection between the device and 
the vendor (beyond an expectation that vouchers are signed). The goal here is 
to allow the vendor to help provide a scalable deployment model.

Re: What about transfer of ownership; particularly if the MASA is antagonistic 
to resale?

Because there is no expectation of sales-channel integration this is really 
limited to discussions of antagonistic vendors. I applaud purchasing decisions 
to avoid such vendors. Such vendors are only able to reject zero touch 
deployment — they can’t effect customers that use less scalable deployment 
models such as console access. All vendors have the option of leveraging 
security technologies to make resale difficult... the existence of BRSKI only 
exposes such attempts in the same way the signed image loading highlights 
similar attempts to avoid 3rd party code.

As per the basic trust model the registrar can even provide the new owner 90% 
of the functionality even in the face of an antagonistic MASA: The owner can 
obtain a nonce-less voucher against a device specific registrar keypair. This 
then provides them a permanent method of bootstrapping the device that they can 
safely provide with the device during resale. This maintains the majority value 
of the protocol to the new owner while completely circumventing any future 
antagonism by the vendor. The device can be reset to factory defaults before 
the sale.

Re: What happens if the MASA service is unavailable?

BRSKI is for the transfer of trust to the current owner. There is no effect to 
deployed devices.
As discussed in this thread there are facilities for nonce-less permanent 
vouchers including ones that can be used for resale. An owner that is worried 
about re-deploying in the future state can take this approach. Either using a 
common registrar or by using a registrar per device (depending on if they plan 
to resale).

There will always be cases where a vendor goes away and a device is therefore 
limited. For example security updates to signed firmware can be impacted if the 
vendor no longer produces them. BRSKI does make this reality worse.

- max

On Oct 2, 2018, at 7:06 PM, Uri Blumenthal mailto:u...@mit.edu>> 
wrote:

Based on this exchange, and the arguments presented here that I observed so 
far, I'm with Randy. I have not seen adequate answers to his concerns (which 
IMHO are reasonable).

P.S. Feel free to trim the CC: list when/if responding.

P.P.S. In one of my prior incarnations many years ago, we designed a somewhat 
similar system, and called it "Zero-Touch Provisioning". It was a very big 
company, so we did not consider the possibility of it/us going out of business 
(and leaving the customers stranded). But if Randy's arguments were presented 
to our team then, we'

Re: [Anima] CDDL-02 section 2.2.2 choices

[Max Pritikin (pritikin)]

> On Jun 19, 2018, at 9:20 AM, Carsten Bormann  wrote:
> 
> Hi Michael,
> 
> 2.2.2 says:
> 
>   It is not an error if a name is first used with a "/=" or "//="
>   (there is no need to “create it" with "=“).

We must have absorbed this sentence w/o noticing it. 

> 
> The intention is indeed to say that no initial rule with a “=“ is needed.
> Any ideas how we can clarify this some more?

I would help if the use of /= or //= is clarified to be a message to 
implementors that future values should be expected and handled appropriately. 
As it reads, in concert with the first sentence of the next section (“Instead 
of naming all the values that make up a choice”), I find myself unsure as to 
the need for a sentence such as we’ve provided. Do we need to inform 
implementors that future values MAY be seen? What if we intended that future 
values MUST NOT be included? 

Its reasonable for CDDL to declare that out-of-scope; in which case the current 
language looks sufficient but it would mean use of CDDL in this area will often 
have an additional sentence to clarify for implementors.

- max

> 
> You could also make use of the convention (not currently checked by any tool, 
> but that could be done) to mark an extension point with a dollar sign:
> 
> $transport-proto /= IPPROTO_TCP
> 
> (See section 3.9 for more about that convention.)
> 
> Grüße, Carsten
> 
> 
>> On Jun 19, 2018, at 17:08, Michael Richardson  wrote:
>> 
>> Signed PGP part
>> 
>> In draft-ietf-anima-bootstrapping-keyinfra-15, we specify a protocol value
>> for GRASP.  In this normative part of the document, there is only one choice,
>> but it is our intention to allow additional choices, as per section 2.2.2
>> of cddl-02.
>> 
>> We think that we should specify our single "choice", using /=, rather than =,
>> as this should clue the reader in to expect multiple values here.
>> 
>> From our document:
>> 
>> transport-proto /= IPPROTO_TCP   ; note this is an extensible CDDL choice
>>; and can be added to in subsequent
>>; specifications using the /= and //=
>> 
>> It is unclear in section 2.2.2 if we can say foo /= without having said
>>  foo = 1 / 2 / 3
>> previously, but it seems like it should be reasonable to do in order to
>> indicate that implementations should expect future values.
>> 
>> --
>> Michael Richardson , Sandelman Software Works
>> -= IPv6 IoT consulting =-
>> 
>> 
>> 
>> 
>> 
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] getting the constrained MASA voucher signing public key to JRC

[Max Pritikin (pritikin)]

On Jun 15, 2018, at 8:38 PM, Michael Richardson 
mailto:mcr+i...@sandelman.ca>> wrote:


Michael Richardson mailto:mcr+i...@sandelman.ca>> wrote:
5) use the existing /voucherrequest, but define the result (when an
application/cbor+cose voucher request is presented) to be a multipart
result, with the second piece being the public key "bag".

I've been convinced to return a multipart/related.
(I think it's related I want).

This is HTTP not CoAP, to be clear.

The next 6tisch-dtsecurity-zerotouch-join will say;

In order to do this, the MASA MAY return a multipart/related return, within that
body, two items SHOULD be returned:

1. An application/voucher-cose+cbor body.
2. An application/pkcs7-mime; smime-type=certs-only, or an
application/SOMETHING containing a Raw Public Key.

It seems weird to combine the cwt style body with such an unconstrained value 
such as a pkcs7-smime blob.
Even if it makes sense to use the http layer multipart instead of x5c 
(unprotected header fields) wouldn’t the more optimized message format make 
sense?

I can’t seem to find a definition of multipart (or “related”?) for CoAP. If its 
handled anything like https://tools.ietf.org/html/rfc2046#section-5.1.1 I’d 
expect to find it in here https://tools.ietf.org/html/rfc7252#section-12.3 or 
at 
https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats
 . Can you provide a pointer to explain what this would look like?

- max



(See other email wherein I ask for opinions)


--
Michael Richardson mailto:mcr+i...@sandelman.ca>>, 
Sandelman Software Works
-= IPv6 IoT consulting =-



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] naming of constrained voucher YANG model

[Max Pritikin (pritikin)]

what is wrong with going simple: “constrained voucher request” ? 

- max

> On Jun 1, 2018, at 9:10 AM, Michael Richardson  wrote:
> 
> 
> Michael Richardson  wrote:
>> Also, a related question is whether ietf-cwt-voucher-request to inherit
>> from BRSKI's ietf-voucher-request, or from ietf-voucher... It's not
>> clear to me that it's a 100% subclass yet.
> 
> So, the name started at "cwt-voucher-request", because it was originally
> thought that it would use CWT directly (RFC8392), using the Claim keys from
> there.
> 
> Then after some distraction, the process is now a COSE signed SID generated
> YANG, which isn't exactly CWT at all.
> 
> The name "cwt-voucher"{,-request} is no longer appropriate.
> Some constraction of "constrained" is probably now appropriate, looking for
> suggestions.  
> 
> It's also reasonable to say that we use CWT concepts when they map, and
> introduce new key ids via the YANG/SID mechanism.  That's a significant
> design change, but it's not that huge.
> 
> -- 
> ]   Never tell me the odds! | ipv6 mesh networks 
> [ 
> ]   Michael Richardson, Sandelman Software Works| network architect  
> [ 
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [ 
>   
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Call for agenda ANIMA @ IETF 101, London

[Max Pritikin (pritikin)]

> On Mar 12, 2018, at 4:12 PM, Toerless Eckert  wrote:
> 
> 
> Hi Sheng,
> 
> Not that many actual new draft/work-items, but lots of activity going
> on, hee's what's on my contributor plate:
> 
> 1. draft-ietf-anima-autonomic-control plane
>  5 min IESG review update
> 
> 2. draft-eckert-anima-grasp-dnssd
>  <= 10 mins ?
>  Update of feedback from DNS-SD WG @ IETF100 (happened after ANIMA@IETF100)
>  and summary of implementation status from Brian.
>  Want to ask for ANIMA WG adoption (in-charter, details that fell off 
> BRSKI/ACP).
> 
> 3. I also have a personal problem, but maybe if Max chimes in and can help,
>  maybe this can also be a slot to discuss:
> 
>  I did contribute text about ANI/BRSKI to draft-nir-saag-star-01
>  (just check difference between the -00 version, eas to identify the ANI 
> text),
>  outlining how ANI itself can benefit from short-lived certificates, but
>  also how ANI could be a great infra to manage short-lived certificates.
> 
>  This was targeted for SAAG, but it ended up on tuesday, probably
>  9:50 - 10:10 time slot in SECDISPATCH.
> 
>  If Max could go to secdispatch, and represent BRSKI/EST/ANI,
>  that would be great, otherwise i would ask for 15 mins off from
>  anima for myself.

I can go to this (will be there in person). I’ll have to read the draft and 
coordinate with you on presentation talking-points,

- max

> 
>  Maybe we can have at the end of the anima schedule a short slot
>  to discuss possible extensions for short-lived certificates, e.g.:
>  what would need to be defined on a standards doc. And whether or not
>  this should be in ANIMA.
> 
> 4. I did not manage to finish a -00 draft, but would very much like to
>   find co-authors for a Yang model for ANI, so if there is anyone here
>   interredsted in this, pls. ping me offline.
> 
> 5. Alas, probably no RFC for ANIMA to report until IETF101. 
>   draft-ietf-anima-stable-connectivity would have no dependencies to wait
>   for, but its in RFC editor queue for 4 weeks, without feedback yet.
>   As far as i was told, this is unfortunately normal before the spring meeting
>   with all the leaving ADs prioritizing the stuff they wanted to get finished
>   in the RFC editor queue, so wait time for RFC editor resources in this
>   time slot is particularily long. (Voucher might be further along, but
>   would have BRSKI dependency to wait for).
> 
> Cheers
>Toerless
> 
> On Wed, Feb 28, 2018 at 05:56:34AM +, Sheng Jiang wrote:
>> Hi, all anima,
>> 
>> 
>> 
>> We have been allocated a session of 2.5-hour for the ANIMA WG meeting for 
>> IETF-101 (London) and are starting to collect agenda items for the session. 
>> Please send your request for agenda by March 8th, Thursday.
>> 
>> 
>> 
>> Giving that most of our chartered work items have been sent to IESG for 
>> publication by the meeting, we expect short time slots for only two or three 
>> of them. For this coming meeting, we would like to discuss potential future 
>> ANIMA works.
>> 
>> 
>> 
>> As normal, the priority among these non-charter work items would be: these 
>> that have active discussion in mail list, then these have submitted drafts, 
>> and topics without drafts.
>> 
>> 
>> 
>> Please send us (anima-chairs at 
>> ietf.org;) 
>> requests for time slot by March 8th, Thursday and include:
>> 
>> Name of time slot:
>> 
>> Name of draft(s):
>> 
>> Time requested:
>> 
>> Presenter name(s):
>> 
>> 
>> 
>> More details about the IETF 101, London can be found at:
>> 
>> 
>> 
>> http://www.ietf.org/meeting/101/index.html
>> 
>> 
>> 
>> Again, presenters and draft authors please invoke active discussions in the 
>> ANIMA list. Mail list is a very good place to discuss and reach consensus on 
>> technical issues.
>> 
>> 
>> 
>> Best regards,
>> 
>> 
>> 
>> Toerless & Sheng
>> 
> 
>> ___
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
> 
> 
> -- 
> ---
> t...@cs.fau.de
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09

[Max Pritikin (pritikin)]

> On Feb 20, 2018, at 7:38 PM, Toerless Eckert  wrote:
> 
> Thanks, Michael
> Can't see a commit on github since 6 dyays ago, maybe in different branch ?
> Comments for now therefore inline against your email.
> 
> On Tue, Feb 20, 2018 at 07:54:40PM -0500, Michael Richardson wrote:
>> 
>> Toerless Eckert  wrote:
>>> Overall:
>> 
>>> a) Requirements about EST:
>> 
>>> - The introduction says: "Integration with a complete EST enrollment is
>>> optional but trivial"
>>> - 5.8.3 says "The Pledge MUST request a new client certificate".
>>> - 1.4 says "bootstrapped devices have a common trust anchor and a 
>>> certificate
>>> has optionally been issued from a local PKI
>> 
>>> a) The text needs to be made consistent across all places where requirements
>>> are defined. I have in general no strong opinion how "optional" the text 
>>> should
>>> say EST operations are, BUT consider he following points:
>> 
>>> b) We need a complete list of BRSKI requirements for ANI devices, where EST
>>> operation requirements are made stronger. I suggest a separate subsection 
>>> at an
>>> appropriate place so that "ANI requirements" shows up in the table of 
>>> contents:
>> 
>>> Section X.Y.Z Requirements for ANI devices:
>> 
>>> For BRSKI on ANI Devices (ANI = BRSKI + ACP), EST operations is mandator.
>>> The ANI pledge MUST perform
>>> - "CA Certificates Request",
>>> - "CSR Attributes"
>>> - "Client Certificate Request"
>>> - "Enrollment status Telemetry"
>>> The ANI registrar MUST support BRSKI and these EST operations.
>>> All ANI devices SHOULD support the BRSKI proxy function.
>> 
>> I've done the following:
> [...]> 
> 
>> 1.1.  Other Bootstrapping Approaches
>> 
>>To literally "pull yourself up by the bootstraps" is an impossible
>> @@ -233,9 +237,10 @@ Internet-DraftBRSKI 
>>February 2018
>>without external help is also an impossibility.  Today it is commonly
>>accepted that the initial connections between nodes are insecure,
>>until key distribution is complete, or that domain-specific keying
>> -   material is pre-provisioned on each new device in a costly and non-
>> -   scalable manner.  Existing mechanisms are known as non-secured 'Trust
>> -   on First Use' (TOFU) [RFC7435], 'resurrecting duckling'
>> +   material (often pre-shared keys, including mechanisms like SIM cards)
>> +   is pre-provisioned on each new device in a costly and non-scalable
>> +   manner.  Existing mechanisms are known as non-secured 'Trust on First
>> +   Use' (TOFU) [RFC7435], 'resurrecting duckling'
>>[Stajano99theresurrecting] or 'pre-staging'.
> 
> Nice.
> 
>>Another approach is to try and minimize user actions during
>> 
>> @@ -358,6 +364,13 @@ Internet-DraftBRSKI 
>>February 2018
>>   "Registrar".  The term JRC is used in common with other bootstrap
>>   mechanisms.
>> 
>> +   (Public) Key Infrastructure:  The collection of systems and processes
>> +  that sustain the activities of a public key system.  In an ANIMA
>> +  Autonomic system, this includes a Domain Certification Authority
>> +  (CA), (Join) Registrar which acts as an [RFC5280] Registrar, as
>> +  well as appropriate certificate revocation list (CRL) distribution
>> +  points and/or OCSP ([RFC6960]) servers.
> 
> I had interpreted Max'es response on the mail discussion to indicate that
> MASA would also be considered to be part of the PKI. I am fine either way.
> Just checking. If as you propose above it's not part of the PKI, a simple
> sentence explaining why not would be great.

The MASA is a certifier of vouchers. A voucher isn’t really a PKI construct 
today. Its more of a distribution of trust-anchor or “pinned cert” construct 
used to bootstrap a PKI because the PKI’s don’t have such a concept. 

I think it could be argued either way but its probably most accurate at this 
time to talk about the MASA as being distinct from the PKI if only because this 
isn’t the PKIX working group and therefore it isn’t in our charter to add 
anything to the public key infrastructure. 

Which highlights the absurdity of trying to draw this distinction. :) I’m good 
with Michael’s excellent text. 

- max

> 
>> +
>>Join Proxy:  A domain entity that helps the Pledge join the domain.
>>   A Proxy facilitates communication for devices that find themselves
>>   in an environment where they are not provided connectivity until
>> 
>> +1.5.  Requirements for Autonomic Network Infrastructure (ANI) devices
>> 
>> +   The BRSKI protocol can be used in a number of environments.  Some of
>> +   the flexibility in this document is the result of users out of the
>> +   ANI scope.  This section defines the base requirements for ANI
>> +   devices.
>> 
>> +   For devices that intend to become part of an Autonomic Network
>> +   Infrastructure (ANI) ([I-D.ietf-anima-reference-model]) that includes
>> +   an Autonomic Control Plane
>> +   ([I-D.ietf-anim

Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09

[Max Pritikin (pritikin)]

> On Feb 15, 2018, at 10:14 AM, Toerless Eckert  wrote:
> 
> On Thu, Feb 15, 2018 at 04:06:33PM +0000, Max Pritikin (pritikin) wrote:
>>>> b)  Key infrastructure
>>> 
>>>> There  is no definition/reference for this term.  Please describe on
>>>> first use and in terminology.  Is there a difference
>>>> between "key infrastructure" and  "keying material" ? If not, then
>>>> maybe remove one term otherwise pls. describe difference.
>>> 
>>> The term is in the title and in section 1.
>>> And you are right that it does not appear again, nor is it defined.
>>> I think it generally refers to the mechanism of PKI, but I'm not sure what 
>>> to do.
> 
>> "Keying material" is defined in RFC4949.
> 
> Well... RFC4949: keying material
>1. (I) Data that is needed to establish and maintain a
>   cryptographic security association, such as keys, key pairs, and IVs.
> 
> Can you explain to me how i should deduce from that explanation whether
> certificates are keying material or not ?

Certificates are a data format for encoding public keys and associated 
certifications (e.g. the CA signature) etc. I think this could reasonably be 
called data needed to establish a cryptographic security association. 

> 
> IMHO, I need certificates to establish (authenticate) the cryptographic 
> security
> association when i am using certificates.  Likewise would a voucher
> be keying material because it is required for authentication.

If we’re stretching like this then sure. A voucher is a certification of a 
public key (the new owner) along with additional data used to interpret the 
certification. If you keep going down that path you’re gonna end up claiming we 
should have simply had an X509 extension instead of a voucher format. There are 
reasons we didn’t go that way but I could see a world where that happened 
(thankfully not our reality though). 

> But the term itself "keying material" implies to a non-native english speaker
> that this is more likely something like a generalisation of "keys" in
> cypto algorithms:
> 
>  output = crypto_algorithm(data,keying_material)
> 
> and in that sense certificates or vouchers are never keying material
> because they would always be classified as the data portion of any
> crypto_algorithm (used for establishment of a crypto association).

They both include public key data. That key material. 

> 
>> An ???infrastructure??? is the basic entities and protocols necessary for 
>> the operations of key management. I think it comes from the common language 
>> term and can???t find a normative definition within IETF document. As a 
>> native english speaker who has used the concept in IETF interactions for 
>> eons it feels silly to try and define it. Odd. 
> 
> Is this correct:
> 
> brski keying material = public/private key pairs of IDevID of Pledge and 
> certs of registrar, CA, MASA.
>  Possible non-crypto speaker confusion: are certs/vouchers part of keying 
> material ? (see above)

I think so. Anytime we talk about raw public keys, certificates, vouchers, etc 
we have to discuss all the same key management issues (updating them, 
lifetimes, revocations, etc). 

> 
> brski keying entities = pledge + registrar + CA ( + MASA ?)
>  Possible non-crypto speaker confusion: Is MASA part of keying entities ?
>  If keying material is just the public key pairs, then probably not ?

Why not? Its all part of the key infrastructure in that these are the entities 
(and associated protocols!) needed to manage all the key material. 

There is something different about “authentication key material” and 
“certification key material” but is it necessary for us to get into those 
pedantic areas? Are you proposing an update to RFC4949? Where are we going with 
this? 

>  But would BRSKI without a following EST part even be "keying entities” ?’

BRSKI and EST are protocols not “entities”. But yes, BRSKI is a part of the key 
infrastructure. It is the protocol for “bootstrapping [the] remote [portion of 
the] secure key infrastructure”. 

> brski keying protocols = BRSKI+ EST (pledge/registrar), EST (registrar/MASA), 
> BRSKI-EST (registrar/MASA)
> 
> brski keying infrastructure = brski keying entities + brski keying protocols
> 
> Or whatever else is correct in the context of BRSKI. Better to just enumerate 
> whats
> meant like i suggested above instead of trying generic definitions because 
> those
> can fail on non-native crypto speakers like my above confusion with rfc4949.
> 
> Also it wold be good if there was a clear understanding if BRSKI claims to 
> expand
> the scope of any of these terms. Eg: If MASA or vouchers are now con

Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09

[Max Pritikin (pritikin)]

> On Feb 14, 2018, at 7:45 PM, Michael Richardson  wrote:
> 
> 
> Toerless Eckert  wrote:
>> 1.2) Terminology:
> 
>> a) vendor vs. manufacturer.
> 
>> The document uses 48 times "vendor" and 13 times "manufacturer". Please
>> revisit this: If there is a clear reason when/why to use vendor and when/why
>> to use the term "manufacturer", then please put these explanations into
>> terminology. Otherwise maybe eliminate "vendor".
> 
> Ha. Good catch.
> I'm pretty sure we want to say manufacturer consistently.
> The IETF has often talked about vendors rather than manufacturers, so this
> might cause some confusion.  Let's go ahead with this and see what confusion
> we cause.
> 
> There is a distinction between vendor (which generally includes VARs) and
> OEMs.
> 
>> For example: Abstract: "using vendor installed X.509 certificate" ...
>> "vendor's authorizing service". This latter one definitely seems to be
>> wrong (MASA = "manufacturer authorizied..., not vendor).
> 
> I've also condensed a number of cases like you noticed:
> "vendor authorized MASA service"  ==> MASA
> 
> I am concerned that we might lose some subtly between the entity that sold
> the device to the customer, and the entity that signs the vouchers.
> We used the term MASA specifically because we were sure that the service
> would be outsourced by many manufacturers.
> 
>> b)  Key infrastructure
> 
>> There  is no definition/reference for this term.  Please describe on
>> first use and in terminology.  Is there a difference
>> between "key infrastructure" and  "keying material" ? If not, then
>> maybe remove one term otherwise pls. describe difference.
> 
> The term is in the title and in section 1.
> And you are right that it does not appear again, nor is it defined.
> I think it generally refers to the mechanism of PKI, but I'm not sure what to 
> do.

An “infrastructure” is the basic entities and protocols necessary for the 
operations of key management. I think it comes from the common language term 
and can’t find a normative definition within IETF document. As a native english 
speaker who has used the concept in IETF interactions for eons it feels silly 
to try and define it. Odd. 

Key management itself is defined in RFC4949, although ironically a “public key 
infrastructure” or “key infrastructure” is not defined. 

"Keying material" is defined in RFC4949.

- max

> 
>> c) (terminology) MASA definition: "A third-party Manufacturer...". Why 
>> "third-party" ?
>> who are the first two parties ? If this is only slang and we can't explain 
>> who the
>> first two parties are, delete "third-party" ?
> 
> Fixed...  The first party is the Pledge and manufacturer.
> The second party is the Domain Owner.
> The third party is the entity running the MASA, which may not be the 
> manufacturer.
> 
>> d) "Domain Registrar" vs. "Join Registrar", JRC. Especially because the text 
>> mostly
>> uses "Domain Registrar" and very seldom "Join Registar".
> 
> Yes, because we agreed that the term across WGs would be JRC, and we say
> in the terminology that we shorten it to Registrar.  We say "Domain
> Registrar" because we want to link it to the PKI concept of a Registration
> Authority (RA).
> 
>> JRC is used in exactly three places in the draft. I also can not find on 
>> www.google.com
>> or wikipedia any example of "The term JRC is used in common with other 
>> bootstrap
>> mechanisms" as the Terminology claims. Either provide a non-anima reference 
>> for the
>> use of that term or eliminate it in the document.
> 
> We agreed to use common terms.
> It was a thread on ANIMA and 6tisch a year ago.
> I can't get mailarchive to find it for me...
> Ah, I see because "JRC" was never used contracted in that thread.
>https://mailarchive.ietf.org/arch/msg/anima/iotBM0-kxsIB66t8hBo4XUtZLag
> 
> As long as they Informative references.
> https://tools.ietf.org/html/draft-ietf-6tisch-architecture-13#section-6.1
> https://tools.ietf.org/html/draft-ietf-6tisch-terminology-09
>(yes, expired, but not forgotten, just not a priority)
> 
>> e) Voucher
>> - misses ":" after term.
>> - please change "statement" to "artifact" so the terminology aligns with 
>> both voucher
>> draft and voucher-request text which also uses artifact. See also section 2.2
>> where you use "cryptographically protected" instead of "signed" and figure 
>> out
>> which term you want to use in all cases (hint: signed).
> 
> I've changed it to:
>  A voucher is a cryptographically protected artifact (a digital signature) 
> to the Pledge
> 
> I feel that we need to say it's cryptographically signed at least once.
> 
>> f) IMPORTANT: Please add/define the term "ANI"
> 
>> ANI - "Autonomic Network Infrastructure". Systems that support both BRSKI and
>> Autonomic Control plane - ACP ([I-D.ietf-anima-autonomic-control-plane]). ANI
>> systems (pledges, proxies, registrar) have specific requirements detailled in
>> the document.
> 
>The Autonomic Network Infrastructure as
>  

Re: [Anima] Technical comments on draft-ietf-anima-bootstrapping-keyinfra-09

[Max Pritikin (pritikin)]

Much thanks for Michael Richardson for putting these diffs together. Comments 
inline,


> On Feb 14, 2018, at 1:09 PM, Michael Richardson  wrote:
> 
> 
> tl:dr: https://github.com/anima-wg/anima-bootstrap/pull/41
>   
> https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-10&url2=https://raw.githubusercontent.com/anima-wg/anima-bootstrap/bill-atwood-comments/dtbootstrap-anima-keyinfra.txt
>or: https://goo.gl/pXNghv
> 
> 
> William Atwood  wrote:
>> Section 1, para 3, lines 4-5.  "is a minor extension to the voucher
>> format (see Section 3)."  What "voucher format"?  I guess that you mean
>> the voucher format defined in draft-ietf-anima-voucher.  I suggest some
>> additional precision here.
> 
> Added another reference to anima-voucher document at the end of the paragraph.
> 
>> Lines 4-5.  Why is this "minor extension" defined here, and not in
>> draft-ietf-anima-voucher?  Would it not be better to have all (currently
>> known) voucher formats in one place?
> 
> No, because anima-voucher is used by the RESTCONF work in the NETCONF WG, and
> they have no use for the voucher-request.
> 
>> Section 2.3, para 2, line 1.  "previously defined fields"  Where are
>> these defined?  Are they previously defined in this document?  Are they
>> previously defined in some other document?  (If so, give reference.)
> 
>> In general, this paragraph and its two bullets might be understandable
>> by someone who is well familiar with X.509, but they are opaque to
>> someone who is not (i.e., this reviewer).  I believe that your message
> 
> so, I think that understanding something about PKIX (X509) and EST is
> unavoidable, and I don't think we should clutter the document explaining
> those parts.
> 
>> Section 2.3, para 5, line 4.  In this document, the string ".well-known"
>> appears variously as ".well-known", "./well-known", and "/.well-known".
>> If these are in fact intentional, then the differences should be
>> explained.  Otherwise, a consistent form should be ensured throughout
>> the document.  Given that I do not know what is correct, or if they are
>> intended to be different, I have not signaled these cases in my General
>> Comments.  You will have to do a search to discover all the instances.
> 
> ./well-known is a typo.  I've put / in front of every use.
> /.well-known refers to rfc5785.
> RFC7030 (EST) all lives under /.well-known/est.
> I've added a reference to 5785 at the first use of /.well-known.
> 
>> Section 2.6, para 1.  I find this entire paragraph puzzling.  I believe
>> that more text is required here, in the hope that the use cases will be
>> clearer.  Perhaps the use cases need to be stated first, followed by the
>> allowed actions.
> 
> Max, I have added a paragraph to explain the legacy situation that the "Cloud
>
>  There are transitional situations where devices may be
>  deployed into legacy networks that use proprietary
>  bootstrapping mechanisms based upon the base EST (  target="RFC7030"/>).  The same device may also be deployed
>  into an ANIMA environment.  This may be due to incremental
>  replacement of a legacy situation with ANIMA.
>
>
>  There are additionally some greenfield situations involving an
>  entirely new installation where a device may have some kind of
>  management uplink that it can use (such as via 3G network for
>  instance).   In such a future situation, the device might use
>  this management interface to learn that it should
>  configure itself by to-be-determined mechanism (such as an Intent)
>  to become the local registrar.
>
>
>  In order to support this scenario, the Pledge MAY contact a well
>  known URI of a cloud Registrar if a

A simpler case could be, 

“There exist operationally open network wherein device gains unauthenticated 
access to the internet at large. In these use cases the management domain for 
the device needs to be discovered within the larger internet. These are less 
likely within the anima scope but may be more important in the future."

(I’ve added this comment within github as well in prep for the pull request)

> 
>> Section 3, para 1, line 6.  What is the meaning of
>> '"proximity-registrar-cert" leaf'?  What is the leaf a leaf of?  If this
>> refers to some YANG module, please cite the YANG module.
> 
> So the title of the section is "Voucher-Request artifact", and the entire
> section is about the YANG module ietf-voucher-request.  I have added one
> phrase: "defined in this section"
> 
>> Section 3.2, Example (2).  Does this example illustrate _a_ Registrar
>> voucher-request, or does it illustrate the Registrar voucher-request
>> that would be used to forward Example (1)?  If the former, why is the
>> nonce identical?  If the latter, it should be explained that certain
>> other fields are carried forward as well.
> 
> The nonce, creat

Re: [Anima] Question on draft-ietf-anima-voucher-06

[Max Pritikin (pritikin)]

On Dec 14, 2017, at 9:32 AM, Eric Rescorla 
mailto:e...@rtfm.com>> wrote:



On Thu, Dec 14, 2017 at 8:29 AM, Max Pritikin (pritikin) 
mailto:priti...@cisco.com>> wrote:

On Dec 14, 2017, at 8:43 AM, Eric Rescorla 
mailto:e...@rtfm.com>> wrote:



On Thu, Dec 14, 2017 at 7:40 AM, Michael Richardson 
mailto:mcr+i...@sandelman.ca>> wrote:

Eric Rescorla mailto:e...@rtfm.com>> wrote:
> The case I am concerned with right now is the case where the attacker
> just imprints the device and then operates it even though it's in the
> victim's network.

How can they join the victim's network, if the point of the enrollment is to
provide the device with keys to be able to join the victim's network?

Ah, now I think we're getting somewhere. I had understood the point of the 
enrollment in this context to be to get it to join the ANIMA fabric, not 
necessarily the physical network (hence why we have ACP, etc.)

Am I just totally missing the point here?

So, more directly responding to your concern: What happens if the attacker 
“just imprints the device and then operates it even though its in the victim’s 
network”?
Answer:

If the vendor system has sales channel integration then the voucher signatures 
provide an optional method of blocking “attacker imprint” (because it is no 
longer trust-on-first-use). This PREVENTS the attack you’re asking about.
If the victim network operator has appropriate inventory management then 
BRSKI/MASA integration provides logging inputs into that system to DETECT the 
scenario you describe, even without sales channel integration.

So if neither of these cases applies, then the attack succeeds?

Correct. My preference is the non-sales channel approach where the network 
operator has complete control.

To be clear, I'm not saying this is a defect in the protocol. I don't know how 
to fix it. I'm just trying to get clear.

Agreed. I don’t see this as a “defect” myself, its a conscious decision to 
allow flexibility in deployment models.

This is important because secure bootstrapping requires devices to engage in 
security operations. Doing so runs the risk that something won’t work when 
needed. Our design choice is to limit the device security operations to the 
minimal amount: just sufficient for network operator audit or vendor control. 
This should be more reliably while allowing the the vendor or the network 
operator can provide substantial security *if they want*.

- max


-Ekr


Once detected, then what? The BRSKI draft has this to say about its protocol 
flow and network access control:

draft-ietf-anima-bootstrapping-keyinfra-09:

   This document presumes that network access control has either already
   occurred, is not required, or is integrated by the proxy and
   registrar in such a way that the device itself does not need to be
   aware of the details.  Although the use of an X.509 Initial Device
   Identity is consistant with IEEE 802.1AR 
[IDevID<https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-09#ref-IDevID>],
 and allows for
   alignment with 802.1X network access control methods, its use here is
   for Pledge authentication rather than network access control.
   Integrating this protocol with network access control, perhaps as an
   Extensible Authentication Protocol (EAP) method (see 
[RFC3748<https://tools.ietf.org/html/rfc3748>]), is
   out-of-scope.

Its even more out of scope for the voucher itself since that is a msg format 
for “who should the device trust” and to trigger enrollment but is even further 
removed from network access control.

A potential integration is to use ANIMA or BRSKI to manage device enrollment 
and credential from a quarantine network. The network access control could be 
configured to segregate all devices that are not enrolled (perhaps into a true 
quarantine network or maybe just pass them all through to a carefully managed 
dmz or … whatever). If the device enrolls successfully then you get on the 
“real” network. In your scenario then the attacker gain control over a device 
that is untrusted and placed appropriately by the network access control 
system. But as noted, providing the tools for this is different than actually 
defining that integration. I encourage the network access control folks to 
address these types of concerns.

- max


-Ekr


(The exact nature of the keys depends upon how the voucher is used.
In BRSKI it's to bootstrap an EST connection, while in some versions of the
6tisch, actual 802.15.4 keys are return.  NETCONF uses this new trust to
permit the owner to reach in and do configuration with RESTCONF)

--
Michael Richardson mailto:mcr%2bi...@sandelman.ca>>, 
Sandelman Software Works
 -= IPv6 IoT consulting =-




___
Anima mailing list
Anima@ietf.org<mailto:Anima@ietf.org>
https://www.ietf.org/mailman/listinfo/anima



__

Re: [Anima] Question on draft-ietf-anima-voucher-06

[Max Pritikin (pritikin)]

On Dec 14, 2017, at 8:43 AM, Eric Rescorla 
mailto:e...@rtfm.com>> wrote:



On Thu, Dec 14, 2017 at 7:40 AM, Michael Richardson 
mailto:mcr+i...@sandelman.ca>> wrote:

Eric Rescorla mailto:e...@rtfm.com>> wrote:
> The case I am concerned with right now is the case where the attacker
> just imprints the device and then operates it even though it's in the
> victim's network.

How can they join the victim's network, if the point of the enrollment is to
provide the device with keys to be able to join the victim's network?

Ah, now I think we're getting somewhere. I had understood the point of the 
enrollment in this context to be to get it to join the ANIMA fabric, not 
necessarily the physical network (hence why we have ACP, etc.)

Am I just totally missing the point here?

So, more directly responding to your concern: What happens if the attacker 
“just imprints the device and then operates it even though its in the victim’s 
network”?
Answer:

If the vendor system has sales channel integration then the voucher signatures 
provide an optional method of blocking “attacker imprint” (because it is no 
longer trust-on-first-use). This PREVENTS the attack you’re asking about.
If the victim network operator has appropriate inventory management then 
BRSKI/MASA integration provides logging inputs into that system to DETECT the 
scenario you describe, even without sales channel integration.

Once detected, then what? The BRSKI draft has this to say about its protocol 
flow and network access control:

draft-ietf-anima-bootstrapping-keyinfra-09:

   This document presumes that network access control has either already
   occurred, is not required, or is integrated by the proxy and
   registrar in such a way that the device itself does not need to be
   aware of the details.  Although the use of an X.509 Initial Device
   Identity is consistant with IEEE 802.1AR 
[IDevID],
 and allows for
   alignment with 802.1X network access control methods, its use here is
   for Pledge authentication rather than network access control.
   Integrating this protocol with network access control, perhaps as an
   Extensible Authentication Protocol (EAP) method (see 
[RFC3748]), is
   out-of-scope.

Its even more out of scope for the voucher itself since that is a msg format 
for “who should the device trust” and to trigger enrollment but is even further 
removed from network access control.

A potential integration is to use ANIMA or BRSKI to manage device enrollment 
and credential from a quarantine network. The network access control could be 
configured to segregate all devices that are not enrolled (perhaps into a true 
quarantine network or maybe just pass them all through to a carefully managed 
dmz or … whatever). If the device enrolls successfully then you get on the 
“real” network. In your scenario then the attacker gain control over a device 
that is untrusted and placed appropriately by the network access control 
system. But as noted, providing the tools for this is different than actually 
defining that integration. I encourage the network access control folks to 
address these types of concerns.

- max


-Ekr


(The exact nature of the keys depends upon how the voucher is used.
In BRSKI it's to bootstrap an EST connection, while in some versions of the
6tisch, actual 802.15.4 keys are return.  NETCONF uses this new trust to
permit the owner to reach in and do configuration with RESTCONF)

--
Michael Richardson mailto:mcr%2bi...@sandelman.ca>>, 
Sandelman Software Works
 -= IPv6 IoT consulting =-




___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] duplicate voucher requests in BRSKI

[Max Pritikin (pritikin)]

I don’t see why the voucher actually has to be expired before obtaining a 
refresh. 
The creation time would of course be updated.

Michael’s point that a Registrar could use this to force the MASA to perform 
crypto operations is valid. As implied the fix is to allow the MASA to simply 
return a current voucher (database lookup but less crypto) if that is more 
expedient. I suggest we leave that up to the MASA implementors. 

- max


> On Oct 23, 2017, at 8:18 AM, Michael Richardson  wrote:
> 
> 
> Kent Watsen  wrote:
>> i don’t see why not, but wouldn’t the creation time be different?
> 
> Yes, the creation time ought to be different, but I think it's okay if it's
> the same.   If the voucher has no expiry time, then this can be done for as
> long as the nonce is the same.
> 
> I think that if the expiry time is <6hr then probably a new voucher needs to
> be issued.  The goal here is to mitigate against crypto-intensive DoS
> attacks, while still dealing with situations where a transfer may have
> aborted, or something bad happened to a registrar and it has to retry.
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] appendix D removed!

[Max Pritikin (pritikin)]

Fantastic!

It looks like you went ahead and dropped them all into Master. I’ll read 
through the diffs and comment if I have concerns (later this evening). 

- max

> On Oct 3, 2017, at 1:09 PM, Michael Richardson  wrote:
> 
> 
> Max, as agreed in today's call, I went through the todo of edits, and did 
> them:
> 
>   Proxy:
>* Action: insert section betweeen 2.4 and 2.5 that indicates the
>   proxy is part of the architecture
> 
> DONE: new text at
>  
> https://github.com/anima-wg/anima-bootstrap/blob/master/dtbootstrap-anima-keyinfra.txt#L851
> 
> *  if you are going to implement a proxy then you
>should support a circuit proxy so that it works with all
>registrars
> 
> *  add a high level section between s5 and s6 that
>details proxy discussion
> 
> DONE:
>  
> https://github.com/anima-wg/anima-bootstrap/blob/master/dtbootstrap-anima-keyinfra.txt#L2084
> 
> *
>  * Action: update figure 1 from "dead branch"
> 
> DONE:
> https://github.com/anima-wg/anima-bootstrap/blob/master/component-diagram.txt
> 
> * Action: move 4.1.2 to new section.
> 
> DONE:
> moved it.
> 
> * Moving on in appendix D:
>  * [30]https://github.com/anima-wg/anima-bootstrap/blob/master/dtboots
> trap-anima-keyinfra.txt#L3341
>  *
>   * Maybe add section 2.0 about MASA to section 2,
> protocol overview.
> 
> DONE:
> the MASA part was up at L851 above.
> 
> * Move section D.1.4 to section 1.3, with reference to ACP.
> 
> DONE:
> added new subsection to section 1.
> 
> Ripped appendix D.
> 
> Remaining TODO:
>  update the JRC discovery with the M_FLOOD method.
> 
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] two EST question/suggestions

[Max Pritikin (pritikin)]

Any protocol work needs balance future proofing (anticipating changes in the 
MTI) against clear and definitive statements to meet the current requirements. 
If there are places where the current language falls down commenting on that 
specific language would help.

Re the HTTP/2 discussion:

HTTP/2 is requested by the client via one of the RFC7540 section3 methods. 
There is nothing in the MTI BRSKI language that would block attempts to so 
upgrade by clients. The server could of course support this if it so desired. 

I don’t see an advantage to HTTP/2 for BRSKI and EST interactions. I guess a 
server could finish authentication of the client and immediately initiate a 
server push of the csrattributes, voucher response (if available), and other 
messages. This would save some round trips but in the primary flows the client 
needs to perform a crypto operation that is used or verified by the server 
before a response is generated. So the basic state machine, I think, would 
continue to flow as currently specified. 

I agree with the conclusion below that "TTP 1.1 with persistent connections is 
the minimum (not the maximum)” and that we don’t have anything else to say 
here. 

- max


> On Sep 13, 2017, at 2:13 PM, Brian E Carpenter  
> wrote:
> 
> On 13/09/2017 11:57, Michael Richardson wrote:
>> 
>> Brian E Carpenter  wrote:
 We are running over HTTP 1.1, we have to assume that.
 The issue is that both client and server libraries will grow HTTP 2, and we
 need to know if this is a problem.
 
> It seems to me that we want to minimise the requirements for low end 
> pledge
> devices, and every item that we make mandatory works against that.
 
 BRSKI does not target constrained devices;  in the future having only an 
 HTTP
 2 library (because the application is using that) might be simplest.  Is it
 going to work okay?
>> 
>>> I don't see why not. But isn't there potentially a class of devices that
>>> while not being 'constrained' in the formal sense, nevertheless needs to
>>> minimise its software footprint? So the implementer will want to choose
>>> the solution with the smallest footprint, rather than whatever MTI we
>>> happen to define in 2017.
>> 
>> Yes, I agree with you.
>> 
>> That's why I would like us to permit pledges to support a single client HTTP
>> library.  They will use whatever HTTP client library that they need for their
>> primary application... so if it's a webrtc nanny camera, then it might well
>> be HTTP2 + QUIC.
>> 
>> The problem with HTTP2 is that it permits requests and responses to be
>> interleaved and not-sequential in the TCP sense.  This potentially has a poor
>> interaction with the BRSKI state machine.  We ought to say something about
>> this *today*.
>> 
>>> Of course we can always change the MTI later, but if we say right now that
>>> the MTI only applies to the server side, adding new solutions for future
>>> types of pledge becomes more straightforward. As far as I can see, this
>>> would have zero impact on first-generation implementations; initially
>>> both servers and clients will support the MTI anyway.
>> 
>> My take is that the server has to support every single MTI that we have every
>> supported.  That's okay.  But, HTTP 1.1 with persistent connections is the
>> minimum (not the maximum).
> 
> Fair enough. I just want to be sure that when someone comes up with
> a brilliant new method with a tiny footprint, pledges are free to adopt
> it despite any MUSTs we write down in 2017.
> 
>Brian
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] resolving overload of pinnned-domain-cert field (was: Re: PKCS7 certificate SignerData certificates)

[Max Pritikin (pritikin)]

There were two issues,

a) The pinned-domain-cert was used as the MASA statement for the domain root 
certificate in vouchers but overloaded as the Registrar certificate in voucher 
requests. This caused confusion and the latest text now adds a 
“proximity-registrar-cert” to
the voucher request. 

b) Each of these fields is a single certificate while PKI discussions often 
include chains. We decided that continuing with the single certificate approach 
is valid and are not transitioning to greater PKI integrations. No change.

The pull request fixing these two was merged with this commit:

https://github.com/anima-wg/anima-bootstrap/commit/4c4eee67cb367faacc976bce0020830a9daea9bf

c) There was a cut/paste error in the language around pkcs7 signatures 
(regarding who signs them) that was fixed with this commit:

https://github.com/anima-wg/anima-bootstrap/commit/d8aeff53fd048c07cebcc88828558c6bafc179df


- max


> On Sep 8, 2017, at 3:24 PM, Max Pritikin (pritikin)  
> wrote:
> 
> I’ve commented inline about these discussion. 
> 
> I’ve also prepared a set of diffs to help bring clarity as per the 
> discussion. The diffs are in this branch:
>   
> https://github.com/anima-wg/anima-bootstrap/commit/bec6d97207aa8faaa600d60622c9b4650ee04934
> 
>> On Sep 7, 2017, at 9:19 AM, Michael Richardson  wrote:
>> 
>> 
>> Max Pritikin (pritikin)  wrote:
>>> The voucher-request has this additional requirement:
>> 
>>> s3.3 of BRSKI-07,
>>> The request is a "YANG-defined JSON
>>> document that has been signed using a PKCS#7 structure" as
>>> described in [I-D.ietf-anima-voucher] using the JSON encoded
>>> described in [RFC7951].  The Registrar MUST sign the request.  The
>>> entire Registrar certificate chain, up to and including the Domain
>>> CA, MUST be included in the PKCS#7 structure.
>> 
>> I feel dumb, because I was sure that I looked for such a sentence, and I
>> didn't find it.  Good that it is there.
>> 
>>>> In a signed voucher request from the pledge to the registrar the
>>>> pinned-domain-cert is that of the *PLEDGE* (signed with it's IDevID).
>> 
>>> Actually this pinned-domain-cert is thus, from s3.2 of BRSKI-07,
>> 
>>> pinned-domain-cert:  In a Pledge voucher request this is the
>>> Registrar certificate as extracted from the TLS handshake (for
>>> example the first certificate in the TLS 'certificate_list'
>>> sequence (see [RFC5246]).  This MUST be populated in a Pledge's
>>> voucher request if the "proximity" assertion is populated.
>> 
>> Huh, this is actually surprising...
>> I guess we need the Registrar to keep the same thing there, and really the
>> voucher *HAS* to be issued for this key in order for the Pledge to get out of
>> provisional state…
> 
> The registrar “keeps” this field by populating the 
> prior-signed-voucher-request (also preserving the Pledges signature over the 
> proximity assertion).  
> 
>> 
>>> I was wondering earlier today if this was confusing. We could add a
>>> leaf for “tls-domain-cert” or something. An additional point is that
>>> the *assumption* is that this is the same cert as the id-kp-cmcRA cert
>>> in the chain discussed above and in s3.3 but maybe that is an
>>> assumption too far and we should support bags of certs and arbitrary
>>> complexity? I’m tired of this PKI mess.
>> 
>> Yes, that's an assumption.
>> The *VOUCHER* that results has to match the certificate in the TLS.
>> So it makes sense for the PLEDGE to indicate what certificate it is
>> expecting.
>> 
>> That lets the Registrar be built using a variety of certificates for
>> load balancing purposes, and deals with a race condition that could occur if
>> the Registrar's certificate is renewed during the imprinting process.
>> 
>> If a Registrar wants/needs to update it's cmcRA cert, it could present
>> the previously signed voucher to the MASA with previous…
> 
> There are two places where consistent use of Registrar cert on both legs is 
> referenced.  
> 
> First BRSKI-08 s4.3 indicates the MASA "MAY verify” the pledge’s proximity 
> assertion is “consistent with the [Registrar’s Registrar's 'TLS client 
> certificate]”. The Registrar’s TLS client certificate chain root certificate 
> is then used to populate the ‘pinned-domain-cert’ (final paragraph s4.3).
> 
> Second BRSKI-08 s4.4 indicates how the Pledge completes the provisional TLS 
> authentication: "The 'pinned-domain-cert' element of the voucher contains the 
> domain CA'

Re: [Anima] two EST question/suggestions

[Max Pritikin (pritikin)]

> On Aug 29, 2017, at 2:31 PM, Michael Richardson  wrote:
> 
> 
> Max, I suggest that we add some text to section 2 to indicate that BRSKI EST
> connections SHOULD be HTTP 1.1 persistent connections.
> I wrote:
>Establishment of the TLS connection for bootstrapping is as
>   specified in EST  section 4.1.1 "Bootstrap
>   Distribution of CA Certificates" .
>   While EST section 3.2 does not insist
>   upon use of HTTP 1.1 persistent
>   connections, BRSKI connections SHOULD use
>   persistent connections.  This is due to the provisional state
>   that occurs in the TLS connection.
>   The following extensions are added for automation:
> 
> 

I agree with this and used the change to tighten language about EST integration 
a bit more:

https://github.com/anima-wg/anima-bootstrap/commit/def9e6351b03f93073f7ff09ebbabd87e8643f95

> We may also want to say something about HTTP 2.0's multiplexed
> request/responses (I think we don't want them).  I'm not sure exactly what
> the list of things we don't want yet, or how to express this.
> I am sure that we don't want QUIC (or SPDY) or other stuff like that!
> 
> I don't know if the binary-ness of HTTP2 matters to use at all in the end,
> and we should just let that upgrade path simply proceeed.

The only HTTP version we indicate is 1.1. in your language inserted above. 
EST is similarly vague, only referencing 1.1. in the context of persistent 
connections. 

I agree a statement that HTTP2 etc is ok so long as it doesn’t change the 
possible client state machine…  ?

> 
> The other question is about the use of 102 Processing codes, and 201 Created
> codes.  I think that we discussed making /requestvoucher more RESTful by
> returning a 201 Created, along with a Location: header, and decided against
> it.  I think that I'm partly re-opening this question. (Shall I make it a 
> ticket)

I’d recommend a ticket. Not sure I want to open this again but am willing to 
hear the argument. 

> 
> The reason for my question is about Registrar->MASA interactions that need to
> occur, and timeouts that might occur.  Returning a 201 Created pointing to a
> URL that could be used to retrieve the resulting voucher would provide a nice
> way to do things. If upon the pledge issuing the GET, the voucher still isn't
> ready, a 102 Processing code could be returned.
> 
> I'm particularly concerned that the pledge not set too-short timeouts here,
> as the only recourse it would have is to close the connection.

understood,

- max

> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] PKCS7 certificate SignerData certificates

[Max Pritikin (pritikin)]

I’ve commented inline about these discussion. 

I’ve also prepared a set of diffs to help bring clarity as per the discussion. 
The diffs are in this branch:

https://github.com/anima-wg/anima-bootstrap/commit/bec6d97207aa8faaa600d60622c9b4650ee04934

> On Sep 7, 2017, at 9:19 AM, Michael Richardson  wrote:
> 
> 
> Max Pritikin (pritikin)  wrote:
>> The voucher-request has this additional requirement:
> 
>> s3.3 of BRSKI-07,
>> The request is a "YANG-defined JSON
>> document that has been signed using a PKCS#7 structure" as
>> described in [I-D.ietf-anima-voucher] using the JSON encoded
>> described in [RFC7951].  The Registrar MUST sign the request.  The
>> entire Registrar certificate chain, up to and including the Domain
>> CA, MUST be included in the PKCS#7 structure.
> 
> I feel dumb, because I was sure that I looked for such a sentence, and I
> didn't find it.  Good that it is there.
> 
>>> In a signed voucher request from the pledge to the registrar the
>>> pinned-domain-cert is that of the *PLEDGE* (signed with it's IDevID).
> 
>> Actually this pinned-domain-cert is thus, from s3.2 of BRSKI-07,
> 
>> pinned-domain-cert:  In a Pledge voucher request this is the
>> Registrar certificate as extracted from the TLS handshake (for
>> example the first certificate in the TLS 'certificate_list'
>> sequence (see [RFC5246]).  This MUST be populated in a Pledge's
>> voucher request if the "proximity" assertion is populated.
> 
> Huh, this is actually surprising...
> I guess we need the Registrar to keep the same thing there, and really the
> voucher *HAS* to be issued for this key in order for the Pledge to get out of
> provisional state…

The registrar “keeps” this field by populating the prior-signed-voucher-request 
(also preserving the Pledges signature over the proximity assertion).  

> 
>> I was wondering earlier today if this was confusing. We could add a
>> leaf for “tls-domain-cert” or something. An additional point is that
>> the *assumption* is that this is the same cert as the id-kp-cmcRA cert
>> in the chain discussed above and in s3.3 but maybe that is an
>> assumption too far and we should support bags of certs and arbitrary
>> complexity? I’m tired of this PKI mess.
> 
> Yes, that's an assumption.
> The *VOUCHER* that results has to match the certificate in the TLS.
> So it makes sense for the PLEDGE to indicate what certificate it is
> expecting.
> 
> That lets the Registrar be built using a variety of certificates for
> load balancing purposes, and deals with a race condition that could occur if
> the Registrar's certificate is renewed during the imprinting process.
> 
> If a Registrar wants/needs to update it's cmcRA cert, it could present
> the previously signed voucher to the MASA with previous…

There are two places where consistent use of Registrar cert on both legs is 
referenced.  

First BRSKI-08 s4.3 indicates the MASA "MAY verify” the pledge’s proximity 
assertion is “consistent with the [Registrar’s Registrar's 'TLS client 
certificate]”. The Registrar’s TLS client certificate chain root certificate is 
then used to populate the ‘pinned-domain-cert’ (final paragraph s4.3).

Second BRSKI-08 s4.4 indicates how the Pledge completes the provisional TLS 
authentication: "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 normative language here allows for Pledges that don’t make the proximity 
assertion. This also allows a Registrar to present a cert to the Pledge that is 
*different* than the cert it presents to the MASA; so long as they are issued 
by the same CA and so long as the MASA allows for the discrepancy. We *could* 
strengthen this normative statement like so:

“If the Pledge provides a proximity assertion then the MASA MUST 
verify…”

The current logic is softer to allow for more flexibility in Pledge behavior. 
See my next comment:

>>> a) is that certificate also included in the PKCS7 bag of certificates?
>>> I think the answer SHOULD be yes.
>>> b) is there any operationally valid reason why there should be additional
>>> certificates in the PKCS7 bag?
>>> I can not come up with one. The registrar is never going to validate
>>> any chain that the manufacturer might have used internally to set up
>>> their CA for their IDevID.  It cares about the end-certificate only.
> 
>> The reason s3.3. mandates the entire chain, including the domain CA
>> certificate, is to allow the abov

Re: [Anima] PKCS7 certificate SignerData certificates

[Max Pritikin (pritikin)]

> On Sep 5, 2017, at 6:09 PM, Michael Richardson  wrote:
> 
> 
> PKCS7 artifacts have three things in them:
> 1) the content (technically optional, but we need them)
> 2) a set of SignerInfo objects on the content.
> 3) within the SignerData, a bag of certificates, one or more of which has
>   signed the content, and the rest which may be useful to establish a trust
>   path to a CA.
> 
> Max and Kent do we need to say anything about what's in this bag of
> certificates, or whether or not they can/should be used to validate a voucher
> or voucher request.

The voucher-request has this additional requirement:

s3.3 of BRSKI-07,
  The request is a "YANG-defined JSON
  document that has been signed using a PKCS#7 structure" as
  described in [I-D.ietf-anima-voucher] using the JSON encoded
  described in [RFC7951].  The Registrar MUST sign the request.  The
  entire Registrar certificate chain, up to and including the Domain
  CA, MUST be included in the PKCS#7 structure.

> Both the JRC (Registrar) and the MASA SHOULD validate signed requests are in
> fact signed by the key they claim is making the request.

s3.3 of BRSKI-07,

  The MASA validation checks before issuing a voucher are as follows:
  [additional requirements removed for brevity]

  Voucher signature consistency:  The MASA MUST verify that the voucher
  request is signed by a Registrar.  This is confirmed by verifying
  that the id-kp-cmcRA extended key usage extension field (as
  detailed in EST RFC7030 section 3.6.1) exists in the certificate
  of the entity that signed the voucher request.  This verification
  is only a consistency check that the unauthenticated domain CA
  intended this to be a Registrar.  Performing this check provides
  value to domain PKI by assuring the domain administrator that the
  MASA service will only respect claims from authorized Registration
  Authorities of the domain.  (The requirement for the Registrar to
  include the Domain CA certificate in the signature structure was
  stated above).

> In a signed voucher request from the pledge to the registrar the
> pinned-domain-cert is that of the *PLEDGE* (signed with it's IDevID).

Actually this pinned-domain-cert is thus, from s3.2 of BRSKI-07,

   pinned-domain-cert:  In a Pledge voucher request this is the
  Registrar certificate as extracted from the TLS handshake (for
  example the first certificate in the TLS 'certificate_list'
  sequence (see [RFC5246]).  This MUST be populated in a Pledge's
  voucher request if the "proximity" assertion is populated.

I was wondering earlier today if this was confusing. We could add a leaf for 
“tls-domain-cert” or something. An additional point is that the *assumption* is 
that this is the same cert as the id-kp-cmcRA cert in the chain discussed above 
and in s3.3 but maybe that is an assumption too far and we should support bags 
of certs and arbitrary complexity? I’m tired of this PKI mess.

>  a) is that certificate also included in the PKCS7 bag of certificates?
> I think the answer SHOULD be yes.
>  b) is there any operationally valid reason why there should be additional
> certificates in the PKCS7 bag?
> I can not come up with one. The registrar is never going to validate
> any chain that the manufacturer might have used internally to set up
> their CA for their IDevID.  It cares about the end-certificate only.

The reason s3.3. mandates the entire chain, including the domain CA 
certificate, is to allow the above consistency checks. But originally this was 
so that the domainCA certificate would be used for the pinned cert. Moving to 
just the RA cert in the pinned-domain-cert field would be a simplification? The 
text of the voucher-05 leaf description seems to allow this.

> 
> In a signed voucher request from the JRC (registrar) to the MASA the
> pinned-domain-cert is that of the *Registrar* (signed with it's cmcRA marked
> certificate from the domain owner's CA).
> 
>  a) is that certificate also included in the PKCS7 bag of certificates?
> I think the answer SHOULD be yes.

This is the current language and *not* that the pinned-domain-cert is populated 
at all. In fact if you look at the new voucher-request-yang branch and Example 
(2) of the voucher requests you see:

   {
   "ietf-voucher-request:voucher": {
   "created-on": "2017-01-01T00:00:02.000Z",
   "assertion": "TBD",
   "idevid-issuer": "base64encodedvalue=="
   "serial-number": "JADA123456789"
   }
   }

I was considering opening an issue about this TBD and the resulting uncertainty 
about the meaning of the pinned-domain-cert in this situation. 

> 
>  b) is there any operationally valid reason why there should be additional
> certificates in the PKCS7 bag?
> 
> Yes.  At least the domain owner's CA and any certificates in between
> the Registrar and the CA SHOULD be presented.
> 

Re: [Anima] Is this how BRSKI/IPIP works?

[Max Pritikin (pritikin)]

re: "this case must work”
There sure is a lot of complexity in this thread to ensure that link local 
addresses can be used outside of the local scope. 

Some simpler suggestions,

1) a stateful proxy. I know, I know. But how many devices are actually going to 
need to perform BRSKI at the same time? And if that many devices are being 
bootstrapped then can’t they wait for the proxy to work through them in order? 

2) Require pledges to complete RFC4862 ‘Creation of Global Addresses’. Pledges 
then perform GRASP and then communicate with the Registrar directly. (Can 
RFC4193 ‘Unique Local IPv6 Unicast Addresses’ be assigned? I think so…)

or 

3) If it *doesn’t work* what happens? Currently BRSKI starts over w/o stating 
anything about obtaining a new Lp. Would it help to restart the stack and look 
for a unique Lp at that point? All we’re looking for is non-collision during 
bootstrapping. I don’t like this approach as much as the above options. 

- max



> On Jul 5, 2017, at 8:19 PM, Brian E Carpenter  
> wrote:
> 
> Hi BRSKI authors,
> 
> Is the following correct?
> 
> Topology (ASCII art):
>   ___
>  | REGISTRAR |
>  |___|
>|Ar
>| 
>   ...
>  (ACP)
> (   routing   )
>  (   cloud   )
>   ...
>|
>|Ax
>   _|_
>  |   PROXY   |
>  |___|
>   |Lx1  |Lx2 
>   | |
>   | |
>  ---LAN1-  ---LAN2--
>  | |
>  |Lp   |Lp
>  |  ___|_ 
> | PLEDGE1 || PLEDGE2 |
> |_||_| 
> 
> Assumptions:
> 
> Pledges have link-local address Lp. By chance, they are equal. (Nothing in
> the standards prevents them from being equal. Even pseudo-random numbers can
> be equal, so this case must work.)
> 
> Proxy has link-local addresses Lx1, Lx2 and ACP address Ax. We can require
> that Lx1 != Lx2.
> 
> Registrar has ACP address Ar.
> 
> Packets for a UDP example:
> 
> (somewhat simplified IPv6 packets!)
> 
> Pledge sends to proxy [Lp, Lx1, 17, UDP-PAYLOAD1]
> 
> Proxy sends to Registrar [Ax, Ar, 41, [Lp, Lx1, 17, UDP-PAYLOAD1]]
> 
> Registrar replies to proxy [Ar, Ax, 41, [Lx1, Lp, 17, UDP-PAYLOAD2]]
> 
> Proxy replies to pledge [Lx1, Lp, 17, UDP-PAYLOAD2]
> 
> Note that the registrar echoes back the addresses Lp and Lx but they mean
> nothing to it. The registrar simply borrows the proxy's LL address Lx
> for the purpose of replying.
> 
> Note that even the 2uple {Ax, Lp} might not uniquely identify the pledge.
> Since the proxy will have at least two interfaces, the address Lp might
> exist on multiple LANs. However, the proxy will have different link-local
> addresses on the two LANs, so the 3uples {Ax, Lp, Lx1} {Ax, Lp, Lx2}
> will be unique. Hence the registrar can distinguish the transactions.
> 
> So, what the registrar needs to tell the proxy is: I accept IP in IP on 
> address Ar.
> Nothing else - no port number, no link-local address.
> 
> What the proxy needs to tell the pledge is: I accept BRSKI/TCP
> or BRSKI/UDP on address Lx. And if it chooses to use IPIP to contact
> the registrar, it simply forwards the packets as-is in both directions,
> encapsulating and decapsulating accordingly. The pledge knows nothing about
> IPIP.
> 
> Regards
>   Brian
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] IPIP in draft-ietf-anima-bootstrapping-keyinfra-07

[Max Pritikin (pritikin)]

Brian, I’m out for a couple of weeks but wanted to thank you for this note. 

Michael Richardson will likely have good comments but for now I’ve set a 
calendar event to catch up when I return and also have created a github issue 
to track this. 
https://github.com/anima-wg/anima-bootstrap/issues/22

- max

> On Jul 3, 2017, at 11:32 PM, Brian E Carpenter  
> wrote:
> 
> Hi,
> 
> I am still trying to figure out what you really want to say in sections 
> 3.1.1. Proxy Discovery Protocol Details and 3.1.2. Registrar Discovery 
> Protocol Details.
> 
> 1. Why doesn't section 3.1.1 mention IP-in-IP (protocol 41)? Surely the 
> pledge needs to know about it?
> 
> 2. The description is wrong anyway; see 
> https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-02#section-2.3
>  for something that can work.
> 
> 3. In section 3.1.2, as I already pointed out, the proposal is really a 
> misuse of the GRASP discovery response message. Not a problem, we simply 
> replace it with a synchronization response; see 
> https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-02#section-2.2.
>  
> But regardless of that, I am confused by the example locators:
>locator1  = [O_IPv6_LOCATOR, fd45:1345::6789, 6,  443]
>locator2  = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683]
>locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil]
> 
> The first two are OK. The ports announced by the proxy to the pledges may be 
> different. If the registrar sends  [O_IPv6_LOCATOR, fd45:1345::6789, 6,  
> 443], the proxy might announce [O_IPv6_LOCATOR, fe80::4321, 6, ] - the 
> proxy's link-local address and a different port chosen by the proxy.
> 
> But the third locator sent by the Registrar indicates a meaningless 
> link-local address, because it could come from many hops away. At first I 
> thought this was a confusion with the previous (proxy-to-pledge) case, where 
> all addresses must be link-local. But no: this text is just confused, I think:
> 
>   A protocol of 41 indicates that packets may be IPIP proxy'ed.  In the
>   case of that IPIP proxying is used, then the provided link-local
>   address MUST be advertised on the local link using proxy neighbour
>   discovery.  The Join Proxy MAY limit forwarded traffic to the
>   protocol (6 and 17) and port numbers indicated by locator1 and
>   locator2.  The address to which the IPIP traffic should be sent is
>   the initiator address (an ACP address of the Registrar), not the
>   address given in the locator.
> 
> A link local address provided by the Registrar is completely invalid except 
> on the relevant link connected directly to the Registrar. So it definitely 
> must not be given to anybody off that link. At the moment I have no idea how 
> the IP-in-IP is supposed to work. Appendix C doesn't help much. Apart from 
> anything else, it mentions a non-existent GRASP message type. I can sort of 
> see what you want to do, but it isn't a codable spec at the moment.
> 
> Maybe you can provide a complete example of the packet flow, where the pledge 
> has link-local address Lp, the proxy has link-local address Lx and ACP 
> address Ax, and the registrar has ACP address Ar. And to make my concern 
> clear, the registrar has the link-local address Lp, by chance the same as the 
> pledge, although on a different LAN.
> 
> Regards
>   Brian
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Result of WGLC on draft-ietf-anima-voucher-03 - Respond by June 23, 2017

[Max Pritikin (pritikin)]

Toerless (the other working group chair) has been involved in conversations 
concerning the open issues listed on the github repository for the voucher 
document.
The issues should be resolved now as per the current status in github. See here 
for details of three open issues remaining:
https://github.com/anima-wg/voucher/issues
The other issues have been resolved and the ‘top of the tree’ is here:
https://github.com/anima-wg/voucher/blob/master/draft-ietf-anima-voucher.txt

If you are curious about what this resolves so far please look at these diffs 
(here summarized via the commit comments):

[some minor editorial work]
typo in "hangTex" instead of "hangText" 2f0d64c
updated hangtext for artifact definition 4f6c710
Updated the proximity description with minor editorial edits. … b742c5a
Merge branch 'master' into voucher_sync_061417 6cc9d72
manual merge of a generated txt file sucks. committing built version … …
[substantive issues]
additional enum for ‘proximity’ assertions:
https://github.com/anima-wg/voucher/commit/b8ec4919242bc26c9082f633099656e4851097ea

addition of prior-signed-voucher to provide history in northbound BRSKI 
exchanges:
https://github.com/anima-wg/voucher/commit/b742c5a63e05f1341b37f96009d6bfcd5f5be0e1

We believe this provides enough to proceed with LC and to allow BRSKI to be 
finalized toward LC as well asap.

- max

On Jun 26, 2017, at 8:33 PM, Sheng Jiang 
mailto:jiangsh...@huawei.com>> wrote:

Hi, all

Given there is no negative response to the WGLC on draft-ietf-anima-voucher-03 
and we did receive good reviews through the WG document stage and considering 
the past history of this work, the ANIMA chairs feel it is has passed the WGLC 
and should advance. This conclusion is made with the condition that the authors 
would solve the comments received during the WGLC and these modifications were 
not substantial changes from 03 version. If there are big changes, a shorter 
second WGLC may be needed.

Once the update is published and it meets the above condition, for which the 
second WGLC is not needed, as shepherd, Sheng Jiang will finalize the shepherd 
document and send the document on.

Best regards,

Toerless & Sheng

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] 200 vs 201 responses from MASA to Registrar (BRSKI-MASA protocol)

[Max Pritikin (pritikin)]

That is an interesting idea. Obtaining a “renewed” voucher would be as simple 
as a query to the known URL (unless the nonce needed to be updated in which 
case use the POST method). Hmm.

Feels a little bit like a premature optimization; but I see the point. 

- max

> On Jun 5, 2017, at 8:02 PM, Michael Richardson  wrote:
> 
> 
> Max Pritikin (pritikin)  wrote:
>> From https://tools.ietf.org/html/rfc2616#section-9.5
> 
>> The action performed by the POST method might not result in a
>> resource that can be identified by a URI. In this case, either 200
>> (OK) or 204 (No Content) is the appropriate response status,
>> depending on whether or not the response includes an entity that
>> describes the result.
> 
>> In this case I think the 200 OK code is most appropriate since the
>> server generates a signed voucher as a result of the POST and returns
>> it. The voucher is not identified by a URI.
> 
> Agreed... let me ask the question again:
>   SHOULD the voucher be identified by a URI?
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt

[Max Pritikin (pritikin)]

> On Jun 5, 2017, at 4:22 PM, Brian E Carpenter  
> wrote:
> 
> This version includes a second round of responses to IESG comments.
> 
> We may not be done yet, but please check the diffs. Here are the main changes:
> 
>   Removed all mention of TLS, including SONN, since it was under-
>   specified.

The -13 text maintains the “MUST be authenticated and encryption MUST be used” 
but now there is no normative requirement on how this is met. Correct? 

 As mentioned in , some GRASP operations 
might be
 performed across an administrative domain boundary by mutual 
agreement, without the
 benefit of an ACP. Such operations
 MUST be confined to a separate instance of GRASP with its own copy of 
all GRASP
 data structures. Messages MUST be authenticated and encryption MUST be 
used.
 
 Further details may be specified in future documents.
 

As such I’m not sure this section is providing any value anymore. Perhaps 
simply remove it? 
Its only saying that some future work might discover an alternative 
non-constained way of running GRASP. This is effectively already discussed 
above:


 The ACP, or in its absence another security mechanism, sets the 
boundary within which nodes
 are trusted as GRASP peers. A GRASP implementation MUST refuse to 
execute GRASP
 synchronization and negotiation functions if there is neither an 
operational
 ACP nor another secure environment. 

QUESTION: The BRSKI -06 draft generically references GRASP for discovery but of 
course we know that this is prior to being able to establish an ACP. Therefore 
we must be referencing something in https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-anima-grasp-13
>> https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-13
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-13
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> ___
>> I-D-Announce mailing list
>> i-d-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> 
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] 200 vs 201 responses from MASA to Registrar (BRSKI-MASA protocol)

[Max Pritikin (pritikin)]

>From https://tools.ietf.org/html/rfc2616#section-9.5

   The action performed by the POST method might not result in a
   resource that can be identified by a URI. In this case, either 200
   (OK) or 204 (No Content) is the appropriate response status,
   depending on whether or not the response includes an entity that
   describes the result.

In this case I think the 200 OK code is most appropriate since the server 
generates a signed voucher as a result of the POST and returns it. The voucher 
is not identified by a URI. 

- max 

> On Jun 4, 2017, at 7:42 PM, Michael Richardson  wrote:
> 
> 
> Max, in section 3.3 we document the contents that the Registrar will POST to
> the MASA's /requestvoucher.
> 
> In section 3.4 we say:
>   3.4.  Voucher Response
> 
>   ...
>   If the the join operation is successful, the server response MUST
>   contain an HTTP 200 response code.  The server MUST answer with a
>   suitable 4xx or 5xx HTTP [RFC2616] error code when a problem occurs.
> 
> It seems that since we are using POST, that we ought to answer with an HTTP
> 201 response code, and include a Location: header at which the voucher could
> be accessed later on.I am not sure if I'm arguing for returning just the
> 201, and expect the Registrar to do a GET, although that would be more
> correct.
> 
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] BRSKI -06 posted (was: Re: [Anima-bootstrap] Concise version of BRSKI)

[Max Pritikin (pritikin)]

The -06 version is posted. We are midstream and expect to keep working on this. 

In particular the voucher document is currently undergoing focused update and 
we expect an -07 of BRSKI to be published soon after to reflect those updates.

- max


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [Anima-bootstrap] Concise version of BRSKI

[Max Pritikin (pritikin)]

> On May 23, 2017, at 8:28 AM, Toerless Eckert  wrote:
> 
> It is quite frustrating to see the bootstrap draft be handled in a way that 
> is impossible
> to track:
> 
> - it would have been better not to crearte anothrer branch that you can only 
> be aware 
>  of by having seen this email

As previously requested this thread was sent to the anima working group mailing 
list rather than the now deprecated bootstrap mailer. Not sure how else to 
communicate status. 

The up to date document is available via the github repository. This is in 
alignment with multiple conversations at ietf and was the subject of a BoF at 
the Chicago IETF. If you have concerns about how git might work within a 
working group process flow i’ll bet the authors of 
https://tools.ietf.org/html/draft-thomson-github-bcp-00 or would be interested 
in the feedback. I suggest raising your concerns on the ietf-and-github mailing 
list to ensure they’re addressed as part of that broader effort. 

> - If you use a new branch, it would be great if you would have updated the 
> IETF anima bootstrap wiki page
>  with this information.
> - for the sake of the non-git experts amongst us, it would be great to also 
> indicate some
>  command how to retrieve this branch. I for once tried:
> 
>  git clone -b concise https://github.com/anima-wg/anima-bootstrap

https://github.com/anima-wg/anima-bootstrap includes a dropdown to select the 
branch if you just want to look at the specific files. Using this for example 
the pre06 version from the concise branch is available here:

https://github.com/anima-wg/anima-bootstrap/blob/concise/dtbootstrap-anima-keyinfra-06.txt
 
One way to determine which branch has the most activity is to look here:
https://github.com/anima-wg/anima-bootstrap/branches/active

>  and that totally did not work.

Using -b worked for me. Not sure what you did wrong then. 

>  So as of right now i am lost in how i should review this version of the 
> document.

Thanks for joining the meeting today and voicing your concerns. To help we’ll 
push the 06 version of the doc to give you a better reference for generating 
feedback. 

- max

> 
> Toerless
> 
> On Tue, Apr 18, 2017 at 05:07:18PM +, Max Pritikin (pritikin) wrote:
>> 
>> Peter,
>> 
>> The current text is wordy and repetitive and says things more than once 
>> . Primary focus is to remove repetitive text, tighten remaining text, 
>> and consolidate normative statements. 
>> 
>> As an initial example the -05 draft has 3 main sections:
>>  architectural overview
>>  functional overview (contains design considerations discussions)
>>  protocol details
>> The initial ???concise??? branch commit moves the functional overview to the 
>> appendix. Subsequent commits are resolving normative texts that were in 
>> there by moving needed bits back into the protocol discussion. You can 
>> follow along via the git repository here:
>>  https://github.com/anima-wg/anima-bootstrap/compare/concise
>> 
>> There was a comment that the design considerations are useful and might be 
>> appropriate to keep here or in another document. At the moment I don???t 
>> have a formulated position on that.  
>> 
>> - max
>> 
>>> On Apr 18, 2017, at 3:27 AM, peter van der Stok  wrote:
>>> 
>>> Hi Max,
>>> 
>>> excellent idea. I looked at the present version, and there is still a lot 
>>> of text.
>>> Where in the text do you want to reduce more? What is the end-objective?
>>> And will this become the final document, or is it a study that will be used 
>>> later for editing the final document?
>>> 
>>> Peter
>>> 
>>> Max Pritikin (pritikin) schreef op 2017-04-15 00:34:
>>>> For those of you tracking the git repository please note the existence
>>>> of a new branch. As warned I???m significantly reducing the text. This
>>>> work is going on in the branch ???concise???.
>>>> ___
>>>> Anima mailing list
>>>> Anima@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/anima
>> 
>> ___
>> Anima-bootstrap mailing list
>> anima-bootst...@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima-bootstrap
> 
> -- 
> ---
> t...@cs.fau.de
> 
> ___
> Anima-bootstrap mailing list
> anima-bootst...@ietf.org
> https://www.ietf.org/mailman/listinfo/anima-bootstrap

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [Anima-bootstrap] Voucher signing method

[Max Pritikin (pritikin)]

> On May 2, 2017, at 7:22 PM, Kent Watsen  wrote:
> 
> 
> I've had some time now to investigate JWS, in particular, reproducing some 
> examples in RFCs 7515 and 7520 using nothing but shell scripts and the 
> `openssl` command line utility.

Excellent. I look forward to hearing what tool you used to convert the openssl 
dgst signature to the JWS form. 

> I want to like JWS, but I wish the header was in a more technology-neutral 
> format, it being JSON seems weird to me.

Given that we’re already using JSON (with discussion of CBOR) this doesn’t seem 
relevant since we aren’t technology-neutral either. I don’t know that there is 
such a thing as a technology neutral header. 

>  Had this been done, it would be a nice general-purpose signature format.  
> Size wise, JWS grows the size of the data 33% when b64 encoding it for the 
> "compact serialization" form, which is actually a 65-character alphabet 
> including '.'.  It seems that a binary header could've also allowed for a 
> binary payload and signature, which would've been perfect, in my opinion.  
> [Of course, the entire binary blob could still be base64url-encoded for those 
> that want it, without forcing it on those that don’t]

In either PKCS7 or JWT we’re using a base64 encoding to transmit the final 
result over the HTTPS/REST interface. With ACE discussions moving toward CoAP 
w/ CBOR they’ll have the option of “CWT” or “PKCS7 binary in a CBOR”.

> The example voucher you obtained from mcr wasn't as trimmed down as it 
> could've been, using the -noattr and -nocert options, which is one reason the 
> asn1parse dump looks as busy as it does.  Another being that the 
> owner/domain-cert-trusted-ca encode very different certs (is one ec while the 
> other is rsa?)

I read this as an argument in favor of a strict profile of PKCS7 if we’re going 
to stick with that format. Of course Postel’s law (“be conservative in what you 
do, be liberal in what you accept”) implies that relying parties would have to 
deal with the more complex ASN1 encodings — which results in the basic issue of 
complex ASN1 parsers on the endpoints.  

> In the end, JWS appears to be just another signature format with its own set 
> of peculiarities.  And given that we already have to support ASN.1 (the 
> voucher encodes both an X.509 cert as well as a X.509 certificate chain), not 
> to mention the need for the MASA to have a PKIX infrastructure, it's not 
> clear to me if this is a good trade at all.
> 
> Lastly, as mentioned before, my netconf zerotouch draft uses CMS/PKCS7 
> elsewhere.  While it would be trivial to update the draft to use a JWS-based 
> format, it would be awkward for clients to have to consider it at all.

But with that approach we’ll never kill off asn1. :(

- max

> 
> Kent
> 
> 
> -ORIGINAL MESSAGE-
> 
> Folks, in Chicago we discussed the signing method for vouchers. 
> 
> Because the voucher is JSON, and there is expectation of a CBOR encoding for 
> future work, there is an open discussion point about using the JWS/COSE 
> signing methods; if not JWT/CWT. There was brief discussion of this at IETF98 
> and one person indicated they liked PKCS7, others indicates JWT and others 
> did not speak up. Fully meeting minutes might provide more information but my 
> recollection was that we’d move the discussion to the list. This thread is 
> for that discussion. 
> 
> The current text of draft-ietf-anima-voucher-02 is:
> 
>> The voucher is signed a PKCS#7 SignedData structure, as specified by Section 
>> 9.1
>> of [RFC2315], encoded using ASN.1 distinguished encoding rules (DER), as 
>> specified in ITU-T X.690.
> 
> 
> For concrete discussion, the proposed change is:
> 
>> The voucher is a JWT [RFC7519] signed token.
> 
> 
> I’ve updated my tooling that was used during the IETF98 hackathon to support 
> a JWT token format; I did this as homework to be informed for the discussion. 
> 
> MY POSITION: is that I appreciate the simplicity of the JWS signing and feel 
> it is a good match for us. It was easy enough to implement, was a refreshing 
> change from the ASN1 complexity of PKCS7, and seems to provide a good path 
> toward CBOR/COSE in a future document without maintaining PKCS7/CMS technical 
> debt or revisiting/rewriting too much. 
> 
> QUESTION FOR THE WORKING GROUP: What is your position? Why? 
> 
> What follows is a dump of the raw JWS before signing (the equivalent 
> PKCS7/CMS structure would be the SignedData asn1 structures which is hard to 
> capture). After that is an encoded and signed voucher. Further below is an 
> example of a PKCS7 signed voucher. 
> 
> Please note these characteristics:
> 
> a) From JWT RFC7519 "JWTs are always represented using the JWS Compact 
> Serialization”. There are some JWT headers that overlap with voucher fields. 
> I’m using JWT here; but the distinction between JWS/JWT is not fundamental to 
> our discussion. The important point is JWS vs PKCS7. 
> 
> b) I’ve added the x5c header to the JWS.

[Anima] max is traveling overseas this week

[Max Pritikin (pritikin)]

I most likely will be missing the bootstrapping discussion this week. I’ll try 
to join as possible.

I should be on email and hope to push some git updates.

My apologies if I can’t join. I will check the etherpad for notes or hope to 
see something posted to the list,

- max 
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] dealing with multiple manufacturer services with a single certificate extension

[Max Pritikin (pritikin)]

I’ve been agitating for a combined form. My thanks to Eliot for continuing the 
conversation. Below I provide some details from the current BRSKI draft to 
flesh out the conversation and then present an argument for my position.

On Apr 23, 2017, at 5:23 AM, Eliot Lear mailto:l...@cisco.com>> 
wrote:

Hi everyone,

Just a quick update on this document.  I am preparing for the next version of 
the draft.  There is one major change contemplated that is not yet addressed.

I received feedback from the IETF Chicago meeting regarding how best to 
structure URLs in manufacturer certificates.  There are currently two planned, 
one for MUD and one for ANIMA/BRSKI.  The question is whether these should be 
combined.

I had said in Chicago that I would ask various manufacturers about whether 
additional complexity on the backend is worth saving the bytes in the 
certificate.  There was, as you might imagine, a mixed response.  A number of 
manufacturers answered, “No, and in fact we want to do our own certificate 
extensions”.  Others simply answered “No, the code requirements for ANIMA will 
probably make the cert extension a relatively minimal matter”.  And some 
manufacturers, said, “yes, every byte counts.”  I am proceeding in a way that 
accommodates the 3rd group for now, but I seek discussion.

If we combine the URLs the way it would work is that there would be a service 
endpoint along the lines of the following:

  *   https://example.com/.well-known/mfg/modelname

Given that the .well-known concept is already well defined the approach taken 
in the BRSKI draft (s2.3) is to include only the “manufacturer” authority:
https://example.com

From here the relying party can use the .well-known constructs to access any 
variety of manufacturer services which I expect to include
https://example.com/.well-known/brksi
https://example.com/.well-known/mud
etc

This minimizes the information stored within the certificate itself. A single 
extension indicating the “manufacturer services authority”. Building a full URL 
to these services is done using the .well-known method.

At that point, we would need to deference, introducing some additional 
complexity somewhere in the system.  We should be mindful of the following 
issue:

  1.  Versioning should be supported OUTSIDE of the referenced service.  The 
more that is done, the more freedom the referenced service has the ability to 
change.
  2.  Versioning of services should not be done in lock step.  That is, if we 
keep the versioning information in the URL, that means that when the MUD 
version is bumped, so too would the ANIMA version.  It is possible to keep a 
registry that would indicate URL versioning and then map to all the different 
versions of whatever is referenced, but that seems ridiculously complex.
  3.  The resolution mechanism to services should be independent of how the URL 
is gotten by the various {MUD/ANIMA/...} controllers.  And thus, if a MUD 
controller receives the URL via LLDP or DHCP, the same processing should occur 
as if it was received via a certificate.  This simplifies code paths, and will 
hence reduce risk of bugs.  It will also follow the principle of least 
astonishment.

It seems to me the simplest way to handle this sort of thing is to create a 
table that MUD/ANIMA controllers simply download when they see the URL.  It 
might look something like this:

{
   "mfg-services" : [
 "mud", "v1", 
"https://mud.example.com/Frobmaster3000.json";,
 "anima", "v1", 
"https://masa.example.com/masa-service";
   ]
}


Using a .well-known to query a host about which possible interfaces are 
available has precedent. For an alternative example also see,
https://tools.ietf.org/html/rfc6415
"The client obtains the host-meta document for a given host by sending

an HTTP [RFC2616] or an HTTPS 
[RFC2818] GET request to the host for
the "/.well-known/host-meta” path […]”


I see this as an optional redirection that MUD or BRSKI or future protocols 
might define but don’t see it as a necessary part of the manufacturing 
certificate extension definition. I’d think we could stop at an extension to 
provide the root authority to form .well-known URLs. Simpler, smaller, and just 
as flexible.

As a side note using this approach imposes a difficulty on MUD: the model and 
serial number information need to be carried elsewhere and normatively defined 
- MUD can no longer depend on a distinct URL for each class of device. So while 
I see this as an improvement for IETF as a whole it is problematic for MUD 
itself and I appreciate the willingness of the MUD authors to discuss it.

- max



This sort of change would be required in both the ANIMA and MUD services, but 
could then be used for any other manufacturer-based service.  Is this what 
people want?  For MUD, this amounts to a 

Re: [Anima] [Anima-bootstrap] Voucher signing method

[Max Pritikin (pritikin)]

Kent, 

> On Apr 21, 2017, at 4:51 PM, Max Pritikin (pritikin)  
> wrote:
> 
>> 
>> On Apr 21, 2017, at 1:50 PM, Kent Watsen  wrote:
>> 
>> Hi Max,
>> 
>> I think what you're trying to say is that the x5c header is not under
>> the signature and therefore can be added after the fact using any text-
>> editing tool. Is that right?
> 
> No, "In the JWS Compact Serialization, no JWS Unprotected Header is used” 
> [RFC7515]. Therefore everything in the header is under the signature. 
> Here is the specification:
>   https://tools.ietf.org/html/rfc7515#section-5.1
> 
>   5.  Compute the JWS Signature in the manner defined for the
>   particular algorithm being used over the JWS Signing Input
>   ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||
>   BASE64URL(JWS Payload)).  The "alg" (algorithm) Header Parameter
>   MUST be present in the JOSE Header, with the algorithm value
>   accurately representing the algorithm used to construct the JWS
>   Signature.
> 
> So for the original example down below the “JWS Protected Header” is:
> 
> {
> "typ": "JWT",
> "alg": "ES256",
> "x5c": 
> ["MIIBdjCCAR2gAwIBAgIBATAKBggqhkjOPQQDAjArMRYwFAYDVQQKDA1DaXNjbyBTeXN0ZW1zMREwDwYDVQQDDAhWZW5kb3JDQTAeFw0xNzA0MDMxNTE1NDVaFw0xODA0MDMxNTE1NDVaMC0xFjAUBgNVBAoMDUNpc2NvIFN5c3RlbXMxEzARBgNVBAMMClZlbmRvck1BU0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAT9GTrDd0GWgwcuSy8LCn0waMeknpLznajZzqWlLhrPwshgIPIPvbyY6IyCo4uBYU/e4OO6TQD9UVLlyU5R6cA6ozAwLjALBgNVHQ8EBAMCBaAwHwYDVR0jBBgwFoAUR4oEpb4YFuelkMrQjlnKtM01ovEwCgYIKoZIzj0EAwIDRwAwRAIgAQ8YR2IdLodEE8k+JxpBOIAGuzCeT9BmFOVhFUb8eJMCIC23Goss6manRjNSmh6+2oB9tsRbjmnnwuMlDXR8fzug",
>  
> "MIIBnTCCAUOgAwIBAgIJAK9Pd5G+/r0UMAoGCCqGSM49BAMCMCsxFjAUBgNVBAoMDUNpc2NvIFN5c3RlbXMxETAPBgNVBAMMCFZlbmRvckNBMB4XDTE3MDQwMzE0MTAwNVoXDTE4MDQwMzE0MTAwNVowKzEWMBQGA1UECgwNQ2lzY28gU3lzdGVtczERMA8GA1UEAwwIVmVuZG9yQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASunsQL2PVOSFWWp0oCjlqF8iVPPpEgJct931CZQ6assp07otmfgZqXsk1JYRTlKCGjROxrAiVRQsB54ioA0yu0o1AwTjAdBgNVHQ4EFgQUR4oEpb4YFuelkMrQjlnKtM01ovEwHwYDVR0jBBgwFoAUR4oEpb4YFuelkMrQjlnKtM01ovEwDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQDAgNIADBFAiEA+SSOhiNQ23RWA76kZ/2u70FCpU8OsU7X9IRiWGDgIAgCIFLu8FnJuqPx10sgHvIzqI5BgOcwCa5vFQZdCDBHIx18"]
> }
> 
> What I mean is that the full header, and the x5c entry, are all simple JSON 
> structures that we already know how to deal with if we were able to build the 
> JSON in the first place. The diffs I pointed to were because I made the 
> mistake of thinking a JWT library would be needed… but then this limited 
> abstraction of the library got in my way. Now that I know better i’ll avoid 
> the extra abstraction layer (those just cause trouble).
> 
>> Actually, for that matter, I imagine that the entire thing could be 
>> constructed without the use of a JWT library - simple openssl/shell
>> script may work? - what do you think?  
> 
> Yup! That was my long winded point! :)
> 
>> For instance, here's a script for base64url:
>> https://raw.githubusercontent.com/Moodstocks/moodstocks-api-clients/master/bash/base64url.sh
> 
> That script would base64 encode the header json, then the payload json, put 
> them together with a “.” between them before calling a simple “sign 
> operation” of the appropriate type. In my example below I used ES256 which is 
> defined in here: 
>   https://tools.ietf.org/html/rfc7518#section-3.4
> 
> I can see how this is done using the openssl API but I don’t know if there is 
> a CLI tool to perform this operation. A quick google search shows folks doing 
> this:
>   echo -n “${BASE64HEADER_DOT_BASE64PAYLOAD}" | openssl dgst -binary 
> -sha256 -sign “${PRIVATE_KEY}"
> Which works ok. If you use “-hmac” and a password you get something you can 
> verify on https://jwt.io but we’ll want to stick with ES256 I’m sure. 
> 
> Interestingly my example token is failing my local attempt to use ”openssl 
> dgst” to verify it. So I’ve probably got something to fix. Now that I see how 
> to do testing using openssl like this I can have my own little hackathon. ;) 

Ah. If you look at dgst.c from your openssl distribution you’ll see its just 
doing:
EVP_DigestSignFinal(ctx, buf, &len)) 
then dumping the resulting signature. The format of this is a ASN1 encoding of 
the r and s values that are the actual signature.

You can see this by exploding the output from openssl dgst via asn1parse: 
pritikin@ubuntu:~/tmp/jwt$ openssl asn1parse -in signature.sign -inform DER
0:d=0  hl=2 l=  69 cons: SEQUENCE  
2:d=1  hl=2 l=  32 prim: INTEGER   
:1EF9060ADA81C288C4FE2E3585BFF6379FF03467EB0D7D848D568604A1C53864
   36:d=1  hl=2 l=  33 prim: INTE

Re: [Anima] [Anima-bootstrap] Voucher signing method

[Max Pritikin (pritikin)]

> On Apr 21, 2017, at 1:50 PM, Kent Watsen  wrote:
> 
> Hi Max,
> 
> I think what you're trying to say is that the x5c header is not under
> the signature and therefore can be added after the fact using any text-
> editing tool. Is that right?

No, "In the JWS Compact Serialization, no JWS Unprotected Header is used” 
[RFC7515]. Therefore everything in the header is under the signature. 
Here is the specification:
https://tools.ietf.org/html/rfc7515#section-5.1

   5.  Compute the JWS Signature in the manner defined for the
   particular algorithm being used over the JWS Signing Input
   ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||
   BASE64URL(JWS Payload)).  The "alg" (algorithm) Header Parameter
   MUST be present in the JOSE Header, with the algorithm value
   accurately representing the algorithm used to construct the JWS
   Signature.

So for the original example down below the “JWS Protected Header” is:

{
"typ": "JWT",
"alg": "ES256",
"x5c": 
["MIIBdjCCAR2gAwIBAgIBATAKBggqhkjOPQQDAjArMRYwFAYDVQQKDA1DaXNjbyBTeXN0ZW1zMREwDwYDVQQDDAhWZW5kb3JDQTAeFw0xNzA0MDMxNTE1NDVaFw0xODA0MDMxNTE1NDVaMC0xFjAUBgNVBAoMDUNpc2NvIFN5c3RlbXMxEzARBgNVBAMMClZlbmRvck1BU0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAT9GTrDd0GWgwcuSy8LCn0waMeknpLznajZzqWlLhrPwshgIPIPvbyY6IyCo4uBYU/e4OO6TQD9UVLlyU5R6cA6ozAwLjALBgNVHQ8EBAMCBaAwHwYDVR0jBBgwFoAUR4oEpb4YFuelkMrQjlnKtM01ovEwCgYIKoZIzj0EAwIDRwAwRAIgAQ8YR2IdLodEE8k+JxpBOIAGuzCeT9BmFOVhFUb8eJMCIC23Goss6manRjNSmh6+2oB9tsRbjmnnwuMlDXR8fzug",
 
"MIIBnTCCAUOgAwIBAgIJAK9Pd5G+/r0UMAoGCCqGSM49BAMCMCsxFjAUBgNVBAoMDUNpc2NvIFN5c3RlbXMxETAPBgNVBAMMCFZlbmRvckNBMB4XDTE3MDQwMzE0MTAwNVoXDTE4MDQwMzE0MTAwNVowKzEWMBQGA1UECgwNQ2lzY28gU3lzdGVtczERMA8GA1UEAwwIVmVuZG9yQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASunsQL2PVOSFWWp0oCjlqF8iVPPpEgJct931CZQ6assp07otmfgZqXsk1JYRTlKCGjROxrAiVRQsB54ioA0yu0o1AwTjAdBgNVHQ4EFgQUR4oEpb4YFuelkMrQjlnKtM01ovEwHwYDVR0jBBgwFoAUR4oEpb4YFuelkMrQjlnKtM01ovEwDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQDAgNIADBFAiEA+SSOhiNQ23RWA76kZ/2u70FCpU8OsU7X9IRiWGDgIAgCIFLu8FnJuqPx10sgHvIzqI5BgOcwCa5vFQZdCDBHIx18"]
}

What I mean is that the full header, and the x5c entry, are all simple JSON 
structures that we already know how to deal with if we were able to build the 
JSON in the first place. The diffs I pointed to were because I made the mistake 
of thinking a JWT library would be needed… but then this limited abstraction of 
the library got in my way. Now that I know better i’ll avoid the extra 
abstraction layer (those just cause trouble).

> Actually, for that matter, I imagine that the entire thing could be 
> constructed without the use of a JWT library - simple openssl/shell
> script may work? - what do you think?  

Yup! That was my long winded point! :)

> For instance, here's a script for base64url:
> https://raw.githubusercontent.com/Moodstocks/moodstocks-api-clients/master/bash/base64url.sh

That script would base64 encode the header json, then the payload json, put 
them together with a “.” between them before calling a simple “sign operation” 
of the appropriate type. In my example below I used ES256 which is defined in 
here: 
https://tools.ietf.org/html/rfc7518#section-3.4

I can see how this is done using the openssl API but I don’t know if there is a 
CLI tool to perform this operation. A quick google search shows folks doing 
this:
echo -n “${BASE64HEADER_DOT_BASE64PAYLOAD}" | openssl dgst -binary 
-sha256 -sign “${PRIVATE_KEY}"
Which works ok. If you use “-hmac” and a password you get something you can 
verify on https://jwt.io but we’ll want to stick with ES256 I’m sure. 

Interestingly my example token is failing my local attempt to use ”openssl 
dgst” to verify it. So I’ve probably got something to fix. Now that I see how 
to do testing using openssl like this I can have my own little hackathon. ;) 

- max

> 
> K.
> 
> -ORIGINAL MESSAGE-
> 
> Kent, 
> 
>> On Apr 20, 2017, at 6:55 PM, Max Pritikin (pritikin)  
>> wrote:
>> 
>>> 
>>> On Apr 20, 2017, at 6:51 PM, Kent Watsen  wrote:
>>> 
>>> 
>>> Hi Max,
>>> 
>>> I'd like to reproduce your experiment, but I can't find a library
>>> that supports the 'x5c' header.  What do you mean that you added
>>> it (the x5c header) to the JWS?
>> 
>> 
>> The x5c header is defined in JWT but the library I used off github (libjwt) 
>> didn’t support it. After looking at the code more closely I’m not sure a jwt 
>> abstraction layer is really even needed; JWS is pretty simple to use 
>> directly. I’ve forked libjwt and will upload my diff to github tomorrow so 
>> you can see what i mean.
> 
> Here is a diff that shows what I mean:
>   
> https://gith

Re: [Anima] [Anima-bootstrap] Voucher signing method

[Max Pritikin (pritikin)]

Kent, 

> On Apr 20, 2017, at 6:55 PM, Max Pritikin (pritikin)  
> wrote:
> 
>> 
>> On Apr 20, 2017, at 6:51 PM, Kent Watsen  wrote:
>> 
>> 
>> Hi Max,
>> 
>> I'd like to reproduce your experiment, but I can't find a library
>> that supports the 'x5c' header.  What do you mean that you added
>> it (the x5c header) to the JWS?
> 
> 
> The x5c header is defined in JWT but the library I used off github (libjwt) 
> didn’t support it. After looking at the code more closely I’m not sure a jwt 
> abstraction layer is really even needed; JWS is pretty simple to use 
> directly. I’ve forked libjwt and will upload my diff to github tomorrow so 
> you can see what i mean.

Here is a diff that shows what I mean:

https://github.com/pritikin/libjwt/commit/da7b8b9b59c26f4af6edefaeafb34ffc1f207cca

In summary: JWS defines a {header}.{payload}.signature method. You don’t really 
need a JWT library to do that. I was new to the space and wanted a quick ramp 
up so I used the libjwt library to experiment and found that it hardcoded the 
{header} information and thus couldn’t support the x5c header we were 
discussing. With normal, simple, JWS via a JSON library, you’d just add this 
element like any other normal JSON but because I was using a jwt abstraction I 
had to update the library’s abstraction layer to support arbitrary JSON 
additions to the header. 

- max

> 
>> 
>> Separately, I don't think "-BEGIN CERTIFICATE-" is valid
>> for the 'domain-cert-trusted-ca' field, for which the YANG in 
>> the voucher-02 draft says is a "binary" type field called 
>> 'trusted-ca-certificate'.  If it's type binary, then it's 
>> encoded as just the base64 of the DER, with no PEM header/footer
>> ceremony. See here:
>> 
>> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-10#section-6.6.
> 
> Totally true. This was discovered at the hackathon too … I just didn’t fix it 
> before looking at the JWT stuff.
> 
> - max
> 
> 
>> 
>> Kent
>> 
>> 
>> -ORIGINAL MESSAGE-
>> 
>> Folks, in Chicago we discussed the signing method for vouchers. 
>> 
>> Because the voucher is JSON, and there is expectation of a CBOR encoding for 
>> future work, there is an open discussion point about using the JWS/COSE 
>> signing methods; if not JWT/CWT. There was brief discussion of this at 
>> IETF98 and one person indicated they liked PKCS7, others indicates JWT and 
>> others did not speak up. Fully meeting minutes might provide more 
>> information but my recollection was that we’d move the discussion to the 
>> list. This thread is for that discussion. 
>> 
>> The current text of draft-ietf-anima-voucher-02 is:
>> 
>>> The voucher is signed a PKCS#7 SignedData structure, as specified by 
>>> Section 9.1
>>> of [RFC2315], encoded using ASN.1 distinguished encoding rules (DER), as 
>>> specified in ITU-T X.690.
>> 
>> 
>> For concrete discussion, the proposed change is:
>> 
>>> The voucher is a JWT [RFC7519] signed token.
>> 
>> 
>> I’ve updated my tooling that was used during the IETF98 hackathon to support 
>> a JWT token format; I did this as homework to be informed for the 
>> discussion. 
>> 
>> MY POSITION: is that I appreciate the simplicity of the JWS signing and feel 
>> it is a good match for us. It was easy enough to implement, was a refreshing 
>> change from the ASN1 complexity of PKCS7, and seems to provide a good path 
>> toward CBOR/COSE in a future document without maintaining PKCS7/CMS 
>> technical debt or revisiting/rewriting too much. 
>> 
>> QUESTION FOR THE WORKING GROUP: What is your position? Why? 
>> 
>> What follows is a dump of the raw JWS before signing (the equivalent 
>> PKCS7/CMS structure would be the SignedData asn1 structures which is hard to 
>> capture). After that is an encoded and signed voucher. Further below is an 
>> example of a PKCS7 signed voucher. 
>> 
>> Please note these characteristics:
>> 
>> a) From JWT RFC7519 "JWTs are always represented using the JWS Compact 
>> Serialization”. There are some JWT headers that overlap with voucher fields. 
>> I’m using JWT here; but the distinction between JWS/JWT is not fundamental 
>> to our discussion. The important point is JWS vs PKCS7. 
>> 
>> b) I’ve added the x5c header to the JWS. This is used to carry the 
>> certificate chain of the signer. Our current voucher format indicates PKCS7 
>> which supports an equivalent field called “CertificateSet

Re: [Anima] [Anima-bootstrap] Voucher signing method

[Max Pritikin (pritikin)]

> On Apr 20, 2017, at 6:51 PM, Kent Watsen  wrote:
> 
> 
> Hi Max,
> 
> I'd like to reproduce your experiment, but I can't find a library
> that supports the 'x5c' header.  What do you mean that you added
> it (the x5c header) to the JWS?


The x5c header is defined in JWT but the library I used off github (libjwt) 
didn’t support it. After looking at the code more closely I’m not sure a jwt 
abstraction layer is really even needed; JWS is pretty simple to use directly. 
I’ve forked libjwt and will upload my diff to github tomorrow so you can see 
what i mean.

> 
> Separately, I don't think "-BEGIN CERTIFICATE-" is valid
> for the 'domain-cert-trusted-ca' field, for which the YANG in 
> the voucher-02 draft says is a "binary" type field called 
> 'trusted-ca-certificate'.  If it's type binary, then it's 
> encoded as just the base64 of the DER, with no PEM header/footer
> ceremony. See here:
> 
> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-10#section-6.6.

Totally true. This was discovered at the hackathon too … I just didn’t fix it 
before looking at the JWT stuff.

- max


> 
> Kent
> 
> 
> -ORIGINAL MESSAGE-
> 
> Folks, in Chicago we discussed the signing method for vouchers. 
> 
> Because the voucher is JSON, and there is expectation of a CBOR encoding for 
> future work, there is an open discussion point about using the JWS/COSE 
> signing methods; if not JWT/CWT. There was brief discussion of this at IETF98 
> and one person indicated they liked PKCS7, others indicates JWT and others 
> did not speak up. Fully meeting minutes might provide more information but my 
> recollection was that we’d move the discussion to the list. This thread is 
> for that discussion. 
> 
> The current text of draft-ietf-anima-voucher-02 is:
> 
>> The voucher is signed a PKCS#7 SignedData structure, as specified by Section 
>> 9.1
>> of [RFC2315], encoded using ASN.1 distinguished encoding rules (DER), as 
>> specified in ITU-T X.690.
> 
> 
> For concrete discussion, the proposed change is:
> 
>> The voucher is a JWT [RFC7519] signed token.
> 
> 
> I’ve updated my tooling that was used during the IETF98 hackathon to support 
> a JWT token format; I did this as homework to be informed for the discussion. 
> 
> MY POSITION: is that I appreciate the simplicity of the JWS signing and feel 
> it is a good match for us. It was easy enough to implement, was a refreshing 
> change from the ASN1 complexity of PKCS7, and seems to provide a good path 
> toward CBOR/COSE in a future document without maintaining PKCS7/CMS technical 
> debt or revisiting/rewriting too much. 
> 
> QUESTION FOR THE WORKING GROUP: What is your position? Why? 
> 
> What follows is a dump of the raw JWS before signing (the equivalent 
> PKCS7/CMS structure would be the SignedData asn1 structures which is hard to 
> capture). After that is an encoded and signed voucher. Further below is an 
> example of a PKCS7 signed voucher. 
> 
> Please note these characteristics:
> 
> a) From JWT RFC7519 "JWTs are always represented using the JWS Compact 
> Serialization”. There are some JWT headers that overlap with voucher fields. 
> I’m using JWT here; but the distinction between JWS/JWT is not fundamental to 
> our discussion. The important point is JWS vs PKCS7. 
> 
> b) I’ve added the x5c header to the JWS. This is used to carry the 
> certificate chain of the signer. Our current voucher format indicates PKCS7 
> which supports an equivalent field called “CertificateSet structure”. Its in 
> the BRSKI document that we specify "The entire certificate chain, up to and 
> including the Domain CA, MUST be included in the CertificateSet structure”. 
> With the transition to JWT we’d be specifying that the x5c header be fully 
> populated up to an including the Domain CA etc. 
> 
> c) From these examples we can’t directly compare size encodings. I don’t 
> think this is a significant aspect of the conversation but can create 
> comparable examples if folks feel that is necessary. 
> 
> The dumps:
> 
> A debug dump of the JWT form before encoding:
> {
>   "typ": "JWT",
>   "alg": "ES256",
>   "x5c": 
> ["MIIBdjCCAR2gAwIBAgIBATAKBggqhkjOPQQDAjArMRYwFAYDVQQKDA1DaXNjbyBTeXN0ZW1zMREwDwYDVQQDDAhWZW5kb3JDQTAeFw0xNzA0MDMxNTE1NDVaFw0xODA0MDMxNTE1NDVaMC0xFjAUBgNVBAoMDUNpc2NvIFN5c3RlbXMxEzARBgNVBAMMClZlbmRvck1BU0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAT9GTrDd0GWgwcuSy8LCn0waMeknpLznajZzqWlLhrPwshgIPIPvbyY6IyCo4uBYU/e4OO6TQD9UVLlyU5R6cA6ozAwLjALBgNVHQ8EBAMCBaAwHwYDVR0jBBgwFoAUR4oEpb4YFuelkMrQjlnKtM01ovEwCgYIKoZIzj0EAwIDRwAwRAIgAQ8YR2IdLodEE8k+JxpBOIAGuzCeT9BmFOVhFUb8eJMCIC23Goss6manRjNSmh6+2oB9tsRbjmnnwuMlDXR8fzug",
>  
> "MIIBnTCCAUOgAwIBAgIJAK9Pd5G+/r0UMAoGCCqGSM49BAMCMCsxFjAUBgNVBAoMDUNpc2NvIFN5c3RlbXMxETAPBgNVBAMMCFZlbmRvckNBMB4XDTE3MDQwMzE0MTAwNVoXDTE4MDQwMzE0MTAwNVowKzEWMBQGA1UECgwNQ2lzY28gU3lzdGVtczERMA8GA1UEAwwIVmVuZG9yQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASunsQL2PVOSFWWp0oCjlqF8iVPPpEgJct931CZQ6assp07otmfgZqXsk1JYRTlKCGjROxrAiVRQsB54ioA0yu0o1AwTjAd

Re: [Anima] new issue in voucher github

[Max Pritikin (pritikin)]

So long as there is close alignment I’m not stuck on a particular approach.
I do want them both defined in the voucher doc so that BRSKI can reference them 
similarly.
There are some fields of the current voucher that apply to one aspect or the 
other (or both). I don’t know how ‘grouping’ addresses that but am happy to 
learn.

- max

On Apr 20, 2017, at 10:29 AM, Kent Watsen 
mailto:kwat...@juniper.net>> wrote:


I don't think that the voucher should also be a voucher request.  There should 
be another
artifact defined for a voucher request, if needed.  YANG 'grouping' statements 
can be used
to ensure syntactic alignment between the two artifacts.

K.

On 4/19/17, 8:13 PM, "Max Pritikin (pritikin)" 
mailto:priti...@cisco.com>> wrote:


FYI - added the below to capture it but not distract myself from current 
‘concise’ branch work. As per the recommendations I’m informing the list as 
well. I’ll circle back to this

- max


https://github.com/anima-wg/voucher/issues/3

There is some inconsistencies in the existing text that need to be resolved 
(see below). Additionally if a "voucher" can also be a "voucher request" then 
the requester can't necessarily populate all the fields. These related issues 
need to be dealt with.

leaf nonce {
type binary {
length "8..32";
}
must "not(../expires-on)";
description
"A value that can be used by a pledge in some bootstrapping
protocols to enable anti-replay protection. This node is
optional because it is not used by all bootstrapping
protocols.

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] new issue in voucher github

[Max Pritikin (pritikin)]

FYI - added the below to capture it but not distract myself from current 
‘concise’ branch work. As per the recommendations I’m informing the list as 
well. I’ll circle back to this

- max


https://github.com/anima-wg/voucher/issues/3

There is some inconsistencies in the existing text that need to be resolved 
(see below). Additionally if a "voucher" can also be a "voucher request" then 
the requester can't necessarily populate all the fields. These related issues 
need to be dealt with.

leaf nonce {
type binary {
length "8..32";
}
must "not(../expires-on)";
description
"A value that can be used by a pledge in some bootstrapping
protocols to enable anti-replay protection. This node is
optional because it is not used by all bootstrapping
protocols.
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [Anima-bootstrap] Voucher signing method

[Max Pritikin (pritikin)]

> On Apr 19, 2017, at 3:59 PM, Kent Watsen  wrote:
> 
> 
>> I think Peter’s point is that moving to JWT for the voucher signature
>> but depending on PKCS#7 in the /cacerts exchange results in client’s
>> being required to handle both formats.
> 
> This is one of my issues, when thinking about the NETCONF zerotouch
> bootstrapping draft, as all the other structures in the are ASN.1,
> and no one has expressed interest in tiny encodings yet.  I'd prefer
> it if the voucher draft supported both encodings,

How would you do this? The voucher draft clearly indicates a specific encoding 
(e.g. PKCS#7 SignedData).
Would you suggest we enhance this to support either JWT or PKCS#7 (maybe CMS) 
and suggest protocols signal their preferred method? 

That would allow us to close the issue for the voucher document but I’m 
conflicted. I don’t want to introduce this as an option that lives with us for 
as long as vouchers are used. :( 

- max

> and then BRSKI and NETCONF zerotouch can cherry-pick their preferred encoding.
> 
> Kent
> 
> 
> -ORIGINAL MESSAGE-
> 
>> On Apr 19, 2017, at 2:24 PM, Panos Kampanakis (pkampana) 
>>  wrote:
>> 
>> About a), I don't think putting all the CA certs in the voucher is a good 
>> idea. EST should be used instead. I don’t think it is right for someone to 
>> expect the voucher to distribute its roots of trust. What if a CA cert gets 
>> revoked of expires? EST has the transitional certs that allow for root CA 
>> cert update, but I don't think we can expect someone to rerun BRSKI in order 
>> to get its new root of trust. 
>> 
>> The cert chain in the voucher should only enable the client to establish a 
>> trust relationship with the server. So, I think only one root cert for the 
>> domain should be carried in the voucher. The rest of the certs in the chain 
>> of the server cert should be sent by the server in the TLS negotiation. 
> 
> Yes, this captures the current draft’s position: The voucher provides 
> sufficient information to trust the registrar, the pledge communicates with 
> the registrar to obtain the rest of the PKI information. 
> 
>> About b), optimizing the cacerts response. The truth is that cacerts can 
>> grow a lot in size. The enroll response could also be big for constrained 
>> environments depending on algorithms used. Some thoughts have been proposed 
>> in pkix/tls in the past to shrink certs like caching and compression, but 
>> they have some disadvantages. DTLS also provides a fragmentation mechanism 
>> in the handshake to accommodate for large records (ca certs in this case). 
>> Thus optimizing the responses might not be necessary, or even easy for that 
>> matter. 
>> 
>> Let's say you still wanted to think about it. I don't think JWT or CBOR 
>> would add any shrinkage to an ASN.1 cert chain. Now if you are contemplating 
>> using a new free-form JSON certificate format (instead of CMS) and then 
>> using JWT or CBOR to secure and shrink it, I am not sure about size 
>> improvements. CMS' ASN.1 is not human friendly, but I would be interested if 
>> writing the cert fields in free-form JSON and encoding with CBOR/JWT would 
>> really lead to a shorter total size. In other words, I am not sure going 
>> beyond JSON vouchers/tokens when talking about new encodings (JWT, CBOR) is 
>> something we should tackle.
> 
> I think you’re touching on three issues we should keep them distinct:
> 1) How a bundle of PKIX certificate is distributed as in the EST /cacerts 
> message. This is what is being discussed.
> 2) out-of-scope: PKIX certificate format.
> 3) out-of-scope: Size of certificate chains and complexity of the PKI 
> hierarchy.
> 
> Lets focus on (1) for now.
> 
> Given that the payloads are full certificates (2 and 3) I don’t think its 
> going to benefit us to try and chose based on the pure size of the structure. 
> I didn’t even bother to ensure comparable structures when I started this 
> thread.
> 
> I think Peter’s point is that moving to JWT for the voucher signature but 
> depending on PKCS#7 in the /cacerts exchange results in client’s being 
> required to handle both formats. This is defensible based on the (lack of) 
> complexity in JWT and the relatively clean way BRSKI *only extends* EST but 
> isn’t optimal for clients. Ensuring that the client can use JWT all the way 
> through requires overloading that one EST call. That’s a more substantial 
> impact on EST but is implied by a transition to JWT. Its a really good point. 
> 
> Cheers, 
> 
> - max
> 
>> 
>> Rgs,
>> Panos
>> 
>> 
>> 
>> -Origin

Re: [Anima] [Anima-bootstrap] Voucher signing method

[Max Pritikin (pritikin)]

> On Apr 19, 2017, at 2:24 PM, Panos Kampanakis (pkampana)  
> wrote:
> 
> About a), I don't think putting all the CA certs in the voucher is a good 
> idea. EST should be used instead. I don’t think it is right for someone to 
> expect the voucher to distribute its roots of trust. What if a CA cert gets 
> revoked of expires? EST has the transitional certs that allow for root CA 
> cert update, but I don't think we can expect someone to rerun BRSKI in order 
> to get its new root of trust. 
> 
> The cert chain in the voucher should only enable the client to establish a 
> trust relationship with the server. So, I think only one root cert for the 
> domain should be carried in the voucher. The rest of the certs in the chain 
> of the server cert should be sent by the server in the TLS negotiation. 

Yes, this captures the current draft’s position: The voucher provides 
sufficient information to trust the registrar, the pledge communicates with the 
registrar to obtain the rest of the PKI information. 

> About b), optimizing the cacerts response. The truth is that cacerts can grow 
> a lot in size. The enroll response could also be big for constrained 
> environments depending on algorithms used. Some thoughts have been proposed 
> in pkix/tls in the past to shrink certs like caching and compression, but 
> they have some disadvantages. DTLS also provides a fragmentation mechanism in 
> the handshake to accommodate for large records (ca certs in this case). Thus 
> optimizing the responses might not be necessary, or even easy for that 
> matter. 
> 
> Let's say you still wanted to think about it. I don't think JWT or CBOR would 
> add any shrinkage to an ASN.1 cert chain. Now if you are contemplating using 
> a new free-form JSON certificate format (instead of CMS) and then using JWT 
> or CBOR to secure and shrink it, I am not sure about size improvements. CMS' 
> ASN.1 is not human friendly, but I would be interested if writing the cert 
> fields in free-form JSON and encoding with CBOR/JWT would really lead to a 
> shorter total size. In other words, I am not sure going beyond JSON 
> vouchers/tokens when talking about new encodings (JWT, CBOR) is something we 
> should tackle.

I think you’re touching on three issues we should keep them distinct:
1) How a bundle of PKIX certificate is distributed as in the EST /cacerts 
message. This is what is being discussed.
2) out-of-scope: PKIX certificate format.
3) out-of-scope: Size of certificate chains and complexity of the PKI hierarchy.

Lets focus on (1) for now.

Given that the payloads are full certificates (2 and 3) I don’t think its going 
to benefit us to try and chose based on the pure size of the structure. I 
didn’t even bother to ensure comparable structures when I started this thread.

I think Peter’s point is that moving to JWT for the voucher signature but 
depending on PKCS#7 in the /cacerts exchange results in client’s being required 
to handle both formats. This is defensible based on the (lack of) complexity in 
JWT and the relatively clean way BRSKI *only extends* EST but isn’t optimal for 
clients. Ensuring that the client can use JWT all the way through requires 
overloading that one EST call. That’s a more substantial impact on EST but is 
implied by a transition to JWT. Its a really good point. 

Cheers, 

- max

> 
> Rgs,
> Panos
> 
> 
> 
> -Original Message-
> From: Anima-bootstrap [mailto:anima-bootstrap-boun...@ietf.org] On Behalf Of 
> Max Pritikin (pritikin)
> Sent: Wednesday, April 19, 2017 2:45 PM
> To: consulta...@vanderstok.org
> Cc: anima-bootst...@ietf.org; anima@ietf.org
> Subject: Re: [Anima-bootstrap] Voucher signing method
> 
> 
>> On Apr 19, 2017, at 1:01 AM, peter van der Stok  wrote:
>> 
>> Hi Max,
>> 
>> thanks for the examples.
>> During IETF98, I was the one to speak up in favour of #pkcs7;
> 
> I thought so but wasn’t sure and the minutes didn’t appear to be available. 
> 
>> One reason only: It is transported by EST that is used by BRSKI.
>> All the code is already present.
> 
> Yes: Enrollment over Secure Transport (EST) is *not* intended to be a new 
> enrollment protocol (instead it focused on clarifying how simple CMC messages 
> could be used when a secure transport is available). As such the /cacerts 
> response is a CMC subset "PKCS#7 "certs-only” response”. 
> 
> That is a really heavy structure to deliver what is essentially, but not 
> exactly, the JWT x5c certificate chain. :(
> 
>> Doing JWS/COSE or JWT/CWT needs additional code.
>> I am sensitive to the payload size argument though.
>> 
>> But, suppose the JWS or JWT is adopted to reduce the payload, where 
>> will the optimizations stop?
>> Will

Re: [Anima] [Anima-bootstrap] Voucher signing method

[Max Pritikin (pritikin)]

> On Apr 19, 2017, at 1:01 AM, peter van der Stok  wrote:
> 
> Hi Max,
> 
> thanks for the examples.
> During IETF98, I was the one to speak up in favour of #pkcs7;

I thought so but wasn’t sure and the minutes didn’t appear to be available. 

> One reason only: It is transported by EST that is used by BRSKI.
> All the code is already present.

Yes: Enrollment over Secure Transport (EST) is *not* intended to be a new 
enrollment protocol (instead it focused on clarifying how simple CMC messages 
could be used when a secure transport is available). As such the /cacerts 
response is a CMC subset "PKCS#7 "certs-only” response”. 

That is a really heavy structure to deliver what is essentially, but not 
exactly, the JWT x5c certificate chain. :(

> Doing JWS/COSE or JWT/CWT needs additional code.
> I am sensitive to the payload size argument though.
> 
> But, suppose the JWS or JWT is adopted to reduce the payload,
> where will the optimizations stop?
> Will you envisage to optimize the EST payloads as well?

The EST discussion in the -06 concise draft is introduced as: "describes EST 
extensions necessary to enable fully automated bootstrapping”. It adds a couple 
of telemetry (success/fail messages) and mandates a few options that were 
defined in EST but has so far avoided redefining any EST messages. 

Thoughts: 

a) The voucher currently contains the x5c header necessary to deliver the CA 
certificate to move the existing TLS connection out of the provisional state — 
but this is not mandated to be the entire /cacerts chain. The client is 
instructed that:
the domainCAcert is not a complete distribution of the EST 
section 4.1.3 CA Certificate Response.
and
The Pledge MUST request the full EST Distribution of CA Certificates
message.  See RFC7030, section 4.1.
One approach is to ensure the voucher x5c header does contain everything 
necessary. This would allow a client that does not continue to use EST to have 
a full /cacerts equivalent response. Within BRSKI itself this would solve the 
discussion. 

We’re encroaching on redefining that header though (see RFC7515#section-4.1.6 
where it x5c is defined — its a chain directly to the root without any cross 
certifications). If we include PKI /cacerts into there we need to change that 
definition via a new header type so that we can cover the oldwithnew, 
newwithold etc stuff from PKI land.

b) Realistically any PKI client really “MUST” keep their ca certificates up to 
date. (BRSKI tries to frame this as optional to ensure a clean integration 
point for non-PKI type deployments). Therefore we could assume that /cacerts 
will be called and therefore embark on your point: an optimization of at least 
this EST payload. If we do take that path I’d lean toward a general purpose 
“discovery” document that details a bunch of information about the service 
including the x5c (or new form) header — thus making this a valuable addition 
and driving alignment toward the token concepts rather than just a new format. 
I’m worried about adding that but do see the value in that it allows a client 
to avoid any CMS/PKCS#7.

Boy, either approach is redefining a message form that almost defined in a 
prior protocol. A great topic to hear folks on this list comment on. 

- max

> 
> Cheerio,
> 
> Peter
> 
> 
> 
> Max Pritikin (pritikin) schreef op 2017-04-18 20:08:
>> Folks, in Chicago we discussed the signing method for vouchers.
>> Because the voucher is JSON, and there is expectation of a CBOR
>> encoding for future work, there is an open discussion point about
>> using the JWS/COSE signing methods; if not JWT/CWT. There was brief
>> discussion of this at IETF98 and one person indicated they liked
>> PKCS7, others indicates JWT and others did not speak up. Fully meeting
>> minutes might provide more information but my recollection was that
>> we’d move the discussion to the list. This thread is for that
>> discussion.
>> The current text of draft-ietf-anima-voucher-02 is:
>>> The voucher is signed a PKCS#7 SignedData structure, as specified by 
>>> Section 9.1
>>> of [RFC2315], encoded using ASN.1 distinguished encoding rules (DER), as 
>>> specified in ITU-T X.690.
>> For concrete discussion, the proposed change is:
>>> The voucher is a JWT [RFC7519] signed token.
>> I’ve updated my tooling that was used during the IETF98 hackathon to
>> support a JWT token format; I did this as homework to be informed for
>> the discussion.
>> MY POSITION: is that I appreciate the simplicity of the JWS signing
>> and feel it is a good match for us. It was easy enough to implement,
>> was a refreshing change from the ASN1 complexity of PKCS7, and seems
>> to provide a good path toward CBOR/COSE in a future document witho

[Anima] Voucher signing method

[Max Pritikin (pritikin)]

Folks, in Chicago we discussed the signing method for vouchers. 

Because the voucher is JSON, and there is expectation of a CBOR encoding for 
future work, there is an open discussion point about using the JWS/COSE signing 
methods; if not JWT/CWT. There was brief discussion of this at IETF98 and one 
person indicated they liked PKCS7, others indicates JWT and others did not 
speak up. Fully meeting minutes might provide more information but my 
recollection was that we’d move the discussion to the list. This thread is for 
that discussion. 

The current text of draft-ietf-anima-voucher-02 is:

> The voucher is signed a PKCS#7 SignedData structure, as specified by Section 
> 9.1
> of [RFC2315], encoded using ASN.1 distinguished encoding rules (DER), as 
> specified in ITU-T X.690.


For concrete discussion, the proposed change is:

> The voucher is a JWT [RFC7519] signed token.


I’ve updated my tooling that was used during the IETF98 hackathon to support a 
JWT token format; I did this as homework to be informed for the discussion. 

MY POSITION: is that I appreciate the simplicity of the JWS signing and feel it 
is a good match for us. It was easy enough to implement, was a refreshing 
change from the ASN1 complexity of PKCS7, and seems to provide a good path 
toward CBOR/COSE in a future document without maintaining PKCS7/CMS technical 
debt or revisiting/rewriting too much. 

QUESTION FOR THE WORKING GROUP: What is your position? Why? 

What follows is a dump of the raw JWS before signing (the equivalent PKCS7/CMS 
structure would be the SignedData asn1 structures which is hard to capture). 
After that is an encoded and signed voucher. Further below is an example of a 
PKCS7 signed voucher. 

Please note these characteristics:

a) From JWT RFC7519 "JWTs are always represented using the JWS Compact 
Serialization”. There are some JWT headers that overlap with voucher fields. 
I’m using JWT here; but the distinction between JWS/JWT is not fundamental to 
our discussion. The important point is JWS vs PKCS7. 

b) I’ve added the x5c header to the JWS. This is used to carry the certificate 
chain of the signer. Our current voucher format indicates PKCS7 which supports 
an equivalent field called “CertificateSet structure”. Its in the BRSKI 
document that we specify "The entire certificate chain, up to and including the 
Domain CA, MUST be included in the CertificateSet structure”. With the 
transition to JWT we’d be specifying that the x5c header be fully populated up 
to an including the Domain CA etc. 

c) From these examples we can’t directly compare size encodings. I don’t think 
this is a significant aspect of the conversation but can create comparable 
examples if folks feel that is necessary. 

The dumps:

A debug dump of the JWT form before encoding:
{
   "typ": "JWT",
   "alg": "ES256",
   "x5c": 
["MIIBdjCCAR2gAwIBAgIBATAKBggqhkjOPQQDAjArMRYwFAYDVQQKDA1DaXNjbyBTeXN0ZW1zMREwDwYDVQQDDAhWZW5kb3JDQTAeFw0xNzA0MDMxNTE1NDVaFw0xODA0MDMxNTE1NDVaMC0xFjAUBgNVBAoMDUNpc2NvIFN5c3RlbXMxEzARBgNVBAMMClZlbmRvck1BU0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAT9GTrDd0GWgwcuSy8LCn0waMeknpLznajZzqWlLhrPwshgIPIPvbyY6IyCo4uBYU/e4OO6TQD9UVLlyU5R6cA6ozAwLjALBgNVHQ8EBAMCBaAwHwYDVR0jBBgwFoAUR4oEpb4YFuelkMrQjlnKtM01ovEwCgYIKoZIzj0EAwIDRwAwRAIgAQ8YR2IdLodEE8k+JxpBOIAGuzCeT9BmFOVhFUb8eJMCIC23Goss6manRjNSmh6+2oB9tsRbjmnnwuMlDXR8fzug",
 
"MIIBnTCCAUOgAwIBAgIJAK9Pd5G+/r0UMAoGCCqGSM49BAMCMCsxFjAUBgNVBAoMDUNpc2NvIFN5c3RlbXMxETAPBgNVBAMMCFZlbmRvckNBMB4XDTE3MDQwMzE0MTAwNVoXDTE4MDQwMzE0MTAwNVowKzEWMBQGA1UECgwNQ2lzY28gU3lzdGVtczERMA8GA1UEAwwIVmVuZG9yQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASunsQL2PVOSFWWp0oCjlqF8iVPPpEgJct931CZQ6assp07otmfgZqXsk1JYRTlKCGjROxrAiVRQsB54ioA0yu0o1AwTjAdBgNVHQ4EFgQUR4oEpb4YFuelkMrQjlnKtM01ovEwHwYDVR0jBBgwFoAUR4oEpb4YFuelkMrQjlnKtM01ovEwDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQDAgNIADBFAiEA+SSOhiNQ23RWA76kZ/2u70FCpU8OsU7X9IRiWGDgIAgCIFLu8FnJuqPx10sgHvIzqI5BgOcwCa5vFQZdCDBHIx18"]
}
.
{
   "ietf-voucher:voucher": {
   "assertion": "logging",
   "domain-cert-trusted-ca": "-BEGIN 
CERTIFICATE-\nMIIBUjCB+qADAgECAgkAwP4qKsGyQlYwCgYIKoZIzj0EAwIwFzEVMBMGA1UEAwwM\nZXN0RXhhbXBsZUNBMB4XDTE3MDMyNTIyMTc1MFoXDTE4MDMyNTIyMTc1MFowFzEV\nMBMGA1UEAwwMZXN0RXhhbXBsZUNBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE\nRVrNlEN2ocYscAILBU7NggABo0JgA1rEGdYdCQj1nHKL6xKONJIUfBibe6iMVYd3\nRUmPwaPiHNZJ98kRwHIwnKMvMC0wDAYDVR0TBAUwAwEB/zAdBgNVHQ4EFgQU+dVX\naXoucU1godNF0bycS1U5W54wCgYIKoZIzj0EAwIDRwAwRAIgNsCGjpEjuvz6OKJ/\n3rOvMc2ZfDhD02K+0PCVFJGCQGwCIAzf3BS6x9kKSROJJvxDSpg0QK9+b9LSFkbZ\nM1PW98AN\n-END
 CERTIFICATE-\n",
   "nonce": "ea7102e8e88f119e",
   "serial-number": "PID:1 SN:widget1",
   "serial-number-issuer": "36097E3DEA39316EA4CE5C695BE905E78AF2FB5A",
   "version": "1"
   }
}
.
[signature goes here]

As per JWT RFC7519 this is what it looks like after URL-safe encoding. You can 
see that now the signature is included  (look to the second to last line to see 
the second “.” followed by a valid signature): 

eyJ0eXAiOiJKV1QiLC

Re: [Anima] Concise version of BRSKI

[Max Pritikin (pritikin)]

Peter,

The current text is wordy and repetitive and says things more than once . 
Primary focus is to remove repetitive text, tighten remaining text, and 
consolidate normative statements. 

As an initial example the -05 draft has 3 main sections:
architectural overview
functional overview (contains design considerations discussions)
protocol details
The initial ‘concise’ branch commit moves the functional overview to the 
appendix. Subsequent commits are resolving normative texts that were in there 
by moving needed bits back into the protocol discussion. You can follow along 
via the git repository here:
https://github.com/anima-wg/anima-bootstrap/compare/concise

There was a comment that the design considerations are useful and might be 
appropriate to keep here or in another document. At the moment I don’t have a 
formulated position on that.  

- max

> On Apr 18, 2017, at 3:27 AM, peter van der Stok  wrote:
> 
> Hi Max,
> 
> excellent idea. I looked at the present version, and there is still a lot of 
> text.
> Where in the text do you want to reduce more? What is the end-objective?
> And will this become the final document, or is it a study that will be used 
> later for editing the final document?
> 
> Peter
> 
> Max Pritikin (pritikin) schreef op 2017-04-15 00:34:
>> For those of you tracking the git repository please note the existence
>> of a new branch. As warned I’m significantly reducing the text. This
>> work is going on in the branch “concise”.
>> ___
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Concise version of BRSKI

[Max Pritikin (pritikin)]

For those of you tracking the git repository please note the existence of a new 
branch. As warned I’m significantly reducing the text. This work is going on in 
the branch “concise”. 
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Factory reset: Do we need two types?

[Max Pritikin (pritikin)]

+2 (grin)

Factory reset means: back to what the factory shipped. No intermediate states.

(If there is actually a requirement for an intermediate state it can be 
developed as part of other/additional work. Such would not be called “factory 
reset” it would be something else). 

- max

> On Mar 10, 2017, at 9:06 AM, Kent Watsen  wrote:
> 
> Also agree, factory reset only means one thing.
> 
> K.
> 
> 
> -Original Message-
> 
> 
> I agree with Michael - only "type 2" should be termed as "factory reset".
> 
> "type 1" reads to me as: "Reset a device to its default settings, but keep it 
> in the domain it was enrolled to".
> This includes keeping the LDevID, but also other data such as the trust 
> anchor(s).
> 
> Stevie
> 
> -Original Message-
> From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Michael H. Behringer
> Sent: Friday, March 10, 2017 11:45 AM
> To: anima@ietf.org
> Subject: [Anima] Factory reset: Do we need two types?
> 
> There was a discussion about the term factory reset, and what it means. 
> Specifically, whether the LDevID (domain certificate) is deleted.
> 
> The notes I have taken (from someone's mail) indicate:
>   type 1: erase all but LDevID - Device doesn’t need to re-enrol
>   type 2: erase all, including LDevID
> 
> While trying to work this into the reference draft, I'm getting less and less 
> comfortable with the sentiment of "two types of factory re-set".
> 
> Here my thinking:
> - Factory reset brings a device back to the state it had when it left the 
> factory. This is very unambiguous, and clear. The device will keep its IDevID 
> and the LDevID will be deleted. (may be worth noting in the reference draft 
> though, to be sure).
> - A process where the LDevID remains on the device in my view of the world is 
> therefore NOT a factory reset. I would call this "erase device configuration 
> except the LDevID".
> 
> I therefore suggest to use / define the term "factory reset" as per first 
> bullet above. And NOT define two types of factory reset. It just feels wrong 
> to me.
> 
> What am I missing? Why did we even need a term for the second? Can we not 
> just say "delete config, but leave LDevID"?
> 
> Michael
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [Anima-bootstrap] weekly boostrap design team meetings

[Max Pritikin (pritikin)]

I’m am OK with the current anchoring. 

It is not clear that the calendaring tools deal with this well so I wanted to 
be sure of how it shook out. thanks,

- max

> On Nov 18, 2016, at 5:42 PM, Michael Richardson  wrote:
> 
> 
> Max Pritikin (pritikin)  wrote:
>> "time zones are hard”
> 
>> I think this shifts our meetings — making them occur 1hr earlier than
>> they have been.
> 
>> Is that intentional? Am I in error?
> 
> If the meeting is anchored to UTC, then the change is because we changed our 
> clocks
> two weeks ago.  If you'd rather the meeting was anchored otherwise, such that
> it stays at 11am EST, please say so.  I'm flexible regardless.
> 
> -- 
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [Anima-bootstrap] weekly boostrap design team meetings

[Max Pritikin (pritikin)]

"time zones are hard”

I think this shifts our meetings — making them occur 1hr earlier than they have 
been. 

Is that intentional? Am I in error? 

- max

> On Nov 17, 2016, at 8:39 PM, Michael Richardson  wrote:
> 
> 
> The Anima Bootstrap design team (which includes work on the ownership
> voucher) will continue to meet at 15:00 UTC on Tuesdays via RTC-enabled
> webex.  The meeting is anchored to UTC, not EST.
> 
> anima bootstrap design team
> Tuesday, November 22, 2016
> 10:00 am Eastern Standard Time (GMT-05:00)
> Recurrence: Every Tuesday, from Tuesday,
> November 22, 2016, to Tuesday, March 21, 2017
> 
> Less information
> Meeting number: 644 519 877
> Meeting password: bootstrap
> Meeting link:
> https://ietf.webex.com/ietf/j.php?MTID=m2045414e2e484e0ad47311ce67c1d596
> Host key: 959942
> 
> Audio connection:
> 1-877-668-4493 Call-in toll free number (US/Canada)
> 1-650-479-3208 Call-in toll number (US/Canada)
> Show toll-free dialing restrictions
> Access code: 644 519 877
> 
> 
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> ___
> Anima-bootstrap mailing list
> anima-bootst...@ietf.org
> https://www.ietf.org/mailman/listinfo/anima-bootstrap

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] red/yellow/green lights for bootstrap and ACP feedback

[Max Pritikin (pritikin)]

The current text around error cases includes:

Section 3.1.1. Discovery
Supports a backoff mechanisms but on review I’m thinking the language about 
final failure to be vague:
   "Once all discovered services are attempted the device SHOULD return
   to Multicast DNS.  It should periodically retry the vendor specific
   mechanisms.  The Pledge may prioritize selection order as appropriate
   for the anticipated environment."

Section 5.1 Request Voucher from the Registrar
  "As detailed in Section 3.1.1 if no suitable Registrar is found the Pledge 
restarts
   the state machine and tries again.  So a Registrar that is unable to
   complete the transaction the first time will have future chances.” 

Section 5.4 Voucher Status Telemetry
This is currently worded as feedback directly to the Registrar (through the 
proxy of course) of failure. 

Section 5.7.4.  Enrollment Status Telemetry
This adds an enrollment status telemetry option as EST feedback has indicated 
this will be important for headless devices. 

Improvements could include:

A flood telemetry status indicator in addition to direct feedback to the 
Registrar. This would enable any local equipment to better report the Pledge’s 
state. I suppose this SHOULD be signed but may be unsigned to avoid extra 
processing overhead on the Pledge.  This would leak the Pledge’s identity 
information so there are privacy/security concerns but it does provide 
feedback. 

Normative text indicating physical indicators such as a blinking LED associated 
with each discovery state could be RECOMMENDED for capable devices. Obviously 
some devices simply won’t have such things so this can’t be required. Doing 
this would help clarify the discovery states. Although keep in mind the 
existing s3.1.1.1 recommendation that "Methods SHOULD be run in parallel to 
avoid head of queue problems”; meaning that the states indicated might be a 
generic “discovery”. 

- max

> On Nov 17, 2016, at 6:19 PM, Michael Richardson  wrote:
> 
> 
> We discussed today in the meeting that the bootstrap (and overall
> anima-reference-model state machine) should indicate in it's failure
> transitions whether the failure is permanent, "red light", and
> whether it is a "yellow light" (try again).
> 
> We may also need an "orange light" which means, "failed, but requires NMS 
> intervention"
> 
> We didn't have time to get a sense from the room whether or not this kind of
> feedback (which may ideally, be real physical feedback to the installer) is
> valuable.  Of course, devices with bigger displays might want to provide more
> details about the process...
>  {I recall the three-digit display on the RS/6000, and the mystery that
>  ensued when I had a code come up that IBM support couldn't explain}
> 
> 
> 
> -- 
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-carpenter-anima-ani-objectives-00.txt

[Max Pritikin (pritikin)]

Some comments on the BRSKI discussion inline, 

> On Nov 17, 2016, at 3:17 PM, Toerless Eckert  wrote:
> 
> 
> Thanks Brian & Bing
> 
> Inline
> 

The following quote levels appear to be direct or paraphrases from the 
objectives draft.
I’m tempted not even to respond to this email thread due to the sloppy quoting 
but we’ll see how it goes. 

>>   This document defines several technical objectives for use with for
>   
>>   the Generic Autonomic Signaling Protocol (GRASP)
>>   [I-D.ietf-anima-grasp].

[snip] I’m focusing on just bootstrap discussions

>>  Secure Bootstrap.
> 
> ANI use case: bootstrapping autonomic devices, non-ANI use case: bootstrapping
> non-autonomic devices.

Since its objectives for autonomic I don’t see that discussing non-autonomic is 
necessary in this document. 
The broader point that BRSKI need not be forced to be ANI specific is important 
to re-enfoce, so thank you. 

> 
>>  Autonomic Control Plane (ACP).
> 
> Part of the ANI, serving autonomic and non-autonomic use cases.
> 
>>  Stable Connectivity of Network OAM.
> 
> Primarily non-autonomic as it discusses SDN management via the ACP without
> intent being involved (yet).
> 
>>  Intent Distribution.
> 
> ANI use case.
> 
> ...
>> 2.  Objectives for Secure Bootstrap
>> 
>>   Three components are involved in the Bootstrapping Remote Secure Key
>  ^^ insert ANI
>>   Infrastructures (BRSKI) process described in
>>   [I-D.ietf-anima-bootstrapping-keyinfra]: the Registrar, the Join
>>   Assistant (or Proxy), and the Joining Node (or Pledge). 
> 
> Pls. get the final official word for proxy/pledge. we're carrying around
> too many terms and repeating them everywhere.

Pledge, Proxy, Registrar, MASA

> 
> Note: ... Bootstrapping has more functions, such as MASA and CA, but we
> do not foresee the need for GRASP signalling with them at this time.
> 
>>   The proxy
>>   and the pledge are attached to the same link-layer and use link-local
>>   communications only, to minimize exposure to eavesdroppers and
>>   malicious nodes.
> 
> I think this is not the right security claim to make. We do have important
> use-cases where the proxy MUST be remote, eg: when i attach a
> pledge to just an open internet connection without any prior ANI
> in the vicinity. And the security comparison of this setup vs. the one with
> L2 is kinda complex and should maybe not had in this doc. 
> 
> I'd suggest:
> 
> Operationally, the most simple case is when proxy and pledge have a
> link-local connection between each other. In this case, mutual discovery and
> bootstrap can happen without any prior provisioning of helper information
> such as DHCP parameters or DNS entries through which the pledge would have
> to find the proxy otherwise. Instead, link-local multicast with GRASP can and
> will be used.

This framing is probably better. We also must note that the Pledge requirement 
to work when the proxy is remote also means those Pledges must support the DNS 
mechanisms. Adding GRASP is truly an addition to the methods not a replacement 
or an optimization.

>>   There may be multiple hops between the proxy and
>>   the registrar.
> 
> Between registrar and proxy, there can and likely will be multiple hops,
> but in an autonomic network, these hops will have autoconfigured ACP and
> GRASP forwarders between them, so this connectivity too is zero-touch like
> the link-local connectivity beteeen pledge and proxy.
> 
>>   Therefore, two different GRASP objectives are
>>   required: one that is used over an existing secure network between
> the  (ACP)
>>   the registrar and the proxy, and another that is used over an
>>   insecure link-local hop between the proxy and the pledge.  The
>>   security aspects and the corresponding limited instances of GRASP are
>>   discussed in [I-D.ietf-anima-bootstrapping-keyinfra] and
>>   [I-D.ietf-anima-grasp].
> 
> And i need to check ACP draft ifhow i capture that fact there as well.
> Especially that each ACP node needs to run a GRASP forwarder for that
> hop-by-hop forwarding of the GRASP flood - securely.
> 
>>   Note that since secure bootstrap takes place, by definition, on an
>>   incompletely secure network, the use of any protocol needs to be kept
>>   as simple and limited as possible.  Therefore, only one GRASP message
>>   type is used - flooding - to avoid giving away any unnecessary
>>   information by any node involved.
> 
> Suggest to move that paragraph up before the proxy/registrar text to
> make reading easier.
> 
>>   A registrar announces itself to potential proxies by use of the
>>   "AN_registrar" objective.  This is a synchronization objective
>>   primarily intended to be flooded throughout the network using the
>>   GRASP Flood Synchronization (M_FLOOD) message.  In accordance with
>>   the design of the Flood message, a locator consisting of a specific
>>   IP addre

Re: [Anima] additional information and JSON/CBOR

[Max Pritikin (pritikin)]

> On Nov 17, 2016, at 3:10 AM, Eliot Lear  wrote:
> 
> Hi authors,
> 
> The Fairhair folk would like some clarity on the following statement in
> Section 3.1.7:
> 
>>   Functionality to provide generic "configuration" information is
>>   supported.  The parsing of this data and any subsequent use of the
>>   data, for example communications with a Network Management System is
>>   out of scope but is expected to occur after bootstrapping enrollment
>>   is complete.
> 
> 
> Many of us [like] this, but we need to know how to hook in.  Specifically 
> we're
> aiming to provide the address of the resource directory, preferably in a
> way that is signed by the registrar.

This has been derailed a bit by the voucher conversation so thank you for 
bringing it back up. 

The “optional config information” is entirely a potential protocol optimization 
— which is why it has fallen to the wayside during architectural and alignment 
discussions (-02 has some more info but its minor so lets just build from -04). 

Let me explain by using the diagram from -04 figure 6:
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-04#section-5
(slightly modified for clarity - i’ll make these changes in the doc) 

  +---+ +--+ +---+ +--+
  | Pledge| | Circuit  | |   | |  |
  |   | | Proxy| | Registrar | | MASA |
  |   | |  | |   | |  |
  ++--+ +--+---+ +-+-+ ++-+
   |   |   ||
   |   |   ||
   |   |   | /requestvoucher|
   |   |  (nonce   +>
   |   |  unknown) <+
   |   |   | /requestlog|
   |   |   +>
   |   |   <+
   |   TLS hello   |  TLS hello||
   Establish   +---C--->|
   TLS |   |   ||
   connection  |   | Server Cert   ||
   <---C---+|
   | Client Cert   |   ||
   |   |   ||
   HTTP REST   | POST /requestvoucher  ||
   Data+--nonce>   (discard |
   |voucher|   nonce)   |
   <---+|
   | (optional config information) ||
   |   .   ||
   |   .   ||

Here we show the flow with nonce-less Audit Vouchers. I chose this flow to 
highlight that there is *no* realtime communications with the vendor MASA 
service during actual BRSKI bootstrapping with the client.

The optimization goal: to distribute some config information to the Pledge!
Without optimization the Pledge needs to discover a management system and 
authenticate it and download the config information via that path. 

Some potential methods in order of integrated optimization:

Possibility-1) The REST response containing the voucher MAY be a a content-type 
of "multipart/mixed” consisting of two parts: one part is the voucher and the 
other part is the config information. The Pledge MUST complete s5.3.1 
“authentication of the Provisional TLS connection” before accepting and parsing 
the 2nd part.

Possibility-2) Same as REST response #1 except that the second part “MUST be a 
signed msg within the PKI hierarchy of the domain as established by the 
Voucher”.  

Possibility-3) Introduce a followup REST message that the Pledge MAY use to 
obtain the configuration after s5.3.1 is complete. This allows the TLS 
connection to be maintained and optimizes the flow but keeps the distinct REST 
api calls from being overloaded. It is most consistent with section 5.7 and is 
probably the approach I’d prefer. Using persistent connections this is close to 
the optimization provided by 1 or 2 and allows for simpler handling on the 
Pledge. 

It would not be fair to discuss this without touching on how netconf zero-touch 
draft addresses this issue. The data structure used in 
draft-ietf-netconf-zerotouch-09 is called “boostrap-information” and it 
contains an optional “configuration”. This is the equivalent data. How it is 
protected is discussed in section 6.4 and can be summarized as a similar flow: 
authenticate the voucher, then use the voucher information to authenticate the 
signed configuration information. Section 6.3 appears to cover the idea

Re: [Anima] Desaster recover... (was: Re: [homenet] write up of time without clocks)

[Max Pritikin (pritikin)]

Re: questions of scope for disaster recovery

I think BRSKI needs to clarify how disaster recovery works. Perhaps a section 
on this or perhaps embedded in the text.
Once the network is up I don’t see how disaster’s effects Anima operations. Its 
just a network and runs as such. 

Continued detailed discussion in line,


> On Nov 6, 2016, at 11:01 PM, Toerless Eckert  wrote:
> 
> On Fri, Nov 04, 2016 at 09:23:15PM +0000, Max Pritikin (pritikin) wrote:
>> There is a lot here. Attempting to comment on it all. 
>> 
>> It would really help if we could relate these discussions to specific text 
>> sections that could be improved. Otherwise we???re just blowing into the 
>> wind. (Where it seems obvious I???ve added such notes). 
> 
> Sure, but lets high level agree what type of content is useful and
> where it would fit.
> 
>>> - Large organizations will have spares. With ANIMA, those spares should
>>> be stored pre-enrolled to avoid MASA/registrar dependency during
>>> recovery/replacements: Receive gear on any site (no central provisioning
>>> site needed), but unpack, plug in for short period, then stash away.
>> 
>> Devices that have been brought up and are in the network post bootstrap are 
>> not relevant to the BRSKI document. 
> 
> To me the most important goal should be to provide candidate users with
> deployment guidance. This should fit ANIMA goals given how its an OPS group.
> 
> Lets say we have two options:
> 
>  a) keep spares unenrolled, enrol during desaster recovery with satellite link
>  b) enrol spare devices when they are stocked, deploy during desaster.
> 
> lets assume we agree both are relevant deployment options that users
> should understand, compare pro/cons for their case and choose. If you think
> we can not mention both in the BRSKY spec, then i think it would be better
> to have a separate document where both could be discussed. 

Yes, these are the two options available to a network that uses BRSKI. We can 
clearly state as such if we add a section on disaster recovery.

>>> This is imo an easy requirement also useful without desaster requirements
>>> - aka: enrolled spares would likely also have better theft/abuse protection
>>> than non-enrolled. And yes, you will have to power up these spares
>>> once a year. Which IMHO is ok. And of course certs should therefore
>>> be somewhat longer than 1 year).
>> 
>> This could be captured as a discussion: what does a device do when its 
>> credentials are out of date? Does it fall back on full bootstrapping? If so 
>> this becomes a potential attack vector wherein the attacker can convince the 
>> device it is out of date and then force it to restart bootstrapping. That 
>> would be bad. 
> 
> Haha... ;-) i just wanted to show what IMHO are the most simple
> deployment options to deal with desaster recover. Now you're the one who is
> opening another round of discussions trying to figure out the best
> security compromise for those deployment processes.  Which is great.
> Just don't blame me that there are more and more interesting details to
> capture somewhere.
> 
>> So, should there be an injection point into the bootstrapping state machine 
>> that says something like:
>> 
>> If a device fails to join the ANI after [some number] of attempts it 
>> attempts to repeat bootstrapping using its original SUDI credentials.
> 
> I'd prepare a flag 'operational' set by SDN controller or ASA after 
> the device is "provisioned" (config/intent applied).
> 
>> During this bootstrapping attempt it MUST only bootstrap on a Registrar that 
>> provides both a valid voucher and an identity recognizably within the same 
>> PKI hierarchy the device was in previously. This is detected by the device 
>> by either (a) the domainCAcert is an exact match for the current domain 
>> trust anchor known to the device or (b) the EST /cacerts response includes a 
>> chain that terminates in the current domain trust anchor known to the 
>> device.  
>> 
>> This extends the lifetime of such a stored device beyond its own certificate 
>> (maybe 1 year) *and* beyond the current CA certificate (maybe a 2year cert) 
>> an all the way into the next CA certificate (another 2 years). That is a 
>> pretty solid lifetime (up to 4 years) for recovery.
> 
> Interesting thought.
> 
> a) Would like to understand how this compares to just making certs
> longer-lived, eg: 3 years, but doing normal renewal after 30% time.
> 
> b) Seem like there's quite a bit of analysis to be done of how different
> parameter/options will work together:
>  - device with/

Re: [Anima] Desaster recover... (was: Re: [homenet] write up of time without clocks)

[Max Pritikin (pritikin)]

Assuming we work out the BRSKI questions such that bootstrapping during 
disaster recovery is clearly defined I’d imagine the rest of anima work work 
“magically” — in that the new equipment added to a network does what it is 
intended to do automatically. 

- max

> On Nov 13, 2016, at 12:02 AM, Michael Richardson  
> wrote:
> 
> 
> Toerless Eckert  wrote:
>>> Devices that have been brought up and are in the network post
>>> bootstrap are not relevant to the BRSKI document.
> 
>> To me the most important goal should be to provide candidate users with
>> deployment guidance. This should fit ANIMA goals given how its an OPS
>> group.
> 
> Chairs, 
>  I think we should add a new document to our set.  The title might be:
> Autonomic Networking in Disaster Recovery: preperation and operation
> 
> This would be a very very very operational BCP.
> We won't finish this until after everything has been put to bed, but I think
> we should start it soonest, so that we can capture much of this
> discussion/concern.
> 
>>  a) keep spares unenrolled, enrol during desaster recovery with
>> satellite link b) enrol spare devices when they are stocked, deploy
>> during desaster.
> 
>> lets assume we agree both are relevant deployment options that users
>> should understand, compare pro/cons for their case and choose. If you
>> think we can not mention both in the BRSKY spec, then i think it would
>> be better to have a separate document where both could be discussed.
> 
> A reason why one would have unenrolled spares is because the spares are kept
> by the manufacturer in distributed warehouses, close to where they might be
> needed, or perhaps even, would be in a FEMA-like entities' warehouse, to be
> deployed to whichever operator needed them.
> 
> The use of Autonomic mechanisms might result in normalization much of the
> configuration of some devices, so it wouldn't matter as much which vendor's
> device was deployed.  Maybe this won't be for core BGP-happy BFRs, but it
> could be the case that less complicated things like 24 10/100/1000s switches
> would be in that category.
> 
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Desaster recover... (was: Re: [homenet] write up of time without clocks)

[Max Pritikin (pritikin)]

There is a lot here. Attempting to comment on it all. 

It would really help if we could relate these discussions to specific text 
sections that could be improved. Otherwise we’re just blowing into the wind. 
(Where it seems obvious I’ve added such notes). 

> On Nov 3, 2016, at 2:40 PM, Toerless Eckert  wrote:
> 
> IMHO, gear replacement after large outages is quite relevant:
> 
> I have seen equipment become unusable after bad
> power situations (spike, brownout, electrical storms,..) because of
> el-cheapo power supply/circuitry as well as wired interface
> circuitry/protection. Certifications in Telco/IoT make that type of gear
> often better, but those certifcations are a zoo.
> 
> - Large organizations will have spares. With ANIMA, those spares should
>  be stored pre-enrolled to avoid MASA/registrar dependency during
>  recovery/replacements: Receive gear on any site (no central provisioning
>  site needed), but unpack, plug in for short period, then stash away.

Devices that have been brought up and are in the network post bootstrap are not 
relevant to the BRSKI document. 

>  This is imo an easy requirement also useful without desaster requirements
>  - aka: enrolled spares would likely also have better theft/abuse protection
>  than non-enrolled. And yes, you will have to power up these spares
>  once a year. Which IMHO is ok. And of course certs should therefore
>  be somewhat longer than 1 year).

This could be captured as a discussion: what does a device do when its 
credentials are out of date? Does it fall back on full bootstrapping? If so 
this becomes a potential attack vector wherein the attacker can convince the 
device it is out of date and then force it to restart bootstrapping. That would 
be bad. 

So, should there be an injection point into the bootstrapping state machine 
that says something like:

If a device fails to join the ANI after [some number] of attempts it attempts 
to repeat bootstrapping using its original SUDI credentials. During this 
bootstrapping attempt it MUST only bootstrap on a Registrar that provides both 
a valid voucher and an identity recognizably within the same PKI hierarchy the 
device was in previously. This is detected by the device by either (a) the 
domainCAcert is an exact match for the current domain trust anchor known to the 
device or (b) the EST /cacerts response includes a chain that terminates in the 
current domain trust anchor known to the device.  

This extends the lifetime of such a stored device beyond its own certificate 
(maybe 1 year) *and* beyond the current CA certificate (maybe a 2year cert) an 
all the way into the next CA certificate (another 2 years). That is a pretty 
solid lifetime (up to 4 years) for recovery.

> - If sparing would be cross-locations (eg: spares sent from some site to
>  other sites during recovery), then its important that the ANIMA certs do
>  not include any location specific attributes that would prohibit thart
>  movement. So far BRSKY does not include any such attributes, but in
>  discussions, three has been interest to lock into the cert some device
>  role specific attributes, and for a spare piecce of equipment, those
>  attributes may not be predetermined.
> 
>  Aka: Desaster sparing means domain certs need to be simple, devices
>  reuseable across domain.

I agree that certs should include the absolute minimum information about the 
device. The actual ID is sufficient in my book. Attribute Certs or backend 
database lookups or short term tokens obtained by the device in place are all 
methods of distributing additional information. 

> - If spares are done by a shared facility: vendor, FEMO (for fed networks)
>  or the like, one could think of that entity offering (emergency)
>  enrolment service.
> 
>  Such an entity would have desaster proof MASA connectivity on site,
>  and the customers would provide it with (emergency) registrar certs.

Ok. So like a Cisco NERV truck that provides connectivity sufficient to rebuild 
a network in place. 

Issuing a new Registrar ID would mean being able to bring up the PKI 
infrastructure during the recovery process. But this is exactly the time period 
when having as much of the critical keying infrastructure offline and secured 
could be beneficial for longterm security. One could argue that extra attempts 
should be made to ensure the PKI is offline. 

>  (emergency) meaning that the entity is only permitted to enrol during
>  emergencies, and the customer could be able to verify the emergency
>  entities behavior by pulling from the MASA an audit log.

Section 5.6 doesn’t include the Registrar identity only the domainID in the 
log. Do folks think the Registrar ID should be included as well?

If this was done then does it matter if the Registrar cert has role information 
in it? As per the above what would happen if all devices in the ANI could act 
as a registrar? There would be a higher chance that one of them would mess up 
and actually perform registr

Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?)

[Max Pritikin (pritikin)]

> On Nov 3, 2016, at 6:45 PM, Toerless Eckert  wrote:
> 
> On Tue, Nov 01, 2016 at 10:42:32PM +0000, Max Pritikin (pritikin) wrote:
>> Taken to the extreme one could argue that we need ANI to be self-contined so 
>> depending on IP seems wrong.
> 
> Can you explain where you think ANI depends on IP in a fashion you
> ae calling "wrong” ?

Sigh. Too much snark — not enough information.

My point is that ANI will, of course, depend on things. It isn’t a self 
contained re-envisionment of the entire concept of networking. 

Where those things are themselves reasonably bounded I don’t see the problem 
with using them. For example I could see an argument against discussing DNS-SD 
because it is intended to span links and therefore ‘depends’ on the DNS 
infrastructure. One could argue secure GRASP provides that role within an ANI 
network and does so better (ie securely). 

But mDNS is not dependent on that infrastructure. Instead it is a relatively 
self contained mechanism that doesn’t “step on the toes” or duplicate things in 
the ANI infrastructure and it exists and is used already. So creating too many 
options in that space is simply adding confusion. Just like it’d be silly to 
suggest that ANI devices shouldn’t use IP. 

- max

> 
> Cheers
>Toerless
> 
>> There is a point where ANI needs to depend and integrate with existing 
>> systems. 
>> 
>> My position is that the demarcation point is bootstrapping of the keying 
>> infrastructure. Prior to bootstrapping we depend on generic mechanisms and 
>> behaviors that any device might experience on a modern network. Post keying 
>> we have sufficient methods to differentiate between ANI and all that other 
>> stuff. 
>> 
>> Another way of stating my position ???we need bootstrapping to be as well 
>> contained as possible, so depending on GRASP seems wrong???. In truth of 
>> course the Proxy to Registrar communication benefits from GRASP so it is 
>> suggested there for ANI devices. This compromise integrates bootstrapping 
>> with ANI in a way that provides value when ANI exists but doesn???t depend 
>> on it for situations where it doesn???t exist. 
>> 
>> - max
>> 
>>> 
>>>> 
>>>>>> When GRASP is run securely in its two forms for the ACP, it is always 
>>>>>> protected/
>>>>>> encrypted by the ACP, so i think your security concern would then not be 
>>>>>> valid.
>>>>> 
>>>>> I'm still waiting to see a clear explanation of how the ACP will secure
>>>>> LL multicast, however.
>>>> 
>>>> I am not sure i understand the documentation ask. The ACP has a bunch of 
>>>> (virtual) interfaces. In
>>>> the most simple implementation option, each ACP channel to an ACP neighbor 
>>>> is its own
>>>> (p2p) L3 interface in the ACP. And thats all the interfaces the ACP has.
>>> 
>>> And that's the problem. GRASP discovery and flooding need sockets that
>>> supports link-local multicast sending and receiving for each physical
>>> interface.
>>> 
>>> Currently the GRASP code finds out how many physical interfaces it has
>>> and for each one creates a multicast sending socket. It also has a socket
>>> that listens for incoming link-local multicasts on all physical interfaces.
>>> I don't see how to do that using the ACP interfaces that you describe.
>>> 
>>>> All packets, unicast or multicast that are sent into or 
>>>> received from those interfaces are protected/encrypted by the fact that 
>>>> they are transmitted
>>>> encrypted by the seleted ACP channel encryption protocol.
>>> 
>>> Yes, and I'd like the LL multicast traffic to be protected too.
>>> But as far as I can see that needs explicit support in the ACP
>>> to emulate LL multicast sockets. The ideal would be that the ACP
>>> simply emulates LL interfaces, so that GRASP could treat them exactly
>>> like physical interfaces.
>>> 
>>> If you want, I can point you the exact Python code that handles this
>>> in the prototype.
>>> 
>>>> 
>>>>>> Do you see some IoT context where you would use insecure GRASP instead 
>>>>>> of DNS-SD/mDNS,
>>>>>> eg: in some IoT context ?
>>>>> 
>>>>> Michael can answer that for himself, but the reason we noted the 
>>>>> *possibility*
>>>>> of doing this in grasp-08 is because it seems clearly harmless. So from 
>>>>> the
>>>>

Re: [Anima] [homenet] write up of time without clocks

[Max Pritikin (pritikin)]

> On Nov 2, 2016, at 1:09 PM, Brian E Carpenter  
> wrote:
> 
> Firstly, no, I have no pixie dust, and I agree that we need to preserve
> security even after a disaster. But on the other hand, if autonomic
> networks matter at all, they will matter then, and we can't safely assume
> that network operators are available even to switch on some sort of emergency
> MASA server. Also, how would a temporary tactical network used by emergency
> responders configure itself if no vendor MASA server is accessible?

I think Eliot’s point that "most first responders will have trained with the 
equipment they have prior to the disaster” meaning that that equipment will 
already have been bootstrapped. In this case MASA isn’t needed.

Any new equipment that needs to be deployed can be bootstrapped using either 
the nonceless audit tokens or the physical possession workarounds. In this case 
the MASA can be offline so long as necessary audit tokens can be brought into 
the area along with the replacement equipment. 

Beyond that, say a large scale network needs to be brought up, then I suspect a 
service like the Cisco NERV truck will be brought in to provide satellite 
connectivity. In which case the MASA server can be contacted. 

- max

> 
> I'm not suggesting that the basic BRSKI mechanisms need to solve this,
> but I think we need to have it on the list of issues to be tackled before
> we can consider Anima complete.
> 
>   Brian
> 
> On 03/11/2016 05:15, Eliot Lear wrote:
>> I myself would be concerned over a downgrade attack. 
>> 
>> Recall that this only impacts BRSKI in as much as the device needs to be
>> provisioned *during* the disaster.  While there may yet be some classes
>> of devices that require this, I'm going to hazard (cough) a guess that
>> most first responders will have trained with the equipment they have
>> *prior* to the disaster.  For the remaining equipment, if it is part of
>> critical infrastructure and requires a network, then the network needs
>> to be up.  The only question then is whether the MASA server needs to be
>> up.  It is perfectly possible to design a system where that is the case.
>> 
>> Eliot
>> 
>> 
>> On 11/2/16 5:05 PM, Max Pritikin (pritikin) wrote:
>>> My position is that during a large scale disaster it would be foolish of us 
>>> to think that security is somehow less important. 
>>> 
>>> BRSKI supports nonceless tokens that can be distributed in advance. These 
>>> include the serial number of the device and the domain CA cert so it IS NOT 
>>> a "master key".
>>> A “master key” is too similar to a “back door” for me to support it. 
>>> 
>>> BRSKI client may support physical presence (buttons etc) that put them in 
>>> ‘trust on first use’ mode. 
>>> 
>>> BRSKI addresses ‘time without clocks’ through the use of nonces and section 
>>> 3.1.5.
>>> 
>>> I could be persuaded toward a more generic tofu model only if devices 
>>> include an integrated hardware assisted endpoint assessment (think TPM 
>>> style attestation w/ runtime measurements). That technology isn’t really 
>>> available yet.
>>> 
>>> The approaches provided here work with some prior planning but are not 
>>> magical. 
>>> 
>>> Do you have pixie dust to suggest? 
>>> 
>>> - max
>>> 
>>>> On Nov 1, 2016, at 8:53 PM, Brian E Carpenter 
>>>>  wrote:
>>>> 
>>>> Something over on homenet prompted me to send the following. I do have the
>>>> same concern for BRSKI - what's the disaster recovery mechanism when all
>>>> vendor MASAs are unreachable but we must restart the network anyway?
>>>> 
>>>>  Brian
>>>> 
>>>>  Forwarded Message 
>>>> Subject: Re: [homenet] write up of time without clocks
>>>> Date: Wed, 2 Nov 2016 08:38:04 +1300
>>>> From: Brian E Carpenter 
>>>> Organization: University of Auckland
>>>> To: home...@ietf.org
>>>> 
>>>> On 02/11/2016 03:52, Philip Homburg wrote:
>>>> ...
>>>>> Which brings me to the following: given that all code has security issues,
>>>>> maybe devices should check for updates and just shutdown if they can't
>>>>> verify that they are running the latest firmware?
>>>> That sounds absolutely dreadful for disaster recovery scenarios where
>>>> the Internet is badly broken (after a hurricane, earthquake, etc.)
>>>> and people need to restart essential s

Re: [Anima] [homenet] write up of time without clocks

[Max Pritikin (pritikin)]

My position is that during a large scale disaster it would be foolish of us to 
think that security is somehow less important. 

BRSKI supports nonceless tokens that can be distributed in advance. These 
include the serial number of the device and the domain CA cert so it IS NOT a 
"master key".
A “master key” is too similar to a “back door” for me to support it. 

BRSKI client may support physical presence (buttons etc) that put them in 
‘trust on first use’ mode. 

BRSKI addresses ‘time without clocks’ through the use of nonces and section 
3.1.5.

I could be persuaded toward a more generic tofu model only if devices include 
an integrated hardware assisted endpoint assessment (think TPM style 
attestation w/ runtime measurements). That technology isn’t really available 
yet.

The approaches provided here work with some prior planning but are not magical. 

Do you have pixie dust to suggest? 

- max

> On Nov 1, 2016, at 8:53 PM, Brian E Carpenter  
> wrote:
> 
> Something over on homenet prompted me to send the following. I do have the
> same concern for BRSKI - what's the disaster recovery mechanism when all
> vendor MASAs are unreachable but we must restart the network anyway?
> 
>   Brian
> 
>  Forwarded Message 
> Subject: Re: [homenet] write up of time without clocks
> Date: Wed, 2 Nov 2016 08:38:04 +1300
> From: Brian E Carpenter 
> Organization: University of Auckland
> To: home...@ietf.org
> 
> On 02/11/2016 03:52, Philip Homburg wrote:
> ...
>> Which brings me to the following: given that all code has security issues,
>> maybe devices should check for updates and just shutdown if they can't
>> verify that they are running the latest firmware?
> 
> That sounds absolutely dreadful for disaster recovery scenarios where
> the Internet is badly broken (after a hurricane, earthquake, etc.)
> and people need to restart essential systems (or they need to restart
> themselves).
> 
>> So the device should have the vendor's long term TLS certicate. With possibly
>> an option for the user to disable this kind of security if the device is
>> not actually connected to the internet.
> 
> No, during disaster recovery the last thing you need is for ordinary people
> to be faced with strange security alerts that they've never seen before.
> (It's rather like advising people to go into the BIOS to change an option
> while the fire alarm is ringing.)
> 
> Things need to just work during disaster recovery.
> 
>Brian
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?)

[Max Pritikin (pritikin)]

> On Oct 31, 2016, at 6:59 PM, Brian E Carpenter  
> wrote:
> 
> Hi Toerless,
> On 01/11/2016 11:18, Toerless Eckert wrote:
>> On Mon, Oct 31, 2016 at 01:23:36PM +1300, Brian E Carpenter wrote:
 I am confused about the reason for this discussion. It seems you are trying
 to figure out how to minimize the impact of the insecure multicast piece 
 of GRASP,
 but in the context of ANIMA this question would be irrelevant, because we 
 are
 not doing any insecure GRASP in BRSKY or ACP with current draft - the use 
 of
 insecure GRASP was removed in those drafts before Berlin because of the 
 majority
 of the bootstrap teams choice for DNS-SD/mDNS. 
>>> 
>>> Which, I have to point out, is not a consensus position; design teams 
>>> propose,
>>> they don't decide. I'm waiting to see the next draft before I raise this 
>>> issue on
>>> the WG list.
>> 
>> Right. I guess we've now posted all drafts we can before the deadline, so
>> let me change this mail threads subject to get the discussion started.
>> 
>> Current state:
>> 
>> a) The bootstrap design team mayority did conclude that mDNS is the best 
>> option
>>   for discovery of bootstrap proxy by the pledge (link-local). I'll still 
>> have
>>   to read in more detail through the document to see how well the text 
>> discusses
>>   all the reasons why.
> 
> I responded to that under a different subject header.
> 
>> 
>> b) I have just posted ACP draft -04 in which i have reversed the choice of 
>> mDNS for
>>   ACP discovery by neighbors from the -03 text which had mDNS. So -04 
>> defines to
>>   use (DULL) GRASP for ACP discovery with more details.
>> 
>>   I had put mDNS into -03 because of my thinking that all the reasons that 
>> that bootstrap
>>   had for mDNS would a) also apply to ACP discovery, and that b) it would 
>> make life easier
>>   to have fewer discovery protocols. a) was not well thought through on my 
>> side.
>> 
>>   Pls check out the text on discover in -04, i hope it justifies use of GRASP
>>   for neighbor discovery.
> 
> I will read that carefully, but for me that doesn't need justification, 
> because
> we need the ANI to be self-contained, so depending on mDNS seems wrong. (In
> fact, why wouldn't configuring mDNS/DNS-SD/DNS be an autonomic function 
> itself?)

Taken to the extreme one could argue that we need ANI to be self-contined so 
depending on IP seems wrong. There is a point where ANI needs to depend and 
integrate with existing systems. 

My position is that the demarcation point is bootstrapping of the keying 
infrastructure. Prior to bootstrapping we depend on generic mechanisms and 
behaviors that any device might experience on a modern network. Post keying we 
have sufficient methods to differentiate between ANI and all that other stuff. 

Another way of stating my position “we need bootstrapping to be as well 
contained as possible, so depending on GRASP seems wrong”. In truth of course 
the Proxy to Registrar communication benefits from GRASP so it is suggested 
there for ANI devices. This compromise integrates bootstrapping with ANI in a 
way that provides value when ANI exists but doesn’t depend on it for situations 
where it doesn’t exist. 

- max

> 
>> 
 When GRASP is run securely in its two forms for the ACP, it is always 
 protected/
 encrypted by the ACP, so i think your security concern would then not be 
 valid.
>>> 
>>> I'm still waiting to see a clear explanation of how the ACP will secure
>>> LL multicast, however.
>> 
>> I am not sure i understand the documentation ask. The ACP has a bunch of 
>> (virtual) interfaces. In
>> the most simple implementation option, each ACP channel to an ACP neighbor 
>> is its own
>> (p2p) L3 interface in the ACP. And thats all the interfaces the ACP has.
> 
> And that's the problem. GRASP discovery and flooding need sockets that
> supports link-local multicast sending and receiving for each physical
> interface.
> 
> Currently the GRASP code finds out how many physical interfaces it has
> and for each one creates a multicast sending socket. It also has a socket
> that listens for incoming link-local multicasts on all physical interfaces.
> I don't see how to do that using the ACP interfaces that you describe.
> 
>> All packets, unicast or multicast that are sent into or 
>> received from those interfaces are protected/encrypted by the fact that they 
>> are transmitted
>> encrypted by the seleted ACP channel encryption protocol.
> 
> Yes, and I'd like the LL multicast traffic to be protected too.
> But as far as I can see that needs explicit support in the ACP
> to emulate LL multicast sockets. The ideal would be that the ACP
> simply emulates LL interfaces, so that GRASP could treat them exactly
> like physical interfaces.
> 
> If you want, I can point you the exact Python code that handles this
> in the prototype.
> 
>> 
 Do you see some IoT context where you would use insecure GRASP instead of 
 DNS-SD

Re: [Anima] [Anima-bootstrap] [Ace] Constrained Environment PKI enrollment

[Max Pritikin (pritikin)]

> On Jun 20, 2016, at 1:41 AM, Hannes Tschofenig  
> wrote:
> 
> Michael,
> 
> it depends what "bootstrapping" means.
> 
> We have a key distribution mechanism in the OAuth-ACE document (which is
> relevant to this specific discussion thread).
> 
> Ciao
> Hannes

Hannes, are referencing this statement?
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-02

   This framework supports a wide variety of communication security
   mechanisms between the ACE entities, such as client, AS, and RS.  We
   assume that the client has been registered (also called enrolled or
   onboarded) to an AS using a mechanism defined outside the scope of
   this document.  In practice, various techniques for onboarding have
   been used, such as factory-based provisioning or the use of
   commissioning tools.  Regardless of the onboarding technique, this
   registration procedure implies that the client and the AS share
   credentials, and configuration parameters.  These credentials are
   used to mutually authenticate each other and to protect messages
   exchanged between the client and the AS.

My working definition of bootstrapping is exactly the things that are declared 
out-of-scope in the ace-oauth-authz doc. 

If you meant a different doc could you provide a more specific reference? 
Thanks,

- max

> 
> On 06/06/2016 08:31 PM, Michael Richardson wrote:
>> 
>> Samuel Erdtman  wrote:
>>> The company I previously worked for where looking into adopting EST for
>>> this purpose, the benefit of EST compared to cmp or scep was that it
>>> defined the process for server side generated keys, which could be
>>> beneficial if key generation would be to cumbersome for the device or
>>> if you don't trust the
>>> device to generate a "good" key.
>> 
>> Hi, these are definitely important considerations.
>> I would invite you to read the ANIMA bootstrap keying documents, and
>> possibly join the design team.
>> At this point I believe the bootstrap is out of scope for ACE.
>> 
>> We are considering whether to use OSCOAP for 6tisch though.
>> 
>> --
>> Michael Richardson , Sandelman Software Works
>> -= IPv6 IoT consulting =-
>> 
>> 
>> 
>> 
>> 
>> ___
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
>> 
> 
> ___
> Anima-bootstrap mailing list
> anima-bootst...@ietf.org
> https://www.ietf.org/mailman/listinfo/anima-bootstrap

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima