Subject: [HOKEY] Changes from 01 to 03 of ERX

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 09 Jul 2007 09:57:30 -0700

Hi all,

Below is a brief summary of changes from 01 to 03 of ERX.  Please post 
your thoughts on any of the changes or any part of the -03- version.

Section 1:  Deleted lingering references to 11r key hierarchy etc.  All 
of that text belongs in the PS, if anywhere.

                Deleted vague text about transport.  We can add a 
reference to draft-ietf-hokey-key-mgm-00 in the next version.

Section 2: Changes in terminology to make things general.

Figures:  Edited spacing (idnits seems to be still not happy with it and 
I realized there are some tweaks yet to be done).

Many sections:  The order of usage of server-id, rIKname (as NAI) and 
peer-id for forwarding was inconsistent across the document.  It is 
consistent now.  Please review to make sure of that.

Many sections:  Removed inconsistencies in key derivation.  There were a 
few places where there were vague references to including "other 
parameters" in the key derivation etc.  For this specific usage 
(reauthentication), no other material needs to be added.  Please review.

Section 4.1.2:  There was a reference to MSK length in the context of 
DSRK.  The HOKEY server may not necessarily know the MSK length. 
Besides the HOKEY keys come from the EMSK and so changed MSK length to 
EMSK length.

Section 4:  There was an inconsistency on rIK algorithm.  The 
crypto-suite parameter was introduced to allow algorithm agility, but 
there was text on key length based on algorithm; but, that information 
would not be available at the time of key derivation.

We fixed that inconsistency elsewhere also and introduced text on a 
deterministic length and then added text about using techniques from 
other IETF RFCs on reducing the key length as necessary (HMAC RFC 2104 
and AES-CMAC RFC 4615).  I plan to post the cipher-based keying 
mechanism for review to the CFRG list.  Please review these changes as 
well in the meanwhile.

Section 4.1.6:  Clarified rMSK length requirements: now the MUST is only 
on "at least 64 octets."  The intent is still to make the properties 
similar to those of the MSK.  Note that the constraint here is that the 
entity deriving the rMSK may not know the MSK length and so saying 
"MUST" introduces the need for sending the MSK length around, which is 
not a good thing.

Section 5, Para 1: editorial

In general there are a number of editorial changes to make things more 
crisp.  Please review the text.

Section 5: There was text about crypto-suite includes PRF.  It became 
clear that only algorithm agility here has to come from the EAP method 
itself.  The rIK is derived prior to running ERP and the rMSKs after and 
so there is no way to pick a PRF as part of the ERP without using 
different algorithms to derive keys from the same parent key.  The 
alternative may be to change the hierarchy further, which might be more 
disruptive.

More editorial changes.

Removed 2119 keywords where such usage is not necessary (think 
interoperability: in general people are more careful about these things 
in external reviews and so using those ideas now).  Not may of these 
really.  But, I request folks to review with that in mind too.

Section 5.3.1  Added clarification text on NAI that goes with rIK name.

Section 5.3.1.3 has text that belongs in 5.3.2.1, so moved the text.

Edited out some text on error processing to make it consistent with the 
text in 5.2.1.  Please review the error processing.  We kept it simple.

In addition to making the use of server-id, rIKname (as NAI) and peer-id 
in the correct order, removed notes on local policy.  Authenticator 
behavior is as specified in the document so peer and the server can get 
uniform behavior.  Please review.

Clarified sequence number maintenance semantics.

thanks,
Lakshminath

_______________________________________________
HOKEY mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hokey