[apps-discuss] Comments on draft-hammer-oauth-v2-mac-token

[Ryan Sleevi <[e-mail]>]

These comments apply to the -05 draft,
http://tools.ietf.org/id/draft-hammer-oauth-v2-mac-token-05.txt . As
I'm not subscribed to apps-discuss, please keep me cc'd in replies.

While reviewing a draft implementation of the above, two decisions
stood out to me that seemed odd, both related to the key entropy. It
seems minor to address these, and by doing so, may make it easier for
clients/implementations with different security requirements to
interoperate successfully and behave predictably.


2. Issuing MAC Credentials

Is there a reason that the MAC key is constrained to printable
encoding, as opposed to being Base64-encoded like bodyhash (3.2),
hmac-sha-1 (3.3.2), or hmac-sha-256 (3.3.3)? My concern here is that,
pursuant to RFC 2104, Section 2, HMAC implementations are required to
hash keys longer than B bytes, the length of the underlying hash
algorithm block size, in order to obtain K, the key used for HMAC. As
a result of this requirement, there is a hard upper limit to the
length and possible entropy of a key.

Under the current text, each key byte is limited to roughly 6.55 bits
of entropy, rather than the possible full 8 bits of entropy with no
character restrictions. In practical terms, this means that the
maximum entropy available for a HMAC-SHA-256 key (B=64 bytes) goes
from 512 bits to approximately 419 bits, which equally causes a
corresponding drop in the maximum security strength available.

Updating the MAC key to be Base64-encoded in Section 2, and
Base64-decoded before processing in Sections 3.3.2 and 3.3.3 would be
able to easily resolve this, allowing the server greater control over
the amount of entropy in the key and the strength of the produced
results. Given the threat model previously discussed, this entropy
upper bound is not likely to be a significant practical concern, but
it struck me as odd to impose this limit.


7.5.  Entropy of MAC Keys

Combined with Sections 3.3.2. and 3.3.3., I'm concerned that there may
be a possible interoperability concern, specifically between
implementations that are operating in a FIPS-approved/FIPS-validated
mode of operation and implementations which are not. While FIPS
validation is primarily a US concern, the current language, combined
with the language in RFC 2104, Section 3, give enough flexibility to
run into this issue. Considering that NIST FIPS-180-3 is referenced in
the draft, it seems appropriate to bring up this issue.

Currently, RFC 2104, Section 3 provides guidance that keys should be
between L bytes, which is the size of the output of the underlying
hash algorithm, and B bytes long. Keys less than L bytes are "strongly
discouraged," but that is not an RFC 2119-style imperative, thus keys
of lengths less than L are perfectly acceptable. Meanwhile,
implementations that were validated according to the requirements of
NIST FIPS-198, whether FIPS 198 (released in 2002) or FIPS 198-1
(updated in 2008), have and typically enforce certain minimum key
lengths. This is traditionally L/2, regardless of algorithm, as that
was the requirement in FIPS 198, but may be implemented as a minimum
strength of the key, independent of the algorithm.

As a result of the differing requirements between the two HMAC
documents, it's possible for an interoperability issue to emerge where
a client, with a cryptographic module that is FIPS validated and
configured to operate in a FIPS-approved mode of operation,
communicates with a server that selects a key smaller than L/2 bytes,
selected based on the general security guidance of Section 7.5. When
passing the MAC key in to the cryptographic module, in order to
compute the request "mac", the key will be rejected for not meeting
the FIPS length requirements and the client will be unable to
authenticate. While there are potentially more complexities regarding
FIPS interoperability, this would seem a trivial issue to address in
the current draft.

By adding language, similar to that added in the -04 revision to
Section 2 for unknown algorithms, to handle unsupported/insufficient
key lengths, this issue could be easily addressed, and in a manner
that is suitable for the differing organizational and operational
security requirements. Under the "MAC key" section of Section 2,
adding "If the issued key is not of sufficient strength for the
client's implementation of the chosen MAC algorithm, the client MUST
NOT use the MAC credentials and should continue as if no MAC
credentials were issued." Likewise, either by adopting similar
language to RFC 2104, Section 3, or simply by referencing it, the
security guidance of Section 7.5 could be updated to reflect the
possible interoperability issues related to minimum key sizes.

By adopting Base64-encoding/decoding for the MAC key, as described
above, implementations should be able to easily evaluate security
strength, which will be the length of decoded key in bits, rather than
having to consider the limited keyspace of the printable encoding and
expanding that based upon the length in bytes of the key.