Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

Jim Schaad <ietf@augustcellars.com> Wed, 04 September 2019 18:02 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1A2120B3F; Wed, 4 Sep 2019 11:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.798
X-Spam-Level:
X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TRACKER_ID=0.1, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDay_sP6zdSH; Wed, 4 Sep 2019 11:02:40 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878D2120B3C; Wed, 4 Sep 2019 11:02:39 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 4 Sep 2019 11:02:33 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: <consultancy@vanderstok.org>
CC: 'Benjamin Kaduk' <kaduk@mit.edu>, <draft-ietf-ace-coap-est.all@ietf.org>, <ace@ietf.org>
References: <20190828233639.GI84368@kduck.mit.edu> <027701d55ebf$994184b0$cbc48e10$@augustcellars.com> <edcbc2a243cc7118e35aec77b2e1599c@bbhmail.nl> <20190901204340.GG27269@kduck.mit.edu> <6b482aaed0ce510c503984dfbac7286c@bbhmail.nl> <7cd78133c263214be535ec36734f7ec1@bbhmail.nl> <038301d56288$3d13a6b0$b73af410$@augustcellars.com> <408feb436aa5c9d1143d8135ad2dbf28@bbhmail.nl>
In-Reply-To: <408feb436aa5c9d1143d8135ad2dbf28@bbhmail.nl>
Date: Wed, 4 Sep 2019 11:02:31 -0700
Message-ID: <041201d5634a$ee237ad0$ca6a7070$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0413_01D56310.41C73AE0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIXV+tDlosvqNImECv+N/+Ud7Gh2wKJlQMAAbM3AHgCj7Ug0QK+5t/8AjJ0tzcCAyUByQFiC3acph7Gg2A=
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/eYWQLOoZ_mjlfEVs_6by1eNzCtA>
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Sep 2019 18:02:43 -0000

Let me draw back and re-address the comment from Ben about the private key in appendix A.3

 

If I take 

 

308187020100301306072a8648ce3d020106082a8648ce3d030107046d30

6b02010104200b9a67785b65e07360b6d28cfc1d3f3925c0755799deeca7

45372b01697bd8a6a144034200041bb8c1117896f98e4506c03d70efbe82

0d8e38ea97e9d65d52c8460c5852c51dd89a61370a2843760fc859799d78

cd33f3c1846e304f1717f8123f1a284cc99f

 

and decode it I get (with comments from me)

 

SEQUENCE (3 elem)    -- OneAsymmetricKey (replacement of PKCS #8)

  INTEGER 0   -- Version = v1

  SEQUENCE (2 elem)  -- privateKeyAlgorithm

    OBJECT IDENTIFIER 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62 public key type)  -- Alg ID

    OBJECT IDENTIFIER 1.2.840.10045.3.1.7 prime256v1 (ANSI X9.62 named elliptic curve) – Parameters == P256

  OCTET STRING (1 elem) – Private Key

    SEQUENCE (3 elem) – ECPrivate Key  [RFC 5915]

      INTEGER 1 – Version – ecPrivkeyVer1

      OCTET STRING (32 byte) 0B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6 – Private Key value

      [1] (1 elem) – Public key value

        BIT STRING (520 bit) 0000010000011011101110001100000100010001011110001001011011111001100011…

 

 

This looks correct to me.

 

Jim

 

 

 

 

From: Peter van der Stok <stokcons@bbhmail.nl>; 
Sent: Wednesday, September 4, 2019 12:02 AM
To: Jim Schaad <ietf@augustcellars.com>;
Cc: consultancy@vanderstok.org; 'Benjamin Kaduk' <kaduk@mit.edu>;; draft-ietf-ace-coap-est.all@ietf.org; ace@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

 

I concluded on the pruned .

Peter

Jim Schaad schreef op 2019-09-03 20:48:

I have pruned and tossed in  a few [JLS] comments.

 

Jim

 

 

From: Peter van der Stok <stokcons@bbhmail.nl <mailto:stokcons@bbhmail.nl> > 
Sent: Tuesday, September 3, 2019 5:18 AM
To: Benjamin Kaduk <kaduk@mit.edu <mailto:kaduk@mit.edu> >
Cc: Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> >; draft-ietf-ace-coap-est.all@ietf.org <mailto:draft-ietf-ace-coap-est.all@ietf.org> ; consultancy@vanderstok.org <mailto:consultancy@vanderstok.org> ; ace@ietf.org <mailto:ace@ietf.org> 
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

 

Hi Ben,

the last part of the responses to your thorough review.
Apart from nits you found some "nice" mistakes.

the openssl example make me worry a bit.

See below.

