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://datatracker.ietf.org/doc/html/rfc2818#section-3.1): 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/rfc/rfc9110.html#name-https-certificate-verificat) 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.ietf.org/archive/id/draft-ietf-anima-brski-prm-08.html#name-request-objects-acquisition). 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/ > .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%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/mailman/listinfo/anima
