Subject: [HOKEY] Yoshi's Comments on draft-ietf-hokey-key-mgm-00.txt

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 20 Jul 2007 15:13:44 -0700

List discussions are welcome. Some of these should probably be captured on
the issue tracker.

I will send my own responses later on.

R,

Madjid

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Sunday, July 15, 2007 8:31 PM
To: [email-masked]
Subject: Comments on draft-ietf-hokey-key-mgm-00.txt

Hi Madjid,

I went through the draft and here is my comments.

Comments on Section 4.1:

[1] Nonce Np does not prevent replay attack.  Since an attacker can replay
message 1, replay attack is possible in which a session with the old
key is created between the attacker and third party without the actual
peer's consent.  This actually does not satisfy one of the
requirements described in draft-ohba-hokey-3party-keydist-ps-01.txt.
For replay attack prevention, the protocol should use timestamp like
Kerberos and ISO/IEC 11770-2 Mechanism 10 do.

[2] The protocol should use Server ID instead of DID (Domain ID) for
more flexibility to support a scenario in which a domain has multiple
servers each may be serving different peers.

[3] I don't see a needed to carry key name such as KN_KIps in all
messages.  Aren't the identifiers of the three parties (e.g., PID,
DTID) sufficient to identity a key?  Note that what is important to
identity a key is to carry all pieces of information to identify the
key is carried.  It's not necessesary to combine those pieces of
information into a single string when carrying the information.

[4] I think Key Type needs to be carried in the protocol to identify
the type of key (i.e., USRK, DSUSRK, DSRK, etc.) to be distributed to
the third party.  I think that such a key type is part of information
to identity a key.

[5] I don't see a need to carry both DTID and DUID in message 2
because both identifiers are carried in clear text.  Carrying just
DTID should be sufficient for the following reason.  The server will
use DTID to select Kts.  If an attacker modifies DTID carried in
message 2, then the server will fail to validate the integrity of the
received data, and thus DUID is not needed.

[6] In message 2, the second Int[] should be carried inside the first
Int[] to prevent an attacker to compose a new message 2 by combining
the first Int[] contained in one message with the second Int[]
contained in another message.

[7] Key length KL_Kpt in message 3 can be considerd to be part of Kpt and
thus is not needed.

[8] Key length KL_Kpt in message 4 should be specified in key
derivation algorithm and thus does not have to be carried in the
message.

Comments on Section 4.3:

[9] Shouldn't CK and IK be specified in 
draft-ietf-hokey-emsk-hierarchy draft instead of this document?

[10] Why generating a key name from the key itself?  In my personal
opinion, it is not a good idea because an attacker can use the key
name as a cryptographic hint to crack the key.

Best Regards,
Yoshihiro Ohba

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

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 20 Jul 2007 16:22:33 -0700

Sending responses inline.

-----Original Message-----
From: Madjid Nakhjiri [mailto:[email-masked]] 
Sent: Friday, July 20, 2007 3:14 PM
To: [email-masked]
Subject: [HOKEY] Yoshi's Comments on draft-ietf-hokey-key-mgm-00.txt

R,

Madjid

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Sunday, July 15, 2007 8:31 PM
To: [email-masked]
Subject: Comments on draft-ietf-hokey-key-mgm-00.txt

Hi Madjid,

Comments on Section 4.1:

Madjid>>I guess I don't understand it, if you replace Np in current message
1 with a time stamp (also coming from the attacker), how is that any better,
if the attacker is putting an old time stamp in the message?

Madjid>>Actually I thought about this, you probably need both server ID and
domain ID in domain specific cases.

Madjid>>At the moment you seem to be right. The ids should lead to the keys.

Madjid>>Wouldn't you know that based on the type of third party you are
dealing with? Sounds like the key name discussion.

Madjid>>I agree, I guess the current write up is more like a test of what
happens when it goes wrong. We can fix that.

Madjid>>Ok, we can do that.

Madjid>>Is there a problem with indicating the key length to the receiver?
I guess we can indicate that as an optional field, one we get all the
notation right.

Madjid>>same as above.

Comments on Section 4.3:

Madjid>>I thought CK and IK can be seen as domain independent USRKs, no?

Madjid>>Where did you see this? I think most of the time I used a
key-name-key from the parent key to generate the key-names. 

Best Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 20 Jul 2007 23:24:36 -0400

Hi Madjid,

Please see my response in line.

> if the attacker is putting an old time stamp in the message?

If we assume time synchronization among three parties, the server can
detect the old timestamp.  On the other hand, maintaining time
synchronization itself is an issue.  "An Improved Provably Secure 3PKD
protocol" uses server nonce to avoid timestamp, but I am not sure
whether server nonce can solve all possible replay attacks.

> dealing with? Sounds like the key name discussion.

Then the issue would be how to identify the type of third party or server.

> I guess we can indicate that as an optional field, one we get all the

What I meant is that the key length should be integral part of Kpt.
For example, if a variable X is of data type "octetstring", it is
assumed that X contains the length of the string contained in the data
type.

> derivation algorithm and thus does not have to be carried in the

Not exactly the same as [7], because message 4 does not carry the key.

> Madjid>>I thought CK and IK can be seen as domain independent USRKs, no?

OK, I see your pont.  Yes, that is certainly possible.

> key-name-key from the parent key to generate the key-names. 

I meant that usage. In any case, I don't think generating key name
from another key is not actually functioning for the purpose of key
name, i.e., uniquely identifying the key, because hash function can
collide.

Regards,
Yoshihiro Ohba

---

From: Charles Clancy <[email-masked]>
Date: Mon, 23 Jul 2007 01:10:47 +0100

Created issues 7 through 14.

-- 
t. charles clancy, ph.d.  <>  [email-masked]  <>  eng.umd.edu/~tcc