Subject: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg

From: Tim Hollebeek <[email-masked]>
Date: Thu, 12 Nov 2020 21:51:10 +0000

For those of you who are following the discussion, you're probably aware of
the following brief draft that is related to the CMP work.

It allocates an OID for AES-GMAC, and contains provisions for its use within
CMS.  The draft is available here:

https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.txt

Please indicate by November 25th whether you support adoption of
draft-housley-lamps-cms-aes-mac-alg by the LAMPS WG.

-Tim

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Nov 2020 17:10:19 -0500

> draft-housley-lamps-cms-aes-mac-alg by the LAMPS WG.

Seems short and to the point.

An example message in an appendix would be nice.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 13 Nov 2020 06:55:37 +0000

I do support the adoption.

Hendrik

Von: Spasm <[email-masked]> Im Auftrag von Tim Hollebeek
Gesendet: Donnerstag, 12. November 2020 22:51
An: LAMPS <[email-masked]>
Betreff: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg

For those of you who are following the discussion, you're probably aware of the following brief draft that is related to the CMP work.
It allocates an OID for AES-GMAC, and contains provisions for its use within CMS.  The draft is available here:

https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.txt<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-housley-lamps-cms-aes-mac-alg-00.txt&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C7a072c28d1ef4fa9325708d887552164%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637408146986106192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=79NiNrw4qUDVsfz62XcDeaqX26QUEG%2BnHrm%2FFnPNsGc%3D&reserved=0>

Please indicate by November 25th whether you support adoption of draft-housley-lamps-cms-aes-mac-alg by the LAMPS WG.

-Tim

---

From: Russ Housley <[email-masked]>
Date: Fri, 13 Nov 2020 09:12:08 -0500

> On Nov 12, 2020, at 5:10 PM, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

Sure.  That is something I can do in the next version.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 13 Nov 2020 14:58:01 +0000

>    An example message in an appendix would be nice.

What he said.

---

From: Jonathan Hammell <[email-masked]>
Date: Fri, 13 Nov 2020 13:42:30 -0500

I support adoption of this draft.

For reference, the ASN.1 module including GMAC in ISO/IEC 9797-3 specifies:
is9797-3 OID ::= {iso standard message-authentication-codes(9797) part3(3)}
id-gmac OID ::= {is9797-3 gmac(4)}
GmacParameters ::= SEQUENCE {
    bcAlgo BlockAlgorithms,
    taglength INTEGER,
    noncelength INTEGER
}

where bcAlgo would specify AES-128, AES-192 or AES-256.  Matching
other algorithms in 9797-3, the nonce is assumed to be transmitted
separately.

However, I think the definition of GMACParameters in your I-D makes more sense.

Best regards,
Jonathan

On Fri, Nov 13, 2020 at 9:12 AM Russ Housley <[email-masked]> wrote:
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Fri, 13 Nov 2020 14:06:20 -0500

I was unaware of the ISO/IEC 9797-3 OID, which seems to allow any block cipher, and thus is not able to constrain the tag length based on the specifics of that block cipher.

Russ

> On Nov 13, 2020, at 1:42 PM, Jonathan Hammell <[email-masked]> wrote:
>

---

From: Jonathan Hammell <[email-masked]>
Date: Fri, 13 Nov 2020 14:25:57 -0500

> I was unaware of the ISO/IEC 9797-3 OID, which seems to allow any block cipher, and thus is not able to constrain the tag length based on the specifics of that block cipher.

That is true that 9797-3 does not constrain the tag length based on
the block cipher.  In the normative text for GMAC, it states "GMAC can
be used with any block cipher from ISO/IEC 18033-3 that has a block
length of 128 bits. The resulting MAC is t bits long, where t is a
multiple of 8 and satisfies 64 ≤ t ≤ 128."

Jonathan

---

From: Russ Housley <[email-masked]>
Date: Fri, 13 Nov 2020 16:14:02 -0500

Here is my proposed addition for the Example.  Please let me know if it does not meet your needs.

Russ

= = = = = = = = =

Appendix: AuthenticatedData Example

This example shows the establishment of an AES-256 key-encryption
key to distribute the AES-128-GMAC content-authentication key.
The content-authentication key is encrypted using AES-256-KEYWRAP.
Thus, any party in possession of the key-encryption key could have
produced the autenticated message.  The recipient only knows that
the message was produced by one of those parties.

The AES-256 key-encryption key, in hexadecimal:
   0b4db8bfae5d202c2dffaa6746658c7edf7a2c100fe8c8a74fc198b2cd9b7419

The identifier assigned to the key-encryption key is:
   fb6f2b3952fd7449d298f68aa4bcd94d

The date used with this identifier is:
   20201110120000Z

The DER encoding of the AuthenticatedData encapsulated in the
ContentInfo produces 289 octets, which are
shown in hexadecimal:
   3082011d060b2a864886f70d0109100102a082010c308201080201003151a24f
   02010430230410fb6f2b3952fd7449d298f68aa4bcd94d180f32303230313131
   303132303030305a300b060960864801650304012d04180cc1b55b29628000d7
   005dc34b7e4ca2dc6735d53ae4def1301b0609608648016503040109300e040c
   bd4fecfd737d29e5419f307ea10b0609608648016503040201302b06092a8648
   86f70d010701a01e041c5468697320697320736f6d652073616d706c6520636f
   6e74656e742ea24b301806092a864886f70d010903310b06092a864886f70d01
   0701302f06092a864886f70d01090431220420c875df2a4210704a9edddbb6df
   cc870471168f904d183318bbf184ac0b045e53040c86e90edca0be9fd74dd59c
   37

