[Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256?

[Tai-Lin Chu]

@marc
The name's definition may need to be changed. But that is not in scope
of this discussion.

On Tue, Jun 2, 2015 at 10:14 AM,  <Marc.Mosko at parc.com> wrote:
> My concern with using the Name in a KeyLocator is that some implementations
> will start sending an Interest for the name, which is the normal thing to do
> for a Name in a KeyLocator.  If there is some way to clearly indicate in
> this case the name it is non-routable and that its purpose is to identify a
> KeyId, that would be ok.  I understand that should be implicit from the
> SignatureType being HMAC….
>
> From the spec on SignatureInfo, one reads:
>
> The specific definition of the usage of Name and KeyDigest options in
> KeyLocator field is outside the scope of this specification. Generally, Name
> names the Data packet with the corresponding certificate. However, it is up
> to the specific trust model to define whether this name is a full name of
> the Data packet or a prefix that can match multiple Data packets. For
> example, the hierarchical trust model [1] uses the latter approach,
> requiring clients to fetch the latest version of the Data packet pointed by
> the KeyLocator (the latest version of the public key certificate) in order
> to ensure that the public key was not yet revoked.
>
>
> So that does not really allow the third option that the Name does not
> specify any Data packet but rather names a KeyId.
>
> Marc
>
> On Jun 2, 2015, at 6:05 PM, Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:
>
> Hi Marc,
>
> As I asked Gene, to avoid expanding the definition of KeyLocator, it is
> possible to use a local/relative sense of a Name for the Key ID?
>
> - Jeff T
>
> From: "Marc.Mosko at parc.com" <Marc.Mosko at parc.com>
> Date: Monday, June 1, 2015 at 14:32
> To: Jeff Thompson <jefft0 at remap.ucla.edu>
> Cc: "christian.tschudin at unibas.ch" <christian.tschudin at unibas.ch>,
> "Ndn-interest at lists.cs.ucla.edu" <Ndn-interest at lists.cs.ucla.edu>
> Subject: Re: [Ndn-interest] Describe the HMAC algorithm in
> SignatureHmacWithSha256?
>
> I think overloading the use of a Name to avoid overloading the use of
> KeyDigest is trading one thing for another.  If the Name is only an SPI
> (32-bit integer), for example, then its not really a name either as it
> cannot be fetched.
>
> I agree that if KeyDigest is defined as the SHA256 of something (as it is in
> the ndn spec), then its not the right container for an index, and possibly
> not the right container for a truncated digest.
>
> To avoid mis-using a Name and mis-using a KeyDigest, then it looks like one
> would need to introduce a new TLV container “KeyIndex” or something like
> that to accommodate negotiated key IDs in a key exchange protocol.
>
> To accomodate truncated KeyDigest, one could use a new container.  However,
> if it is a truncated SHA256, then I think it would be obvious that it is
> only the “length” bytes of the SHA256, not the full 32-bytes.  I could see
> allowing a shorter (left truncated) SHA256 in the KeyDigest without loss of
> specificity.
>
> Marc
>
> On Jun 1, 2015, at 7:42 PM, Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:
>
> Hi Christian and Marc,
>
> I think we agree that we'll spell out how to get the key digest from the
> Key, but not spell out the HMAC algorithm itself (or how Key is padded to
> make the internally-used KeyValue).
>
> If the applications want to use an integer identifier for the Key, then
> the KeyLocator would need to be a Name with the integer as a name
> component, right?
>
> Also, if the "truncated key digest" (maybe as short as a byte) is used as
> an identifier, I wonder whether this should be in a Name too.  This way,
> we don't mess with the semantics of KeyDigest which usually means the full
> digest. What do you think?
>
> Thanks,
> - Jeff T
>
> On 2015/6/1, 9:48, "christian.tschudin at unibas.ch"
> <christian.tschudin at unibas.ch> wrote:
>
> I understood Jeff wanting to make the spec as self-contained as
> possible, but I doubt that a reference to an HMAC-internal variable is
> helping.
>
> (It translate into "Dear NDN implementor, to implement this two-line
> feature you need to read the following RFC and locate that Keyval
> variable in your favorit shrinked-wrapped library." As a probe: the
> Python hashlib API page does not reference it).
>
> So better write at least that part out?
>
> Regarding how to choose the KeyId (hash, ISAKMP SPI etc): I see, so it
> make sense to point out the many possibilities to pick your way. At
> least an advantage of the currently discussed hashing approach would
> be to not add another document to read 8-)
>
> best, c
>
>
> On Mon, 1 Jun 2015, Marc.Mosko at parc.com wrote:
>
> The proposed spec already defines KeyValue as the right-padded (for
> short keys) or sha256 (for long keys) of the Key.  I would define the
> KeyDigest as the SHA256(KeyValue) and not repeat the same algorithm used
> to compute KeyValue.
>
> With regard to repeating the definition of HMAC, I would not do that
> but simply say that the Œtext¹ input to HMAC is {Name, MetaInfo,
> Content, SignatureInfo} TLVs.
>
> For symmetric key systems, like HMAC, I think it is also acceptable to
> use an agreed upon integer identifier for the shared secret, as
> determined by a key exchange protocol (e.g. an ISAKMP SPI).  I don¹t
> think that symmetric key KeyDigests need to be derived from the key.
> That¹s different than public key systems, where the the KeyDigest is
> used like the Subject Key Identifier (RFC 5280 4.2.1.2) and derived from
> the actual public key.
>
> Marc
>
> On Jun 1, 2015, at 1:45 PM, <christian.tschudin at unibas.ch>
> <christian.tschudin at unibas.ch> wrote:
>
> On Wed, 27 May 2015, Thompson, Jeff wrote:
>
> Hello Christian,
> Two questions:
> 1. Can you repeat your suggestion that the spec allow a truncated
> form of the key digest, for example the first 8 bytes of the key
> digest instead of the full 32 bytes?
>
>
> Hi Jeff,
>
> This is a trick that Marc Mosko used when we presented the 1+0
> encoding at the January ICNRG interim meeting: Just reduce then number
> of KeyID-Bits (2 Bytes, in our case), if need be.
>
> The observation is that the key digest is for convenience, not
> security reasons: If you have many parties for which you have to
> maintain different symmetric keys, it is nice to quickly identify which
> key to use for validating the signature. But theoretically, you could
> just try out all symmetric keys you have for some peer. Rivest's
> "chaffing and winnowing" even relies on not sending any KeyID bits, on
> purpose.
>
>
> 2. If you want this suggestion on the spec, what is the best way to
> describe the computation of the key digest if we don't describe the
> HMAC algorithm in the spec?
>
>
> First, it could be made optional. But then I think it would be good to
> write down how the digest is computed, as you suggest (because RFC 2104
> does not cover it, right?)
>
> Adapted from previous text of yours:
>
> "The Key must not be included in the signature but optionally a full
> or partial KeyDigest can be put in the KeyLocator block of the
> SignatureInfo field. If the byte length of Key is less than or equal to
> the SHA256 block length (64 bytes) then the full length 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 the full length KeyDigest is SHA256(SHA256(Key)). The optional
> KeyDigest bits consist of 2 to 32 of the most-significant (=left-most)
> bytes of the full length KeyDigest. For the convenience of the
> validator and if packet size permits, it is recommended to include the
> full 32 bytes."
>
> Would that be precise enough?
>
> best, c
>
> Thanks,
> - Jeff T
> From: Junxiao Shi <shijunxiao at email.arizona.edu>
> Date: Wednesday, May 27, 2015 at 5:10
> To: Jeff Thompson <jefft0 at remap.ucla.edu>
> Cc: "ndn-interest at lists.cs.ucla.edu" <Ndn-interest at lists.cs.ucla.edu>
> Subject: Re: [Ndn-interest] Describe the HMAC algorithm in
> SignatureHmacWithSha256?
> Dear folks
> Details about HMAC algorithm, or any other crypto algorithm, SHOULD
> NOT appear in NDN Packet Format
> spec.
> Instead, the implementer should be referred to RFC.
> Those details are duplication of RFC, and they would make the spec
> unnecessary long.
> They also increase the probability of incorrect implementations
> because the implementer is unsure
> whether it's exactly same as what she/he has in the library, and
> would have to implement it again.
> "don't have HMAC in their crypto library" is not a valid argument -
> it's easier to find an
> RFC-compliant library or snippet for most languages than to implement
> according to the (duplicate of
> RFC in) spec.
> Yours, Junxiao
> On Mon, May 18, 2015 at 4:00 PM, Thompson, Jeff
> <jefft0 at remap.ucla.edu> wrote:
>     The proposed SignatureHmacWithSha256 spec (below) repeats the
> details of the HMAC
>     algorithm from RFC 2104. But should the details be removed and
> just refer to RFC 2104?
>     Arguments for keeping the details are that it provides details
> for the discussion of
>     creating the KeyDIgest and also because some applications don't
> have HMAC in their crypto
>     library and need to implement it directly. An argument against
> keeping the details is that
>     the info is in RFC 2104 so an application writer can read the
> RFC if needed, and that we
>     don't repeat the details of other algorithms like SHA-256.
> Any opinions on removing the algorithm details?
> - Jeff T
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
>
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>