Subject: [Emu] GPSK Issue - Identity in key derivation

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 3 Oct 2006 15:37:51 -0700

There currently is no separator between the identities in the GPSK key
derivation which means that 'a || bc' and 'ab || c' would produce same
keys.  It seems this can be addressed by including the length as part of
the identity or inserting a delimiter between identities. 

It seems that including the lengths as part of the identity would be
fine.  Any objections?

Thanks,

Joe

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

---

From: "M. Vanderveen" <[email-masked]>
Date: Tue, 3 Oct 2006 15:51:34 -0700 (PDT)

I have heard from folks who actually implemented such key derivations that the null character would work just as well.

"Joseph Salowey (jsalowey)" <[email-masked]> wrote:  There currently is no separator between the identities in the GPSK key
derivation which means that 'a || bc' and 'ab || c' would produce same
keys. It seems this can be addressed by including the length as part of
the identity or inserting a delimiter between identities. 

Thanks,

Joe

 		
---------------------------------
Do you Yahoo!?
 Get on board. You're invited to try the new Yahoo! Mail.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 04 Oct 2006 11:41:38 +0200

We could also use the null character as separator.

Ciao
Hannes

M. Vanderveen schrieb:
> I have heard from folks who actually implemented such key derivations 
> that the null character would work just as well.
> 
> */"Joseph Salowey (jsalowey)" <[email-masked]>/* wrote:
> 
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Get on board. You're invited 
> <http://us.rd.yahoo.com/evt=40791/*http://advision.webevents.yahoo.com/mailbeta> 
> to try the new Yahoo! Mail.
> 
> 
> ------------------------------------------------------------------------
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 04 Oct 2006 11:04:25 -0700

I think this issue comes from:

    o  Entropy = RAND_Client || RAND_Server || ID_Client || ID_Server

First, a nit, none of the information in there qualifies as entropy, 
so let's call it something else, please.

How about we define the above as    RAND_Client || ID_Client || 
RAND_Server || ID_Server  ?

Lakshminath

---

From: Charles Clancy <[email-masked]>
Date: Thu, 05 Oct 2006 21:16:07 -0400

Sure, it can be renamed.

I vote for simply prepending the identities with 16-bit lengths.  It's 
consistent with the rest of the protocol payload formatting.  Inserting 
NULLs could work in theory, but a poor implementation might accept an 
identity "a\0b" in which case we haven't protected against the 
malleability attack.

-- 
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy

Lakshminath Dondeti wrote:
> First, a nit, none of the information in there qualifies as entropy, so 
> let's call it something else, please.
>

---

From: Charles Clancy <[email-masked]>
Date: Thu, 05 Oct 2006 21:16:07 -0400

Sure, it can be renamed.