[Ndn-interest] Adding HMAC to available NDN signature types

[Thompson, Jeff]

I submitted a pull request for adding SignatureHmacWithSha256
https://github.com/named-data/NDN-TLV/pull/1

For convenience, the text is below. I am especially interest in feedback on the languages about provenance: "Provided that the signature verifies, this type of signature ensures provenance that the Data packet was signed by one of the parties which holds the shared Key. The key is identified using a KeyDigest as described above. It is the application’s responsibility to establish the identities of the parties who hold the shared Key."

- Jeff T
SignatureHmacWithSha256<cid:6B94E289-C6DC-4002-9EF9-948D08AD1503>

SignatureHmacWithSha256 defines a hash-based message authentication code that is calculated over the Name<cid:AC18F89D-17C3-42FC-9E01-3D98C498CF70>, MetaInfo<cid:FAADCD52-F5F2-4B4F-8F23-8572A094F60B>, Content<cid:63CEF72F-159E-490F-ACCD-10B291183891>, and SignatureInfo<cid:4BC39041-4470-4AAE-A916-93EFAFB2F6C0> TLVs, using SHA256 as the hashing function. The signature algorithm is defined in Section 2 in RFC 2104<http://tools.ietf.org/html/rfc2104#section-2>.

SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH
                    SIGNATURE-TYPE-TYPE TLV-LENGTH(=1) 4
                    KeyLocator

SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH(=32)
                     BYTE++(=SHA256({KeyValue XOR opad, SHA256({KeyValue XOR ipad, Name, MetaInfo, Content, SignatureInfo})}))


where

opad = 0x5c5c5c...5c5c5c (repeated 64 times)
ipad = 0x363636...363636 (repeated 64 times)


Key is a shared key known to the sender and receiver of the signed packet. KeyValue is derived from a shared Key as follows. If the byte length of Key is less than the SHA256 block length (64 bytes) then append zeros to the end of the Key to create the 64-byte KeyValue. If the byte length of Key is greater than 64 bytes then hash it with SHA256 to produce a 32-byte value then append 32 zeros to the end to create the 64-byte KeyValue. (The HMAC functions in most cryptographic libraries are supplied the Key and will internally derive the KeyValue in this way.)

Note

Key is not included in the signature. It is the application’s responsibility to ensure that the receiver already knows the shared Key. It can be identified using a KeyDigest as the KeyLocator<cid:91E28A76-B2E3-4C4A-A5C6-B21BBE7AF358> block in the SignatureInfo<cid:D9F93FE6-7AA5-4798-94A4-F9C08EEEF53D> block of SignatureHmacWithSha256 as follows. If the byte length of Key is less than or equal to the SHA256 block length (64 bytes) then the KeyDigest is SHA256(Key). But if the byte length of Key is greater than 64 bytes, the KeyValue is already SHA256(Key) with zeros appended, so in this case KeyDigest is SHA256(SHA256(Key)).

Note

As stated in in Section 3 of RFC 2104<http://tools.ietf.org/html/rfc2104#section-3> , keys shorter than the SHA256 output byte length (32 bytes) are strongly discouraged.

Provided that the signature verifies, this type of signature ensures provenance that the Data packet was signed by one of the parties which holds the shared Key. The key is identified using a KeyDigest as described above. It is the application’s responsibility to establish the identities of the parties who hold the shared Key.

From: <Thompson>, Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Date: Monday, March 9, 2015 at 6:07
To: Yingdi Yu <yingdi at cs.ucla.edu<mailto:yingdi at cs.ucla.edu>>
Cc: "ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>" <Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>>
Subject: Re: [Ndn-interest] Adding HMAC to available NDN signature types

Hi Yingdi,

Following up to your message (6 months ago):

> Moreover, how to definition of KeyDigest is important in the validation part, so that data consumers can determine which symmetric key should be used to verify the HMAC. I agree with Marc that, for key longer than the block size, we can use the digest of digest of the key as the key id because the digest of the key is the actual key in this case.

Agreed for KeyDigest. The KeyLocator can also a key Name but normally a key Name is used to fetch a certificate which has more info. But there is not certificate for HMAC so would you agree that we only describe a KeyDigest for the KeyLocator?

Thanks,
- Jeff T

From: Yingdi Yu <yingdi at cs.ucla.edu<mailto:yingdi at cs.ucla.edu>>
Date: Tuesday, September 23, 2014 at 9:51
To: Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Cc: Adeola Bannis <abannis at ucla.edu<mailto:abannis at ucla.edu>>, "ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>" <Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>>
Subject: Re: [Ndn-interest] Adding HMAC to available NDN signature types

Hi Jeff,

On Sep 22, 2014, at 10:02 AM, Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:

Hash output length vs. block size…

Marc is right. The HmacWithSha256 algorithm hashes the key when it is longer than the block size (64 bytes), not the hash output length (32 bytes).  So we would prohibit keys longer than 64 bytes (not 32 bytes).

In Adeola's spec, the block size is not required to be 64 bytes. The RFC does not require the block size to be 64. I wonder if we should clarify that in the spec?

Also, most applications will use a crypto library's HMAC function which should automatically hash the key if it is longer than the block size. It could be confusing to put this in the spec since the application writer may unnecessarily has the key when the crypto library will do it anyway, and more efficiently.

I think the purpose of this spec is not only for application developers, but also for library developers, especially if we want to have good interoperability. So I think it would be better to clearly specify what is the requirement of generating a signature, how to generate a signature and what should be put into the SignatureInfo.

Moreover, how to definition of KeyDigest is important in the validation part, so that data consumers can determine which symmetric key should be used to verify the HMAC. I agree with Marc that, for key longer than the block size, we can use the digest of digest of the key as the key id because the digest of the key is the actual key in this case.

Yingdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20150317/8cbeeb42/attachment.html>