Peter
_______________________________________________________________________


   SignedData is signed by the party that generated the private key,
   which may be the EST server or the EST CA.  The SignedData is further
   protected by placing it inside of a CMS EnvelopedData as explained in
   Section 4.4.2 of [RFC7030].  In summary, the symmetrically encrypted

.... if the SignedData is not the outermost container, then we don't care
what the relevant Content-Format for it is; we only care about the
Content-Format for the EnvelopedData.

<pvds>

s/ SignedData is signed/SignedData, placed in the outermost container, is signed/

s/ The SignedData is further protected by placing it inside of a CMS EnvelopedData/

SignedData placed within the Enveloped Data does not need additional signing/

</pvds>

Also, did we explicitly consider and reject AuthEnvelopedData?

<pvds>

Not sure about this

[JLS] As a CMS person, I would consider the use of EnvelopedData and AuthEnvelopedData to be equivalent.  Which of these is used is totally dependent on what algorithm is used for encryption.  If one requires the use of AES-GCM or AES-CCM then one has no choice but to use AuthEnvelopedData.  If one wants to use AES-CCM ten one has no choice but to use EnvelopedData.  Everybody is slowly moving from EnvelopedData to AuthEnvelopedData just because everybody is changing algorithms.  I do not remember any discussions about this, but AuthEnvelopeData is generally going to be the more correct value here.   I will also note that there is a space between Enveloped and Data which is not CMS.

<pvds2>
I don't do anything here
</pvds2>

</pvds>






   encryptedKey attribute in a KeyTransRecipientInfo structure.
   Finally, if the asymmetric encryption key is suitable for key
   agreement, the generated private key is encrypted with a symmetric
   key which is encrypted by the client defined (in the CSR) asymmetric

In the key-agreement case, the symmetric key-encryption key is the
result of the key-agreement operation, no?  In which case it is not
itself encrypted, but rather the server's ephemeral public value is
sent.

<pvds>

In RFC7030 the text says: the EnvelopedData content is encrypted using a randomly

generated symmetric encryption key (that means ephemeral I assume). The cryptographic strength of

the symmetric encryption key SHOULD be equivalent to the clientspecified

asymmetric key.

However, I see no explicit relation with the ephemeral public value.

I don't know what to do here; probably insert the 7030 text.

[JLS] Ben, you do not have the correct view of the key-agreement case.  It does a key agreement -> KDF -> KeyWrap -> Content.  There is always a key wrap step between the key agreement and the content encryption key.
<pvds2>
Also here I see no room for improvement then.
<pvds2>

