Subject: Re: [Ietf-krb-wg] Information Model: aliases and keys

From: Leif Johansson <[email-masked]>
Date: Fri, 13 Feb 2009 11:39:28 +0100

On Thursday 08 January 2009 00:04:27 Luke Howard wrote:
> On 08/01/2009, at 7:51 AM, Jeffrey Hutzelman wrote:
> > --On Sunday, January 04, 2009 04:22:20 PM +1100 Luke Howard
> > <[email-masked]
> >
> > > wrote:
> > >
> >>> Are you sure you made the distinction between "same salt" and "same
> >>> salt algorithm"? Recall arcfour has no salt.
> >>>
> >>> Also, the Active Directory attribute that stores keys only
> >>> contains a
> >>> single field for the salt. See [MS-SAMR] 2.2.10.4.
> >>
> >> Sorry, I was wrong here; the most recent revision of [MS-SAMR]
> >> indicates that AES keys are stored in a different container within
> >> supplementalCredentials (KERB_STORED_CREDENTIAL_NEW). So, it's
> >> possible for AES keys to have a different salt to DES keys in Windows
> >> (although I'm not sure if that is ever the case).
> >
> > Can someone who's been following this discussion more closely than I
> > please give me an idea of where we are on this issue?
>
> Larry tells me the computation of the salt name has not changed since
> Windows added AES support.
>
> So, effectively, the salt is associated with a canonical principal
> (although in Windows the canonical naming principal and the canonical
> salting principal may be different).
>
> --luke
> _______________________________________________
> ietf-krb-wg mailing list
> [email-masked]
> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

So it sounds like there needs to be a fairly simple change to the information
model to reflect this. While catching up this thread I once thought we would
need to introduce inheritance into the metamodel but that doesn't seem to be
necessary.

	Cheers Leif
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Fri, 13 Feb 2009 11:39:28 +0100

Cheers Leif

---

From: Martin Rex <[email-masked]>
Date: Fri, 13 Feb 2009 15:59:32 +0100 (MET)

> > salting principal may be different).

Admittedly I have an extremely vague understanding of the lower levels
of Kerberos, but I don't get that description in sync with my observations:

Ever since Windows2000 (but still true on Windows2003sp2) Microsoft
seems to perform some sort of brute force to open service tickets
and there doesn't seem to be any salt in use that thwarts this approach.

On a Windows 2003(sp2) domain at Windows 2003 functional level
I just created two new domain user accounts and added (different)
service principal names to each in order to enable the traditional
2-token security context establishment.

I did set the same(!) password for both user accounts Alice and Bob
and then started "gss-server.exe" under the Alice account and
"gss-client.exe" under the Bob account.

Now it doesn't matter which target name I use on the gss-client.exe,
the security context establishment succeeds with target name
[email-masked] as well as [email-masked].  To me it looks like
the either there is no salt at all or it is the same for at least
all users of a Windows Domain.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 13 Feb 2009 15:59:32 +0100 (MET)

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Feb 2009 11:09:10 -0500

I'd expect that by default W2K and W2k3 would use RC4 encryption.  RC4
encryption does not use the salt parameter to string2key.  I think for
a meaningful test you'd need to either upgrade to W2k8 and enable AES
or set the DES flag on the service accounts.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Feb 2009 11:09:10 -0500