Subject: [HOKEY] draft-ietf-hokey-erx Rev based on LC comments

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 6 Nov 2007 23:12:29 -0800

Charles, Pasi, Katrin,
Many thanks for all your comments.  We have addressed most of your
comments and submitted an 06 version (thanks to Lakshminath for most of
the actual edits!).  I will send out separate emails to discuss any
comments not addressed.  

Clarification on one significant change: 

Charles had comments on improving algorithm agility by sending a list of
acceptable cryptosuites from the server, when the exchange fails due to
an unacceptable cryptosuite used by the peer.  This change is
incorporated, although it led to some changes as a result.  

Associated issues and resolutions done in the draft:  

1) If the key names are computed using prf-64, as recommended in the
EMSK hierarchy document, those are also then tied to the prf indicated
in the cryptosuite.  At a minimum, the server should be able to look up
a key for the peer based on the key name.  Hence, the key name
derivations are now changed to just a hash, SHA-256-64.  This is not a
problem, since the key name derivations do not use any parts of the key
itself and all inputs are public.  So, now, the key names are
independent of the PRF used and hence, the server can still lookup a key
and compute keys for the peer based on the key name. 

2) When the server receives an ERP-Initiate/Re-auth message with a
cryptosuite it doesn't support, it cannot be expected to verify the MAC
on the packet.  Hence, the server cannot differentiate between a genuine
and bogus packet.  The operation now allows for both protected
transmission of the cryptosuite list (when a valid rIK is found for the
peer) and unprotected transmission of the same (when no rIK is found for
the peer).  In either case, the result is a failure.  The peer behavior
is defined appropriately (please see section 5.2.1 in the new draft for
full details). 

3) Given that the same rIK cannot be used with multiple MAC algorithms,
the cryptosuite is now included into the rIK derivation as an input, so
that, cryptographic separation can be provided to rIKs used with
different algorithms.  This is needed in the case where the peer sends
an EAP-Initiate/Re-auth message with algorithm X and the server rejects
it and sends an EAP-Finish/Re-auth message with algorithm Y.  The rIK
used to generate the MAC in both cases cannot (should not) be the same.
Please see section 4.1.3 in the new draft for rIK derivation details). 

Thanks!
Vidya

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