Re: [Anima] BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI
Hi Steffen, Thank you for your comments. I put my reply also inline. Best regards, Lei YAN From: Anima On Behalf Of Fries, Steffen Sent: Monday, July 24, 2023 14:17 To: Yanlei(Ray) ; Michael Richardson Cc: anima@ietf.org Subject: Re: [Anima] BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI 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 mailto:anima-boun...@ietf.org>> On Behalf Of Yanlei(Ray) Sent: Friday, July 21, 2023 12:27 PM To: Michael Richardson mailto:mcr+i...@sandelman.ca>> Cc: anima@ietf.org<mailto: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 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? [Lei] Yes, BRSKI-CLE can be an independent protocol. The (provisional) TLS connection between the pledge and the registrar also helps the trust delivery in BRSKI-CLE. The pledge receives the AC’s ID and public key through the TLS connection from the registrar. Thus, the pledge can believe the received information of AC is true, as the pledge trusts the registrar. >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? [Lei] The validity period, update mechanism and revocation mechanism will be introduced in the future version of the draft. In this 00 version, I want to focus on introducing why to propose the certificateless authentication mechanism in BRSKI. >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 gen
Re: [Anima] BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI
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 On Behalf Of Yanlei(Ray) Sent: Friday, July 21, 2023 12:27 PM To: Michael Richardson 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 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 e
Re: [Anima] BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI
Hi Michael, Thank you for your comments. On 20. Jul 2023, Michael Richardson 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. >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. >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. >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? >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 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
[Anima] BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI
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 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. 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. I don't understand how it would differ from all the work in OAUTH and ACE. 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. I don't think that section 3 needs to educate us about Schnorr. I learnt nothing about the trust algorithm from the math. Something about a Master Key, which really scares me. 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. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