Decoding this ASN.1 structure gives:
  0 285: SEQUENCE {
  4  11:  OBJECT IDENTIFIER authData (1 2 840 113549 1 9 16 1 2)
 17 268:  [0] {
 21 264:   SEQUENCE {
 25   1:    INTEGER 0
 28  81:    SET {
 30  79:     [2] {
 32   1:      INTEGER 4
 35  35:      SEQUENCE {
 37  16:       OCTET STRING
       :       FB 6F 2B 39 52 FD 74 49 D2 98 F6 8A A4 BC D9 4D
 55  15:       GeneralizedTime 10/11/2020 12:00:00 GMT
       :        }
 72  11:      SEQUENCE {
 74   9:       OBJECT IDENTIFIER
       :        aes256-wrap (2 16 840 1 101 3 4 1 45)
       :        }
 85  24:      OCTET STRING
       :       0C C1 B5 5B 29 62 80 00 D7 00 5D C3 4B 7E 4C A2
       :       DC 67 35 D5 3A E4 DE F1
       :       }
       :      }
111  27:    SEQUENCE {
113   9:     OBJECT IDENTIFIER
       :      aes128-GMAC (2 16 840 1 101 3 4 1 9)
124  14:     SEQUENCE {
126  12:      OCTET STRING BD 4F EC FD 73 7D 29 E5 41 9F 30 7E
       :       }
       :      }
140  11:    [1] {
142   9:     OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)
       :      }
153  43:    SEQUENCE {
155   9:     OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
166  30:     [0] {
168  28:      OCTET STRING 'This is some sample content.'
       :       }
       :      }
198  75:    [2] {
200  24:     SEQUENCE {
202   9:      OBJECT IDENTIFIER
       :       contentType (1 2 840 113549 1 9 3)
213  11:      SET {
215   9:       OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
       :        }
       :       }
226  47:     SEQUENCE {
228   9:      OBJECT IDENTIFIER
       :       messageDigest (1 2 840 113549 1 9 4)
239  34:      SET {
241  32:       OCTET STRING
       :       C8 75 DF 2A 42 10 70 4A 9E DD DB B6 DF CC 87 04
       :       71 16 8F 90 4D 18 33 18 BB F1 84 AC 0B 04 5E 53
       :        }
       :       }
       :      }
275  12:    OCTET STRING 86 E9 0E DC A0 BE 9F D7 4D D5 9C 37
       :     }
       :    }
       :   }

The authenticated content is: 'This is some sample content.'

---

From: Michael Richardson <[email-masked]>
Date: Fri, 13 Nov 2020 16:37:34 -0500

> does not meet your needs.

Looks okay to me.
I have a preference to base-64 encode the DER, because I think it's easier
for people to decode that.

I decode to something equivalent with
  "xxd -r -p n4 | openssl asn1parse -in -inform der"

I'm curious what ASN1 dumper you are using?

And wasn't the IETF april-1 standard PSK "makemetastegoat"?

---

From: Russ Housley <[email-masked]>
Date: Sat, 14 Nov 2020 01:26:47 -0500

I used dumpasn1 from Peter Gutmann:
  https://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c
  https://www.cs.auckland.ac.nz/~pgut001/dumpasn1.cfg

Russ

> On Nov 13, 2020, at 4:37 PM, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
>

---

From: "Dang, Quynh H. (Fed)" <[email-masked]>
Date: Mon, 23 Nov 2020 11:35:09 +0000

Hi Tim,

I support adoption of the draft.

Regards,
Quynh.
________________________________
From: Spasm <[email-masked]> on behalf of Tim Hollebeek <tim.hollebeek=[email-masked]>
Sent: Thursday, November 12, 2020 4:51 PM
To: LAMPS <[email-masked]>
Subject: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg

For those of you who are following the discussion, you’re probably aware of the following brief draft that is related to the CMP work.

https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.txt<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-housley-lamps-cms-aes-mac-alg-00.txt&data=04%7C01%7Cquynh.dang%40nist.gov%7C22ecfd8d3ac5419324da08d887551f7e%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637408146998624205%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=pz9%2BHetbufARZxSdREzwWm9EtQWcfG8kUz%2Bstrj70Qk%3D&reserved=0>

-Tim

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 23 Nov 2020 11:47:46 +0000

I support the adoption of this draft
Hendrik

________________________________
From: Spasm <[email-masked]<mailto:[email-masked]>> on behalf of Tim Hollebeek <tim.hollebeek=[email-masked]<mailto:tim.hollebeek=[email-masked]>>
Sent: Thursday, November 12, 2020 4:51 PM
To: LAMPS <[email-masked]<mailto:[email-masked]>>
Subject: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg

https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.txt<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-housley-lamps-cms-aes-mac-alg-00.txt&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C855327bb23cd4370aff208d88fa3ddd4%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637417281244470187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7krBt6ITJbtRtfVEhPlHjrDz16xepHFcy2LgqQq5n4I%3D&reserved=0>

-Tim

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 23 Nov 2020 15:20:37 +0000

I support adoption. 

From: Spasm <[email-masked]> On Behalf Of Tim Hollebeek
Sent: Thursday, November 12, 2020 4:51 PM
To: LAMPS <[email-masked]>
Subject: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg

-Tim

---

From: Sean Turner <[email-masked]>
Date: Mon, 23 Nov 2020 13:49:49 -0500

I support adoption and will review.

spt

> On Nov 12, 2020, at 16:51, Tim Hollebeek <tim.hollebeek=[email-masked]> wrote:
>