Re: [netconf] Security template RE: I-D Action: draft-ietf-netconf-tcp-client-server-26.txt

[Kent Watsen <[e-mail]>]

Hi Med,

Right, but mandatory-to-implement != mandatory-to-use.  What is important to say is that *all* defined/allowed transports are 1) secure and 2) require mutual-authentication.  This statement is what allows the security analysis to proceed.

As an aside, looking at RFC 8040 just now, it says "The RESTCONF protocol MUST NOT be used over HTTP without using the TLS protocol”, which is bad given recent moves to run RESTCONF on top of QUIC.  We also want to run NETCONF on top of QUIC, but fortunately RFC 6241 doesn’t limit that possibility.

Kent



> On Apr 5, 2024, at 1:01 PM, [e-mail] wrote:
> 
> Kent,
>  
> I’m not sure what is broken in the template. It is true that other transports were defined, but still SSH is MTI for NETCONF and TLS is MTI for RESTCONF.
>  
> Cheers,
> Med
>  
> De : Kent Watsen <[e-mail] <mailto:[e-mail]>> 
> Envoyé : vendredi 5 avril 2024 18:13
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail] <mailto:[e-mail]>>
> Cc : [e-mail] <mailto:[e-mail]>
> Objet : Re: [netconf] I-D Action: draft-ietf-netconf-tcp-client-server-26.txt
>  
>  
> 
> rfc8407bis isn’t published yet…
> [Med] This is the actual template since 2018! Please seehttps://wiki.ietf.org/group/ops/yang-security-guidelines
>  
> Ack, but that text is broken for the reasons I mentioned true.
>  
>  
> My text is better:
>   - more concise
>   - more accurate
>              - NETCONF supports other transports besides SSH
>              - RESTCONF supports other transports beside TLS
>  
> I suggest fixing rfc8407bis
>  
> Please fix the broken text in rfc8704bis.
>  
>  
> ____________________________________________________________________________________________________________
> 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.