Re: [netconf] Éric Vyncke's Abstain on draft-ietf-netconf-crypto-types-29: (with COMMENT)

[Kent Watsen <[e-mail]>]

Hi Éric,

> On Jan 31, 2024, at 6:51 AM, Eric Vyncke (evyncke) <[e-mail]> wrote:
> 
> Hello Kent,
>  
> Thanks for your prompt reply and the comments.
>  
> As my corporate mail agent is not the most suitable one, please see below for EVY>

Please find responses below!

> While my ballot is not blocking your document, I will welcome the discussion on the “key rollover” and “not valid before” topics.

There is a separate thread (on the trust-anchors document) discussing this too.

Kent


>  
> Regards
>  
> -éric
>  
> From: Kent Watsen <[e-mail] <mailto:[e-mail]>>
> Date: Monday, 29 January 2024 at 16:14
> To: Eric Vyncke <[e-mail] <mailto:[e-mail]>>
> Cc: The IESG <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>>
> Subject: Re: Éric Vyncke's Abstain on draft-ietf-netconf-crypto-types-29: (with COMMENT)
>  
> Hi Éric,
>  
> Thank you for your review.
> Please find below my responses to your comments.
>  
> Kent
>  
> 
> 
>> On Jan 29, 2024, at 9:05 AM, Éric Vyncke via Datatracker <[e-mail] <mailto:[e-mail]>> wrote:
>>  
>> Éric Vyncke has entered the following ballot position for
>> draft-ietf-netconf-crypto-types-29: Abstain
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
>> for more information about how to handle DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Thanks for the work done.
>> 
>> The shepherd's writeup would benefit from a better justification of the
>> intended status.
>  
> There is not much I can do about the shepherd writeup…  ;)
>  
> The document’s header says the Intended Status is "Standards Track”.
>   - is this okay?
>  
> EVY> indeed the author can do nothing about it, but usually there are some justifications about why it is ‘proposed standard’.

If you’re asking me, I guess it is because this document defines a YANG module, and such documents are typically Standards Track per https://datatracker.ietf.org/doc/html/rfc8407.


>> Is there a reason why there are several NETCONF WG crypto-related I-Ds rather
>> than a single one ?
>  
> Do you mean the suite of documents - 9 documents in total?
>  
> EVY> Yes, and thanks for the explanations below. I understand the point of view.

Ack.
 

> I guess because each document has its focus and can be referenced by other
> documents individually.
>  
> For instance, other WGs have documents that reference the “keystore” document,
> while others reference the “tis-client-server” draft.  If there were a single document,
> those references would be too course.  Makes sense?
>  
> 
> 
>> I was about to DISCUSS the following point but balloting ABSTAIN as I am unsure
>> about the use case: the model has cleartext and encrypted passwords (the latter
>> is a hint that the password can be decrypted back to cleartext) but what about
>> password hashes if the remote party should also be authenticated over a
>> protected channel by sending a clear text password ?
>  
> The password documented here is for when configuring a server to connect to a
> remote system, in which case the cleartext password is needed.
>  
> EVY> if this is only for authenticating *TO* a peer, then we agree. It was unclear to me whether authentication *BY* a peer was also in scope.

Right, only for authenticating *TO* a remote peer (i.e., a remote server).

How about this update to the password-grouping’s “description”?

OLD
-      "A password that may be encrypted.";

NEW:
+      "A password used for authenticating to a remote system.
+       
+       The 'ianach:crypt-hash' typedef from RFC 7317 should be
+       used instead when needing a password to authencate a
+       local account.";


> 
> Elsewhere (in the "ssh-client-server" and "http-client-server" drafts), there are passwords
> used for local users (i.e., users logging into the server itself).  The configuration for
> those passwords use the “crypt-hash” type from RFC 7317.
>  
> Makes sense?
>  
> 
> 
>> Another near-DISCUSS point: what about key rollover when 2 keys/passwords could
>> be used ?
>  
> What do you mean?  Can you say some more?
>  
> EVY> in many systems, it is nearly impossible to change the keys/passwords everywhere simultaneously (notably because some systems could be unreachable).
> EVY> I.e., two keys/passwords can be used simultaneously for a short period of time to allow *all* peers to synchronize the credentials.
> EVY> typical case with certificates and also IPsec key rollover.
> EVY> for a OPS WG document, I would expect those operational considerations taken into account.


Here we’re discussing the “crypto-types” document, the YANG module in which only defines *types*…

If I understand you correctly, what your focus is more on the configuration model for a certain protocol, which likely wouldn’t appear in this document.

You mention IPsec, but nowhere in this suite of documents (nine drafts) is IPsec formalized, so I can’t speak to how that configuration model might be structured.

You also mention certificates, which *are* used in the "tls-client-server” draft (soon to be reviewed by the IESG). .  The “ietf-tls-client” YANG module defined in that document enables just one certificate at a time to be configured.   My guess is that if we wanted to rollover the key/cert pair in an automated manner, we’d need/want something like the “Time” conditional from this long-expired I-D: https://datatracker.ietf.org/doc/html/draft-kwatsen-conditional-enablement-00#section-5.3

One additional consideration, my understanding is CAs often issue certs with partially-overlapping validity periods.  For instance, a 1st cert w/ validity Jan thru Jun, and then later, a 2nd cert w/ validity May thru Nov.  This provides the entire month of May to replace the old cert with the new cert, and yet only one cert is ever needing to be configured at a time.  Makes sense?

IDK if I’m answering your question.  If not, could you please provide a quick outline for what the expected solution is that you’re looking for?



>> As in another document, it is nice to have a certificate expiration date but
>> what about a 'not valid before' date ? This is similar to the previous point of
>> key rollover.
>  
> The “certificate-expiration” notification is an asynchronous  message used to alert
> when a certificate is about to become invalid.
>  
> AFAICT, there isn’t a need for an asynchronous notification that a certificate isn’t
> valid yet, or even when a cert is about the become valid, and hence no notification
> is defined for this case - make sense?
>  
> EVY> Very similar to the discussion about roll-over. If a node has two certificates (e.g., 1 day before the expiration, a new one is requested/installed),
> EVY> which one should be used? Especially, if one is not *yet* valid.

I think my previous comment regarding the conditional-enablement draft applies here as well.


Thanks again!
Kent


>> Please add a reference to `rainbow attacks`.
>  
> A rainbow attack is used to crack hashed passwords. 
>  
> As mentioned above, RFC 7317 defines the “crypt-hash” type, which is used by
> other documents in this document-series (specifically the "ssh-client-server” and
> "http-client-server” drafts).
>  
> The “password-grouping” defined in this document isn't for local users, where 
> hashed-passwords would be used, but rather to configure clients to connect to
> remote systems, where a cleartext password is needed.
>  
> I don’t understand why this document might reference rainbow attacks.  Perhaps
> RFC 7317 could’ve referenced rainbow attacks, but it didn’t.
>  
> Please let me know if there is anything I can do to improve the text!
>  
>  
> Thanks,
> Kent
>  
>  
>  
>  
>