</pvds>

   public key and is carried in an recipientEncryptedKeys attribute in a
   KeyAgreeRecipientInfo.

   [RFC7030] recommends the use of additional encryption of the returned
   private key.  For the context of this specification, clients and
   servers that choose to support server-side key generation MUST
   support unprotected (PKCS#8) private keys (Content-Format 284).
   Symmetric or asymmetric encryption of the private key (CMS
   EnvelopedData, Content-Format 280) SHOULD be supported for
   deployments where end-to-end encryption needs to be provided between
   the client and a server.  Such cases could include architectures
   where an entity between the client and the CA terminates the DTLS
   connection (Registrar in Figure 4).

This carefully says nothing about recommendations for use, only for
software support.  Are we letting 7030's recommendation for use of
encryption stand?  It's probably worth being explicit, either way.

<pvds> I did not find any recommendation for use in RFC7030 apart the responsibility of the server for generating random numbers. The recommendations at the top of section 5.8 of the draft seem adequate in my opinion. The alternative is classifying the applications; unless you see a better way to do this.

</pvds>





Why OPTIONAL?  (Also, nit: OPTIONALLY isn't a 2119 keyword; only OPTIONAL.)

   client.  For example, it could be configured to accept POP linking
   information that does not match the current TLS session because the
   authenticated EST client Registrar has verified this information when
   acting as an EST server.

This is close enough to a literal quote that we might think about
actually quoting and using quotation marks.
nit: s/POP/PoP/ if we don't do the literal quote.

<pvds>

Hope my co-authors will react to this

[JLS] I would disagree with the nit.

[JLS] I would agree with the nit on OPTIONALLY being wrong, but I think  that it ought to be at least a SHOULD if not a MUST for the use of COAPS as it is terminating the connection.  The only exception would be in there is internal authentication for the EST request.
<pvds2>
Suggest to use SHOULD and not distinguish between terminating or not.
<pvds2>

</pvds>






Section 9.1

I think we probably need this document as a reference for all the
allocations; as the document effectuating the registration, we are still
of interest even if most details of content encoding lie elsewhere.

[JLS] No response from Peter?
<pvds2>
Sorry, misunderstood. Will add <thisdocument>
</pvds2>


Appendix A.3

I'm having trouble validating the private key in the PKCS#8 component:
asn1parse says:

<pvds>

As input I used recently a hex dump of Wt1234.key.der:

308187020100301306072a8648ce3d020106082a8648ce3d030107046d30
6b020101042061336a86ac6e7af4a96f632830ad4e6aa0837679206094d7
679a01ca8c6f0c37a14403420004c8b421f11c25e47e3ac57123bf2d9fdc
494f028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95
cf75f602f9152618f816a2b23b5638e59fd9

 

I used openssl pkey -in Wt1234.key.der -text -noout -inform der\

-passin pass:watnietweet

[JLS] I would lose the password on the key if possible.

<pvds2>
Right, It means changing the whole chain of certificates. and redoing the examples.
But I understand the reason, being confronted with the disassembly failure.
</pvds2>

The password is may be prohibitive?

Resulting in:
Private-Key: (256 bit)
priv:
    61:33:6a:86:ac:6e:7a:f4:a9:6f:63:28:30:ad:4e:
    6a:a0:83:76:79:20:60:94:d7:67:9a:01:ca:8c:6f:
    0c:37
pub: 
    04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d:
    9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5:
    0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90:
    be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b:
    56:38:e5:9f:d9
ASN1 OID: prime256v1
NIST CURVE: P-256
 

$ unhex|openssl asn1parse -inform der
   308187020100301306072a8648ce3d020106082a8648ce3d030107046d30
   6b02010104200b9a67785b65e07360b6d28cfc1d3f3925c0755799deeca7
   45372b01697bd8a6a144034200041bb8c1117896f98e4506c03d70efbe82
   0d8e38ea97e9d65d52c8460c5852c51dd89a61370a2843760fc859799d78
   cd33f3c1846e304f1717f8123f1a284cc99f
    0:d=0  hl=3 l= 135 cons: SEQUENCE          
    3:d=1  hl=2 l=   1 prim: INTEGER           :00
    6:d=1  hl=2 l=  19 cons: SEQUENCE          
    8:d=2  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
   17:d=2  hl=2 l=   8 prim: OBJECT            :prime256v1
   27:d=1  hl=2 l= 109 prim: OCTET STRING      [HEX DUMP]:306B02010104200B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6A144034200041BB8C1117896F98E4506C03D70EFBE820D8E38EA97E9D65D52C8460C5852C51DD89A61370A2843760FC859799D78CD33F3C1846E304F1717F8123F1A284CC99F

which doesn't look like an RFC5208 PrivateKeyInfo:

      PrivateKeyInfo ::= SEQUENCE {
        version                   Version,
        privateKeyAlgorithm       PrivateKeyAlgorithmIdentifier,
        privateKey                PrivateKey,
        attributes           [0]  IMPLICIT Attributes OPTIONAL }

      Version ::= INTEGER

      PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier

      PrivateKey ::= OCTET STRING

      Attributes ::= SET OF Attribute

due to the lack of OID for privateKeyAlgorithm, etc.
(`openssl pkcs8` also chokes on it, but I don't have a working example and
can't rule out user error there.)

Even that giant OCTET STRING 27 bytes in doesn't seem to match a
PrivateKeyInfo:

$ unhex|openssl asn1parse -inform der -strparse 27
   308187020100301306072a8648ce3d020106082a8648ce3d030107046d30
   6b02010104200b9a67785b65e07360b6d28cfc1d3f3925c0755799deeca7
   45372b01697bd8a6a144034200041bb8c1117896f98e4506c03d70efbe82
   0d8e38ea97e9d65d52c8460c5852c51dd89a61370a2843760fc859799d78
   cd33f3c1846e304f1717f8123f1a284cc99f
    0:d=0  hl=2 l= 107 cons: SEQUENCE          
    2:d=1  hl=2 l=   1 prim: INTEGER           :01
    5:d=1  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:0B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6
   39:d=1  hl=2 l=  68 cons: cont [ 1 ]        
   41:d=2  hl=2 l=  66 prim: BIT STRING        

though the OCTET STRING does have the private key and the BIT STRING has
the public key's contents as depicted in C.3 (details of that too boring
to show).

So I have to wonder if I'm messing something up, somewhere.






Appendix B.1






Should we be using the same Token value in two different exchanges in
this document?

<pvds>

No opinion

[JLS] As long as the Token values are not in the same exchange, this makes no difference.  Tokens are reused after an amount of time in CoAP.

<pvds2>
No extra text, I gather
</pvds2>

</pvds>