<div dir="ltr">It sounds like the current proposal for NDN is in line with what's defined in CCNx.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 20, 2014 at 11:20 AM,  <span dir="ltr"><<a href="mailto:Marc.Mosko@parc.com" target="_blank">Marc.Mosko@parc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">In CCNx 1.0, we have HMAC-SHA256 running along side RSA-SHA256/512.<div><br></div><div>We require a keyid field in the signature algorithm section.  This could be a SHA256 of the key, or we do allow it to be any identifier agreed upon by the two parties as part of a key exchange protocol.  For example, two nodes could begin using integers 0, 1, 2, … for some given namespace.  They would only need to remember 2 identifiers at a time (the current and the last one to handle packets in flight during change over).  The keyid does not need to be globally significant like for RSA, as MACs should really be pair-wise authentications.</div><div><br></div><div>Obviously, the key itself is never communicated outside a key exchange protocol.</div><div><br></div><div>A previous poster was correct.  The HMAC key can be any length up to and including the hash block length (which may be greater than the output length).   Section 2 of the the RFC also states that if the key is longer than the block length, one should hash the key with the hash function, then use that as the key.  The keyid would be the hash of that hash (obviously not wanting to put the key in the keyid).  For HMAC, section 2 recommends keys the same length as the hash function output.</div><div><br></div><div>We have a specific identifier for each validation algorithm, whether it is CRC-32c, HMAC-SHA256, RSA-256,etc.  See <a href="http://www.ccnx.org/pubs/ccnx-mosko-tlvmessages-01.txt" target="_blank">http://www.ccnx.org/pubs/ccnx-mosko-tlvmessages-01.txt</a>, sec. 3.6.  Thus, if we wanted to use HMAC-BLAKE2s-32, for example, that would end up as a new crypto-suite identifier for us.  We do not identifier the signing algorithm apart from the hashing algorithm.</div><div><br></div><div>Marc</div><div><div class="h5"><div><br></div><div><br></div><div><br><div><div>On Sep 20, 2014, at 10:24 AM, GTS <<a href="mailto:gts@ics.uci.EDU" target="_blank">gts@ics.uci.EDU</a>> wrote:</div><br><blockquote type="cite">

  
  <div bgcolor="#FFFFFF" text="#000000">
    Hi,<br>
    <br>
    adding an HMAC-based authenticator option to secure NDN content is a
    good idea. <br>
    It certainly makes sense for intranets and other intra-AS settings.
    <br>
    <br>
    I believe that CCNx has introduced an HMAC option quite some time
    ago.<br>
    It might be worthwhile to check with PARC and not to reinvent the
    wheel.<br>
    <br>
    Cheers,<br>
    Gene<br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <div>On 9/19/14, 11:12 AM, Adeola Bannis
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">Hello all,
        <div><br>
        </div>
        <div>I am proposing to add an HMAC type, using SHA256 as the
          hash function, to the signature types defined at <a href="http://named-data.net/doc/NDN-TLV/current/signature.html" target="_blank">http://named-data.net/doc/NDN-TLV/current/signature.html</a>.
          This will enable communication with symmetric keys, which
          reduces the signing and verification load on
          resource-constrained devices.</div>
        <div><br>
        </div>
        <div>The proposal is attached. Please review it and reply with
          any comments or suggestions.</div>
        <div><br>
        </div>
        <div>Thanks,</div>
        <div>Adeola</div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
Ndn-interest mailing list
<a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a>
</pre>
    </blockquote>
    <br>
  </div>

_______________________________________________<br>Ndn-interest mailing list<br><a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a><br><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br></blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
Ndn-interest mailing list<br>
<a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
<br></blockquote></div><br></div>