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.
signature.asc
Description: OpenPGP digital signature