Re: [netconf] crypto-types fallback strategy

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Rich,

From: Salz, Rich <[e-mail]>
Sent: 17 September 2019 14:55
To: Rob Wilton (rwilton) <[e-mail]>; Kent Watsen <[e-mail]>
Cc: Russ Housley <[e-mail]>; [e-mail]; Sean Turner <[e-mail]>; Rifaat Shekh-Yusef <[e-mail]>
Subject: Re: [netconf] crypto-types fallback strategy


Ø  In ietf-crypto-types I would define the base identities for:


hash-algorithm, asymmetric-key-algorithm, mac-algorithm, encryption-algorithm, encryption-and-mac-algorithm, signature-algorithm, key-exchange-algorithm

[RW]
These base identities are just the ones that were already defined in cypto-types-08.  I.e. really I am just saying that defining the base identities in the crypto types draft is the right thing to do, whereas the actual identities can be defined in separate types modules.


I am not very comfortable with that division, as the same key material can be used in multiple places, and we’re transporting key material.  A symmetric key can be used to both encrypt data, and to do an HMAC “signature.”  As a minor note, it omits Key Derivation Functions, KDF, which are a key part of TLS 1.3 and used for “exporting” keys from TLS up to the application layer among other things.
[RW]
If you had an algorithm that can be used for multiple things then it can just derive from multiple base identities.

E.g. if you take “aes-128-ccm” (from draft-ietf-netconf-crypto-types-08) that is currently has “encryption-and-mac-algorithm” as its base, it could be defined as follows, allowing it to be used either as a mac-algorithm or an encryption algorithm:

    identity aes-128-ccm {
      base encryption-algorithm;
      base mac-algorithm;
      description
        "Encrypt message with AES algorithm in CCM mode with a key
         length of 128 bits; it can also be used for generating MAC";
      reference
        "RFC 4309:
           Using Advanced Encryption Standard (AES) CCM Mode with
           IPsec Encapsulating Security Payload (ESP)";
    }





Ø  The key step is that I would say that NETCONF should only standardizes the ones that we need now.

A very strong yes for this.


Ø    For the others, we could potentially create the YANG modules and either hand this off to the security groups, or work whether them to standardize these through the appropriate WGs.

I think it would be worthwhile to contact the Security AD’s and ask for time to present this somewhere, like the open SAAG meeting.
[RW]
I agree that seems like a good idea.  But I think that narrowing the scope to get these documents finished is the highest priority.

Thanks,
Rob