Subject: [saag] Fwd: Good but not-quite-trivial change in auth-48 for draft-harkins-owe

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Mar 2017 23:18:13 +0000

FYI

-------- Forwarded Message --------
Subject: Good but not-quite-trivial change in auth-48 for draft-harkins-owe
Date: Tue, 14 Mar 2017 20:52:17 +0000
From: Stephen Farrell <[email-masked]>
To: IETF-Discussion <[email-masked]>
CC: Jouni Malinen <[email-masked]>

Hiya,

This draft [1] is currently paused in auth-48 as one
of the authors (Dan) just got some implementer feedback
(Many thanks Jouni!) that a clarification is needed.

The proposed change is to add a table explicitly calling
out how derived keys are to be used in the protocol. The
proposed NEW text is below (with an easier to view diff
at [2]) and Dan tells me that the content of the table
is about the only sensible choice and would almost be
obvious, but is much better being explicit.

I don't think myself that that change requires us to
go back to IETF last call but I've asked the RFC editor
folks to pause processing of the draft for a week or
so while we check that this change doesn't cause any
problems. If you do think that this change or handling
the change this way is problematic please let me or
the IESG know (or just reply to this;-) and we can see
how best to handle things.

If there are no problems I'll ask the RFC editor to ok
that change in a week (on Tuesday 21st).

Cheers,
S.

[1] https://datatracker.ietf.org/doc/draft-harkins-owe/
[2]
https://tools.ietf.org/rfcdiff?url1=http://www.lounge.org/rfc-ed-8110-orig.txt&url2=http://www.lounge.org/rfc-ed-8110.txt

NEW TEXT to be added to section 4.4:

   +---------+--------------+----------+-------+------------+----------+
   |   Hash  |  Integrity   | KCK_bits |  Size |  Key-wrap  | KEK_bits |
   |         |  Algorithm   |          |   of  | Algorithm  |          |
   |         |              |          |  MIC  |            |          |
   +---------+--------------+----------+-------+------------+----------+
   | SHA-256 | HMAC-SHA-256 |   128    |   16  |  NIST AES  |   128    |
   |         |              |          |       |  Key-wrap  |          |
   | SHA-384 | HMAC-SHA-384 |   192    |   24  |  NIST AES  |   256    |
   |         |              |          |       |  Key-wrap  |          |
   | SHA-512 | HMAC-SHA-512 |   256    |   32  |  NIST AES  |   256    |
   |         |              |          |       |  Key-wrap  |          |
   +---------+--------------+----------+-------+------------+----------+

                Table 2: Integrity and Key Wrap Algorithms

   Upon completion of 802.11 association, the AP initiates the 4-way
   handshake to the client using the PMK generated above.  The 4-way
   handshake generates a key-encrypting key (KEK), a key-confirmation
   key (KCK), a message integrity code (MIC), to use for protection of
   the frames that define the 4-way handshake.  The algorithms and key
   lengths used in the 4-way handshake depend on the hash algorithm
   selected in Section 4.1 and are listed in Table 2.