Re: [lamps] Feedback on figure 3 in draft-brockhaus-lamps-lightweight-cmp-profile-01

["Brockhaus, Hendrik" <[e-mail]>]

Justin

thank you very much for you feedback and ideas to ease the use of the lightweight CMP profile for constrained entities.
Please see my comments inline below.


> -----Ursprüngliche Nachricht-----
> Von: Spasm <[e-mail]> Im Auftrag von Justin Cranford
> Gesendet: Mittwoch, 4. Dezember 2019 00:55
> An: [e-mail]
> Betreff: [lamps] Feedback on figure 3 in draft-brockhaus-lamps-lightweight-
> cmp-profile-01
> 
> Hello,
> 
> Figure 3 shows the proposed message format for securely returning a remote
> generated privateKey to a lightweight CMP client.
> 
> -
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.
> org%2Fhtml%2Fdraft-brockhaus-lamps-lightweight-cmp-profile-01%23page-
> 31&amp;data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C4c12326f0f
> 9e4680fdcf08d7784c8cfc%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1
> %7C637110142482661729&amp;sdata=grVrLN8a43hCZC93QIbKELZFxENB0q1Y
> zs2hFhEKMUc%3D&amp;reserved=0
> 
> 
> Feedback summary:
> 
> 1. CMS SignedData should be the outer layer.
> 2. CMS ContentInfo should be used to wrap both of the CMS EnvelopedData and
> CMS SignedData layers.
> 3. CMS Data may be useful to wrap the privateKey payload.
> 
> 
> 
> Feedback details:
> 
> 1. CMS SignedData should be the outer layer.
> a) When a lightweight IOT client receives a response, it should do the
> lightweight SignedData verification first.

[Bro] I see your goal and appreciate it. Actually there is the outer signature provided by the CMP protection. But to explain a bit further, I had two points in mind while defining the structure like this.
i) Currently the structure specified in CMP to carry the private key is EncryptedValue. EncryptedValue is defined in CRMF and is depreciated in favor of EnvelopedData for a long time already. Therefore I would like to make use of the EncryptedKey, as also specified in CRMF, to allow EnvelopedData next to EncryptedValue. This procedure was also recommended by Jim Schaad while discussion this at IETF104 as this is backward compatible with current syntax on the bitstream and requires only a minimal extension to CMP. This change is documented in CMP Updates section 3.4 (https://tools.ietf.org/html/draft-brockhaus-lamps-cmp-updates-01#section-3.4 ).
ii) While specifying the structure I used guidance from "CMS Encrypted Key Package Content Type" RFC6032 (https://www.rfc-editor.org/rfc/rfc6032.html ). As the CMP response message is signed, I have a layering like this: CMPProtection(EnvelopedData(SignedData(privateKey)))
Finally, the inner signedData serves the goal to proof who generated the key-pair and therefore has knowledge of the privateKey next to the end entity. This can only be achieved by putting the signature into the envelopedData structure.

Therefore I would say, I also follow the procedure of Gutmann with regard to the outer signature provided by the CMPProtection and the envelopedData encrypting the privateKey. But I added an inner signature to proof who has knowledge of the privateKey. This is required especially in a scenario where the key-pair was not generated by the PKI management entity the end entity directly talks to. In such scenarios, where the encrypted privateKey is transferred over several hops, the inner signature is necessary. May be Peter Gutmann should consider adding such inner signature to his syntax to also offer this feature. In case the end entity does not care or has very limited resources, it can skip the validation of this inner signature.

Did this clarify my design goals and constraints. If you have concrete suggestions to improve this with regard to simplification of validation, please let me know.
In case I misunderstood your suggestion, please also come back to me. :-)

> b) In other words, if a lightweight client does heavyweight EnvelopedData
> decryption first, and SignedData verification fails second, the client just wasted
> a lot of processing power, battery life, and time.

[Bro] This is right. Therefor the functional extension to deliver centrally generated keys is optional and not recommended. As motivated in https://tools.ietf.org/html/draft-brockhaus-lamps-lightweight-cmp-profile-01#section-5.1.6  it is recommended to locally generated the key material if possible. 
If the end entity has to request for central key generation it anyhow first validates the signature of the CMP protection when receiving the response message and therefore has some evidence that the response message comes from a legitimate PKI management entity.

> c) CMS SignedData can be used to provide extra data needed by the client to
> decrypt EnvelopedData. Consider if client and server both use EC key pairs.
> Example: EnvelopedData contains KeyAgreeRecipentInfo using static-static
> ECDH algorithm. Client needs the server EC public key to compute
> EnvelopedData KEK. Server options for the originator KeyIdentifier in KARI
> include IssuerAndSerialNumber, SubjectKeyIdentifier, or OriginatorPublicKey. If
> server chooses IssuerAndSerialNumber, the client must find the server's EC
> public cert. That somewhere can be the SignedData certificates set if-and-only-
> if SignedData is outside EnvelopedData.

[Bro] I tried to make use of data already used in the CMPHeader of the response message, for example to identify the end entities key to be used for the keyManagement.
                   recipientEncryptedKey
                                REQUIRED
                     rid        REQUIRED
                       rKeyId   REQUIRED
                         subjectKeyID
                                REQUIRED
       -- MUST contain the same value as the senderKID in the respective
       -- request messages

