Re: [Anima] Magnus Westerlund's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS)
Michael, Magnus, I want to reinforce a point I made in that previous discussion about pledges using BRSKI with H2 (and by extension QUIC). In this limited case, both present needless overhead both in terms of dev costs and COGS. H2 in particular, and in this particular case, introduces new dev complexity because the provisional trust model used in BRSKI means that you cannot make use of multiple channels within the transport until at least the BRSKI transaction is complete. And once it’s complete, and once EST is complete, the session is expected to terminate(*). When BRSKI is in play, these transactions will happen lock step. Eliot (*) Keep in mind these protocols are used to establish network access. A good analogy is that they are the language used to communicate at the gate with the security guard. Typically one prefers that conversation to be short and to the point, so that one can get on with the business at hand. > On 13 Jul 2019, at 20:41, Michael Richardson wrote: > > > <#secure method=pgpmime mode=sign> > > Magnus Westerlund via Datatracker wrote: >> A. This is really a discuss discuss. With to little time to dig into >> the details it appears that this protocol is making i hack of its >> interface towards the its transport. It appears to attempt to use an >> HTTP rest interface, but then it is also have a lot of talking about >> requirement for the TLS connection underlying the HTTP. So to >> illustrate the issue I see here is what happens if one like to use QUIC >> as the underlying transport for the rest interface rather than TCP/TLS? >> So can this document achieve a clearer interface to the lower layers so >> that it will be simpler to move the protocol to another underlying >> version of the HTTP "transport"? > > Between the JRC (Registrar) and the MASA, we can support any HTTPS, including > HTTP/2 with QUIC (with the 'normal' corporate firewall issue with UDP). > > Between the Pledge and the Registrar, we support any HTTPS that works over a > single TCP connection. We can not support QUIC, since the Pledge is behind > an intentionally limited proxy. We had some discussion about this a year or > so ago, please see: > https://mailarchive.ietf.org/arch/msg/anima/ml1OSEKhR4-ICS0Bd0zfuzn8uw4 > > You are certainly right: we have linkage between the TLS layer and the > application layer, and we expect TLSClientCertificates and > TLSServerCertificates to have meaning at the application layer. > > None of the connections could go through TLS "forced proxies" of the kind > that are apparently common in Enterprises. > > I am open to suggestions on how to make the document clearer about how it > interfaces to TLS. We have a sections: >5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 36 >5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 38 > > > >> B. Section 5.6: > >> The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616] error >> code when a problem occurs. > >> Referencing RFC 2616 that has been obsolete by RFC 7230 and >> companions. I do note that there are no normative reference for that >> part in this document. > > Fixed to 7230. > Yes, that wasn't even a real reference, just a literal [RFC2616]. > > -- > ] 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 > [ > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > ___ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima signature.asc Description: Message signed with OpenPGP ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Eliot> I think the simplest way to address the bulk of both Adam’s and Eliot> Warren’s concern is to require the device to emit via whatever Eliot> management interface exists, upon request, a voucher that it has Eliot> signed with its own iDevID. It would have to be nonceless with Eliot> perhaps a long expiry, and that would cover a number of other use Eliot> cases as well. That way if the manufacturer goes out of business, or Eliot> if the owner wants to transfer the device without manufacturer Eliot> consent, there is a way forward. Benjamin Kaduk wrote: > An interesting thought. Would there be a way (or a need) to usefully > audit such voucher issuance? The vendor would be unable to provide any record of them being issued. The device could provide an audit log. Perhaps we could use some kind of merkle tree such that every such voucher had a record of all previous ones, going back to the original MASA issue voucher. I had originally considered this to be the right way to do resale, but many others thought it too complex. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Eliot Lear wrote: > Whether such a voucher would be pinned is something we do not have to > specify, with the risks of it not being pinned being born by the owner. I beg to differ! I think that the security properties are vastly different. It's why we decided when creating RFC8366 not to do bearer tokens. We simply didn't think we were competent enough to specify it tightly enough to not become a security disaster. An unpinned voucher is some kind of bearer token, and if disclosed has significant operational risk. As such, keeping it around/online is a serious issue. A voucher pinned to the public part of a keypair whose private key is kept offline (to be turned over to a new owner) is different because there are potentially far fewer things to keep private. Worse case, it's perhaps the same, I would agree. The bigger problem is that I don't see a way to define such an artifact in a timely fashion, nor do I know which WG we'd do it in. -- ] 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[ signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
I presume I am missing something basic. I have tried to follow this discussion, as it seems to be about a critical aspect of whether the BRSKI work is acceptable. I have assumed that what we needed is the ability for a buyer, who has physical possession of the device, and possibly some simple (non cryptographic) credentials provided by the seller to force the device to reset what it thinks it is part of, and to emit in some accessible form the information the buyer needs to be able to make this device part of his network, using his authentication servers, etc. Have I got the wrong end of the stick? Joel On 7/14/2019 5:33 PM, Michael Richardson wrote: Eliot Lear wrote: > Whether such a voucher would be pinned is something we do not have to > specify, with the risks of it not being pinned being born by the owner. I beg to differ! I think that the security properties are vastly different. It's why we decided when creating RFC8366 not to do bearer tokens. We simply didn't think we were competent enough to specify it tightly enough to not become a security disaster. An unpinned voucher is some kind of bearer token, and if disclosed has significant operational risk. As such, keeping it around/online is a serious issue. A voucher pinned to the public part of a keypair whose private key is kept offline (to be turned over to a new owner) is different because there are potentially far fewer things to keep private. Worse case, it's perhaps the same, I would agree. The bigger problem is that I don't see a way to define such an artifact in a timely fashion, nor do I know which WG we'd do it in. ___ 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] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Eliot Lear wrote: > I think the simplest way to address the bulk of both Adam’s and > Warren’s concern is to require the device to emit via whatever > management interface exists, upon request, a voucher that it has signed > with its own iDevID. It would have to be nonceless with perhaps a long > expiry, and that would cover a number of other use cases as well. That > way if the manufacturer goes out of business, or if the owner wants to > transfer the device without manufacturer consent, there is a way > forward. 1) would it have a pinned-domain-cert for the new owner, or would it be some kind of wildcard/bearer voucher? 2) what would the management interface be, specifically, how would it be secured? This would seem to cover the case where there is an orderly sale of equipment From an owner who is still in business to a new owner who is ready to receive the device. In my experience buying used routing equipment, this is never the case. The best case is that equipment was removed from active service 6 to 10 months previously, stored somewhere until it was certain that no spares would be required, and then sold on eBay directly to the buyer. Creating this new voucher would require that the sellor spin the systems up, hook them back onto some management interface (which effectively means going through the onboarding process again, since their IP addresses will be wrong, having been replaced), and then getting a voucher issued for the buyor's domainID. Is this ridiculous? No. Knowing that the systems boot (and haven't rotted), and knowing that the old configurations have correctly wiped is pretty good hygiene. Often the systems are purchased by a used equipment broker, and having the broker issue an intermediate (could be time limited) voucher to themselves would be reasonable as they take the systems into their inventory. In larger sales, the broker could provide personnel to do the spin-up at the sellor's location. The sellor *could* generate that voucher themselves before the device is taken offline, linking the voucher to a newly generated domain owner keypair. This effectively is now a bearer voucher. At which point one could consider some other kind of existing technology: a TLS session resumption ticket (issued by the BRSKI client to the Registrar) might make more sense. It has all the properties of a bearer voucher, and all the risks, but is well established mechanism. I would be happy to start a draft that explained this process. It's something that I wish we have a SEC-AREA BRSKI WG to make sure we get this right. In the worst case, the reason the equipment is being sold is because the sellor went into bankruptcy. There is no sellor Registrar to invoke this API. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
