Re: [Anima] Initial Call for agenda discussion / items ANIMA@IETF118 Prague (was: anima - New Meeting Session Request for IETF 118)
Dear Chairs, A 5 min time slot is also ok. Is there still an available 5 min time slot? Best regards Lei YAN -Original Message- From: Anima On Behalf Of Yanlei(Ray) Sent: Wednesday, October 25, 2023 2:29 PM To: anima-cha...@ietf.org Cc: anima@ietf.org Subject: Re: [Anima] Initial Call for agenda discussion / items ANIMA@IETF118 Prague (was: anima - New Meeting Session Request for IETF 118) Dear Chairs, I would like to ask for the a time slot for my updated individual draft. Topic/Title:Update on BRSKI-CLE: A Certificateless Enrollment framework in BRSKI Name of Presenter(s): Lei YAN Length of time requested: 10 min Name of draft(s) discussed: draft-yan-anima-BRSKI-CLE-01 Best regards Lei YAN -Original Message- From: Anima On Behalf Of Esko Dijk Sent: Tuesday, September 19, 2023 9:11 PM To: anima-cha...@ietf.org; anima@ietf.org Subject: Re: [Anima] Initial Call for agenda discussion / items ANIMA@IETF118 Prague (was: anima - New Meeting Session Request for IETF 118) I'd like to present the update of draft-ietf-anima-constrained-voucher: -22 ; and status / remaining open issues. (This will be published prior to the IETF meeting.) 5 minutes would be ok, 10 minutes better if we have the time ;) Esko -Original Message- From: Anima On Behalf Of Fries, Steffen Sent: Thursday, September 14, 2023 14:58 To: Toerless Eckert ; anima@ietf.org Cc: anima-cha...@ietf.org; rwil...@cisco.com Subject: Re: [Anima] Initial Call for agenda discussion / items ANIMA@IETF118 Prague (was: anima - New Meeting Session Request for IETF 118) Hi Toreless, I would like to ask for the following slots in the IETF 118 meeting: Topic/TitleBRSKI-AE Status Update Name of Presenter(s) David von Oheimb Length of time requested 5 min If applicable: name of draft(s) discussed: draft-ietf-anima-brski-ae-06 (version 06 to be submitted) Topic/TitleJWS-voucher Status Update Name of Presenter(s)Thomas Werner/ Steffen Fries Length of time requested 5 min If applicable: name of draft(s) discussed: draft-ietf-anima-jws-voucher-09 Topic/TitleBRSKI-PRM Status Update Name of Presenter(s) Steffen Fries Length of time requested 10 min If applicable: name of draft(s) discussed: draft-ietf-anima-brski-prm-10 (version 10 to be submitted) Best regards Steffen > -Original Message- > From: Anima On Behalf Of Toerless Eckert > Sent: Thursday, September 14, 2023 1:12 AM > To: anima@ietf.org > Cc: anima-cha...@ietf.org; rwil...@cisco.com > Subject: [Anima] Initial Call for agenda discussion / items > ANIMA@IETF118 Prague (was: anima - New Meeting Session Request for > IETF 118) > > Dear ANIMA WG, > > This time, we wanted to ask for agenda items for ANIMA@IETF118 early > enough that we can accordingly ask for a fitting slot length. The > window for requesting WG slots closes on 09-22 23:59 UTC. > > For now, we have requested a one hour slot based on feedback from our > AD and others who ae trying to ensure that IETF in-person meeting time > is spent mostly on discussions that can only be had in-person, > especially given the ever growing number of WGs. > > Given how we are making good working progress with most our adopted > BRSKI WG items on our weekly online meetings (to the extend they are > not on back-burner because of serialization/dependencies), we think > for those WG items one hour will suffice at IETF118, so that is the current > request. > > If you have additional work you would like to see discussed, please > start discuss it on the list, so that we can consider extending the WG > meeting time request for > IETF118 as then needed. > > Cheers > Toerless - for the chairs > > On Wed, Sep 13, 2023 at 04:05:47PM -0700, IETF Meeting Session Request > Tool wrote: > > > > > > A new meeting session request has just been submitted by Toerless > > Eckert, a Chair of the ANIMA Working Group. > > > > > > - > > Working Group Name: Autonomic Networking Integrated Model and > Approach > > Area Name: Operations and Management Area Session Requester: > > Toerless Eckert > > > > > > Number of Sessions: 1 > > Length of Session(s): 1 Hour > > Number of Attendees: 40 > > Conflicts to Avoid: > > Chair conflict: detnet bier 6man intarea pim v6ops iabopen > > Technology overlap: emu netconf mboned Key participant conflict: > > nmrg opsarea intarea saag > > > > > > > > > >
Re: [Anima] Initial Call for agenda discussion / items ANIMA@IETF118 Prague (was: anima - New Meeting Session Request for IETF 118)
Dear Chairs, I would like to ask for the a time slot for my updated individual draft. Topic/Title:Update on BRSKI-CLE: A Certificateless Enrollment framework in BRSKI Name of Presenter(s): Lei YAN Length of time requested: 10 min Name of draft(s) discussed: draft-yan-anima-BRSKI-CLE-01 Best regards Lei YAN -Original Message- From: Anima On Behalf Of Esko Dijk Sent: Tuesday, September 19, 2023 9:11 PM To: anima-cha...@ietf.org; anima@ietf.org Subject: Re: [Anima] Initial Call for agenda discussion / items ANIMA@IETF118 Prague (was: anima - New Meeting Session Request for IETF 118) I'd like to present the update of draft-ietf-anima-constrained-voucher: -22 ; and status / remaining open issues. (This will be published prior to the IETF meeting.) 5 minutes would be ok, 10 minutes better if we have the time ;) Esko -Original Message- From: Anima On Behalf Of Fries, Steffen Sent: Thursday, September 14, 2023 14:58 To: Toerless Eckert ; anima@ietf.org Cc: anima-cha...@ietf.org; rwil...@cisco.com Subject: Re: [Anima] Initial Call for agenda discussion / items ANIMA@IETF118 Prague (was: anima - New Meeting Session Request for IETF 118) Hi Toreless, I would like to ask for the following slots in the IETF 118 meeting: Topic/TitleBRSKI-AE Status Update Name of Presenter(s) David von Oheimb Length of time requested 5 min If applicable: name of draft(s) discussed: draft-ietf-anima-brski-ae-06 (version 06 to be submitted) Topic/TitleJWS-voucher Status Update Name of Presenter(s)Thomas Werner/ Steffen Fries Length of time requested 5 min If applicable: name of draft(s) discussed: draft-ietf-anima-jws-voucher-09 Topic/TitleBRSKI-PRM Status Update Name of Presenter(s) Steffen Fries Length of time requested 10 min If applicable: name of draft(s) discussed: draft-ietf-anima-brski-prm-10 (version 10 to be submitted) Best regards Steffen > -Original Message- > From: Anima On Behalf Of Toerless Eckert > Sent: Thursday, September 14, 2023 1:12 AM > To: anima@ietf.org > Cc: anima-cha...@ietf.org; rwil...@cisco.com > Subject: [Anima] Initial Call for agenda discussion / items > ANIMA@IETF118 Prague (was: anima - New Meeting Session Request for > IETF 118) > > Dear ANIMA WG, > > This time, we wanted to ask for agenda items for ANIMA@IETF118 early > enough that we can accordingly ask for a fitting slot length. The > window for requesting WG slots closes on 09-22 23:59 UTC. > > For now, we have requested a one hour slot based on feedback from our > AD and others who ae trying to ensure that IETF in-person meeting time > is spent mostly on discussions that can only be had in-person, > especially given the ever growing number of WGs. > > Given how we are making good working progress with most our adopted > BRSKI WG items on our weekly online meetings (to the extend they are > not on back-burner because of serialization/dependencies), we think > for those WG items one hour will suffice at IETF118, so that is the current > request. > > If you have additional work you would like to see discussed, please > start discuss it on the list, so that we can consider extending the WG > meeting time request for > IETF118 as then needed. > > Cheers > Toerless - for the chairs > > On Wed, Sep 13, 2023 at 04:05:47PM -0700, IETF Meeting Session Request > Tool wrote: > > > > > > A new meeting session request has just been submitted by Toerless > > Eckert, a Chair of the ANIMA Working Group. > > > > > > - > > Working Group Name: Autonomic Networking Integrated Model and > Approach > > Area Name: Operations and Management Area Session Requester: > > Toerless Eckert > > > > > > Number of Sessions: 1 > > Length of Session(s): 1 Hour > > Number of Attendees: 40 > > Conflicts to Avoid: > > Chair conflict: detnet bier 6man intarea pim v6ops iabopen > > Technology overlap: emu netconf mboned Key participant conflict: > > nmrg opsarea intarea saag > > > > > > > > > > Participants who must be present: > > Michael Richardson > > > > Resources Requested: > > > > Special Requests: > > China remote attendance friendly time would be lovely (the earlier > > in the day, the better). One co-chair likely attending remotely > > - > > > > -- > --- > t...@cs.fau.de > > ___ > Anima mailing list > Anima@ietf.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .ietf.org%2Fmailman%2Flistinfo%2Fanima=05%7C01%7Csteffen.fries% > 40siemens.com%7C610b34f12fc2405a350308dbb4aed160%7C38ae3bcd95 >
[Anima] FW: I-D Action: draft-yan-anima-brski-cle-01.txt
Hi all,
I'd like to bring your attention to the following Individual draft and invite
you to review the draft.
I just updated BRSKI-CLE (draft-yan-anima-brski-cle-01.txt) with the following
changes from draft 00 -> draft 01:
* Issue 1 (from Steffen Fries): The cryptographic approach should be discussed
with CFRG.
Changes for issue 1: All the mathematical algorithm is deleted from the
draft. Considering the evolution towards quantum-
safe algorithms, the draft is changed to a KEM-based enrollment framework.
(KEM: Key Encapsulation Mechanism)
* Issue 2 (from Michael Richardson): COSE objects and ACE-EST should be
compared.
Changes for issue 2:
1) The draft does not specify the local credentials any more. As BRSKI-CLE is
a framework now, any lightweight credentials, such as CBOR Web Tokens (CWTs),
can be issued by using this framework.
2) The scenario is clarified and detailed. The Class 1 constrained IoT
devices, defined in RFC7228, may be unable to use certificates within limited
RAM. Even using CBOR to encode certificates, the certificate chain is also
heavy for the Class 1 constrained IoT devices.
3) ACE-EST uses EDHOC for authentication. As BRSKI-CLE is based on KEM, the
framework is compared with the KEM mechanism in EDHOC (I-D.ietf-lake-edhoc) and
TLS (I-D.wiggers-tls-authkem-psk). Encapsulating by the server's public key in
KEM, the IoT device does not need to configure a public key to identify itself.
* EDHOC is used for the mutual authentication between the pledge and the
registrar in BRSKI, as shown in {{I-D.selander-lake-authz}}. Moreover, the
pledge's credential is supported transporting by reference rather than by
value. Therefore, a constrained IoT device has no need to configure a public
key to identify itself for the whole bootstrapping process.
Comments and suggestions are welcome.
I am looking for co-authors.
Best regards
Lei YAN
-Original Message-
From: I-D-Announce On Behalf Of
internet-dra...@ietf.org
Sent: Monday, October 23, 2023 9:00 PM
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-yan-anima-brski-cle-01.txt
Internet-Draft draft-yan-anima-brski-cle-01.txt is now available.
Title: BRSKI-CLE: A Certificateless Enrollment framework in BRSKI
Author: Lei YAN
Name:draft-yan-anima-brski-cle-01.txt
Pages: 10
Dates: 2023-10-23
Abstract:
The Class 1 constrained IoT devices, defined in RFC7228, may be
unable to use certificates within limited RAM. Exiting enrollment
protocols of BRSKI are all using certificates. This document defines
a certificateless enrollment framework in BRSKI (BRSKI-CLE) for
constrained IoT devices. Considering the evolution towards quantum-
safe algorithms, the framework is based on Key Encapsulation
Mechanism (KEM). Cooperating with the authentication mechanism shown
in I-D.selander-lake-authz, a constrained IoT device does not need to
configure a public key to identify itself for the whole bootstrapping
process. An authentication centre (AC) is used for issuing
lightweight credentials, such as CBOR Web Tokens (CWTs), to
constrained IoT devices. This document does not specify any
lightweight credentials.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-yan-anima-brski-cle/
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-yan-anima-brski-cle-01.html
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-yan-anima-brski-cle-01
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
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 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
Re: [Anima] Call for agenda items ANIMA@IETF117@ San Francisco
Toerless, Thank you for your comments. Yes, the mathematical model is pre-existing. I will add the reference and explanation of the closest pre-existing work in the draft. Best regards, Lei YAN - Original Message - From: Toerless Eckert Sent: 2023年7月19日 22:52 To: Yanlei(Ray) Cc: 蒋胜 ; anima-cha...@ietf.org; anima@ietf.org Subject: Re: [Anima] Call for agenda items ANIMA@IETF117@ San Francisco I did see that there where already discussions afterwards. My comment was purely standard disclaimer ;-)) High level browsing on your draft: Is the mathematical model something pre-existing and it was just adopted to BRSKI ? If so, then it would be nice to have reference and explanation of the closest pre-existing work before it was adopted to BRKI. Purely to vet how proven/widely used the mechanism might be outside of BRSKI. Thanks for confirming registration, maybe i overlooked it yesterday when i was looking up presenters registration status to know whether they're remote or local. Cheers Toerless On Wed, Jul 19, 2023 at 07:25:22AM +, Yanlei(Ray) wrote: > Toerless, > > > Toerless Eckert wrote: > >Ray: > > > >Added to agenda. Will still need to check how much time we will have. > >Consider 10+ minutes guaranteed. Start a discussion on the list, if there is > >interest/feedback ere and we have more time after WG slots, we can use more. > > There are some comments from Michael Richardson. > I will send a new email to start a discussion on the list. > > >Also: I do not see you registered, which you will need to be if you want to > >present. > > I have already registered. > The registered information as below: > Last Name: YAN > First Name: Lei > Reg Type: Remote - Week Pass > > >Cheers > >Toerless > > > >On Tue, Jul 11, 2023 at 03:43:32AM +, Yanlei(Ray) wrote: > >> Dear Chairs, > >> > >> I would like to ask for the a time slot for my new individual draft. > >> Topic/Title:BRSKI-CLE: A > >> Certificateless Enrollment protocol in BRSKI > >> Name of Presenter(s): Lei YAN > >> Length of time requested: 20 min > >> Name of draft(s) discussed: draft-yan-anima-BRSKI-CLE-00 > >> > >> Best regards > >> Lei YAN > >> > >> >- Original Message - > >> >From: Anima On Behalf Of 蒋胜 > >> > Sent: Thursday, July 6, 2023 10:33 AM > >> > To: anima > >> > Cc: anima-chairs ; Toerless Eckert > >> > > >> > Subject: [Anima] Call for agenda items ANIMA@IETF117@ San > >> >Francisco > >> > > >> >Dear ANIMA WG, > >> > > >> >The preliminary IETF117 agenda is on the web. > >> >ANIMA WG will meet at IETF117 for one 2 hour slot: > >> >Wednesday July 26th, 09:30-11:30 (Session I), Plaza B, MEETING TIMEZONE > >> >(San Francisco). > >> > > >> >Please submit your requests for Agenda items in reply to this email, as > >> >soon as possible. > >> >The chairs plan to make WG draft agenda before 7/14/2023, so would be > >> >great if you could submit your agenda requests in before! > >> > > >> >Note that you do not need to have the slides by the time you're asking > >> >for the slot! > >> > > >> >Please send requests to anima-cha...@ietf.org. > >> >Copy anima@ietf.org if you like. > >> > > >> >Topic/Title > >> > Name of Presenter(s) > >> >Length of time requested > >> >If applicable: name of draft(s) discussed > >> > > >> >Also: Once you have your slides, go to: > >> > > >> > https://datatracker.ietf.org/meeting/117/session/anima > >> > > >> >and upload your slides via the "Propose Slides" Button (pick either of > >> >the two slots as you see fit). > >> > > >> >Please also remember to (re-)start discussing any non-WG adopted work > >> >also on the anima@ietf.org mailing list to encourage WG members to read > >> >your work and comment! > >> > > > >>More details about the IETF 117 will be found at: > >> >https://www.ietf.org/how/meetings/117/ > >> > > >> >Thank you so much! > >> > > >> >ANIMA WG Chairs, > >> >Sheng/Toerless > >> >___ > >> >Anima mailing list > >> >Anima@ietf.org > >> >https://www.ietf.org/mailman/listinfo/anima > > > >-- > >--- > >t...@cs.fau.de > > > Best regards, > Lei YAN -- --- t...@cs.fau.de ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] Invite comments on draft-yan-anima-BRSKI-CLE-00
Hi all, I'd like to bring your attention to the following Individual IETF draft and invite you to review the draft. I believe this draft best fits under the auspices of the ANIMA WG. It is welcome to give feedback or make comments. The high level summary is as follows: == 1. This document describes a lightweight certificateless enrollment protocol in BRSKI for constrained IoT devices. 2. A credential based on public keys is designed to replace the domain certificate used in BRSKI. 3. An authentication centre (AC) replaced the certification authority (CA) is used to issue the credential to the pledge. 4. A new mutual authentication protocol is designed for the authentication between two pledges by the credentials. More details are available in the ID text. Name: draft-yan-anima-brski-cle Revision: 00 Title: BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI Document date: 2023-07-10 Group: Individual Submission Pages: 13 URL:https://www.ietf.org/archive/id/draft-yan-anima-brski-cle-00.txt Status: https://datatracker.ietf.org/doc/draft-yan-anima-brski-cle/ Html: https://www.ietf.org/archive/id/draft-yan-anima-brski-cle-00.html Htmlized: https://datatracker.ietf.org/doc/html/draft-yan-anima-brski-cle There are some comments from Michael Richardson. Thank you for your comments. -- On 11. Jul 2023, Michael Richardson wrote: >Yanlei\(Ray\) wrote: > > I would like to ask for the a time slot for my new individual draft. > > Topic/Title: BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI > >Thank you for your document. I look forward to your slides for further >explanation. > >1. It seems that you've missed much of the Raw Public Key support that is a >key part of constrained-BRSKI. The Raw Public Key is used by the voucher before the "enroll" state as defined in constrained-BRSKI. The BRSKI-CLE is designed for the "enroll" state after the "imprint" state. +--v---+ | (4) Imprint | +--+---+ | send Voucher Status Telemetry +--v---+ | (5) Enroll | +--+---+ Thus, BRSKI-CLE is not involved in the vouchers. This draft focuses on the enrollment phase in BRSKI and the authentication for the communication between pledges after enrollment. >2. Do you have a proof-of-concept implementation? We have some implementations on certificateless authentication but not on BRSKI-CLE. >3. There seems to be a significant gap in how the vouchers would work. >I didn't understand this at all. As explaining in the first question, BRSKI-CLE is not involved in the vouchers. >It all starts with an unsupported assumption that IoT devices can not hold >certificates. Yet, they are being installed into devices by the billions >today. If the enrollment protocol issues a domain certificate to the IoT devices, after the enrollment, the IoT devices just can use the domain certificate for authentication in communication. BRSKI-CLE is an enrollment protocol that issues a credential, instead of certificates, based on public keys to the IoT devices. Thus, the IoT devices can use the credential to authenticate each other in communication after enrollment. BRSKI-CLE provides a lightweight way for the authentication between IoT devices in communication after enrollment. BRSKI-CLE does not change any process before the "enroll" state in BRSKI. Thus, BRSKI-CLE also supports an X.509 IDevID certificate installed by the vendor on IoT devices. The IoT devices only need to bootstrap once and may do mutual communications unlimited times after enrollment. Therefore, it doesn't matter to use certificates in bootstrapping. A lightweight authentication protocol for communication after bootstrapping is more meaningful. -- Best regards, Lei YAN ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Call for agenda items ANIMA@IETF117@ San Francisco
Toerless, Toerless Eckert wrote: >Ray: > >Added to agenda. Will still need to check how much time we will have. >Consider 10+ minutes guaranteed. Start a discussion on the list, if there is >interest/feedback ere and we have more time after WG slots, we can use more. There are some comments from Michael Richardson. I will send a new email to start a discussion on the list. >Also: I do not see you registered, which you will need to be if you want to >present. I have already registered. The registered information as below: Last Name: YAN First Name: Lei Reg Type: Remote - Week Pass >Cheers >Toerless > >On Tue, Jul 11, 2023 at 03:43:32AM +, Yanlei(Ray) wrote: >> Dear Chairs, >> >> I would like to ask for the a time slot for my new individual draft. >> Topic/Title:BRSKI-CLE: A Certificateless >> Enrollment protocol in BRSKI >> Name of Presenter(s): Lei YAN >> Length of time requested: 20 min >> Name of draft(s) discussed: draft-yan-anima-BRSKI-CLE-00 >> >> Best regards >> Lei YAN >> >> >- Original Message - >> >From: Anima On Behalf Of 蒋胜 >> > Sent: Thursday, July 6, 2023 10:33 AM >> > To: anima >> > Cc: anima-chairs ; Toerless Eckert >> > >> > Subject: [Anima] Call for agenda items ANIMA@IETF117@ San Francisco >> > >> >Dear ANIMA WG, >> > >> >The preliminary IETF117 agenda is on the web. >> >ANIMA WG will meet at IETF117 for one 2 hour slot: >> >Wednesday July 26th, 09:30-11:30 (Session I), Plaza B, MEETING TIMEZONE >> >(San Francisco). >> > >> >Please submit your requests for Agenda items in reply to this email, as >> >soon as possible. >> >The chairs plan to make WG draft agenda before 7/14/2023, so would be great >> >if you could submit your agenda requests in before! >> > >> >Note that you do not need to have the slides by the time you're asking for >> >the slot! >> > >> >Please send requests to anima-cha...@ietf.org. >> >Copy anima@ietf.org if you like. >> > >> >Topic/Title >> > Name of Presenter(s) >> >Length of time requested >> >If applicable: name of draft(s) discussed >> > >> >Also: Once you have your slides, go to: >> > >> > https://datatracker.ietf.org/meeting/117/session/anima >> > >> >and upload your slides via the "Propose Slides" Button (pick either of the >> >two slots as you see fit). >> > >> >Please also remember to (re-)start discussing any non-WG adopted work also >> >on the anima@ietf.org mailing list to encourage WG members to read your >> >work and comment! >> > > >>More details about the IETF 117 will be found at: >> >https://www.ietf.org/how/meetings/117/ >> > >> >Thank you so much! >> > >> >ANIMA WG Chairs, >> >Sheng/Toerless >> >___ >> >Anima mailing list >> >Anima@ietf.org >> >https://www.ietf.org/mailman/listinfo/anima > >-- >--- >t...@cs.fau.de Best regards, Lei YAN ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Call for agenda items ANIMA@IETF117@ San Francisco
Michael Richardson wrote: >Yanlei\(Ray\) wrote: > > I would like to ask for the a time slot for my new individual draft. > > Topic/Title: BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI > >Thank you for your document. I look forward to your slides for further >explanation. > >1. It seems that you've missed much of the Raw Public Key support that is a >key part of constrained-BRSKI. The Raw Public Key is used by the voucher before the "enroll" state as defined in constrained-BRSKI. The BRSKI-CLE is designed for the "enroll" state after the "imprint" state. +--v---+ | (4) Imprint | +--+---+ | send Voucher Status Telemetry +--v---+ | (5) Enroll | +--+---+ Thus, BRSKI-CLE is not involved in the vouchers. This draft focuses on the enrollment phase in BRSKI and the authentication for the communication between pledges after enrollment. >2. Do you have a proof-of-concept implementation? We have some implementations on certificateless authentication but not on BRSKI-CLE. >3. There seems to be a significant gap in how the vouchers would work. >I didn't understand this at all. As explaining in the first question, BRSKI-CLE is not involved in the vouchers. >It all starts with an unsupported assumption that IoT devices can not hold >certificates. Yet, they are being installed into devices by the billions >today. If the enrollment protocol issues a domain certificate to the IoT devices, after the enrollment, the IoT devices just can use the domain certificate for authentication in communication. BRSKI-CLE is an enrollment protocol that issues a credential, instead of certificates, based on public keys to the IoT devices. Thus, the IoT devices can use the credential to authenticate each other in communication after enrollment. BRSKI-CLE provides a lightweight way for the authentication between IoT devices in communication after enrollment. BRSKI-CLE does not change any process before the "enroll" state in BRSKI. Thus, BRSKI-CLE also supports an X.509 IDevID certificate installed by the vendor on IoT devices. The IoT devices only need to bootstrap once and may do mutual communications unlimited times after enrollment. Therefore, it doesn't matter to use certificates in bootstrapping. A lightweight authentication protocol for communication after bootstrapping is more meaningful. -- Best regards, Lei YAN ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] FW: New Version Notification for draft-yan-anima-brski-cle-00.txt
Hi all, I'd like to bring your attention to the following Individual IETF draft and invite you to review the draft. I believe this draft best fits under the auspices of the ANIMA WG. It is welcome to give feedback or make comments. The high level summary is as follows: == 1. This document describes a lightweight certificateless enrollment protocol in BRSKI for constrained IoT devices. 2. A credential based on public keys is designed to replace the domain certificate used in BRSKI. 3. An authentication centre (AC) replaced the certification authority (CA) is used to issue the credential to the pledge. 4. A new mutual authentication protocol is designed for the authentication between two pledges by the credentials. More details are available in the ID text. Best regards, Lei YAN - Original Message - From: internet-dra...@ietf.org Sent: July 10, 2023 22:28 To: Yanlei(Ray) Subject: New Version Notification for draft-yan-anima-brski-cle-00.txt A new version of I-D, draft-yan-anima-brski-cle-00.txt has been successfully submitted by Lei YAN and posted to the IETF repository. Name: draft-yan-anima-brski-cle Revision: 00 Title: BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI Document date: 2023-07-10 Group: Individual Submission Pages: 13 URL:https://www.ietf.org/archive/id/draft-yan-anima-brski-cle-00.txt Status: https://datatracker.ietf.org/doc/draft-yan-anima-brski-cle/ Html: https://www.ietf.org/archive/id/draft-yan-anima-brski-cle-00.html Htmlized: https://datatracker.ietf.org/doc/html/draft-yan-anima-brski-cle Abstract: Bootstrapping Remote Secure Key Infrastructure (BRSKI, RFC 8995) is an automated bootstrap protocol for unconfigured devices called "pledges". Existing enrollment protocols in BRSKI are all based on certificates, which are not suitable for constrained IoT devices. This document defines a certificateless enrollment protocol in BRSKI (BRSKI-CLE) for constrained IoT devices. To achieve a lightweight protocol, a credential based on public keys is designed to replace the domain certificate used in BRSKI. An authentication centre (AC) replaced the certification authority (CA) is used to issue the credential to the pledge. A new mutual authentication protocol is also designed to authenticate using the credentials. The IETF Secretariat ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Call for agenda items ANIMA@IETF117@ San Francisco
Dear Chairs, I would like to ask for the a time slot for my new individual draft. Topic/Title:BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI Name of Presenter(s): Lei YAN Length of time requested: 20 min Name of draft(s) discussed: draft-yan-anima-BRSKI-CLE-00 Best regards Lei YAN >- Original Message - >From: Anima On Behalf Of 蒋胜 > Sent: Thursday, July 6, 2023 10:33 AM > To: anima > Cc: anima-chairs ; Toerless Eckert > Subject: [Anima] Call for agenda items ANIMA@IETF117@ San Francisco > >Dear ANIMA WG, > >The preliminary IETF117 agenda is on the web. >ANIMA WG will meet at IETF117 for one 2 hour slot: >Wednesday July 26th, 09:30-11:30 (Session I), Plaza B, MEETING TIMEZONE (San >Francisco). > >Please submit your requests for Agenda items in reply to this email, as soon >as possible. >The chairs plan to make WG draft agenda before 7/14/2023, so would be great if >you could submit your agenda requests in before! > >Note that you do not need to have the slides by the time you're asking for the >slot! > >Please send requests to anima-cha...@ietf.org. >Copy anima@ietf.org if you like. > >Topic/Title > Name of Presenter(s) >Length of time requested >If applicable: name of draft(s) discussed > >Also: Once you have your slides, go to: > > https://datatracker.ietf.org/meeting/117/session/anima > >and upload your slides via the "Propose Slides" Button (pick either of the two >slots as you see fit). > >Please also remember to (re-)start discussing any non-WG adopted work also on >the anima@ietf.org mailing list to encourage WG members to read your work and >comment! > >More details about the IETF 117 will be found at: >https://www.ietf.org/how/meetings/117/ > >Thank you so much! > >ANIMA WG Chairs, >Sheng/Toerless >___ >Anima mailing list >Anima@ietf.org >https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
