Re: [Anima-bootstrap] Detailed BRSKI review, part 1

> > Bullet 4 / Imprint operation:
> >
> > A specific device may require a MASA token to bootstrap, another one may
> NOT. This is really a feature of the pledge. And this behaviour MUST NOT be
> changeable (ie it's hard coded). (somewhere we should state that, I think we
> don't so far).
> 
> CONCERN: I think section 6 about reduced security modes directly addresses
> this; by specifically allowing this to be changed (e.g. allow a reduced security
> mode).
> What we don’t talk about is how a device might indicate it wants one type of
> token from the MASA or the other. I’m comfortable mandating that a Pledge
> is required to support either format; since my concerns about the ownership
> voucher are around how the sales channel integration work. The client side
> implementation is pretty trivial.

You seem to suggest to have a pledge EITHER be accepting an ownership voucher OR an audit log.

To me, there are three "modes" a pledge can be in: 
1 - requiring an ownership voucher to join a domain
2 - requiring an audit log to join a domain 
3 - requiring nothing. (first seen first joined)

My statement: A pledge is hard-coded to be in one and only one of these states. Specifically, if it is expecting an ownership voucher, it MUST NOT accept an audit log. An ownership voucher is a much stronger assertion than an audit log. I guess if a pledge is hard-coded to accept an audit log it may also accept an ownership voucher? (not sure). 

My points: 
- I think a pledge is hardcoded to be in one of these three modes
- There is a logic that defines what should happen if I get "something else" from what I expect. 

Right now the doc doesn't really distinguish between the two token types, I think this needs fixing. 

See also my mail from 14 Oct, which contained a graphic about this. 

(Where this goes in the doc is a separate discussion). 

Thoughts? 
Michael

> > In the "Imprint" step three errors can happen: 1) The device receives
> > a bad MASA token, or doesn't receive one; and 2) the domain Registrar
> > receives a bad or no MASA token or 3) the audit log makes the
> > Registrar reject the device. For trouble shooting, I think it is
> > imperative that in 1) the pledge informs the Registrar of the error,
> 
> CONCERN: So I think you recommend either expanding s5.7.4 “status
> telemetry” to explicitly cover this case or add another telemetry option?
> 
> > and in 2) and 3) the Registrar informs the pledge (e.g., to turn on a red LED,
> such that the installer knows that an error condition has arisen. I think we
> don't cover those cases yet?
> 
> CONCERN: This is an interesting idea but w/o a valid MASA response the
> domain has no secure way to drive behavior on the Pledge. What do you
> think about the Pledge being required to indicate something about failed
> attempts when it moves on to future discovery? (via timeout etc).
> 
> > 3.1.1
> > " The result of discovery is logically (should be "logical") communication
> with a Proxy instead ... " I would have said it the other way round, and
> reduced that paragraph to: " The result of discovery is a logical
> communication with a Registrar, through a Proxy.”
> 
> Fixed. "The result of discovery is a logical communication with a Registrar,
> through a Proxy. The Proxy is transparent to the Pledge but  is always
> assumed to exist."
> 
> > " To discover the Domain Bootstrap Server" you mean " To discover a
> Registrar" - right? I suggest to remove the term "bootstrap server"
> completely (globally) to avoid confusion.
> 
> Fixed.
> 
> > a): We exclude a case with normal DHCP for IPv4. Do we really want to do
> this? Also, if option d) is the only one working, we require DNS to work. So a)
> should probably be expanded to include these options?
> 
> Good point. I’ve added a reference to DHCP [RFC2131] as follows:
> 
> The Plege MAY obtain an IP address via DHCP [RFC2131]. The DHCP provided
> parameters for the Domain Name System can be used to perform step (d)
> DNS operations if all local discovery attempts fail (see below).
> 
> CONCERN: how to balance this MAY with the MUST concerning RFC3927 and
> RFC4862 (dynamic IP address for v4 or v6)?
> 
> > b): Do we need an IANA registration for the "_bootstrapks._tcp.local"
> service? We have no IANA considerations section!!
> 
> CONCERN: great point. I’ve added the section but left the content as a
> [[EDNOTE:]]
> 
> > c) We're using both "example.com" and "example.net". Only use .com
> > (http://www.iana.org/domains/reserved)
> 
> Fixed.
> CONCERN: the next example is “vendor-example.com” to distinguish it.
> Perhaps this should be example.com as well?
> 
> > d) "Vendors that leverage this method SHOULD provision appropriately."
> Explain? I don't understand what that means?
> 
> If they sell devices that search for this address they should build out their
> infrastructure sufficiently to handle the load of whatever devices they ship.
> I’ve changed the text to read: "Vendors that leverage this method on the
> Pledge are responsible for providing the bootstrapks service”.
> 
> > Not sure, just verifying: Our proxy methods would work if the pledge is
> IPv4 and the Registrar IPv6?
> 
> CONCERN: I believe so but MCR’s input would be helpful.
> 
> > "to avoid overloading that discovery methods network infrastructure."
> Does that make sense? I think "to avoid overloading the network
> infrastructure with discovery”.
> 
> Fixed.
> 
> > In the reference model we state that if a pledge has been rejected by a
> domain, it should preferably use other domains that are seen. We may want
> to add something at the end of 3.1.1. This is also the reason why the pledge
> needs to know if the Registrar has rejected it based on MASA input.
> 
> CONCERN: Discovery doesn’t include a secure statement of the domain
> identity. So this behavior would imply something like “if the TLS
> authentication results in a domain that has explicitely rejected the Pledge
> previously then the attempt immediately fails and no request is initiated” in
> section 5?
> 
> > s/Therefore or clarity/Therefore for clarity/
> 
> Fixed with an above comment.
> 
> > 3.1.2 suggest to merge with 3.1.3. The "request join" includes the
> "identity", really. These are NOT two separate steps.
> > s/ bootstrapping protocol server/Registrar/g s/bootstrapping
> > server/Registrar/g s/Bootstrapping server/Registrar/g
> 
> CONCERN: as noted above these are two distinct protocol steps. Leaving this
> for now.
> 
> > 3.1.4
> > The non-autonomic methods are confusing here. I wonder whether we
> should exclude them? Are they really in scope?
> 
> CONCERN: I’d like to leave these for now. I receive a lot of questions about
> how this is different than the non-autonomic methods in EST and around
> how TOFU etc relates. I think it seems extraneous to us to discuss these
> (again) for but newer readers it helps.
> 
> > The pledge must support three modes:
> > 1 - (no MASA): doesn't require an ownership voucher or audit token
> 
> CONCERN: I emphatically don’t see this as a requirement on the Pledge.
> Section 6 allows this case only because we’re not yet serious about security.
> 
> > 2 - (MASA with audit only): requires an audit token
> > 3 - (MASA with ownership tracking): requires an ownership voucher.
> 
> I’ve updated the statement before the list to read:
> "This document describes autonomic methods that MUST be supported by
> the Pledge:"
> 
> >
> > 3.1.5
> > "   o  In accordance with IEEE 802.1AR and RFC5280 all manufacturing
> >      installed certificates and trust anchors are assumed to have
> >      infinite lifetimes.  All such certificates "SHOULD be assigned the
> >      GeneralizedTime value of 99991231235959Z" [RFC5280].  The New
> >      Entity, Registrar and MASA server MUST ignore any other validity
> >      period information in these credentials and treat the effective
> >      lifetime as 99991231235959Z.  This ensures that client
> >      authentication (see Section 3.3.1) and the audit token signature
> >      (see Section 5.3) can always be verified during RFC5280 path
> >      validation."
> >
> > The MUST statement implies that a MASA etc actually knows whether a
> certificate is 8201.AR or another type of cert, right? Is that true? When I look
> at a device certificate, how do I know it's an IDevID?
> >
> > Assuming you *can* distinguish IDevID from a "normal" cert, we may run
> into cases where "normal" certs are used in the function of an IDevID, right?
> I.e. a device type doesn't really support IDevID, but a manufacturer has pre-
> loaded certs at manufacturing time.
> >
> > This "All such certificates "SHOULD be assigned the GeneralizedTime
> > value of 99991231235959Z" [RFC5280]. " in combination with "MUST
> > ignore" makes me nervous…
> 
> I’ve updated this bullet as:
> 
> During Pledge authentiation by the Registrar a realtime clock can be used by
> the Registrar. This bullet expands on a closely related issue regarding Pledge
> lifetimes. RFC5280 indicates that long lived Pledge certifiates "SHOULD be
> assigned the GeneralizedTime value of 99991231235959Z" [RFC5280] so the
> Registrar MUST support such lifetimes and SHOULD support ignoring Pledge
> lifetimes if they did not follow the RFC5280 recommendations.
> 
> Arguably this bullet could be moved to a different section.
> 
> >
> > We're referring to an audit token in this section, but not to the
> > other 2 methods  (Onwership voucher and no MASA). This isn't complete…
> 
> I’ve moved the nonce discussion to the end of this section and added a
> comment about Ownership vouchers:
> 
> The nonce included in join attempts provides an alternate mechanism for the
> Pledge to ensure Audit Token responses are associated with a particular
> bootstrapping attempt. Nonceless Audit Tokens from the MASA server are
> always valid and thus time is not needed.
> 
> Ownership Vouchers include time information and MUST be validated a
> realtime clock.
> 
> >
> > Specifically, in a case without MASA, I think we need to simply state that
> we cannot validate time during enrolment. I think this is what the statement
> "When accepting an enrollment certificate the validity period
> >      within the new end entity certificate is assumed to be valid by
> >      the New Entity." wants to say?
> 
> CONCERN: I don’t see how “without MASA” enters into this so I’ve probably
> not addressed something here.
> 
> > Actually, we only look at the domain validating time from the pledge,
> > shouldn't we also describe the other direction? --> Wouldn't it be correct to
> say "A pledge without real-time clock cannot securely bootstrap time. During
> the bootstrap process it accepts all certificates without validating time. Once
> bootstrapped such devices MUST be provided with the current correct time
> for other PKI operations to succeed."
> >
> > This whole section 3.1.5 makes me a bit nervous…
> 
> Good. :/ Its a scary concept and I’m happy to have folks comment. Do the
> above cleanups help?
> 
> >
> > 3.1.6
> > "The New Entity contacts the Registrar" add "via a proxy". We always
> assume a proxy.
> 
> Fixed.
> 
> >
> > In this section we don't foresee a case without MASA sever. (Bullet
> > list)
> >
> > "   o  The EST server is authenticated by using the Ownership Voucher
> >      indicated fully qualified domain name to build the EST URI such
> >      that EST section 4.1.1 bootstrapping using the New Entity implicit
> >      Trust Anchor database can be used."
> >
> > Read this several times, still don't parse it. Can we make this sentence
> simpler? Not even sure this is grammatically correct?!?
> >
> > Also this section, I think we should distinguish the three cases of MASA.
> Last paragraph starts with "once the audit token is received". What if there is
> none or an ownership voucher?
> 
> Fixed.
> 
> "Ownership Vouchers are obtained by a Registrar from the MASA service and
> explicitly indicate the owner of the Pledge.”
> 
> "The Ownership Voucher contains the Owner Certificate which the Pledge
> uses to authenticate the TLS connection."
> 
> >
> > 3.1.7
> > As mentioned in my other mail, I would prefer to call the final state here
> "enrolled". We could explain here that in the case of ANIMA, the next step is
> the establishment of the ACP, see draft ...  and in the non-ANIMA case we
> expect normal management to take place, ex via NETCONF, ... But I suggest
> to have a reference to the ACP draft.
> 
> CONCERN: I like switching this to ‘enrolled’. Not sure what the rest of the
> suggestion is.
> 
> >
> > 3.2
> > We should re-state here that architecturally, a Pledge ALWAYS interfaces a
> Proxy; if the directly adjacent device happens to be a Registrar, it has to
> present itself to the pledge in the same way a normal Proxy would.
> 
> Fixed.
> "A Proxy is always assumed even if directly integrated into a Registrar”.
> 
> >
> > "the chosen mechanism SHOULD... " - This is the mechanism we specify
> later in the doc, right? (Sounds like this is a requirement outside this doc).
> Then I would re-phrase "the chosen mechanism was designed to …"
> >
> > I disagree with the *general* goal "SHOULD use the minimum amount of
> state on the proxy device." This is a good goal for constrained devices, but in
> a normal network we always try to handle DoS for example as far "out" as
> possible. (We had that discussion a while back).
> >
> > What are we planning to do with draft-richardson-anima-state-for-
> joinrouter? It contains valuable background. Wouldn't it be nice to have that
> as an appendix in brski? (However, then the naming would need to be
> adapted to the brski terminology).
> >
> > Add: "If this bootstrap mechanism is used in an ANIMA context, the proxy
> device will discover Registrar(s) through GRASP based discovery, inside the
> ACP. The connection from the Pledge will also be forwarded inside the ACP."
> A proxy will only be enabled when a device sees a Registrar; if it loses
> connections to all Registrars, it withdraws the proxy service announcements.
> > Or did we decide to leave ANIMA completely out of the draft? (I thought
> we wanted it independent, but ANIMA is still the main use case for now).
> 
> CONCERN: I’d like to hear MCR’s thoughts about this proxy discussion.
> 
> >
> > 3.3
> > I think we need to take a step back here. First, explain that the registrar is
> typically configured. Then, we need to give a bit more context: On one side,
> it expects connections from pledges, on the other we have a CA connection
> and (optionally) a MASA.
> 
> Fixed.
> 
> "A Registrar listens for Pledges and determines if they can join the domain. A
> Registrar obtains either Audit Tokens or Ownership Vouchers from the MASA
> service and delivers them to the Pledge as well as facilitating enrollment with
> the domain PKI. A Registrar is typically configured manually."
> 
> > Then, in an ANIMA context, the Registrar(s) announce their service inside
> the ACP, and they expect to be contacted by proxies through the ACP.
> 
> CONCERN: I agree with the announce point as per the continued GRASP
> discussions (over the ACP). I don’t know that the proxy communications is
> necessarily through the ACP. Holding off on changes to this section until we
> hear from MCR on that.
> 
> >
> > 3.3.2
> > The whole document is focused on the audit method; If this is the main
> method, then we MUST explain the white list here, because neither of the 3
> bullets in this section is sufficient for authorizing exactly "my" devices. (I
> realise white lists appear later on).
> 
> Fixed.
> 
> >
> > Paragraph "In order to validate the IEEE 802.1AR device identity..." belongs
> into 3.3.1.
> 
> Fixed.
> 
> >
> > s/it is expected request/it is expected to request/
> 
> Fixed.
> 
> >
> > "these certificates can subsequently be used to determine the boundaries
> of the homenet..." - remove the homenet references here. I suggest to re-
> phase: "These certificates can be used for other methods, for example
> boundary detection, auto-securing protocols, etc.”.
> 
> Fixed.
> 
> >
> > "The authorization performed during this phase MAY be
> >   cached for the TLS session and applied to subsequent EST enrollment
> >   requests so long as the session lasts." - not clear?!? Each request is for a
> single device. Why cache?
> 
> Fixed.
> I’ve changed it to “is used for”. The point is, and maybe this isn’t clear, that
> the same TLS session is maintained using session resumption so don’t think
> you’re gonna do some other authorization about the certificate issuance.
> 
> >
> > I stop the detailed review here for a moment, since my comments would
> depend too much on how we resolve the question asked above about the 3
> methods. Will resume here once we settled on this...
> >
> >
> >
> > _______________________________________________
> > Anima-bootstrap mailing list
> > Anima-bootstrap@ietf.org
> > https://www.ietf.org/mailman/listinfo/anima-bootstrap