On Fri, 26 Jul 2013 17:42:03 -0400
Jeffrey Altman wrote:
> That was added as a hotfix to Server 2003. In Server 2000 the KDC
> always issued tickets with the session key and service ticket key
> configured based upon the client specified enctype list. This was a
> bug that was fixed in Server
On 7/26/2013 4:30 PM, Andrew Deason wrote:
> On Fri, 26 Jul 2013 14:07:46 +0200
> Lars Schimmer wrote:
>
>> Ok, now with access to such a machine:
>> krbtgt/cgv.tugraz...@cgv.tugraz.at
>> Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS
>> mode with 96-bit SHA-1 HMAC
>> afs
On Fri, Jul 26, 2013 at 5:09 PM, Andrew Deason wrote:
> On Fri, 26 Jul 2013 13:39:22 -0700
> Russ Allbery wrote:
>
> > > This plus
> > > [kdc]svc-use-strongest-session-key=true
> >
> > > Works.
> >
> > svc-use-strongest-session-key looks like it still tries to find
> > something in the common sub
On Fri, Jul 26, 2013 at 4:39 PM, Russ Allbery wrote:
> Derrick Brashear writes:
> > Sergio Gelato wrote:
>
> >> I'm compiling my next (and hopefully final) iteration right now.
> >> I went for this variant:
> >> if (clientbest != (krb5_enctype)ETYPE_NULL &&
> >> enctype == (k
Andrew Deason writes:
> Russ Allbery wrote:
>> svc-use-strongest-session-key looks like it still tries to find
>> something in the common subset of supported keys between the client and
>> server, and legacy aklog sends only des-cbc-crc as its supported keys.
>> So how could this work? Isn't th
On Fri, 26 Jul 2013 13:39:22 -0700
Russ Allbery wrote:
> > This plus
> > [kdc]svc-use-strongest-session-key=true
>
> > Works.
>
> svc-use-strongest-session-key looks like it still tries to find
> something in the common subset of supported keys between the client
> and server, and legacy aklog
Derrick Brashear writes:
> Sergio Gelato wrote:
>> I'm compiling my next (and hopefully final) iteration right now.
>> I went for this variant:
>> if (clientbest != (krb5_enctype)ETYPE_NULL &&
>> enctype == (krb5_enctype)ETYPE_NULL) {
>> enctype = clientbest;
>>
On Fri, 26 Jul 2013 14:07:46 +0200
Lars Schimmer wrote:
> Ok, now with access to such a machine:
> krbtgt/cgv.tugraz...@cgv.tugraz.at
> Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS
> mode with 96-bit SHA-1 HMAC
> afs/cgv.tugraz.at/CGV.TUGRAZ.AT
> Etype /skey, tkt): DES
On Fri, Jul 26, 2013 at 7:33 AM, Sergio Gelato wrote:
> * Ragnar Sundblad [2013-07-26 13:01:00 +0200]:
> > >> I believe you should change the test to also check that ret_key ==
> NULL:
> > >>if (clientbest != ETYPE_NULL && enctype == ETYPE_NUL &&
> ret_key == NULL) {
> > >>enct
On Fri, 26 Jul 2013 09:45:13 -0500
Andrew Deason wrote:
> To summarize: in MIT you do not want any DES keys in rxkad.keytab or
> in the KDC's db. In Heimdal you do not want any DES keys in
> rxkad.keytab, but you must have a DES key in the KDC's db due to how
> it selects session keys. (This is f
On Fri, 2013-07-26 at 10:57 +0200, Sergio Gelato wrote:
> Speaking of which, is anyone known to be working on rxkad-kdf support for
> Heimdal's libkafs? I'd like kinit --afslog to do the right thing.
It's on my todo list, but I won't complain if someone else gets there
first.
-- Jeff
__
On Fri, 26 Jul 2013, Andrew Deason wrote:
On Thu, 25 Jul 2013 19:12:54 -0400 (EDT)
Benjamin Kaduk wrote:
In going over the re-keying document, a few more questions popped
into my mind that weren't clear from my reading of the document.
In the "Basic" procedure for MIT, it mentions ensuring t
On Fri, 26 Jul 2013 14:07:46 +0200
Lars Schimmer wrote:
> Ok, now with access to such a machine:
> krbtgt/cgv.tugraz...@cgv.tugraz.at
> Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS
> mode with 96-bit SHA-1 HMAC
> afs/cgv.tugraz.at/CGV.TUGRAZ.AT
> Etype /skey, tkt): DES
On Thu, 25 Jul 2013 19:12:54 -0400 (EDT)
Benjamin Kaduk wrote:
> > In going over the re-keying document, a few more questions popped
> > into my mind that weren't clear from my reading of the document.
> >
> > In the "Basic" procedure for MIT, it mentions ensuring that DES
> > should not be one o
On Thu, 25 Jul 2013, Benjamin Kaduk wrote:
Some versions of Heimdal have a KDC bug wherein the ticket enctype is always
the same as the session key enctype; in these cases the DES key is needed in
the rxkad.keytab (and the KeyFile).
Forgive me if I'm missing an obvious answer, but in this sit
On 2013-07-26 12:56, Jeffrey Altman wrote:
> What are the enctypes of the service tickets obtained on the Windows
> systems that do not work? The enctypes from a service ticket on Linux
> using the old client using the old algorithm are not comparable.
Ok, now with access to such a machine:
kr
* Ragnar Sundblad [2013-07-26 13:01:00 +0200]:
> >> I believe you should change the test to also check that ret_key == NULL:
> >>if (clientbest != ETYPE_NULL && enctype == ETYPE_NUL && ret_key ==
> >> NULL) {
> >>enctype = clientbest;
> >>ret = 0;
> >>}
> >> sin
On 26 jul 2013, at 12:18, Sergio Gelato wrote:
> * Ragnar Sundblad [2013-07-26 11:43:57 +0200]:
>>
>> On 26 jul 2013, at 10:57, Sergio Gelato wrote:
>>
>>> Secondly, the following patch is required:
>>> --- a/kdc/kerberos5.c
>>> +++ b/kdc/kerberos5.c
>>> @@ -183,9 +183,10 @@
>>> }
>>>
On 7/26/2013 2:56 AM, Lars Schimmer wrote:
> On 2013-07-25 17:55, Andrew Deason wrote:
>> On Thu, 25 Jul 2013 11:36:52 -0400 (EDT)
>> Benjamin Kaduk wrote:
>>
>>> The short version is: a misconfigured KDC can cause problems for new
>>> clients against old servers.
>>
>> If that's true, we need to
* Ragnar Sundblad [2013-07-26 11:43:57 +0200]:
>
> On 26 jul 2013, at 10:57, Sergio Gelato wrote:
>
> > Secondly, the following patch is required:
> > --- a/kdc/kerberos5.c
> > +++ b/kdc/kerberos5.c
> > @@ -183,9 +183,10 @@
> > }
> > }
> > if (clientbest != (krb5_enctype)ETYPE_NU
On 26 jul 2013, at 10:57, Sergio Gelato wrote:
> * Andrew Deason [2013-07-25 14:35:58 -0500]:
>> On Thu, 25 Jul 2013 15:22:50 -0400 (EDT)
>> Benjamin Kaduk wrote:
>>
>>> On Thu, 25 Jul 2013, Sergio Gelato wrote:
>>>
I've been poking a bit into this. First of all, let's make sure I
d
* Andrew Deason [2013-07-25 14:35:58 -0500]:
> On Thu, 25 Jul 2013 15:22:50 -0400 (EDT)
> Benjamin Kaduk wrote:
>
> > On Thu, 25 Jul 2013, Sergio Gelato wrote:
> >
> > > I've been poking a bit into this. First of all, let's make sure I
> > > don't misunderstand your expectation here: do you want
22 matches
Mail list logo
