[Anima] Re: Mohamed Boucadair's Discuss on draft-ietf-anima-brski-prm-18: (with DISCUSS and COMMENT)

["Fries, Steffen" <[e-mail]>]

Hi Mohamed,

Ah sorry, forgot to include the info regarding open-brski. That implementation is an example implementation of BRSKI-PRM and parts of cBRSKI and was done as part of a master thesis. The implementation bases on OpenSSL and utilizes to my knowledge TLS 1.2.

Best regards
Steffen

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Thursday, April 10, 2025 6:04 PM
> To: Fries, Steffen <steffen.fries=[e-mail]>; The IESG
> <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: RE: Mohamed Boucadair's Discuss on draft-ietf-anima-brski-prm-18: (with
> DISCUSS and COMMENT)
> 
> Re-,
> 
> Thanks, Steffen.
> 
> I think we are almost there, modulo the "paused" item and recording the limitation.
> 
> > > BTW, what is currently supported by implementations such as
> > open-brski?
> > [stf]
> >
> 
> [Med] It seems this was one was incomplete. I'm interested still interested, but
> that's fine if we don't have an answer. Thanks.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Fries, Steffen <steffen.fries=[e-mail]>
> > Envoyé : jeudi 10 avril 2025 17:35
> > À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> The
> > IESG <[e-mail]> Cc : [e-mail];
> > [e-mail]; [e-mail]; [e-mail];
> > [e-mail] Objet : RE: Mohamed Boucadair's Discuss on
> > draft-ietf-anima-brski-
> > prm-18: (with DISCUSS and COMMENT)
> >
> >
> > Hi Mohamed,
> >
> > Thanks for your comments. As last time, I leave the comments with
> > reactions and dropped the closed ones for easier reading.
> > The draft with the updates has been put on the usual place in github
> > (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feur
> >
> 03.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%25252&d
> >
> ata=05%7C02%7Csteffen.fries%40siemens.com%7C1afd21e6721341eb8a9308dd7
> 8
> >
> 495eba%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6387989786909
> 06742
> >
> %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD
> AwMCIsI
> >
> lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=
> crY
> > y0R759q139IOXkuJl4imtDXICDfeHhLlSkSnn3M4%3D&reserved=0
> > Fgithub.com%2Fanima-wg%2Fanima-brski-prm%2Fblob%2Fmain%2Fdraft-
> > ietf-anima-brski-
> >
> prm.md&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C94792fe975f
> >
> 94fd8972f08dd784543bc%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7
> >
> C638798961115558475%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
> ydW
> > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3
> >
> D%3D%7C0%7C%7C%7C&sdata=0ibhUGU1HfNOMvByzeiLbmnrUu5ruMeye%2B
> %2FYND
> > Ev7iE%3D&reserved=0).
> >
> > Best regards
> > Steffen
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > <[e-mail]>
> > > Sent: Thursday, April 10, 2025 7:11 AM
> > > To: Fries, Steffen (FT RPD CST) <[e-mail]>; The
> > IESG
> > > <[e-mail]>
> > > Cc: [e-mail]; [e-mail];
> > > [e-mail]; [e-mail]; [e-mail]
> > > Subject: RE: Mohamed Boucadair's Discuss on
> > > draft-ietf-anima-brski-prm-18: (with
> >
> > > > > > > --------------------------------------------------------
> > ----
> > > > > > > DISCUSS:
> > > > > > > --------------------------------------------------------
> > ----
> > > > > > > # DISCUSS
> > > > > > > # Compliance with HTTP BCP (RFC9205)
> > > > > > >
> > > > > > > CURRENT:
> > > > > > >    If the pledge is unable to create the PVR, it SHOULD
> > respond with an
> > > > > > >    HTTP error status code to the Registrar-Agent.  The
> > following client
> > > > > > >    error status codes SHOULD be used:
> > > > > > >
> > > > > > > The use of normative language is IMO not compliant with
> > the
> > > > > > > guidance in RFC9205, about error handling.
> > > > > > [stf] I created a new issue for this:
> > > > > > From RFC 9205 I understood that we could use the HTTP
> > status
> > > > > > codes in this way. What would you suggest here?
> > > > > >
> > > > >
> > > > > [Med] A simple fix here is to remove the normative language.
> > > > > Listing the appropriate codes is definitely right, but need
> > to
> > > > > redefine the error codes, just be affirmative. For example,
> > an
> > > > > entity will return 404 when there is no resources, etc.
> > > > [stf] Hm, after the discussion in the design team, we are not
> > quite
> > > > sure about your concern. Is it the one.-to-one mapping
> > referenced in
> > > > section 4.6 of RFC 9205 or the understanding we re- define
> > status
> > > > codes?
> > > >
> > >
> > > [Med] I'm afraid that you are redefining those. We don't need
> > new
> > > normative HTTP behavior here. I suggest we simply make this
> > change
> > > (and similar)
> > >
> > > OLD:
> > >    If the pledge is unable to create the PER, it SHOULD respond
> > with an
> > >    HTTP error status code to the Registrar-Agent.  The following
> > client
> > >    error status codes MAY be used:
> > >
> > >    *  400 Bad Request: if the pledge detects an error in the
> > format of
> > >       the request.
> > >   ...
> > >
> > > NEW:
> > >    If the pledge is unable to create the PER, it responds with
> > an
> > >    HTTP error status code to the Registrar-Agent.  The following
> > client
> > >    error status codes can be used:
> > >
> > >    *  400 Bad Request: if the pledge detects an error in the
> > format of
> > >       the request.
> > >    ..
> > [stf] Okay, got it, made the changes as proposed for the different
> > HTTP status codes
> >
> 
> [Med] Thanks.
> 
> >
> > > > > > > # Cluster with 8366bis
> > > > > > >
> > > > > > > CURRENT:
> > > > > > >
> > > > > > >    The JSON PVR Data MUST contain the following fields
> > of the "ietf-
> > > > > > >    voucher-request" YANG module as defined in
> > > > > > > [I-D.ietf-anima-rfc8366bis];
> > > > > > >
> > > > > > > I think this spec should be clustered with 8366bis.
> > There are
> > > > > > > several structure that used in this document and which
> > depends on what is defined in 8366bis.
> > > > > > > Changes to the bis will have implications on this one.
> > > > > > >
> > > > > > > With that in mind, I tend to suggest holding approval of
> > this
> > > > > > > specification till we finalize the bis spec.
> > > > > > [stf] As indicated by Michael, we already have a cluster
> > for
> > > > RFC
> > > > > > 8366bis and further drafts related to BRSKI variants to
> > take
> > > > > > care of mutual influences. I opened an issue
> > > > >
> > > > > [Med] ACK.
> > > > [stf] Also discussed in design team meeting today. It is less
> > about
> > > > changes in the draft but more to the processing. The intention
> > is
> > > > that all other BRSKI variant documents currently handled will
> > go
> > > > into MISSREF, as draft-ietf-jws-voucher waiting for 8366bis.
> > 8366bis
> > > > collects considerations from the different documents and is
> > likely
> > > > not to lead to addition of new information in the respective
> > drafts
> > > > (at least that is the intention).
> > > >
> > >
> > > [Med] I would be more comfortable if I had more stability signs
> > of
> > > 8366 ;-)
> > >
> > > That's said, I think that I have the discussion I wanted to
> > have. I
> > > leave it to Mahesh to decide.
> > [stf] Okay, agreed
> >
> >
> > > > > > > # Requires TLS1.3
> > > > > > >
> > > > > > > CURRENT:
> > > > > > >    As already stated in [RFC8995], the use of TLS 1.3
> > (or newer) is
> > > > > > >    encouraged.  TLS 1.2 or newer is REQUIRED on the
> > Registrar-Agent
> > > > > > >    side.  TLS 1.3 (or newer) SHOULD be available on the
> > registrar, but
> > > > > > >    TLS 1.2 MAY be used.  TLS 1.3 (or newer) SHOULD be
> > available on the
> > > > > > >    MASA, but TLS 1.2 MAY be used.
> > > > > > >
> > > > > > > Please update to take into to reflect draft-ietf-uta-
> > require-tls13.
> > > > > > [stf] I saw that there was already discussion on this
> > issue. I
> > > > > > created a corresponding issue as We will discuss the use
> > of TLS
> > > > > > 1.2 and if there is a desire to also allow or existing
> > pledges,
> > > > > > that may have no option to only allow TLS 1.3, we would
> > add a
> > > > > > note as suggested and explain the necessity.
> > > > > >
> > > > >
> > > > > [Med] ACK. I'm neutral on the outcome here, but I'd like we
> > back
> > > > > the design and include some reasoning if we don't follow the
> > UTA reco. Thanks.
> > > > [stf] BRSKI-PRM is an extension of existing BRSKI, which
> > requires
> > > > TLS 1.2. We aligned with that and also included it in BRSKI-
> > PRM.
> > > > TLS1.3 is currently widely used in browsers, but industry
> > adoption
> > > > is not as fast. There are constraint devices using SDKs, which
> > are
> > > > not updated fast.
> > > > We enhanced the part with following to state the consideration
> > of
> > > > the uta draft.:
> > > > OLD
> > > > As already stated in {{!RFC8995}}, the use of TLS 1.3 (or
> > newer) is
> > > > encouraged.
> > > > NEW
> > > > As already stated in {{!RFC8995}}, and required by {{I-D.ietf-
> > uta-
> > > > require-tls13}}, the use of TLS 1.3 (or newer) is encouraged.
> > > >
> > >
> > > [Med] I suggest we pause on this one and reflect the outcome of
> > the
> > > ongoing discussion.
> > [stf] Okay, agreed
> >
> > >
> > > I would at least see in the text a brief mention of the SDK
> > > limitations you mentioned.
> > [stf] Yes, it is likely good
> > >
> 
> [Med] ACK
> 
> > > BTW, what is currently supported by implementations such as
> > open-brski?
> > [stf]
> >
> 
> [Med] It seems this was one was missing. I'm interested, but that's fine if we don't
> have an answer. Thanks.
> ______________________________________________________________________
> ______________________________________
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou
> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si
> ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed, used or
> copied without authorisation.
> If you have received this email in error, please notify the sender and delete this
> message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.