Max, I have been through the concise branch, and done a dozen or so
     small edits which are in the git tree at
     https://github.com/anima-wg/anima-bootstrap/tree/concise

We are defining DomainID in the terminology section.
Now that I've been through the entire revised structure, I'll think
on where to put that definition. We should define a crypto operation
in the terminology part :-)
I will do an edit tomorrow for that.
I also owe notes from April meetings.

section 3.3 reads:
   automatically authorized.  If authorization is successful the MASA
   responds with a [I-D.ietf-anima-voucher] voucher.  The MASA SHOULD
   check for revocation of the Registrar certificate.  The maximum

is this going to read right when it is replaced with "RFCXXXX"?
It just seems awkward here.


3.7 worries:
          extensive history. A Registrar MAY request logs at future times
          [[EDNOTE: we need to ensure MASA server is not slammed with too
          many requests]].

Thoughts: permit a 301 redirect, even to an HTTP resource.
A MASA seeing a lot of requests could redirect to a static content server
elsewhere (cloudflare, amazon s3 bucket).  That reduces the load of the
big response.
The object retrieved could even be signed by the MASA.

Michael B and I talked during todays call about the MASA URL extension.
What's valid? Specifically, would it be valid to have an HTTP URL?
It could be to a DDoS aware cloud provider (amazon, cloudflare, etc)
which would provide a 30x redirect to an https URL.
Also concider if TLS upgrade on an HTTP/2 connection makes sense.

Cases: 
         - pledge contains URL of MASA
         - step 1: registrar follows URL (default)
         - option 1: redirect: should it be allowed? (if not, cannot deploy
        anti-DDOS re-direct)
         - option 2: manual override of URL: should it be allowed? 

Tentatively: Neither option 1 or 2 have an impact on security ("stealing" a
device). 


Next:   Is there a relationship between the TLS Server Certificate of the
        MASA, and the Issuer Certificate from the IDevID?

Is the MASA's ServerCertificate validated with WebPKI?
How does the Registrar obtain the Vendor's cert chain that permits it
to validate the IDevID.  Can it obtain it via the MASA connection?

Registar: IDevID provides URL, use URL with WebPKI validation, obtain private
          cert chain (not anchored to WebPKI) from MASA, validate IDevID.
          Is there any attack here if the pledge can control the MASA URL?

MB suggests that IDevID and MASA Server Certificate would be verifiable via
the WebPKI, and there would not necessarily be any common root of trust
between the two.

MB: There are two security associations: 
- between pledge and MASA
- between Registrar and MASA
Observations: 
- those two SAs are independent
- the first (BRSKI/EST) is anchored on a trust anchor that may be private (ie 
not part of the public PKI)
- the second (MASA<->Registrar) is normally anchored on the public WebPKI for 
the ServerCertificate.
- the URL in the certificate of the IDevID of the pledge may be used to point 
the registrar to the MASA. (or, redirect, or override, see line 1477-1478)
  --> In that URL, the vendor defines the type of security association to be 
used between registrar and MASA. 
  --> The vendor choooses the type of SA. MUST define a minimum protocol set 
that MUST be supported on the registrar, including a minimum level of security.



--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-



Attachment: signature.asc
Description: PGP signature

_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to