Hi Toerless, As discussed in the last Design Team meeting, we agreed to include optional support for TLS between the registrar-agent and the pledge, to protect the communication regarding privacy. Depending on the utilized TLS version, certain information about the pledge may still be visible (TLS 1.2 has the handshake in clear, so the pledge IDevID certificate will be visible during the establishment). On the other hand, as the pledge will accept incoming connections in factory mode, it is also possible the TLS connection is established by a potential active adversary.
The optional TLS support has been included in the latest commit on gitlab addressing issue #82 and also #83. Next week we will further discuss remaining open issues in the Design Team Meeting. Best regards Steffen > -----Original Message----- > From: Anima <[email protected]> On Behalf Of Fries, Steffen > Sent: Dienstag, 2. Mai 2023 07:50 > To: Esko Dijk <[email protected]>; Toerless Eckert <[email protected]>; > [email protected]; [email protected] > Cc: [email protected] > Subject: Re: [Anima] ANIMA: Certificate authentication, BRSKI PRM and > RFC8995 > > Hi Toerless, Esko, > > After some further discussions and double check of RFC 2818 I agree, it is > possible to omit the hostname verification. > The key I think is the statement in section 3.1 of RFC 2818 > (https://datatrac/ > ker.ietf.org%2Fdoc%2Fhtml%2Frfc2818%23section- > 3.1&data=05%7C01%7Csteffen.fries%40siemens.com%7Cc2662a2ceff649ab93f > e08db4ad110d2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6381 > 86034047182057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ > QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata > =nzQ4Q4em6jN9yCqrXPNNTMVlCkMD6Ct9Q%2F6wu%2B7Hj5A%3D&reserved= > 0): > If the client has external information as to the expected identity of > the > server, the hostname check MAY be omitted. > A similar statement can be found in section 4.3.4 of RFC 9110 > (https://www.rfc/ > -editor.org%2Frfc%2Frfc9110.html%23name-https-certificate- > verificat&data=05%7C01%7Csteffen.fries%40siemens.com%7Cc2662a2ceff649 > ab93fe08db4ad110d2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7 > C638186034047182057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C > &sdata=Mxr%2F%2BXwUx77bmIJiyfec2hYY5DLF7IvHO6pUZBjuKPo%3D&reserve > d=0) > In special cases, it might be appropriate for a client to simply > ignore the > server's identity, but it must be understood that this leaves a connection > open to > active attack. > > In case of BRSKI-PRM the identity check of the pledge (as TLS server) may be > done based on the device serial numbers a registrar-agent must possess before > onboarding pledges as outlined in section 6.1 > (https://www.iet/ > f.org%2Farchive%2Fid%2Fdraft-ietf-anima-brski-prm-08.html%23name-request- > objects- > acquisition&data=05%7C01%7Csteffen.fries%40siemens.com%7Cc2662a2ceff6 > 49ab93fe08db4ad110d2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0% > 7C638186034047182057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C > &sdata=heSaUFyA8n6dno4k3oBYZETpmKFlaxmg4LiBiEDfrV0%3D&reserved=0). > This is in addition to the trustanchor (IDevID CA certificate) the > registrar-agent > (TLS client) would need to verify the IDevID certificate of the pledge to > ensure > he is connected to the specific instance of the pledge. > > Getting back to the origin of the discussion, as the discussion was a result > on > one of the reasoning provided in BRSKI-PRM to not apply TLS between the > registrar-agent and the pledge: > - In BRSKI-PRM the communication between the registrar-agent and the pledge > was designed to not rely on transport security, to enable also alternative > transports such as BTLE or even NFC. For these, the use of TLS was not > expected > and therefore security is applied on the messages exchanged directly. > - As BRSKI-PRM targets as first approach for the exchange of the bootstrapping > information to utilize http as transport we could recommend using TLS here to > protect the privacy of the communication. This would only enhance the existing > approach for that specific communication link as TLS is already used between > the registrar-agent and the registrar. > > I will provide a proposal what to change in BRSKI-PRM for discussion in the > next > Design Team Meeting (today). > > Best regards > Steffen > > > > -----Original Message----- > > From: Anima <[email protected]> On Behalf Of Esko Dijk > > Sent: Donnerstag, 27. April 2023 23:46 > > To: Toerless Eckert <[email protected]>; [email protected]; draft-ietf-anima- > > [email protected] > > Cc: [email protected] > > Subject: Re: [Anima] ANIMA: Certificate authentication, BRSKI PRM and > > RFC8995 > > > > Hi Toerless, > > > > I agree with your analysis here. RFC 2818 does allow to omit the > > hostname check if the client has additional information about the > > expected identity of the server. (Which is in the PRM case, the CA > > trust anchors of the manufacturer of the device - or a set of trusted > > manufacturers that the commissioning tool > > tusts.) > > > > Also notice that although EST (RFC 7030) mentions RFC 2818, the > > BRSKI-PRM device to be onboarded does not implement EST server so any > > RFC 7030 requirements on the server are not really applicable for that > > BRSKI- > PRM device. > > We define a new type of server here (the "Pledge-PRM" TLS server?) > > with own rules. I don't see why it should follow EST server rules > > here, it's not an EST server. > > > > That said, RFC 9110 makes things more restrictive it seems. But it > > also says in 4.3 "However, authoritative access is not limited to the > > identified > mechanism." > > which means that other means of authoritative access to a > > resource/HTTPS server , i.e. other than the method defined in section 4.3 , > > are > also foreseen. > > So it should be okay to use HTTPS for the BRSKI-PRM use case. > > > > Regards > > Esko > > > > -----Original Message----- > > From: Anima <[email protected]> On Behalf Of Toerless Eckert > > Sent: Wednesday, April 26, 2023 19:11 > > To: [email protected]; [email protected] > > Cc: [email protected] > > Subject: [Anima] ANIMA: Certificate authentication, BRSKI PRM and > > RFC8995 > > > > In the process of discussing shepherd review feedback for BRSKI-PRM > > draft, the authors brought up arguments relating to their > > interpretation of requirements against required TLS server certificate > validation by the client. > > > > Let me try to hopefully correctly restate and provide my thoughts, if > > i am misrepresenting, please correct me! > > > > Pre: > > > > A pledge has an IDevID and some dynamically assigned IP(v6) address, > > and no domain name. > > > > Claim of the authors > > > > Another device can not build a HTTP over TLS connection to the pledge > > and authenticate the pledge, because of the absence of domain name and > > IP- address based SubjectAltNames in the certificate - according to RFC2818. > > RFC2818 is required to be met because BRSKI relies on RFC7030 and > > RFC7030 requires RFC2818. > > > > My assessment: > > > > I think this is an incorrect reading: I think that any time that a TLS > > server would identify itself with an IDevID, paragraph 2 of section > > 3.1 of RFC2818 would be > > applicable: The "narrow the scope of acceptable certificates" are > > those certificates that can be validted against the trust anchors that the > > client > trusts. > > E.g.: The trust anchors from the vendor(s) from which the client > > expects the IDevID to be signed. > > > > Furthermore: > > > > I think the very same is also true for BRSKI itself, e.g.: the only > > authentication that pledges are doing against a registrar is > > authenticating the certificate against the trust anchor provided in > > the voucher. There is no additional authentication against any type of > > additional Subject Name or SubjectAltName that the certificate of a > > registrar > my carry (dns name or ip address). > > > > draft-t2trg-idevid-considerations > > > > I did not have time to read through this draft, but would that > > potentially be a good place to reconfirm that one can build a TLS > > connection to a device that will use it's IDevID to authenticate > > itself, and a secure authentication of that device as a TLS server > > effectively only requires validation of the certificate chain against > > the trust anchor of the menufacturer for the device - no additional > > verification > of other addresses. > > > > RFC2818 -> RFC9110: > > > > I find these whole HTTP drafts quite confusing: > > > > - RFC2818 was never standards track, but only informational but still > > uses > > RFC2119 terminology > > (MUST / SHOULD / ...). > > > > - RFC2818 was obsoleted by RFC9110. And RFC9110 is now standards track. > > > > - RFC9110 states in section B.1 that it does not changes anything from > RFC2818. > > But then you look at RFC9110 section 4.3.4 and the text is quite different > from > > RFC2818 section 3.1. In fact, i would claim that RFC9110 is even more > WebPKI > > centric written than RFC2818 ("In general, a client MUST verify > > the service identity using the verification process defined in > > Section 6 of > > [RFC6125].") > > Aka: "In General all certificate validation is WebPKI validation".... > > With our non-webPKI uses cases i feel somewhat neglected ;-) > > > > Does this help ? > > > > Cheers > > Toerless > > > > _______________________________________________ > > Anima mailing list > > [email protected] > > https://www/. > > > ietf%2F&data=05%7C01%7Csteffen.fries%40siemens.com%7Cc2662a2ceff649a > b9 > > > 3fe08db4ad110d2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63 > 8186034 > > > 047182057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV > 2luMzIi > > > LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sVh%2FRwFe > iixj6Kh > > RzUQFB3YKgDsjjoZ%2FpG2z4D8DHkc%3D&reserved=0 > > > .org%2Fmailman%2Flistinfo%2Fanima&data=05%7C01%7Csteffen.fries%40siem > > > ens.com%7C3bf355e2d13d48444efe08db4768e50b%7C38ae3bcd95794fd4adda > > > b42e1495d55a%7C1%7C0%7C638182288078157646%7CUnknown%7CTWFpbGZ > > > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > > > %3D%7C3000%7C%7C%7C&sdata=BQZ2%2BrJKFSkb0DIS%2B%2B1qPL8QzJZTkZ > > OIsu%2BFfjOCLYg%3D&reserved=0 > > > > _______________________________________________ > > Anima mailing list > > [email protected] > > https://www/. > > > ietf%2F&data=05%7C01%7Csteffen.fries%40siemens.com%7Cc2662a2ceff649a > b9 > > > 3fe08db4ad110d2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63 > 8186034 > > > 047182057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV > 2luMzIi > > > LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sVh%2FRwFe > iixj6Kh > > RzUQFB3YKgDsjjoZ%2FpG2z4D8DHkc%3D&reserved=0 > > > .org%2Fmailman%2Flistinfo%2Fanima&data=05%7C01%7Csteffen.fries%40siem > > > ens.com%7C3bf355e2d13d48444efe08db4768e50b%7C38ae3bcd95794fd4adda > > > b42e1495d55a%7C1%7C0%7C638182288078157646%7CUnknown%7CTWFpbGZ > > > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > > > %3D%7C3000%7C%7C%7C&sdata=BQZ2%2BrJKFSkb0DIS%2B%2B1qPL8QzJZTkZ > > OIsu%2BFfjOCLYg%3D&reserved=0 > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf/ > .org%2Fmailman%2Flistinfo%2Fanima&data=05%7C01%7Csteffen.fries%40siem > ens.com%7Cc2662a2ceff649ab93fe08db4ad110d2%7C38ae3bcd95794fd4addab > 42e1495d55a%7C1%7C0%7C638186034047182057%7CUnknown%7CTWFpbGZs > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > %3D%7C3000%7C%7C%7C&sdata=S1C9Opot0vvm9qI2UjCDYzc%2F7%2FTIvfgN > Y6xyxIg%2FDkM%3D&reserved=0 _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
