Subject: [HOKEY] New Version Notification for draft-ietf-hokey-key-mgm-01

From: IETF I-D Submission Tool <[email-masked]>
Date: Wed, 07 Nov 2007 15:07:32 -0500

A new version of I-D, draft-ietf-hokey-key-mgm-01.txt has been successfuly submitted by Yoshihiro Ohba and posted to the IETF repository.

Filename:	 draft-ietf-hokey-key-mgm
Revision:	 01
Title:		 Derivation, delivery and management of EAP based keys for handover and re-authentication
Creation_date:	 2007-11-07
WG ID:		 hokey
Number_of_pages: 18

Abstract:
This document describes a delivery framework for usage and domain
specific root keys (USRK and DSRK), derived as part of an EAP EMSK
hierarchy, and delivered from an EAP server to an intended third
party key holder.  The framework description includes different
scenarios for key delivery, depending on the type of keys being
delivered.  It also includes, specification of derivation of keys
required for security protection of key requests and delivery
signaling.

The IETF Secretariat.

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 7 Nov 2007 15:19:23 -0500

Changes from rev-00:

- Simplification (28 pages -> 18 pages)

- Consistency with other HOKEY draft

- Added comprehensive mapping between different scenarios and key
distribution parameters

- Added recursively combined key distribution example for optimized
hierarchical key distribution

Hope this helps,
Yoshihiro Ohba

---

From: Charles Clancy <[email-masked]>
Date: Sun, 18 Nov 2007 20:04:03 -0500

Yoshi,

Thanks for your efforts on this.  Can you indicate how this new revision
affects any of the open issues for the km doc?

Issues can be found here:

	http://www.ltsnet.net:8080/hokey/

--
t. charles clancy, ph.d.                 eng.umd.edu/~tcc
electrical & computer engineering, university of maryland

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 18 Nov 2007 22:32:03 -0500

Hi Charles and all,

In summary, all issues except for issues 27 and 28 can be closed.
Issue 28 should be discussed in IETF70.  Please see detailed
resolutions below.

On Issue 7 (replay attacks/nonce Np), key-mgm-01 uses FV (freshness
value) which allows time stamp or nonce.  In the case of nonce, the
draft has a warning that an additional mechanism may be required to
assure freshness.  This issue can be closed.

On Issue 8 (server id/domain id), key-mgm-01 uses both server id and
domain id to be more flexible.  This issue can be closed.

On Issue 9 (carrying key names), key-mgm-01 still carries key names to
identity the latest key from older ones between a given pair of
entities where each entity is still identified with PID, SID or TID.
This issue can be closed.

On Issue 10 (carrying key types), key-mgm-01 has now key type (KT) in
message 1, requiring that the peer specifies the key type.  This issue
can be closed.

On Issue 11 (carrying DTID and DUID), key-mgm-01 carries only TID for
the third-party identity instead of DTID and DUID.  This issue can be
closed.

On Issue 12 (formatting of msg2, composition attack), the second Int[]
is now carried inside the first Int[].  This issue can be closed.

On Issue 13 (key length in message 3/4), key length is now integral
part of key variable.  Note KL_X now represents a key lifetime of key
X instead of a key length of key X.  This issue can be closed.

On Issue 14 (key name generation), key-mgm-01 follows hokey-emsk draft
for key name generation.  This issue can be closed.

On Issue 24 (editorial changes), a massive editorial surgery has been
made :) Now this issue can be closed.

On Issue 25 (update figure 1 to match EMSK doc), Figure 1 has been
updated to be consistent with hokey-emsk doc.  This issue can be
closed.

On Issue 26 (references to HOKEY/HRK/etc), HRK and DSHRK are now gone.
This issue can be closed.

On Issue 27 (formal protocol format specification needed), this is
still an open issue.  We will work on it in the next revision.

On Issue 28 (encryption optional), the key-mgm-01 still mandate
encryption.  Instead, the following note has been added in Security
Considerations section:

   "EDITOR'S NOTE: For a key distribution mechanism that works with
   indirect trust relationship, a Kerberos-like key distribution
   protocol that supports "inter-realm" keys would be needed."

This would be a good discussion topic in IETF70 as to determine
whether HOKEY WG should weaken the encryption requirement.

On Issue 29 (hierarchy depth, DSUSRK children), key-mgm-01 has only
one usage for a child key of DSUSRK, that is ERX usage for rMSK
derived from DSUSRK.  This issue can be closed.

On Issue 30 (terminology for DSRK child keys), KX and KY are removed.
This issue can be closed.

On Issue 31 (remove section 5.1), most of the content of Section 5.1
has gone, except for CK and IK needed for protecting key distribution
messages and not covered by the ERX doc.  This issue can be closed.

Best Regards,
Yoshihiro Ohba

---

From: Charles Clancy <[email-masked]>
Date: Tue, 20 Nov 2007 07:24:11 -0500

Thanks for the comprehensive list -- I've closed everything but issues
#27 and #28.  I think #28 will depend on the outcome of Russ's talk in
Vancouver.