Re: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI
> but there are significant benefits to not maintaining your own protocols, and > significant benefits to getting the extensive review that TLS gets. I could not agree more with this statement. Thanks, --Jack -Original Message- From: Michael Richardson Sent: Saturday, August 10, 2019 5:16 PM To: Jack Visoky ; Randy Armstrong (OPC) ; iot-onboard...@ietf.org; anima@ietf.org Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI Jack Visoky wrote: > I am also involved with OPC-UA and would like to provide my/my > company's perspective. One of the major drivers of this engagement > with the ANIMA group was a contentious point around whether or not TLS > and EST are required for support of BRSKI. Some of us had taken the > position that these technologies are an integral part of BRSKI and > shouldn't be replaced with OPC specific methods, especially given the > benefit of using highly adopted security technologies, as well as the > tight coupling of BRSKI to these. So, I think the idea that OPC should > just use these technologies is very much a viable answer. If the device is powered or has enough battery to do 802.11, then it probably has enough power and code space to do TLS (particularly mbedtls from ARM). If it's on a very low duty cycle on battery, and/or it does 802.15.4, then the question is still open. The IETF may start work on a 802.15.4 specific AKE, (see l...@ietf.org). We believe we need these for 6tisch (TSCH mode of 802.15.4 for deterministic industrial networks) It appears that the OPC UA methods provide enough security to do BRSKI, but there are significant benefits to not maintaining your own protocols, and significant benefits to getting the extensive review that TLS gets. > Also, I would strongly push back on any claims that low end OPC devices > cannot support TLS. Other industrial protocols have already added TLS > support and are shipping products, including those with TLS client > functionality. TLS is no more heavy-weight than existing, OPC-specific > security mechanisms. The OPC-specific mechanism appears to avoid a DH operation and therefore lacks PFS. I understand it uses RSA, which means that it's significantly more expensive than TLS with ECDSA (and ECDH) would be, and most SOCs have hardware acceleration for ECDSA's secp256v1, fewer have RSA acceleration. > In any event I will be sure to join the call that has been set up for > later in August. Awesome. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT 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
Re: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI
> I think so; there are some details of resale that BRSKI would like to make > out-of-scope for the first document. Some way, we have to deal with it, and > I would actually like feedback from OPC about the parameters of different > solutions here. So in this case would the MASA need to be OPC specific, that is, use OPC Security and OPC methods? Apologies if I'm getting ahead of myself on this conversation. Thanks, --Jack -Original Message- From: Michael Richardson Sent: Saturday, August 10, 2019 9:08 PM To: Randy Armstrong (OPC) Cc: Jack Visoky ; iot-onboard...@ietf.org; anima@ietf.org Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI Randy Armstrong (OPC) wrote: > The questions that the OPC WG needs to answer are: > 1) Can BRSKI meet our requirements? I think so; there are some details of resale that BRSKI would like to make out-of-scope for the first document. Some way, we have to deal with it, and I would actually like feedback from OPC about the parameters of different solutions here. > 2) If the answer to 1) is yes then can it work with OPC UA security? yes, I think so. is there any open source reference code for the OPC UA security? > 3) If the answer to 2) is no then do we use TLS or extend our own model > with something like BRSKI but not BRSKI? > While I cannot predict how the various participants in the OPC WGs will > respond to question 3), I do know it would make collaboration a lot > easier if the answer to 2) was yes. I think yes. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Iot-onboarding] EXTERNAL: Re: OPC and BRSKI
Randy Armstrong (OPC) wrote: > 1) As it stands today BRSKI is pull model only and the push model is > out of scope but I don't see why that has to be the case once you allow > for different protocols between the Device and the Registrar. With our > proposed OPC mapping we would define a Registrar that supports both > models. Is this of any interest to the IETF or would it be an OPC only > thing? There are a number of reasons to think a push model is also workable. I'm unclear if OPC needs to onboard devices into a wireless network or if everything is wired. This matters because the new device has to announce its presence to the Registrar for push to work. For instance, you could take a look at: https://tools.ietf.org/html/draft-richardson-6tisch-dtsecurity-secure-join-01 which is an old version of the constrained-BRSKI mechanism. Section 3, (3.2) explains how the Registrar would reach out to the Pledge using the 6tisch 6p protocol (when it ran over IPv6). > 2) Perhaps the most value from BRSKI comes not from the MASA per se but > the voucher format (i.e. a digitally signed document with a standard > format). We could meet a lot of our requirements if we had a voucher > which has a list of nonce-less or bearer vouchers shipped to a > particular location for use by a particular end user. We could create > workflows where the manufacturer/distributor has to create this > document when devices are delivered. The document could be delivered > via the MASA or via some other B2B exchange or even on a USB > stick. However it is delivered it can then be read by the Registrar and > use it to build a whitelist of Devices allowed on the network. RFC 8572 -- Secure Zero Touch Provisioning (SZTP) may suit you better. It also uses RFC8366 vouchers. > I am also thinking that this voucher would be a good application for > block chain where instead of a bearer voucher we define a mechanism > where the owner the device could append a "block" to the original > voucher which authorizes the transfer to new owner. We considered distributed ledgers for the audit log. In all distributed ledgers, you have to ask: 1) are there mutually distrusting parties? 2) what do they need to agree upon? 3) what is the incentive for a third party to validate the chain? What you have described above, however, is just a certificate chain. No Block Required. https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00 Describes an early notion of how vouchers work, and notice how it delegates at each step. Subsequent sales just extend the chain. We didn't go this way because: 1) it mandates sales channel integration, and we think that this will be rare at the beginning. 2) any party in the chain can issue a new sale certificate, effectively stealing the device from the current owner. -- 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] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI
Jack Visoky wrote: >> I think so; there are some details of resale that BRSKI would like to >> make out-of-scope for the first document. Some way, we have to deal >> with it, and I would actually like feedback from OPC about the >> parameters of different solutions here. > So in this case would the MASA need to be OPC specific, that is, use > OPC Security and OPC methods? Apologies if I'm getting ahead of myself > on this conversation. I don't think that the MASA would be OPC specific. The Registrar would have to speak the OPC security rather than HTTPS on the plant side. The Registrar would still speak HTTPS to the MASA. This is what we have done in draft-ietf-anima-constrained-voucher: it speaks CoAPS (CoAP over DTLS) or OSCORE-EDHOC (CoAP with OSCORE, keyed by EDHOC) on the plant side, and HTTPS to the Registrar. There are (at least) two major ways to build a Registrar. 1) a single monolithic application framework, it receives the voucher-request, and then does a synchronous HTTPS request to the MASA. (Perhaps doing 100-Continue). 2) The other way is for the pledge-facing part of the Registrar to put it all into a database, return 202, and wait for another query. Asynchronously some other part sends requests to the MASA and stores the answers back in the database. Perhaps the only thing connecting the two parts is some multi-master database replication... Case 1 is appropriate up to a certain level of load and complexity. It's certainly way easier to test! Case 2 has scaling advantages, some security advantages, and also makes it way easier to build different plant facing interfaces. I believe that all implementations are case 1 so far. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT 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] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI
Hi Toerless, Just responding to one of your points, a colleague of mine from Cisco (Nancy Cam-Winget) and I have created a draft for authentication-only data protection for TLS 1.3. We've registered the cipher suites and will be going through the Independent Review for this RFC soon. If you, Michael, or even others would like to serve as reviewers we'd be grateful. Link to RFC: https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-04 Thanks, --Jack -Original Message- From: Anima On Behalf Of Toerless Eckert Sent: Monday, August 12, 2019 2:50 PM To: Jack Visoky Cc: Michael Richardson ; Randy Armstrong (OPC) ; anima@ietf.org; iot-onboard...@ietf.org Subject: Re: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI Agreeing to what Michael and you said, but also wanted to point out that TLS as defined by IETF is on a trajectory which may or may not be desirable for e.g.: industrial automation (where OPC is used) or other regulated/ critical environments. For example the total elimination of any non-encryption option in the TLS1.3 profile and the removal of the ability for passive observers to see the certificates exchanged impeeds severely on the ability to do passive diagnostics. I at least think there are good reasons to also have a strong and independent reviewed authentication scheme without encryption that can well be diagnosed by passive observers. Aspects like these are easily fixed IMHO by creating different profiles of TLS. Whether or not one could get such profiles through the TLS WG in the IETF is of course a different question given what seems to be a highly contentuous nature of the topic. There also seems to be a desire of areas of industrial automation to avoid the overhead of a perceived to be redundant network layer. This was a thing back in the days of OSI where TP4 was often run in factories without CLNS, and given how IP hasn't really improved on simplified, automated address management vs. L2 switched ethernet, this still seems to be a thing. Aka: Someone would need to define TLS on top of just ethernet instead of IP/IPv6. And there may be other similar L2 "transport" technologies where its not clear if simple ethernet mappings would suffice (bluetooth, wifi,...). Last but not least, QUIC is on a path to replace TLS and that too puts a dent into the belief that TLS as it stands would be a long term stable most-widely used protocol. Finally: There is something said to not simply trust a design like TLS which you do not really understand just because its widely used, and thus hopefully well reviewed, but rather make sure you have a design based on solid understanding of the cryptographic principles employed and a well defined review/control process of implementations. Incidents like with OpenSSL show how badly reviewed even the most widely deployed crypto mechanisms can be. Cheers Toerless On Sun, Aug 11, 2019 at 09:31:22PM +, Jack Visoky wrote: > > but there are significant benefits to not maintaining your own protocols, > > and significant benefits to getting the extensive review that TLS gets. > > I could not agree more with this statement. > > Thanks, > > --Jack > > > -Original Message- > From: Michael Richardson > Sent: Saturday, August 10, 2019 5:16 PM > To: Jack Visoky ; Randy Armstrong (OPC) > ; iot-onboard...@ietf.org; > anima@ietf.org > Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI > > > Jack Visoky wrote: > > I am also involved with OPC-UA and would like to provide my/my > > company's perspective. One of the major drivers of this engagement > > with the ANIMA group was a contentious point around whether or not TLS > > and EST are required for support of BRSKI. Some of us had taken the > > position that these technologies are an integral part of BRSKI and > > shouldn't be replaced with OPC specific methods, especially given the > > benefit of using highly adopted security technologies, as well as the > > tight coupling of BRSKI to these. So, I think the idea that OPC should > > just use these technologies is very much a viable answer. > > If the device is powered or has enough battery to do 802.11, then it probably > has enough power and code space to do TLS (particularly mbedtls from ARM). > If it's on a very low duty cycle on battery, and/or it does 802.15.4, > then the question is still open. The IETF may start work on a > 802.15.4 specific AKE, (see l...@ietf.org). We believe we need these > for 6tisch (TSCH mode of 802.15.4 for deterministic industrial > networks) > > It appears that the OPC UA methods provide enough security to do BRSKI, but > there are significant benefits to not maintaining your own protocols, and > significant benefits to getting the extensive review that TLS gets. > > > Also, I would strongly push back on any claims that low end OPC devices > > cannot support TLS. Other
Re: [Anima] comments on draft-ietf-anima-grasp-api
Hi Toerless, Yes, I think your model is correct. Three more comments below, then I will leave this alone until we revise the draft: On 13-Aug-19 07:10, Toerless Eckert wrote: > On Sat, Aug 10, 2019 at 11:23:20AM +1200, Brian E Carpenter wrote: >> Hi Toerless, >> >> If there was only one operating system in the world, I guess we could >> describe this. The challenge I see is that the way to solve this may >> be drastically different in different o/s environments, depending on >> what sort of IPC is available between contexts. So apart from saying >> that an implementation needs to do this, I'm not sure how much we can say. > > The transport of the API is of course always system specific. But thats > not unique to the API between core and library, it equally extends > to the API between library and ASA. So threre is IMHO no need to > consider the library/core API to be any more proprietary than the > ASA/library API. > >> I did try to build an IPC interface into my Python implementation, >> but the only way I could see that produced portable code was to >> use a standard socket as the IPC mechanism. That works, but it's >> pretty clumsy and seems very inefficient for production use. > > None of the currently popular OSs seems to have OS mechanisms that > would make API calls into a daemon as easy as they are into the > OS kernel. Nevertheless, more and more services code gets built > as daemons for flexiblity and modularily reasons. Just got to > suck up the overhead and live with it. Not a GRASP specific issue. > >> However, it did show me that you are correct. There are some GRASP >> functions that really need to be in a daemon** because they run on >> their own even if there's no ASA in the node, and others that need >> to be callable from multiple ASAs. The API as currently defined >> only concerns those callable functions. You're actually asking for >> the scope of the API draft to be expanded. > > I gave two options: Either eliminate the distinction between library > and core or introduce better text to justify that distinction, and > i think the strongest way to do that is to define the API between > them. Which i think is not much different from the one ASA/library. > >> 2nd level however: The daemon and the callable functions need to share >> some common stateful data structures, which I suppose are somewhat >> implementation-dependent, but the ones I found necessary are: >> >> _asa_registry ??? where ASAs are registered >> _obj_registry ??? where objectives are registered >> _discovery_cache ??? where locators for discovered objectives are cached >> _session_id_cache ??? where GRASP sesssion ids and ASA nonces are cached. >> _flood_cache ??? where flooded objectives and their values are cached. > > I don't think you need to elaborate on that level of detail. > Just think of the library as something that provides on its > northbound the API you specified, and on its southbound to the > core it uses almost the same API, Yes, that's essentially what my version with an IPC interface does, but I didn't release that to GitHub because it really is cobbled together and very Python-specific. > and the only thing that the > library can really do by itself is to directly build those > TLS unicast connections to remote GRASP peers. So its really > a demultiplexer between passing calls from/to the core and its > own maintained TLS connections. In fact I delegated all the TCP to the core as well, but that was an implementation choice not a necessity. > >> ** In fact I needed to provide a way to activate such a daemon, because >> Michael and Bill discovered that they needed to do so by hand during >> the hackathon last month. It's called gremlin.py and contains 4 lines >> of code. > > IMHO, it should be started when system comes up. Yes. Just for fun, it does now come up when my laptop boots, but there doesn't seem to be any other GRASP traffic on my home LAN :-(. Brian > In a reasonable secure > envirnment, a normal ASA shouldn't have permission to provide > system level services, because ASA IMHO are more like user provided > applications and each of them should be able to be less trustworthy > than a system level function like GRASP discovery. > > One could say this is an implementation detail, but i think it would > add one reason to talking about separarte library/core: Distinction > between "ASA user" and system context. > > Cheers > Toerless > >> Thanks >>Brian >> >> P.S. We'll wait for Guangpeng's promised review before we revise the >> draft. >> >> On 10-Aug-19 07:43, Toerless Eckert wrote: >>> >>> Hi Brian, * >>> >>> I have right now primarily a high level comment: >>> >>> The problem i have with the three layers of GRASP is that there >>> is no good justification why they exist and why the API document >>> needs to bother about them. The doc really only talks about the >>> library of the GRASP Library. >>> >>> This is not to say that i do not like the idea to talk
Re: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI
Agreeing to what Michael and you said, but also wanted to point out that TLS as defined by IETF is on a trajectory which may or may not be desirable for e.g.: industrial automation (where OPC is used) or other regulated/ critical environments. For example the total elimination of any non-encryption option in the TLS1.3 profile and the removal of the ability for passive observers to see the certificates exchanged impeeds severely on the ability to do passive diagnostics. I at least think there are good reasons to also have a strong and independent reviewed authentication scheme without encryption that can well be diagnosed by passive observers. Aspects like these are easily fixed IMHO by creating different profiles of TLS. Whether or not one could get such profiles through the TLS WG in the IETF is of course a different question given what seems to be a highly contentuous nature of the topic. There also seems to be a desire of areas of industrial automation to avoid the overhead of a perceived to be redundant network layer. This was a thing back in the days of OSI where TP4 was often run in factories without CLNS, and given how IP hasn't really improved on simplified, automated address management vs. L2 switched ethernet, this still seems to be a thing. Aka: Someone would need to define TLS on top of just ethernet instead of IP/IPv6. And there may be other similar L2 "transport" technologies where its not clear if simple ethernet mappings would suffice (bluetooth, wifi,...). Last but not least, QUIC is on a path to replace TLS and that too puts a dent into the belief that TLS as it stands would be a long term stable most-widely used protocol. Finally: There is something said to not simply trust a design like TLS which you do not really understand just because its widely used, and thus hopefully well reviewed, but rather make sure you have a design based on solid understanding of the cryptographic principles employed and a well defined review/control process of implementations. Incidents like with OpenSSL show how badly reviewed even the most widely deployed crypto mechanisms can be. Cheers Toerless On Sun, Aug 11, 2019 at 09:31:22PM +, Jack Visoky wrote: > > but there are significant benefits to not maintaining your own protocols, > > and significant benefits to getting the extensive review that TLS gets. > > I could not agree more with this statement. > > Thanks, > > --Jack > > > -Original Message- > From: Michael Richardson > Sent: Saturday, August 10, 2019 5:16 PM > To: Jack Visoky ; Randy Armstrong (OPC) > ; iot-onboard...@ietf.org; anima@ietf.org > Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI > > > Jack Visoky wrote: > > I am also involved with OPC-UA and would like to provide my/my > > company's perspective. One of the major drivers of this engagement > > with the ANIMA group was a contentious point around whether or not TLS > > and EST are required for support of BRSKI. Some of us had taken the > > position that these technologies are an integral part of BRSKI and > > shouldn't be replaced with OPC specific methods, especially given the > > benefit of using highly adopted security technologies, as well as the > > tight coupling of BRSKI to these. So, I think the idea that OPC should > > just use these technologies is very much a viable answer. > > If the device is powered or has enough battery to do 802.11, then it probably > has enough power and code space to do TLS (particularly mbedtls from ARM). > If it's on a very low duty cycle on battery, and/or it does 802.15.4, then > the question is still open. The IETF may start work on a 802.15.4 specific > AKE, (see l...@ietf.org). We believe we need these for 6tisch (TSCH mode of > 802.15.4 for deterministic industrial networks) > > It appears that the OPC UA methods provide enough security to do BRSKI, but > there are significant benefits to not maintaining your own protocols, and > significant benefits to getting the extensive review that TLS gets. > > > Also, I would strongly push back on any claims that low end OPC devices > > cannot support TLS. Other industrial protocols have already added TLS > > support and are shipping products, including those with TLS client > > functionality. TLS is no more heavy-weight than existing, OPC-specific > > security mechanisms. > > The OPC-specific mechanism appears to avoid a DH operation and therefore > lacks PFS. I understand it uses RSA, which means that it's significantly > more expensive than TLS with ECDSA (and ECDH) would be, and most SOCs have > hardware acceleration for ECDSA's secp256v1, fewer have RSA acceleration. > > > In any event I will be sure to join the call that has been set up for > > later in August. > > Awesome. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker wrote: > Section 13.2 > I think CDDL needs to be a normative reference, as does RFC 7231. RFC > 2473 is listed but not referenced in the text, as are RFC 2663, RFC > 7217, and RFC 7575. CDDL->RFC8610, now normative. (Glad that got published) RFC2473 removed, we no longer attempt to document a stateless IPIP proxy mechanism. RFC2663 (NAT terminology) reference was for Join Proxy, and I've restored a reference in section 4. RFC7217 was thought to be relevant to Pledge use of SLAAC, but actually it's not, removed. You are right that we don't reference RFC7575, which is the architecture of ANIMA. I have added a sentence to the Intro, referencing RFC7575's goal of "secure by default" > Appendix B doc>Discovery of registrar MAY also be performed with DNS-based service doc> discovery by searching for the service "_brski- doc> registrar._tcp.example.com". In this case the domain "example.com" is doc> discovered as described in [RFC6763] section 11 (Appendix A.2 suggests doc> the use of DHCP parameters). > I'd suggest using "" per 6763 rather than "example.com". okay. doc>If no local proxy or registrar service is located using the GRASP doc> mechanisms or the above mentioned DNS-based Service Discovery methods doc> the pledge MAY contact a well known manufacturer provided bootstrapping doc> server by performing a DNS lookup using a well known URI such as doc> "brski-registrar.manufacturer.example.com". The details of the URI are doc> manufacturer specific. Manufacturers that leverage this method on the doc> pledge are responsible for providing the registrar service. Also see doc> Section 2.7. > It seems like there are some security considerations for device owners > that may wish to prevent such registrars from being used. Do we need > to direct them to run a firewall or similar? If they are doing ANIMA ACP bootstrapping, then there would ideally be no IPv4 available, and so this won't work anyway. I'd rather not get into too much of this here. > Appendix C > I don't know how important file "ietf-mud-extens...@2018-02-14.yang" > is, but it seems a tad generic. Renamed already. Ben, I'm posting the -25, and then moving on back to the responses to my responses, including Adam's concerns. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT 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] MACsec as an alternative to L3-tunnels
Hi, In the context of the L2ACP draft (draft-carpenter-anima-l2acp-scenarios): It seems that MACsec keying and associations are generally pair-wise, but IEEE Std 802.1AE-2018 says: "The guarantees provided by MACsec support the following security services for stations participating in MACsec: a) Connectionless data integrity [6.8a), 6.8b)] b) Data origin authenticity [6.8a)]. If the connectivity model is point-to-point, the originator is authenticated, but _if the connectivity model is multipoint, then the authenticated originator is any member of the CA, rather than a particular individual station._ c) Confidentiality [6.8d)] d) Replay protection [6.8c), 6.8d)] e) Bounded receive delay" Also 802.1 bridges do forward MACsec. So multicast should work. However 1) This does not carry over to 802.11. An L2ACP that was a mixture of 802.1 and 802.11 would need to deal with two different security solutions. 2) On 25-Jul-19 11:03, Michael Richardson wrote: > I was asked to decode words mangled at the mic at Tuesday morning's ANIMA > meeting. > The word was "MACsec", and > https://en.wikipedia.org/wiki/IEEE_802.1AE > https://1.ieee802.org/security/802-1ae/ > > provides a reasonable description, and probably the getieee mechanism > might get you a copy for free, but IEEE doesn't have a URL that > leads to the actual document. I did read it once. > (One of the URLs in the wikipedia page leads to 404) > > https://ieeexplore.ieee.org/document/8585421 > might get you the document if you have a valid password, which > I used to, but apparently not anymore. We should use the 2018 version of the standard, which should be freely available via https://ieeexplore.ieee.org/browse/standards/get-program/page > Given my newly acquired understanding that MACsec applies on a per-port > basis, not on a per-VLAN basis, this means that it would be rather difficult > to do peer discovery and security for a L2-bridged LAN. As I read the current standard, it should work, but if you do MACsec then the user plane VLAN is apparently protected by the same keys as the ACP VLAN. However, the two VLANs would still be completely protected from each other by 802.1Q, so I think it's OK. On 31-Jul-19 08:41, Toerless Eckert wrote: > I think my reference was more to what chips can do as to what > necessarily existing standaerds may say. There is this one issue of > having an 802.1ae capable switch port connected via a hub to multiple > host, in which case you could imagine to use a different set of keys to > each host but the public vendor documentation i found was quite > inconclusive whether this actually works in todays products. Yes, Google finds various different proprietary explanations that seem incompatible. Re the VLAN question, StackExchange says: "There is no standard for MACSec and 802.1Q, so manufacturers have come up with their own solutions." That is no longer true; 802.1AE-2018 explains exactly how it co-exists with 802.1Q. But I doubt if the products have all been updated yet. We need an expert. I like this explanation, but it's now out of date: https://developers.redhat.com/blog/2016/10/14/macsec-a-different-solution-to-encrypt-network-traffic/ Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
https://tinyurl.com/yylruorn contains a diff against -24. Benjamin Kaduk via Datatracker wrote: > Section 5.8.1 doc>A log data file is returned consisting of all log entries associated doc> with the the device selected by the IDevID presented in the request. doc> The audit log may be truncated of old or repeated values as explained doc> below. The returned data is in JSON format ([RFC7951]), and the doc> Content-Type SHOULD be "application/json". For example: > If RFC 7951 is to be used, I'd suggest "is JSON-encoded YANG data". Typo, it should be 7159. doc>This document specifies a simple log format as provided by the MASA doc> service to the registrar. This format could be improved by distributed doc> consensus technologies that integrate vouchers with technologies such doc> as block-chain or hash trees or optimized logging approaches. Doing so doc> is out of the scope of this document but is an anticipated improvement doc> for future work. As such, the registrar client SHOULD anticipate new doc> kinds of responses, and SHOULD provide operator controls to indicate doc> how to process unknown responses. > This would be a great place to talk about the "version" field that's > otherwise ignored. As in, what should occur if the "version" is not 1? How about: A registrar that sees a version value greater than 1 indicates an audit log format that has been enhanced with additional information. No information will be removed in future versions; should an incompatible change be desired in the future, then a new HTTP end point will be used. doc>anticipated improvement for future work. As such, the registrar doc> client SHOULD anticipate new kinds of responses, and SHOULD provide doc> operator controls to indicate how to process unknown responses. > Is "registrar client" intended to be both words or just one? Probably not, removed. doc>A registrar SHOULD use the log information to make an informed doc> decision regarding the continued bootstrapping of the pledge. The > I may be confused, but I thought the registrar was asking for the log > after the voucher had already been issued. Are these check supposed to > keep the registrar from forwarding the voucher to the pledge, or just > as a check for future renewal operations? The voucher can be returned to the Pledge immediately, as there is never any issue about whether the Pledge should join. The MASA has already made that decision. The Registrar could avoid passing the voucher on until after the audit log checks are done, or could do that concurrently. What matters is that the audit log checks are done prior to the Registrar accepting an enroll request.This is down in (what is now) Figure 4. The Registrar may do additional checks of the audit log at later times, but I don't think we have any good advice on this yet. doc>A relatively simple policy is to white list known (internal or doc> external) domainIDs and to require all vouchers to have a nonce and/ or doc> require that all nonceless vouchers be from a subset (e.g. only doc> internal) domainIDs. A simple action is to revoke any locally issued > nit: missing "of" I don't know where the "of" that is missing goes. While investigating, I broke the big sentence up, and discovered that the 5209 reference was not coded as XML. Please clue me in what you mean... A relatively simple policy is to white list known (internal or external) domainIDs. To require all vouchers to have a nonce. Alternatively to require that all nonceless vouchers be from a subset (e.g. only internal) domainIDs. If the policy is violated a simple action is to revoke any locally issued credentials for the pledge in question or to refuse to forward the voucher. The Registrar MUST then refuse any EST actions, and SHOULD inform a human via a log. A registrar MAY be configured to ignore (i.e. override the above policy) the history of the device but it is RECOMMENDED that this only be configured if hardware assisted (i.e. TPM anchored) Network Endpoint Assessment (NEA) is supported. doc>credentials for the pledge in question or to refuse to forward the doc> voucher. A registrar MAY be configured to ignore the history of the > "simple action" in the case that the registrar doesn't like the audit > log results? See changes above for better clarity. >device but it is RECOMMENDED that this only be configured if > hardware assisted NEA [RFC5209] is supported. > Probably need to expand NEA. done, see above. > Section 5.9 doc>Although
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
WG: there is a chunk of Security Considerations text here that I hope
many will read.
Benjamin Kaduk via Datatracker wrote:
> Section 11.4
> It is not entirely clear to me whether device manufacturers are set up
> with incentives to maintain a well-run secure CA with strong hardware
> protections on the offline signing key for the root CA, cycling through
> various levels of intermediates, etc., that CAs in the Web PKI do
> today. If the manufacturer uses a less stringent process, that would
> leave the manufacturer's key as a more tempting attack surface, and it
> may be worth some discussion here about what damage could be done with
> a compromised MASA signing key. E.g., would an attack require
> restoring devices to factory defaults or otherwise waiting for natural
> bootstrapping events to occur? Would the attacker need to be on-path?
> Etc.
I wanted to add that I think that there are some interesting economic
discussions about these incentives. I wonder how to interest some people
into doing some analysis of a monetary rather that technical manner.
I have added:
11.4. Manufacturer Maintenance of trust anchors . . . . . . . 75
11.4.1. Compromise of Manufacturer IDevID signing keys . . . 77
11.4.2. Compromise of MASA signing keys . . . . . . . . . . 77
11.4.3. Compromise of MASA web service . . . . . . . . . . . 79
and this text is rough, and as yet unreviewed by anyone, and I
11.4. Manufacturer Maintenance of trust anchors
BRSKI depends upon the manufacturer building in trust anchors to the
pledge device. The voucher artifact which is signed by the MASA will
be validated by the pledge using that anchor. This implies that the
manufacturer needs to maintain access to a signing key that the
pledge can validate.
The manufacturer will need to maintain the ability to make signatures
that can be validated for the lifetime that the device could be
onboarded. Whether this onboarding lifetime is less than the device
lifetime depends upon how the device is used. An inventory of
devices kept in a warehouse as spares might not be onboarded for many
decades.
There are good cryptographic hygiene reasons why a manufacturer would
not want to maintain access to a private key for many decades. A
manufacturer in that situation can leverage a long-term certificate
authority anchor, built-in to the pledge, and then a certificate
chain may be incorporated using the normal CMS certificate set. This
may increase the size of the voucher artifacts, but that is not a
significant issues in non-constrained environments.
There are a few other operational variations that manufacturers could
consider. For instance, there is no reason that every device need
have the same set of trust anchors pre-installed. Devices built in
different factories, or on different days, or any other consideration
could have different trust anchors built in, and the record of which
batch the device is in would be recorded in the asset database. The
manufacturer would then know which anchor to sign an artifact
against.
Aside from the concern about long-term access to private keys, a
major limiting factor for the shelf-life of many devices will be the
age of the cryptographic algorithms included. A device produced in
2019 will have hardware and software capable of validating algorithms
common in 2019, and will have no defense against attacks (both
quantum and von-neuman brute force attacks) which have not yet been
invented. This concern is orthogonal to the concern about access to
private keys, but this concern likely dominates and limits the
lifespan of a device in a warehouse. If any update to firmware to
support new cryptographic mechanism were possible (while the device
was in a warehouse), updates to trust anchors would also be done at
the same time.
The set of standard operating proceedures for maintaining high value
private keys is well documented. For instance, the WebPKI provides a
number of options for audits at {{cabforumaudit}}, and the DNSSEC
root operations are well documented at {{dnssecroot}}.
It is not clear if Manufacturers will take this level of precaution,
or how strong the economic incentives are to maintain an appropriate
level of security.
This next section examines the risk due to a compromised MASA key.
This is followed by examination of the risk of a compromised
manufacturer IDevID signing key. The third section sections below
examines the situation where MASA web server itself is under attacker
control, but that the MASA signing key itself is safe in a not-
directly connected hardware module.
11.4.1. Compromise of Manufacturer IDevID signing keys
An attacker that has access to the key that the manufacturer uses to
sign IDevID certificates can create
[Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-25.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Toerless Eckert Michael H. Behringer Kent Watsen Filename: draft-ietf-anima-bootstrapping-keyinfra-25.txt Pages : 107 Date: 2019-08-12 Abstract: This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a Remote Secure Key Infrastructure (BRSKI) is created using manufacturer installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping to is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-25 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-25 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-25 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/ ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] comments on draft-ietf-anima-grasp-api
On Sat, Aug 10, 2019 at 11:23:20AM +1200, Brian E Carpenter wrote: > Hi Toerless, > > If there was only one operating system in the world, I guess we could > describe this. The challenge I see is that the way to solve this may > be drastically different in different o/s environments, depending on > what sort of IPC is available between contexts. So apart from saying > that an implementation needs to do this, I'm not sure how much we can say. The transport of the API is of course always system specific. But thats not unique to the API between core and library, it equally extends to the API between library and ASA. So threre is IMHO no need to consider the library/core API to be any more proprietary than the ASA/library API. > I did try to build an IPC interface into my Python implementation, > but the only way I could see that produced portable code was to > use a standard socket as the IPC mechanism. That works, but it's > pretty clumsy and seems very inefficient for production use. None of the currently popular OSs seems to have OS mechanisms that would make API calls into a daemon as easy as they are into the OS kernel. Nevertheless, more and more services code gets built as daemons for flexiblity and modularily reasons. Just got to suck up the overhead and live with it. Not a GRASP specific issue. > However, it did show me that you are correct. There are some GRASP > functions that really need to be in a daemon** because they run on > their own even if there's no ASA in the node, and others that need > to be callable from multiple ASAs. The API as currently defined > only concerns those callable functions. You're actually asking for > the scope of the API draft to be expanded. I gave two options: Either eliminate the distinction between library and core or introduce better text to justify that distinction, and i think the strongest way to do that is to define the API between them. Which i think is not much different from the one ASA/library. > 2nd level however: The daemon and the callable functions need to share > some common stateful data structures, which I suppose are somewhat > implementation-dependent, but the ones I found necessary are: > > _asa_registry ??? where ASAs are registered > _obj_registry ??? where objectives are registered > _discovery_cache ??? where locators for discovered objectives are cached > _session_id_cache ??? where GRASP sesssion ids and ASA nonces are cached. > _flood_cache ??? where flooded objectives and their values are cached. I don't think you need to elaborate on that level of detail. Just think of the library as something that provides on its northbound the API you specified, and on its southbound to the core it uses almost the same API, and the only thing that the library can really do by itself is to directly build those TLS unicast connections to remote GRASP peers. So its really a demultiplexer between passing calls from/to the core and its own maintained TLS connections. > ** In fact I needed to provide a way to activate such a daemon, because > Michael and Bill discovered that they needed to do so by hand during > the hackathon last month. It's called gremlin.py and contains 4 lines > of code. IMHO, it should be started when system comes up. In a reasonable secure envirnment, a normal ASA shouldn't have permission to provide system level services, because ASA IMHO are more like user provided applications and each of them should be able to be less trustworthy than a system level function like GRASP discovery. One could say this is an implementation detail, but i think it would add one reason to talking about separarte library/core: Distinction between "ASA user" and system context. Cheers Toerless > Thanks >Brian > > P.S. We'll wait for Guangpeng's promised review before we revise the > draft. > > On 10-Aug-19 07:43, Toerless Eckert wrote: > > > > Hi Brian, * > > > > I have right now primarily a high level comment: > > > > The problem i have with the three layers of GRASP is that there > > is no good justification why they exist and why the API document > > needs to bother about them. The doc really only talks about the > > library of the GRASP Library. > > > > This is not to say that i do not like the idea to talk about the > > modularity of a GRASP implementation, its just not well motivated > > and executed i feel. > > > > So, one way to solve this is to also talk about the other APIs. > > > > For the extended function module, one could for example say > > any extensions to GRASP that are CAN BE implemented on top the > > GRASP API defined in this document SHOULD be implemented as > > a GRASP Function Module. And examples could be the functions > > suggested in my DNS drafts, or ther drafts you have that fit. > > So, thats the simple part. > > > > More interestingly, i would be a great fan of talking about the > > API between library and core, to justify why we want to think about > > this modularity. > > > > This is where