Generally I am not in favor of static-static DH. I prefer static-ephemeral DH to have more variation in the agreed symmetric keys, in case the same PKI management entity generates another key pair for the same end entity. You may argue, that it will not happen that this will be performed using the same key-pairs on both sides, but you never know. Therefore, I mandated to use the OriginatorPublicKey field in the section 5.1.6.2 (https://tools.ietf.org/html/draft-brockhaus-lamps-lightweight-cmp-profile-01#section-5.1.6.2 ). Doing so I reduce the options in the syntax and offere the server side to align with the algorithm the client uses. Therefore I do not have to require that client and server both have EC key pairs.
 
> 
> 2. CMS ContentInfo should be used to identify the CMS EnvelopedData and CMS
> SignedData layers.
> a) The lightweight client's CMS parser can to do more strict verification of the
> response structure without incurring significant overhead.

[Bro] You are right, CMS recommends to use ContentInfo. For the outer EnvelopedData the use of EncryptedKey does not allow wrapping in ContentInfo. In the EnvelopedData structure I do use the contentType field to specify the id-signedData type and in SignedData I also used the contentType id-data to specify the type for the privateKey. 
See section 5.1.6 (https://tools.ietf.org/html/draft-brockhaus-lamps-lightweight-cmp-profile-01#section-5.1.6 ):

[...]
             encryptedContentInfo
                                 REQUIRED
               contentType       REQUIRED
       -- MUST be id-signedData
               contentEncryptionAlgorithm
                                 REQUIRED
       -- MUST be the algorithm identifier of the symmetric
       -- content-encryption algorithm used
       -- As private keys need long-term protection, the use of AES-256
       -- or a stronger symmetric algorithm is RECOMMENDED
               encryptedContent  REQUIRED
       -- MUST be the encrypted signedData structure as specified in
       -- CMS [RFC5652] section 5
[...]
                   contentType   REQUIRED
       -- MUST be id-data
                   content       REQUIRED
       -- MUST be the privateKey as OCTET STRING
[...]

Would you still recommend to wrap the SignedData and the privateKey in a ConentInfo structure first, before putting it into the surrounding structure?
I feel like this would be too much.

> 
> 3. CMS Data can be used to wrap the privateKey.
> a) This is optional, but it might be useful to wrap the payloads.
> b) If you choose to add a CMS Data layer, also wrap it with CMS ContentInfo
> like in point #2.

[Bro] As described, I do mandate to use the contentType id-data for the privateKey.

> 
> 
> 
> References:
> 
> I based my feedback on SCEP pkiMessage format from Gutmann SCEP draft 14.
> SCEP is a lightweight enrollment protocol with similar goals to lightweight CMP
> profile draft.
> 
> Gutmann SCEP draft 14 does a good job of explaining the structure of its secure
> pkiMessage format with different layers of ContentInfo, SignedData,
> EnvelopedData, and Data.
> 
> -
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.
> org%2Fhtml%2Fdraft-gutmann-scep-14%23page-
> 13&amp;data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C4c12326f0f
> 9e4680fdcf08d7784c8cfc%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1
> %7C637110142482661729&amp;sdata=G4zoSgXCHDD2zJUDNwo268Gdsp6teT
> MPt10647UrXCI%3D&amp;reserved=0 (June 9 2019)
> 
> Gutmann inherited this message format from Nourse SCEP draft 23. However,
> Gutmann does a much better job showing and explaining the structure, so use
> the Gutmann reference.
> 
> -
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.
> org%2Fhtml%2Fdraft-nourse-scep-23%23section-
> 3&amp;data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C4c12326f0f9
> e4680fdcf08d7784c8cfc%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%
> 7C637110142482671723&amp;sdata=h3lJnuPkm8nRdndj0Wb7ptKIAsngK8EG%2
> FrRdBqRuALQ%3D&amp;reserved=0 (September 2011)
> 
> Here is a compact summary of the SCEP pkiMessage format. SCEP uses it for
> requests and responses.
> 
> - SCEP's pkiMessage =
> ContentInfo[SignedData[ContentInfo[EnvelopedData[ContentInfo[Data[payload]
> ]]]]]
> 
> 
> Summary:
> 
> Ignore SCEP payload formats since they are not applicable. Optionally use the
> same CMS Data layer.  Definitely put SignedData first, and consider adding
> ContentInfo wrappers for all CMS layers.
> 
> Thank you,
> Justin Cranford
> Prin Software Developer
> Entrust Datacard
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.
> org%2Fmailman%2Flistinfo%2Fspasm&amp;data=02%7C01%7Chendrik.brockha
> us%40siemens.com%7C4c12326f0f9e4680fdcf08d7784c8cfc%7C38ae3bcd9579
> 4fd4addab42e1495d55a%7C1%7C1%7C637110142482671723&amp;sdata=LU4
> UFLDKg4Lru40ZcmdYvk%2BCXPkS4UkfoA59cp8aFNg%3D&amp;reserved=0