PrinciplaName makeSalt method

[Emmanuel Lécharny <el...@gmail.com>]

Hi !

I wonder what the PrincipalName.makeSalt() method is doing... It
constructs a PrincipalName where the '/' and '@' are removed, and
concatenated in reverse order, which does not make a lot of sense to
me... Worst case : it is used to produce a salt for an encryption
method, which is a bad idea, considering the salt is based on the
principalName's content...

Re: PrinciplaName makeSalt method

[Emmanuel Lécharny <el...@gmail.com>]

Le 30/12/15 10:46, Zheng, Kai a écrit :
> The logic is either from the spec (3961?) or MIT Kerberos codes. It's intended to form the salt in that way, thus given a certain password for a principal, the generated encryption key will be the same value for an encryption type. All the vendors implement the logic so they can talk to each other for the clients using password. 
http://www.cmf.nrl.navy.mil/krb/kerberos-faq.html#keysalt :
" In Kerberos 5 the complete principal name (including the realm) is
used as the salt . This means that the same password will not result in
the same encryption key in different realms or with two different
principals in the same realm. "

and http://k5wiki.kerberos.org/wiki/Projects/Random_Salt_Generation :

The default salt is specified by RFC 4120
<http://tools.ietf.org/html/rfc4120> as "the concatenation of the
principal's realm and name components, in order, with no separators"

and RFC 4120 :

"The default salt string, if none is provided via pre-authentication
data, is the concatenation of the principal's realm and name components,
in order, with no separators."

That explains what.




Here is an interesting read :

http://k5wiki.kerberos.org/wiki/Projects/Random_Salt_Generation

RE: PrinciplaName makeSalt method

["Zheng, Kai" <ka...@intel.com>]

The logic is either from the spec (3961?) or MIT Kerberos codes. It's intended to form the salt in that way, thus given a certain password for a principal, the generated encryption key will be the same value for an encryption type. All the vendors implement the logic so they can talk to each other for the clients using password. Not safe? Yes, that's why the other mean like using genkey with random bytes would be preferred for service principals. This explanation may be not accurate but should be a starting to explore.

Regards,
Kai

-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com] 
Sent: Wednesday, December 30, 2015 5:19 PM
To: kerby@directory.apache.org
Subject: PrinciplaName makeSalt method

Hi !

I wonder what the PrincipalName.makeSalt() method is doing... It constructs a PrincipalName where the '/' and '@' are removed, and concatenated in reverse order, which does not make a lot of sense to me... Worst case : it is used to produce a salt for an encryption method, which is a bad idea, considering the salt is based on the principalName's content...