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