I'm interested in the simple case of shared/symmetric key authentication.
RFC 5905 discusses MD5 but doesn't mention SHA1.
Recent code supports both. Or actually any digest from OpenSSL with a digest
length of 16 or 20 bytes. The code looks like:
EVP_DigestInit(&ctx, EVP_get_digestbynid(type));
EVP_DigestUpdate(&ctx, key, cache_secretsize);
EVP_DigestUpdate(&ctx, (u_char *)pkt, length);
EVP_DigestFinal(&ctx, digest, &len);
(copy or compare)
That code works with any key length and any digest length.
Why is AES-CMAC more interesting than one of the digests supported by OpenSSL?
The current code and extension RFCs and proposals only supports digest
lengths of 16 and 20 bytes. I was expecting an extension code for shared
keys so we could handle any length, but I don't see one on the IANA list. Is
anybody else interested in that case?
RFC 7822 (NTP Extension Fields) grandfathers in old MACs with MAC lengths of
24 or less. There is a 4 byte keyID, so the digest length is 20 bytes or
less. The current code works with MD5 (16) and SHA1 (20). RIPEMD160 also
has a 20 byte digest.
Section 7.5.1.1 and 7.5.1.2 discuss the case of mixed extension fields and
bare MACs. Is there a reason to allow that case as compared to put the MAC
into the last extension? (Is it leftover Autokey? Does anybody use
Autokey?) The idea I'm fishing for is that if there are any extensions, then
the rest of the packet is all covered cleanly by extensions and maybe the
last extension is a MAC. Does what I want just work out if the last
extension is a MAC?
PS: RFC 7822 says:
While the minimum field length containing required fields is
four words (16 octets) ...
Why? What's wrong with a 4 byte extension? (The info would be in the type.)
That's an extreme case, but 8 and 12 byte extensions seem reasonable.
--
These are my opinions. I hate spam.
_______________________________________________
TICTOC mailing list
TICTOC@ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
