Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[STDS-802-11-TGM] document 14/1357r1 for TGmc



--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Hello,

 

I will not be at the 11mc session where 14/1357r1 is presented, so I

want to get discussion on it started on the mailing list.

 

There are some issues with the proposed terminology for the various flavours

of keyed-hash message authentication code (HMAC).  In an effort to obtain

what the author views as "a single unified definition" he has introduced

confusion and, in my opinion, inconsistency.

 

HMAC is described in IETF RFC 2104, which is listed in clause 2.

Clause 2 starts as follows (my emphasis):

 

The following referenced documents are indispensable for the application of this standard (i.e., they must be

understood and used

 

The notation for truncation of HMAC is described in section 5 of

IETF RFC 2104 (my emphasis):

 

We propose denoting a realization of HMAC

that uses a hash function H with t bits of output as HMAC-H-t. For

example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function

and with the output truncated to 80 bits.

 

It is therefore very clear that the notation -- which "must be understood

and used" according to clause 2 -- is to exclude any hyphen from the

name of the hash used in an HMAC.  (I could speculate on why this was

done, but that would not be relevant here.)

 

There is no need to invent a new notation, and there is therefore no

need to describe it in subclause 1.4.  The notation given in the HMAC

reference in clause 2 ("Normative references", which "must be understood

and used", remember) is simple, unambiguous and clear.

 

A resolution using the correct terminology is given in 14/1104 under

CID 3429 et al., and this should be preferred on this basis.

 

[Note: there is the possibility of debate regarding the one case of

an HMAC using SHA-1 without truncation.  I do not have a strong

opinion on whether this should be special-cased (as "HMAC-SHA-1").

I am happy for it not to be special-cased (i.e. to be "HMAC-SHA1").]

 

Regards,

 

Mark

 

P.S.: There are a number of other issues with 14/1357r1, e.g.:

 

- A requirement to truncate to 128 bits an HMAC already truncated to 128 bits!

 

- Omission of HMAC-MD5 in the template for "construction of descriptions for

uses of hash functions", whatever that's supposed to mean

 

- A malformed sentence (of the form "Where x is y.")

 

- References to "the HMAC-SHA-1-64 hash algorithm" despite earlier assertions

that "there is no such algorithm called 

"HMAC-SHA1-64", or even "HMAC-SHA-1-64" so we should not be using

the definite article when describing the use of SHA1 in an HMAC 

construct while truncating the output to 64 bits."

 

However, since the changes proposed there are fundamentally flawed as

described above, it seems pointless giving detailed corrections.

 

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223  434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223  434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

 

From: *** IEEE stds-802-11 List *** [mailto:STDS-802-11@xxxxxxxx] On Behalf Of Dan Harkins
Sent: 18 September 2014 08:14
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11] document 11-14/1104r1 for TGmc

 

--- This message came from the IEEE 802.11 Working Group Reflector ---

 

  Hello,

 

  I may not be at the 11mc session where 11-14/1104r1 is presented so I

want to get discussion on it started on the mailing list.

 

  There are some issues with the proposed description of various designations

of the Secure Hash Algorithm family of hash functions. In an effort to obtain

what the author views as "consistency" he has introduced ambiguity and,

in my opinion, incorrectness.

 

  There are 3 families of the Secure Hash Algorithm. There's the 1st family of

SHA, (which is just designated SHA1) and there's the 2nd family of SHA (known

as SHA2) which is SHA256 and SHA512, including truncated versions of each,

SHA224 is a truncated version of SHA256 and SHA384 is a truncated version of

SHA512. The 3rd family of SHA, SHA3 is a weird beast that we don't need to

trouble  ourselves with since we're not using it.

 

  It is important to understand, though, that SHA1, SHA256, and SHA512 are

different. They are not just truncated versions of the same function. And while

SHA256 does actually produce 256-bits of digest output, SHA1 does not 

produce 1-bit of digest output, it produces 160-bits.  But we (802.11) do

truncate the output of SHA family hash functions. For instance, we sometimes

want only the first 128-bits of SHA1. Just to make things more complicated,

we also use the HMAC construct with a SHA family algorithm.

 

  So how to deal with identifying the appropriate algorithm in the appropriate

family of SHA, whether it is alone or as HMAC, and how to identify the particular

output bit length that we are concerned with? 11-14/1104r1 does a poor job.

Let me propose a better way:

 

  * the particular algorithm of the family is used without any hyphens— for

     example, it's SHA256 not SHA-256, and it's SHA1 always. 

 

  * when we want to truncate we add a hyphen and indicate the bit length we

     want to use— for example, it's SHA256-128 (not sure why we'd do this but it's

     an example) or SHA1-128. 

 

  * if we don't add a hyphen and number indicating truncation then the entire

     length of the algorithm output is used.

 

  * if we want to use the HMAC construct we prepend "HMAC-" to the SHA family

     algorithm indicated, including any possible indication of truncation— for

     example, HMAC-SHA256 or HMAC-SHA1-128. 

 

  * if we don't prepend "HMAC-" then we are using the algorithm directly, and

     not as a keyed hash function.

 

  While 11-14/1104r1 does this correct in some cases— it proposes to 

change "HMAC-SHA-256" to "HMAC-SHA256"-- it does it wrong in other

cases— it proposes to change "SHA1" to "SHA-1".

 

  Also, if we adopt this more correct way of referring to these various 

incarnations of hashing we do not need to say something like

"Truncate-128(HMAC-SHA1(xxx))" we just say HMAC-SHA1-128(xxx)".

 

  Minor grammatical gripe: there is no such algorithm called 

"HMAC-SHA1-64", or even "HMAC-SHA-1-64" so we should not be using

the definite article when describing the use of SHA1 in an HMAC 

construct while truncating the output to 64 bits.

 

  Please modify 11-14/1104r1 to adopt this more correct terminology

before it gets adopted.

 

  regards,

 

  Dan.

_______________________________________________________________________________

IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.

SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________