Hi Lei Yan, I'm just using your latest response as I had similar questions as Michael regarding BRSKI-CLE. I put my remarks inline
Best regards Steffen From: Anima <anima-boun...@ietf.org> On Behalf Of Yanlei(Ray) Sent: Friday, July 21, 2023 12:27 PM To: Michael Richardson <mcr+i...@sandelman.ca> Cc: anima@ietf.org Subject: Re: [Anima] BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI Hi Michael, Thank you for your comments. On 20. Jul 2023, Michael Richardson <mcr+i...@sandelman.ca<mailto:mcr+i...@sandelman.ca>> wrote: >Having read through the emails and reviewed the document a bit more, I think >that I see some ways in which the document could be clarified. > >First, this is not an extension or amendment to BRSKI. >BRSKI is a way to introduce trust between Pledges and Registrars via the >third-party RFC8366 voucher. >In 8995, it results in a RFC7030 *EST* channel, which is literally... >"Enrollment over Secure Transport". >RFC7030 defines a CSR-based method to get a new certificate. > >CLE is not about BRSKI at all, it's about a new kind of enrollment. >So, this document should be "EST-CLE", which is much akin to "BRSKI-AE" >(which arguably from this point of view, should be "EST-AE" or even "EST-CMP", >only it's not EST at all) > >The reason CMP changes BRSKI is because it does away with the (provisional) >TLS connection, and RFC8995 deals primarily with how that connection is setup >to be useful. > >From what I can see, BRSKI-CLE does nothing to the provisional-TLS connection >at all, but rather changes what occurs after the Secure Transport exists. Yes, you are right. BRSKI-CLE just changes the enrollment phase in BRSKI. I think enrollment is also a part of the bootstrap process in BRSKI, as shown in RFC8995. Therefore, I think BRSKI-CLE somehow changes the process of BRSKI. I saw BRSKI-AE is a working group draft. Thus, I think BRSKI-CLE is also suitable under the auspices of the ANIMA WG. [stf] BRSKI-AE essentially described a way to exchange the enrollment protocol used in RFC 8995 with another enrollment. Specifically it employes CMP using the Lightweight CMP Profile. So in general the idea is to rely on the voucher exchange and ideally utilize the established TLS session also for the enrollment. The new enrolment protocol is expected to define an own endpoint for operation. In case of BRSKI-AE using CMP the endpoint is "cmp". In case of BRSKI-CLE, would the enrollment for credentials be an independent protocol employed by RSKI as it is the case for EST and CMP? >The BRSKI-CLE document has a lot of text dealing with how the public keys are >derived. >I don't really understand what the credential that is created by the AC is... >it looks like it's a signed object. >Second, I don't understand how to devices (having been enrolled) as depicted >in section 2.3, as client and server are able to trust each other. Maybe >there is some important magic that I've missed among the math. The AC is a trusted third party, similar to the CA. The CA uses its private key to sign the pledge's public key. Other pledges use the CA's public key to verify whether the signature is signed by the CA. The AC adds its public and private keys to the process of generating the pledge's public and private keys. Other pledges can also use the AC's public key to verify whether the credential, which can derive the pledge's public key, is generated by the AC. [stf] Based on section 2 in the draft, the credentials have no validity period and may not support revocation. Would this require to renew also the AC keys if some existing keys are to be marked as invalid? >I don't understand how it would differ from all the work in OAUTH and ACE. A token is used by a client to request resources from a server in the scenario of ACE-OAUTH [RFC9200]. In BRSKI-CLE, the usage of the credential is more general. The pledge's action after the authentication using credentials is not specified in BRSKI-CLE. [stf] I understood section 2.3 for the mutual authentication to describe the application of the credentials in some kind of independent manner >I don't think that section 3 needs to educate us about Schnorr. I learnt >nothing about the trust algorithm from the math. The certificateless cryptography in BRSKI-CLE is similar to ECDSA and ECDHE. I wrote these algorithms because I think it is necessary to explain the principle of certificateless authentication for applying it in BRSKI. Now, I also realize putting the math algorithms in this draft may not be suitable. However, I don't know which working group is proper for promoting the certificateless cryptography algorithms. Do you have any suggestions? [stf] If this is a new approach for setting up credentials it would be good if there is some more investigation of the security (you referred to the Schnorr signature algorithm, but the credential establishment seems to go further). To get feedback on the approach, it could be provided to LAMPS or also to the CRFG to get their opinion. >Something about a Master Key, which really scares me. The master key is a symmetric key, which can only be figured out by the two communicating peers, similar to the symmetric key generated by ECDHE. And the master key is used to derive the keys utilized in the communication later, similar to the master secret in TLS v1.3. >I would suggest that rather than tell us about the math, that the presentation >should explain to us the use case for this work. > > >-- >Michael Richardson <mcr+i...@sandelman.ca<mailto:mcr+i...@sandelman.ca>> . o >O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide Best regards, Lei YAN
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
