From jhutz at cmu.edu  Fri May  2 18:17:12 2008
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Fri, 02 May 2008 18:17:12 -0400
Subject: Kerberos dev project for review: domain_realm mapping
	via	KDCreferral 
In-Reply-To: <C38D6FDC-3839-40FF-BE10-7A628F3E90FC@MIT.EDU>
References: <8190.1209492972@malison.ait.iastate.edu>
	<098331D2-66B8-4ACC-B8CB-FEA810726542@mit.edu>
	<0D8F2EFD3A10E24DAEEA48EA6DA07D3048A905@postman-pat.csafe.local>
	<31EAC32D-4D0B-497E-830A-D6AD81EE2BC9@MIT.EDU>
	<0D8F2EFD3A10E24DAEEA48EA6DA07D3048A90B@postman-pat.csafe.local>
	<3F683DE5-3945-4005-A86A-C99D8125E8FC@MIT.EDU>
	<0D8F2EFD3A10E24DAEEA48EA6DA07D3048A90C@postman-pat.csafe.local>
	<C38D6FDC-3839-40FF-BE10-7A628F3E90FC@MIT.EDU>
Message-ID: <B7528843E4BB87C81FC44D10@sirius.fac.cs.cmu.edu>

--On Tuesday, April 29, 2008 10:22:23 PM -0400 Ken Raeburn 
<raeburn at mit.edu> wrote:

> On Apr 29, 2008, at 17:25, Tim Alsop wrote:
>> Ok, thanks for explaining. I am now clear that this is an
>> implementation
>> of the draft. If this is the case, why didn't the design on the wiki
>> say
>> this so it is clear which draft version this is based on ?
>
> Because I've spent enough time myself dealing with the referrals draft
> that I thought it would be obvious to the whole world. :)  I'll put in
> a pointer to the draft.

And because you've spent enough time with people for whom "referrals" 
automatically expands to "draft-ietf-krb-wg-kerberos-referrals-NN.txt".

Incidentally, I think this is a generally good idea; eliminating 
domain_realm mappings from client configuration would be a major win.  I am 
a little concerned about the KDC being overzealous in issuing referrals, 
but I'm still thinking about what might be a reasonable set of rules to 
mitigate this without requiring excessive configuration.  Note that IMHO a 
feature which requires explicit configuration on every KDC is several 
orders of magnitude less painful than one which requires explicit 
configuration on every client.  So, I'm perfectly willing to accept a 
tradeoff in which one must configure an explicit list of services for which 
the KDC issues domain_realm based referrals in order to avoid having to 
configure domain_realm mapping on every client.

-- Jeff

From jhutz at cmu.edu  Fri May  2 18:24:24 2008
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Fri, 02 May 2008 18:24:24 -0400
Subject: Kerberos dev project for review: domain_realm mapping via
	KDC		referral
In-Reply-To: <DC1A82AB-7BEF-4746-88BF-E6487368E79F@jpl.nasa.gov>
References: <mailman.434713.1209443062.25182.krbdev@mit.edu>
	<DC1A82AB-7BEF-4746-88BF-E6487368E79F@jpl.nasa.gov>
Message-ID: <BDA121F6B354E186F242FCD5@sirius.fac.cs.cmu.edu>

--On Tuesday, April 29, 2008 09:37:21 AM -0700 "Henry B. Hotz" 
<hotz at jpl.nasa.gov> wrote:

> Since "host-based" is the normal situation

That's a big assumption.  But it probably holds when the requested service 
principal name type is NT-SRV-HST.  IMHO, this form of referrals should 
probably apply only when the principal name is of that type or of type 
NT-SRV-HST-DOMAIN (in which case you need to apply domain_realm mapping to 
the _third_ component, not the second).

It should not be applied when the requested name type is NT-UNKNOWN, 
perhaps unless the first component is found in a list of services for which 
such mapping should be done.


> shouldn't the list be the exclusions?

And yes, there should probably be a list of first components for which 
domain_realm based referrals are not issued even if the requested name type 
is NT-SRV-HST and the second component looks like a domain name.

-- Jeff

From rra at stanford.edu  Tue May  6 00:10:45 2008
From: rra at stanford.edu (Russ Allbery)
Date: Mon, 05 May 2008 21:10:45 -0700
Subject: libkdb-ldap and ABI stability
Message-ID: <87r6cg1396.fsf@windlord.stanford.edu>

When I packaged the LDAP KDC plugin for Debian, I immediately got a bug
report that I shouldn't have packaged libkdb-ldap1 as a public shared
library because it's not really one and the ABI isn't stable.  Apparently
the current svn trunk has changed the exported functions without changing
the SONAME.

On one hand, it would make sense to package that library into a private
directory rather than /usr/lib, such as /usr/lib/krb5, and use RPATH for
the plugin and the admin utility to find it, since it's not really a
public library and there are no header files.  In that case, I'd just
include it in the same package as the LDAP plugin instead of putting it in
a separate package as Debian requires for public shared libraries.

On the other hand, that's a lot of hacking on MIT Kerberos's build system
and special modifications I'd need to maintain for Debian, and your build
system just installs it in the regular public library directory.

So... what are the plans for this library?  Can I safely package it as a
regular shared library and rest assured that the SONAME will change with
any future backward-incompatible change to the interface, such as what's
apparently currently in Subversion?  Will it ever have a public header?
Or would it be better to install it into /usr/lib/krb5 and use RPATH to
find it (and if so, is that a patch you'd take back)?

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

From josephharfouch at iinet.net.au  Wed May  7 02:27:36 2008
From: josephharfouch at iinet.net.au (josephharfouch@iinet.net.au)
Date: Wed, 07 May 2008 14:27:36 +0800
Subject: OK-AS-DELEGATE FLAG setting. 
Message-ID: <32992.1210141656@iinet.net.au>

Hi, 

Does the MIT kerberos source code set the OK-AS-DELEGATE flag
(TKT_FLG_OK_AS_DELEGATE),
and if yes, then under what circumstances?  
 
I am conducting a cross platform test where the gss client and server are using the 
z/OS Kerberos implementation, but the KDC is using the MIT implementation. The test 
case fails, unless I tell the z/OS kerberos implementation code to ignore the 
delegate check test. (We have a check_delegate flag that is turned on by default,
but 
we can turn it off in krb5.conf), so I am wondering if turning off the check is the 
best way to proceed. 


Thank you

Joseph Harfouch 
z/OS Kerberos Change Team
IBM Australia Development Laboratory, West Perth






From raeburn at MIT.EDU  Wed May  7 11:45:51 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Wed, 7 May 2008 11:45:51 -0400
Subject: OK-AS-DELEGATE FLAG setting. 
In-Reply-To: <32992.1210141656@iinet.net.au>
References: <32992.1210141656@iinet.net.au>
Message-ID: <2F4CF58E-E4D9-4AD7-93A4-D3E7E0F7561F@mit.edu>

On May 7, 2008, at 02:27, josephharfouch at iinet.net.au wrote:
> Does the MIT kerberos source code set the OK-AS-DELEGATE flag
> (TKT_FLG_OK_AS_DELEGATE),
> and if yes, then under what circumstances?

No.  Our code will display the flag in "klist" output, but has no  
support for setting it at present.

> I am conducting a cross platform test where the gss client and  
> server are using the
> z/OS Kerberos implementation, but the KDC is using the MIT  
> implementation. The test
> case fails, unless I tell the z/OS kerberos implementation code to  
> ignore the
> delegate check test. (We have a check_delegate flag that is turned  
> on by default,
> but
> we can turn it off in krb5.conf), so I am wondering if turning off  
> the check is the
> best way to proceed.

It certainly sounds like the easiest way to proceed.  Modifying the  
MIT code to set the flag (perhaps controlled by policies, perhaps only  
by per-principal flags? needs some thought) would be more work, but  
would let you retain the check.

Ken

From deengert at anl.gov  Wed May  7 12:22:05 2008
From: deengert at anl.gov (Douglas E. Engert)
Date: Wed, 07 May 2008 11:22:05 -0500
Subject: OK-AS-DELEGATE FLAG setting.
In-Reply-To: <2F4CF58E-E4D9-4AD7-93A4-D3E7E0F7561F@mit.edu>
References: <32992.1210141656@iinet.net.au>
	<2F4CF58E-E4D9-4AD7-93A4-D3E7E0F7561F@mit.edu>
Message-ID: <4821D72D.8090307@anl.gov>



Ken Raeburn wrote:
> On May 7, 2008, at 02:27, josephharfouch at iinet.net.au wrote:
>> Does the MIT kerberos source code set the OK-AS-DELEGATE flag
>> (TKT_FLG_OK_AS_DELEGATE),
>> and if yes, then under what circumstances?
> 
> No.  Our code will display the flag in "klist" output, but has no  
> support for setting it at present.
> 
>> I am conducting a cross platform test where the gss client and  
>> server are using the
>> z/OS Kerberos implementation, but the KDC is using the MIT  
>> implementation. The test
>> case fails, unless I tell the z/OS kerberos implementation code to  
>> ignore the
>> delegate check test. (We have a check_delegate flag that is turned  
>> on by default,
>> but
>> we can turn it off in krb5.conf), so I am wondering if turning off  
>> the check is the
>> best way to proceed.
> 
> It certainly sounds like the easiest way to proceed.  Modifying the  
> MIT code to set the flag (perhaps controlled by policies, perhaps only  
> by per-principal flags? needs some thought) would be more work, but  
> would let you retain the check.
> 

If I recall, there was a request from one of the other Labs to have
MIT clients check for the flag being set, much like a  Windows SSPI
client does before delegating. So it might be a good feature to allow
the KDC set the flag based on per-server flags.   As it allows a
client to authenticate to a semi-trusted server, but not delegate
to it. Gives the realm admin some control over what machines are
trusted with delegated credentials.

FireFox or other browsers using SPNEGO may also check the flag,
they probably don't today but they may in the future.

On Windows the ksetup /setRealmFlags Delegate can override the test
for non-Windows realms.



> Ken
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

From jc at F5.com  Wed May  7 12:37:19 2008
From: jc at F5.com (JC Ferguson)
Date: Wed, 7 May 2008 12:37:19 -0400
Subject: OK-AS-DELEGATE FLAG setting.
In-Reply-To: <4821D72D.8090307@anl.gov>
References: <32992.1210141656@iinet.net.au><2F4CF58E-E4D9-4AD7-93A4-D3E7E0F7561F@mit.edu>
	<4821D72D.8090307@anl.gov>
Message-ID: <C89707A732F6914A82468F82EE77A4C1226CE5@lwlexch01.olympus.f5net.com>


FWIW: microsoft sets this when a principal is "trusted for delegation"
in Active Directory.  When a microsoft client is connecting to a
CIFS-based service and the OK_AS_DELEGATE flag is set, the microsoft
client fetches a forwardable TGT and wraps that up in the authentication
material along with the service ticket. 


> -----Original Message-----
> From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] 
> On Behalf Of Douglas E. Engert
> Sent: Wednesday, May 07, 2008 12:22
> To: Ken Raeburn
> Cc: krbdev at mit.edu
> Subject: Re: OK-AS-DELEGATE FLAG setting.
> 
> 
> 
> Ken Raeburn wrote:
> > On May 7, 2008, at 02:27, josephharfouch at iinet.net.au wrote:
> >> Does the MIT kerberos source code set the OK-AS-DELEGATE flag 
> >> (TKT_FLG_OK_AS_DELEGATE), and if yes, then under what 
> circumstances?
> > 
> > No.  Our code will display the flag in "klist" output, but has no 
> > support for setting it at present.
> > 
> >> I am conducting a cross platform test where the gss client 
> and server 
> >> are using the z/OS Kerberos implementation, but the KDC is 
> using the 
> >> MIT implementation. The test case fails, unless I tell the z/OS 
> >> kerberos implementation code to ignore the delegate check 
> test. (We 
> >> have a check_delegate flag that is turned on by default, 
> but we can 
> >> turn it off in krb5.conf), so I am wondering if turning 
> off the check 
> >> is the best way to proceed.
> > 
> > It certainly sounds like the easiest way to proceed.  Modifying the 
> > MIT code to set the flag (perhaps controlled by policies, 
> perhaps only 
> > by per-principal flags? needs some thought) would be more work, but 
> > would let you retain the check.
> > 
> 
> If I recall, there was a request from one of the other Labs 
> to have MIT clients check for the flag being set, much like a 
>  Windows SSPI client does before delegating. So it might be a 
> good feature to allow
> the KDC set the flag based on per-server flags.   As it allows a
> client to authenticate to a semi-trusted server, but not 
> delegate to it. Gives the realm admin some control over what 
> machines are trusted with delegated credentials.
> 
> FireFox or other browsers using SPNEGO may also check the 
> flag, they probably don't today but they may in the future.
> 
> On Windows the ksetup /setRealmFlags Delegate can override 
> the test for non-Windows realms.
> 
> 
> 
> > Ken
> > _______________________________________________
> > krbdev mailing list             krbdev at mit.edu
> > https://mailman.mit.edu/mailman/listinfo/krbdev
> > 
> > 
> 
> -- 
> 
>   Douglas E. Engert  <DEEngert at anl.gov>
>   Argonne National Laboratory
>   9700 South Cass Avenue
>   Argonne, Illinois  60439
>   (630) 252-5444
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 


From ssorce at redhat.com  Wed May  7 16:23:27 2008
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 07 May 2008 16:23:27 -0400
Subject: OK-AS-DELEGATE FLAG setting.
In-Reply-To: <C89707A732F6914A82468F82EE77A4C1226CE5@lwlexch01.olympus.f5net.com>
References: <32992.1210141656@iinet.net.au>
	<2F4CF58E-E4D9-4AD7-93A4-D3E7E0F7561F@mit.edu>
	<4821D72D.8090307@anl.gov>
	<C89707A732F6914A82468F82EE77A4C1226CE5@lwlexch01.olympus.f5net.com>
Message-ID: <1210191807.32052.44.camel@localhost.localdomain>

On Wed, 2008-05-07 at 12:37 -0400, JC Ferguson wrote:
> FWIW: microsoft sets this when a principal is "trusted for delegation"
> in Active Directory.  When a microsoft client is connecting to a
> CIFS-based service and the OK_AS_DELEGATE flag is set, the microsoft
> client fetches a forwardable TGT and wraps that up in the authentication
> material along with the service ticket. 

It would be very useful to have a flag like that to mark trusted
services.
Being able to forward TGTs is very useful in some cases, but the
downside is that then you end up forwarding it just to everybody. Being
able to say, at the KDC level, whom the client should fully trust or not
would be a major improvement.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York


From raeburn at MIT.EDU  Thu May  8 12:18:10 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Thu, 8 May 2008 12:18:10 -0400
Subject: Kerberos dev project for review: domain_realm mapping via
	KDC		referral
In-Reply-To: <BDA121F6B354E186F242FCD5@sirius.fac.cs.cmu.edu>
References: <mailman.434713.1209443062.25182.krbdev@mit.edu>
	<DC1A82AB-7BEF-4746-88BF-E6487368E79F@jpl.nasa.gov>
	<BDA121F6B354E186F242FCD5@sirius.fac.cs.cmu.edu>
Message-ID: <BDFBA2B3-4275-4BD8-B664-A822995AD831@mit.edu>

I've made some edits on the wiki page, but there's a point that still  
seems up in the air:

On May 2, 2008, at 18:24, Jeffrey Hutzelman wrote:
> --On Tuesday, April 29, 2008 09:37:21 AM -0700 "Henry B. Hotz"
> <hotz at jpl.nasa.gov> wrote:
>> Since "host-based" is the normal situation
>
> That's a big assumption.  But it probably holds when the requested  
> service
> principal name type is NT-SRV-HST.  IMHO, this form of referrals  
> should
> probably apply only when the principal name is of that type or of type
> NT-SRV-HST-DOMAIN (in which case you need to apply domain_realm  
> mapping to
> the _third_ component, not the second).
>
> It should not be applied when the requested name type is NT-UNKNOWN,
> perhaps unless the first component is found in a list of services  
> for which
> such mapping should be done.
>
>> shouldn't the list be the exclusions?
>
> And yes, there should probably be a list of first components for which
> domain_realm based referrals are not issued even if the requested  
> name type
> is NT-SRV-HST and the second component looks like a domain name.

Having to configure both a *positive* list to apply to NT-UNKNOWN and  
a *negative* list to apply to NT-SRV-HST seems like a lot.  Can we  
actually rely on the name type being set consistently enough by  
clients that we could restrict this behavior to the NT-SRV-HST case?   
(We don't have NT-SRV-HST-DOMAIN support yet.)  I'm pretty sure we're  
not doing any logging of anything that would help us figure out if  
it's consistently used.

Ken

From hotz at jpl.nasa.gov  Thu May  8 13:08:36 2008
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Thu, 8 May 2008 10:08:36 -0700
Subject: OK-AS-DELEGATE FLAG setting.
In-Reply-To: <mailman.633.1210263405.8133.krbdev@mit.edu>
References: <mailman.633.1210263405.8133.krbdev@mit.edu>
Message-ID: <6B0EE896-DEF0-4CB3-9BFC-22163ECFF333@jpl.nasa.gov>


On May 8, 2008, at 9:16 AM, krbdev-request at mit.edu wrote:

> Message: 3
> Date: Wed, 07 May 2008 16:23:27 -0400
> From: Simo Sorce <ssorce at redhat.com>
> Subject: RE: OK-AS-DELEGATE FLAG setting.
> To: JC Ferguson <jc at F5.com>
> Cc: Ken Raeburn <raeburn at mit.edu>, krbdev at mit.edu,	"Douglas E. Engert"
> 	<deengert at anl.gov>
> Message-ID: <1210191807.32052.44.camel at localhost.localdomain>
> Content-Type: text/plain
>
> On Wed, 2008-05-07 at 12:37 -0400, JC Ferguson wrote:
>> FWIW: microsoft sets this when a principal is "trusted for  
>> delegation"
>> in Active Directory.  When a microsoft client is connecting to a
>> CIFS-based service and the OK_AS_DELEGATE flag is set, the microsoft
>> client fetches a forwardable TGT and wraps that up in the  
>> authentication
>> material along with the service ticket.
>
> It would be very useful to have a flag like that to mark trusted
> services.
> Being able to forward TGTs is very useful in some cases, but the
> downside is that then you end up forwarding it just to everybody.  
> Being
> able to say, at the KDC level, whom the client should fully trust or  
> not
> would be a major improvement.
>
> Simo.

I hope I don't need to say this to this crowd, but I will anyway.

This flag does *not* actually aid security.  This is an advisory  
flag.  There is nothing that requires the clients to respect it.  In  
fact (as this discussion demonstrates) everything works just fine if  
clients forward tgt's regardless of the flag setting.  This means in  
turn that there is nothing that prevents evil servers from making use  
of such a forwarded tgt.

Unless things have changed in the last 6 months or so, neither  
Firefox, nor Safari pay any attention to the flag.  Only IE, AFAIK.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu




From cneberg at sandia.gov  Thu May  8 13:49:39 2008
From: cneberg at sandia.gov (Nebergall, Christopher)
Date: Thu, 8 May 2008 11:49:39 -0600
Subject: OK-AS-DELEGATE FLAG setting.
In-Reply-To: <6B0EE896-DEF0-4CB3-9BFC-22163ECFF333@jpl.nasa.gov>
References: <mailman.633.1210263405.8133.krbdev@mit.edu>
	<6B0EE896-DEF0-4CB3-9BFC-22163ECFF333@jpl.nasa.gov>
Message-ID: <9C71AD778A20DC47A9A1F89BFDD2C83B2367BF47E6@ES05SNLNT.srn.sandia.gov>

>>Unless things have changed in the last 6 months or so, neither Firefox, nor Safari pay any attention to the flag.  Only IE, AFAIK.

The problem is that there is no way of doing it only using GSSAPI calls. If there were, it would be no problem to add to Firefox.  For example the SSPI in windows takes care of it transparently.  So if you are using Firefox on windows using the SSPI just configure Firefox to delegate to everything, and the SSPI will restrict it automatically.

This discussion came up a while back.
http://mailman.mit.edu/pipermail/krbdev/2006-March/004180.html

-Christopher
-----Original Message-----
From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf Of Henry B. Hotz
Sent: Thursday, May 08, 2008 11:09 AM
To: krbdev at mit.edu
Subject: RE: OK-AS-DELEGATE FLAG setting.


On May 8, 2008, at 9:16 AM, krbdev-request at mit.edu wrote:

> Message: 3
> Date: Wed, 07 May 2008 16:23:27 -0400
> From: Simo Sorce <ssorce at redhat.com>
> Subject: RE: OK-AS-DELEGATE FLAG setting.
> To: JC Ferguson <jc at F5.com>
> Cc: Ken Raeburn <raeburn at mit.edu>, krbdev at mit.edu,    "Douglas E. Engert"
>       <deengert at anl.gov>
> Message-ID: <1210191807.32052.44.camel at localhost.localdomain>
> Content-Type: text/plain
>
> On Wed, 2008-05-07 at 12:37 -0400, JC Ferguson wrote:
>> FWIW: microsoft sets this when a principal is "trusted for
>> delegation"
>> in Active Directory.  When a microsoft client is connecting to a
>> CIFS-based service and the OK_AS_DELEGATE flag is set, the microsoft
>> client fetches a forwardable TGT and wraps that up in the
>> authentication material along with the service ticket.
>
> It would be very useful to have a flag like that to mark trusted
> services.
> Being able to forward TGTs is very useful in some cases, but the
> downside is that then you end up forwarding it just to everybody.
> Being
> able to say, at the KDC level, whom the client should fully trust or
> not would be a major improvement.
>
> Simo.

I hope I don't need to say this to this crowd, but I will anyway.

This flag does *not* actually aid security.  This is an advisory flag.  There is nothing that requires the clients to respect it.  In fact (as this discussion demonstrates) everything works just fine if clients forward tgt's regardless of the flag setting.  This means in turn that there is nothing that prevents evil servers from making use of such a forwarded tgt.

Unless things have changed in the last 6 months or so, neither Firefox, nor Safari pay any attention to the flag.  Only IE, AFAIK.

------------------------------------------------------
The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu



_______________________________________________
krbdev mailing list             krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev




From ssorce at redhat.com  Thu May  8 15:11:08 2008
From: ssorce at redhat.com (Simo Sorce)
Date: Thu, 08 May 2008 15:11:08 -0400
Subject: OK-AS-DELEGATE FLAG setting.
In-Reply-To: <6B0EE896-DEF0-4CB3-9BFC-22163ECFF333@jpl.nasa.gov>
References: <mailman.633.1210263405.8133.krbdev@mit.edu>
	<6B0EE896-DEF0-4CB3-9BFC-22163ECFF333@jpl.nasa.gov>
Message-ID: <1210273868.32052.104.camel@localhost.localdomain>


On Thu, 2008-05-08 at 10:08 -0700, Henry B. Hotz wrote:
> On May 8, 2008, at 9:16 AM, krbdev-request at mit.edu wrote:
> 
> > Message: 3
> > Date: Wed, 07 May 2008 16:23:27 -0400
> > From: Simo Sorce <ssorce at redhat.com>
> > Subject: RE: OK-AS-DELEGATE FLAG setting.
> > To: JC Ferguson <jc at F5.com>
> > Cc: Ken Raeburn <raeburn at mit.edu>, krbdev at mit.edu,	"Douglas E. Engert"
> > 	<deengert at anl.gov>
> > Message-ID: <1210191807.32052.44.camel at localhost.localdomain>
> > Content-Type: text/plain
> >
> > On Wed, 2008-05-07 at 12:37 -0400, JC Ferguson wrote:
> >> FWIW: microsoft sets this when a principal is "trusted for  
> >> delegation"
> >> in Active Directory.  When a microsoft client is connecting to a
> >> CIFS-based service and the OK_AS_DELEGATE flag is set, the microsoft
> >> client fetches a forwardable TGT and wraps that up in the  
> >> authentication
> >> material along with the service ticket.
> >
> > It would be very useful to have a flag like that to mark trusted
> > services.
> > Being able to forward TGTs is very useful in some cases, but the
> > downside is that then you end up forwarding it just to everybody.  
> > Being
> > able to say, at the KDC level, whom the client should fully trust or  
> > not
> > would be a major improvement.
> >
> > Simo.
> 
> I hope I don't need to say this to this crowd, but I will anyway.
> 
> This flag does *not* actually aid security.  This is an advisory  
> flag.  There is nothing that requires the clients to respect it.  In  
> fact (as this discussion demonstrates) everything works just fine if  
> clients forward tgt's regardless of the flag setting.  This means in  
> turn that there is nothing that prevents evil servers from making use  
> of such a forwarded tgt.
> 
> Unless things have changed in the last 6 months or so, neither  
> Firefox, nor Safari pay any attention to the flag.  Only IE, AFAIK.

This is understood, but once we have the flag from the KDC we can start
doing that, at least the client will have a way to know what it should
do. Currently you would have to manually configure the list of trusted
services per application, not something that scale in any reasonable use
case.

Also being able to enforce respect of such flag in the kerberos/gssapi
libraries would be a big advantage, but I am not sure that is always
possible/wanted.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York


From paul.moore at centrify.com  Thu May  8 18:15:36 2008
From: paul.moore at centrify.com (Paul Moore)
Date: Thu, 8 May 2008 15:15:36 -0700
Subject: OK-AS-DELEGATE FLAG setting.
In-Reply-To: <1210273868.32052.104.camel@localhost.localdomain>
References: <mailman.633.1210263405.8133.krbdev@mit.edu><6B0EE896-DEF0-4CB3-9BFC-22163ECFF333@jpl.nasa.gov>
	<1210273868.32052.104.camel@localhost.localdomain>
Message-ID: <BB7E16A14DE689469A181EC770AFBF4D016758E2@exch-one.centrify.com>

The GSS layer should enforce the obedience of this flag. In the current
MIT gss code it does not. This is very bad (we have reported this
before). The KDC has set a flag saying 'don't forward this' and yet the
MIT client code forwards it anyway. We offered a fix (we have it in
place already) but were told 'no thanks'. I suspect that the reason the
client side code ignores it is because the MIT KDC never sets it and so
nobody in MIT has paid much attention to it. MS AD KDC uses it all the
time. In fact AD's default mode is to set 'do not forward '

-----Original Message-----
From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf
Of Simo Sorce
Sent: Thursday, May 08, 2008 12:11 PM
To: Henry B. Hotz
Cc: krbdev at mit.edu
Subject: RE: OK-AS-DELEGATE FLAG setting.


On Thu, 2008-05-08 at 10:08 -0700, Henry B. Hotz wrote:
> On May 8, 2008, at 9:16 AM, krbdev-request at mit.edu wrote:
> 
> > Message: 3
> > Date: Wed, 07 May 2008 16:23:27 -0400
> > From: Simo Sorce <ssorce at redhat.com>
> > Subject: RE: OK-AS-DELEGATE FLAG setting.
> > To: JC Ferguson <jc at F5.com>
> > Cc: Ken Raeburn <raeburn at mit.edu>, krbdev at mit.edu,	"Douglas E.
Engert"
> > 	<deengert at anl.gov>
> > Message-ID: <1210191807.32052.44.camel at localhost.localdomain>
> > Content-Type: text/plain
> >
> > On Wed, 2008-05-07 at 12:37 -0400, JC Ferguson wrote:
> >> FWIW: microsoft sets this when a principal is "trusted for 
> >> delegation"
> >> in Active Directory.  When a microsoft client is connecting to a 
> >> CIFS-based service and the OK_AS_DELEGATE flag is set, the 
> >> microsoft client fetches a forwardable TGT and wraps that up in the

> >> authentication material along with the service ticket.
> >
> > It would be very useful to have a flag like that to mark trusted 
> > services.
> > Being able to forward TGTs is very useful in some cases, but the 
> > downside is that then you end up forwarding it just to everybody.
> > Being
> > able to say, at the KDC level, whom the client should fully trust or

> > not would be a major improvement.
> >
> > Simo.
> 
> I hope I don't need to say this to this crowd, but I will anyway.
> 
> This flag does *not* actually aid security.  This is an advisory flag.

> There is nothing that requires the clients to respect it.  In fact (as

> this discussion demonstrates) everything works just fine if clients 
> forward tgt's regardless of the flag setting.  This means in turn that

> there is nothing that prevents evil servers from making use of such a 
> forwarded tgt.
> 
> Unless things have changed in the last 6 months or so, neither 
> Firefox, nor Safari pay any attention to the flag.  Only IE, AFAIK.

This is understood, but once we have the flag from the KDC we can start
doing that, at least the client will have a way to know what it should
do. Currently you would have to manually configure the list of trusted
services per application, not something that scale in any reasonable use
case.

Also being able to enforce respect of such flag in the kerberos/gssapi
libraries would be a big advantage, but I am not sure that is always
possible/wanted.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
krbdev mailing list             krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev


From ssorce at redhat.com  Thu May  8 18:40:13 2008
From: ssorce at redhat.com (Simo Sorce)
Date: Thu, 08 May 2008 18:40:13 -0400
Subject: OK-AS-DELEGATE FLAG setting.
In-Reply-To: <BB7E16A14DE689469A181EC770AFBF4D016758E2@exch-one.centrify.com>
References: <mailman.633.1210263405.8133.krbdev@mit.edu>
	<6B0EE896-DEF0-4CB3-9BFC-22163ECFF333@jpl.nasa.gov>
	<1210273868.32052.104.camel@localhost.localdomain>
	<BB7E16A14DE689469A181EC770AFBF4D016758E2@exch-one.centrify.com>
Message-ID: <1210286413.32052.117.camel@localhost.localdomain>


On Thu, 2008-05-08 at 15:15 -0700, Paul Moore wrote:
> The GSS layer should enforce the obedience of this flag. In the current
> MIT gss code it does not. This is very bad (we have reported this
> before). The KDC has set a flag saying 'don't forward this' and yet the
> MIT client code forwards it anyway. We offered a fix (we have it in
> place already) but were told 'no thanks'. I suspect that the reason the
> client side code ignores it is because the MIT KDC never sets it and so
> nobody in MIT has paid much attention to it. MS AD KDC uses it all the
> time. In fact AD's default mode is to set 'do not forward '

Paul is your patch public somewhere?
I'd be interested in testing it some.
I agree that the GSS layer should enforce it, and I think it would
indeed be very useful to delegate these decisions as much as possible to
a component that can be easily controlled by the administrator rather
than hoping the apps to honor it by their own choice..

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York


From jaltman at secure-endpoints.com  Thu May  8 18:40:29 2008
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Thu, 08 May 2008 18:40:29 -0400
Subject: OK-AS-DELEGATE FLAG setting.
In-Reply-To: <BB7E16A14DE689469A181EC770AFBF4D016758E2@exch-one.centrify.com>
References: <mailman.633.1210263405.8133.krbdev@mit.edu><6B0EE896-DEF0-4CB3-9BFC-22163ECFF333@jpl.nasa.gov>	<1210273868.32052.104.camel@localhost.localdomain>
	<BB7E16A14DE689469A181EC770AFBF4D016758E2@exch-one.centrify.com>
Message-ID: <4823815D.4020408@secure-endpoints.com>

Paul Moore wrote:
> The GSS layer should enforce the obedience of this flag. In the current
> MIT gss code it does not. This is very bad (we have reported this
> before). The KDC has set a flag saying 'don't forward this' and yet the
> MIT client code forwards it anyway. We offered a fix (we have it in
> place already) but were told 'no thanks'. I suspect that the reason the
> client side code ignores it is because the MIT KDC never sets it and so
> nobody in MIT has paid much attention to it. MS AD KDC uses it all the
> time. In fact AD's default mode is to set 'do not forward '

You have to understand that the creation of this flag changes the
behavior.  Historically there was no flag indicating whether or not the
KDC thought it was safe to forward.  So is the absence of the flag an
indication that it is not safe or that the KDC does not support the flag?

If you add support for this in the client and I use that client to
talk to a realm whose KDC does not support the flag, then I lose.

If you have a realm whose KDC does not support the flag and you
upgrade to a new version that does, does the upgrade set the flag by
default to ensure backward compatibility with the previous behavior?

If not, does the realm administrator know that they need to set the
flag and on which service principals it is required on?

These are serious issues and it would be inappropriate for MIT to simply 
take a patch that enabled the option in the KDC and enforced it in the
client without working through an appropriate upgrade path.

In my opinion the flag that should have been added is not OK-AS-DELEGATE
but DO-NOT-FORWARD and have AD set that flag by default on all 
principals.  Doing so would have provided an easy upgrade path for other 
Kerberos KDC and client implementations.

The way things are, no matter what is done someone is going to have to
pay a significant price.

Jeffrey Altman
Secure Endpoints Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20080508/9d521846/smime-0001.bin

From ssorce at redhat.com  Thu May  8 19:13:30 2008
From: ssorce at redhat.com (Simo Sorce)
Date: Thu, 08 May 2008 19:13:30 -0400
Subject: OK-AS-DELEGATE FLAG setting.
In-Reply-To: <4823815D.4020408@secure-endpoints.com>
References: <mailman.633.1210263405.8133.krbdev@mit.edu>
	<6B0EE896-DEF0-4CB3-9BFC-22163ECFF333@jpl.nasa.gov>
	<1210273868.32052.104.camel@localhost.localdomain>
	<BB7E16A14DE689469A181EC770AFBF4D016758E2@exch-one.centrify.com>
	<4823815D.4020408@secure-endpoints.com>
Message-ID: <1210288410.32052.120.camel@localhost.localdomain>


On Thu, 2008-05-08 at 18:40 -0400, Jeffrey Altman wrote:
> Paul Moore wrote:
> > The GSS layer should enforce the obedience of this flag. In the current
> > MIT gss code it does not. This is very bad (we have reported this
> > before). The KDC has set a flag saying 'don't forward this' and yet the
> > MIT client code forwards it anyway. We offered a fix (we have it in
> > place already) but were told 'no thanks'. I suspect that the reason the
> > client side code ignores it is because the MIT KDC never sets it and so
> > nobody in MIT has paid much attention to it. MS AD KDC uses it all the
> > time. In fact AD's default mode is to set 'do not forward '
> 
> You have to understand that the creation of this flag changes the
> behavior.  Historically there was no flag indicating whether or not the
> KDC thought it was safe to forward.  So is the absence of the flag an
> indication that it is not safe or that the KDC does not support the flag?
> 
> If you add support for this in the client and I use that client to
> talk to a realm whose KDC does not support the flag, then I lose.
> 
> If you have a realm whose KDC does not support the flag and you
> upgrade to a new version that does, does the upgrade set the flag by
> default to ensure backward compatibility with the previous behavior?
> 
> If not, does the realm administrator know that they need to set the
> flag and on which service principals it is required on?
> 
> These are serious issues and it would be inappropriate for MIT to simply 
> take a patch that enabled the option in the KDC and enforced it in the
> client without working through an appropriate upgrade path.
> 
> In my opinion the flag that should have been added is not OK-AS-DELEGATE
> but DO-NOT-FORWARD and have AD set that flag by default on all 
> principals.  Doing so would have provided an easy upgrade path for other 
> Kerberos KDC and client implementations.
> 
> The way things are, no matter what is done someone is going to have to
> pay a significant price.

If the upgrade path is the issue it is easy to add a [libdefaults]
options to turn on/off obeying the flag, with default set to off.

example:

[libdefaults]
  honor-ok-as-delegate = true|false


But not having at all the option to honor the flag is worst imo.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York


From jhutz at cmu.edu  Fri May  9 14:13:07 2008
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Fri, 09 May 2008 14:13:07 -0400
Subject: Kerberos dev project for review: domain_realm mapping
	via	KDC		referral
In-Reply-To: <BDFBA2B3-4275-4BD8-B664-A822995AD831@mit.edu>
References: <mailman.434713.1209443062.25182.krbdev@mit.edu>
	<DC1A82AB-7BEF-4746-88BF-E6487368E79F@jpl.nasa.gov>
	<BDA121F6B354E186F242FCD5@sirius.fac.cs.cmu.edu>
	<BDFBA2B3-4275-4BD8-B664-A822995AD831@mit.edu>
Message-ID: <E91D7018F5E2C1E29F2CFFE5@sirius.fac.cs.cmu.edu>

--On Thursday, May 08, 2008 12:18:10 PM -0400 Ken Raeburn <raeburn at mit.edu> 
wrote:

> Having to configure both a *positive* list to apply to NT-UNKNOWN and
> a *negative* list to apply to NT-SRV-HST seems like a lot.  Can we
> actually rely on the name type being set consistently enough by
> clients that we could restrict this behavior to the NT-SRV-HST case?
> (We don't have NT-SRV-HST-DOMAIN support yet.)  I'm pretty sure we're
> not doing any logging of anything that would help us figure out if
> it's consistently used.

Well, in the ideal situation, you don't _have_ to configure either.  But in 
practice, no, I don't believe we can count on clients setting the name type 
to NT-SRV-HST in all cases where they should.  I'm pretty sure there exist 
clients which always use NT-UNKNOWN.  Then there is the fact that RFC1964 
doesn't actually require that krb5-gss implementations use NT-SRV-HST when 
constructing principals for GSS_C_NT_HOSTBASED_SERVICE names.  And, there 
are probably applications which use GSS_KRB5_NT_PRINCIPAL_NAME even for 
host-based service names (in some cases, this is almost unavoidable, 
because interfaces for allowing a user to specify a principal name rarely 
provide a way to specify a name type).

So for those reasons, I think it's necessary to either have a positive list 
to apply to NT-UNKNOWN or else apply the same logic for NT-UNKNOWN that is 
used for NT-SRV-HST.  Either way, I believe it's essential to be able to 
override that policy by being able to provide a negative list and/or turn 
off the feature entirely (preferably both).

-- Jeff

From deengert at anl.gov  Fri May  9 14:16:44 2008
From: deengert at anl.gov (Douglas E. Engert)
Date: Fri, 09 May 2008 13:16:44 -0500
Subject: OK-AS-DELEGATE FLAG setting.
In-Reply-To: <BB7E16A14DE689469A181EC770AFBF4D016758E2@exch-one.centrify.com>
References: <mailman.633.1210263405.8133.krbdev@mit.edu><6B0EE896-DEF0-4CB3-9BFC-22163ECFF333@jpl.nasa.gov>	<1210273868.32052.104.camel@localhost.localdomain>
	<BB7E16A14DE689469A181EC770AFBF4D016758E2@exch-one.centrify.com>
Message-ID: <4824950C.1010406@anl.gov>



Paul Moore wrote:
> The GSS layer should enforce the obedience of this flag. In the current
> MIT gss code it does not. This is very bad (we have reported this
> before). The KDC has set a flag saying 'don't forward this' and yet the
> MIT client code forwards it anyway. We offered a fix (we have it in
> place already) but were told 'no thanks'.

"Enforce" is probable the wrong word to use here. From a Kerberos
prospective the flag is only advisory. The client can ignore the bit,
and forward a TGT if it wants too. The KDC has no control over the
forwarding.

That said, the client should take the advice of the KDC and not forward.

  I suspect that the reason the
> client side code ignores it is because the MIT KDC never sets it and so
> nobody in MIT has paid much attention to it. MS AD KDC uses it all the
> time. In fact AD's default mode is to set 'do not forward '

Well, the OK-TO-DELAGATE was a MS thing, so MS implemented it first.
I do agree that it would be a good feature to have, as it can help prevent
rough user-administrated computers from pretending they are servers.

It would also make it easier to allow user to self register computers
as there is less chance that the computer could steal forwarded tickets
if other clients took the advice of the KDC and not forwarded tickets
to these self registered computers.



> 
> -----Original Message-----
> From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf
> Of Simo Sorce
> Sent: Thursday, May 08, 2008 12:11 PM
> To: Henry B. Hotz
> Cc: krbdev at mit.edu
> Subject: RE: OK-AS-DELEGATE FLAG setting.
> 
> 
> On Thu, 2008-05-08 at 10:08 -0700, Henry B. Hotz wrote:
>> On May 8, 2008, at 9:16 AM, krbdev-request at mit.edu wrote:
>>
>>> Message: 3
>>> Date: Wed, 07 May 2008 16:23:27 -0400
>>> From: Simo Sorce <ssorce at redhat.com>
>>> Subject: RE: OK-AS-DELEGATE FLAG setting.
>>> To: JC Ferguson <jc at F5.com>
>>> Cc: Ken Raeburn <raeburn at mit.edu>, krbdev at mit.edu,	"Douglas E.
> Engert"
>>> 	<deengert at anl.gov>
>>> Message-ID: <1210191807.32052.44.camel at localhost.localdomain>
>>> Content-Type: text/plain
>>>
>>> On Wed, 2008-05-07 at 12:37 -0400, JC Ferguson wrote:
>>>> FWIW: microsoft sets this when a principal is "trusted for 
>>>> delegation"
>>>> in Active Directory.  When a microsoft client is connecting to a 
>>>> CIFS-based service and the OK_AS_DELEGATE flag is set, the 
>>>> microsoft client fetches a forwardable TGT and wraps that up in the
> 
>>>> authentication material along with the service ticket.
>>> It would be very useful to have a flag like that to mark trusted 
>>> services.
>>> Being able to forward TGTs is very useful in some cases, but the 
>>> downside is that then you end up forwarding it just to everybody.
>>> Being
>>> able to say, at the KDC level, whom the client should fully trust or
> 
>>> not would be a major improvement.
>>>
>>> Simo.
>> I hope I don't need to say this to this crowd, but I will anyway.
>>
>> This flag does *not* actually aid security.  This is an advisory flag.
> 
>> There is nothing that requires the clients to respect it.  In fact (as
> 
>> this discussion demonstrates) everything works just fine if clients 
>> forward tgt's regardless of the flag setting.  This means in turn that
> 
>> there is nothing that prevents evil servers from making use of such a 
>> forwarded tgt.
>>
>> Unless things have changed in the last 6 months or so, neither 
>> Firefox, nor Safari pay any attention to the flag.  Only IE, AFAIK.
> 
> This is understood, but once we have the flag from the KDC we can start
> doing that, at least the client will have a way to know what it should
> do. Currently you would have to manually configure the list of trusted
> services per application, not something that scale in any reasonable use
> case.
> 
> Also being able to enforce respect of such flag in the kerberos/gssapi
> libraries would be a big advantage, but I am not sure that is always
> possible/wanted.
> 
> Simo.
> 
> --
> Simo Sorce * Red Hat, Inc * New York
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

From deengert at anl.gov  Fri May  9 14:47:11 2008
From: deengert at anl.gov (Douglas E. Engert)
Date: Fri, 09 May 2008 13:47:11 -0500
Subject: OK-AS-DELEGATE FLAG setting.
In-Reply-To: <1210288410.32052.120.camel@localhost.localdomain>
References: <mailman.633.1210263405.8133.krbdev@mit.edu>	<6B0EE896-DEF0-4CB3-9BFC-22163ECFF333@jpl.nasa.gov>	<1210273868.32052.104.camel@localhost.localdomain>	<BB7E16A14DE689469A181EC770AFBF4D016758E2@exch-one.centrify.com>	<4823815D.4020408@secure-endpoints.com>
	<1210288410.32052.120.camel@localhost.localdomain>
Message-ID: <48249C2F.6070909@anl.gov>



Simo Sorce wrote:
> On Thu, 2008-05-08 at 18:40 -0400, Jeffrey Altman wrote:
>> Paul Moore wrote:
>>> The GSS layer should enforce the obedience of this flag. In the current
>>> MIT gss code it does not. This is very bad (we have reported this
>>> before). The KDC has set a flag saying 'don't forward this' and yet the
>>> MIT client code forwards it anyway. We offered a fix (we have it in
>>> place already) but were told 'no thanks'. I suspect that the reason the
>>> client side code ignores it is because the MIT KDC never sets it and so
>>> nobody in MIT has paid much attention to it. MS AD KDC uses it all the
>>> time. In fact AD's default mode is to set 'do not forward '
>> You have to understand that the creation of this flag changes the
>> behavior.  Historically there was no flag indicating whether or not the
>> KDC thought it was safe to forward.  So is the absence of the flag an
>> indication that it is not safe or that the KDC does not support the flag?
>>
>> If you add support for this in the client and I use that client to
>> talk to a realm whose KDC does not support the flag, then I lose.
>>
>> If you have a realm whose KDC does not support the flag and you
>> upgrade to a new version that does, does the upgrade set the flag by
>> default to ensure backward compatibility with the previous behavior?
>>
>> If not, does the realm administrator know that they need to set the
>> flag and on which service principals it is required on?
>>
>> These are serious issues and it would be inappropriate for MIT to simply 
>> take a patch that enabled the option in the KDC and enforced it in the
>> client without working through an appropriate upgrade path.
>>
>> In my opinion the flag that should have been added is not OK-AS-DELEGATE
>> but DO-NOT-FORWARD and have AD set that flag by default on all 
>> principals.  Doing so would have provided an easy upgrade path for other 
>> Kerberos KDC and client implementations.
>>
>> The way things are, no matter what is done someone is going to have to
>> pay a significant price.
> 
> If the upgrade path is the issue it is easy to add a [libdefaults]
> options to turn on/off obeying the flag, with default set to off.
> 
> example:
> 
> [libdefaults]
>   honor-ok-as-delegate = true|false

It should be on a per-realm basis, as some realms may or may not
set the flag.

Even Microsoft realized this, and for non-AD KDCs, on a client machine
"ksetup /SetRealmFlag <realm> Delegate" says Everyone in this realm is trusted
for delegation. In effect setting your "honor-ok-as-delegate = false"

Mircosoft also controls who can set the bit on the principal,
by a group policy on the DC. Only selected admins can set the
TRUSTED_FOR_DELEGATION bin the the userAccountControl flag.
Thus workstaion level admins, those that join workstations to the
domain can not set this bit.



And as Jeff pointed out, the flag should have been a DO-NOT-FORWARD bit.
It would have made for a better transition.

> 
> 
> But not having at all the option to honor the flag is worst imo.
> 
> Simo.
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

From raeburn at MIT.EDU  Fri May  9 15:26:18 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Fri, 9 May 2008 15:26:18 -0400
Subject: Kerberos dev project for review: domain_realm mapping
	via	KDC		referral
In-Reply-To: <E91D7018F5E2C1E29F2CFFE5@sirius.fac.cs.cmu.edu>
References: <mailman.434713.1209443062.25182.krbdev@mit.edu>
	<DC1A82AB-7BEF-4746-88BF-E6487368E79F@jpl.nasa.gov>
	<BDA121F6B354E186F242FCD5@sirius.fac.cs.cmu.edu>
	<BDFBA2B3-4275-4BD8-B664-A822995AD831@mit.edu>
	<E91D7018F5E2C1E29F2CFFE5@sirius.fac.cs.cmu.edu>
Message-ID: <E5AA630C-CC1E-463D-9612-06C65A0D309A@mit.edu>

On May 9, 2008, at 14:13, Jeffrey Hutzelman wrote:
> So for those reasons, I think it's necessary to either have a  
> positive list to apply to NT-UNKNOWN or else apply the same logic  
> for NT-UNKNOWN that is used for NT-SRV-HST.  Either way, I believe  
> it's essential to be able to override that policy by being able to  
> provide a negative list and/or turn off the feature entirely  
> (preferably both).

Without explicitly deciding that name types are going to be important  
parts of the request (and outside of the NT-ENTERPRISE proposal, I  
don't think they are particularly, but maybe that's enough), I think  
I'd be more comfortable keeping the logic the same, or more similar,  
at least for now.

Having a separate flag to turn it off altogether sounds okay -- but  
I'm curious why people think it's needed.

If we assume (and I'm not sure it's valid) that the reason to suppress  
this handling based on first-component strings is to permit the admin  
to identify the service names that are not actually host-based names,  
then one could make an argument for always doing the processing for NT- 
SRV-HST without exception, and using heuristics (including the  
positive or negative first-component list in the config file) to  
figure out if an NT-UNKNOWN name is really host-based.  Does that  
sound reasonable, or are there other reasons to suppress referral  
processing for a specific service name that really is host-based?

Ken

From hartmans at MIT.EDU  Fri May  9 17:47:55 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Fri, 09 May 2008 17:47:55 -0400
Subject: OK-AS-DELEGATE FLAG setting.
In-Reply-To: <9C71AD778A20DC47A9A1F89BFDD2C83B2367BF47E6@ES05SNLNT.srn.sandia.gov>
	(Christopher Nebergall's message of "Thu, 8 May 2008 11:49:39 -0600")
References: <mailman.633.1210263405.8133.krbdev@mit.edu>
	<6B0EE896-DEF0-4CB3-9BFC-22163ECFF333@jpl.nasa.gov>
	<9C71AD778A20DC47A9A1F89BFDD2C83B2367BF47E6@ES05SNLNT.srn.sandia.gov>
Message-ID: <tslr6cbm9o4.fsf@mit.edu>

>>>>> "Nebergall," == Nebergall, Christopher <cneberg at sandia.gov> writes:

    >>> Unless things have changed in the last 6 months or so, neither
    >>> Firefox, nor Safari pay any attention to the flag.  Only IE,
    >>> AFAIK.
    Nebergall,> The problem is that there is no way of doing it only
    Nebergall,> using GSSAPI calls. If there were, it would be no
    Nebergall,> problem to add to Firefox.  For example the SSPI in
    Nebergall,> windows takes care of it transparently.  So if you are
    Nebergall,> using Firefox on windows using the SSPI just configure
    Nebergall,> Firefox to delegate to everything, and the SSPI will
    Nebergall,> restrict it automatically.

    Nebergall,> This discussion came up a while back.
    Nebergall,> http://mailman.mit.edu/pipermail/krbdev/2006-March/004180.html

I think that we have Sandia's patch sitting in our bug database.
If we don't I definitely have it in my email.

I think that MIT Kerberos would be improved by taking the kadmin and kdc parts of that patch (or the similar Redhat patch).

Long term I think that adding OK-AS-Delegate support to libkrb5 and
(although it is harder) gssapi would be a good idea.
I believe the discussion you point to describes all the issues.



From hartmans at MIT.EDU  Fri May  9 17:48:49 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Fri, 09 May 2008 17:48:49 -0400
Subject: OK-AS-DELEGATE FLAG setting.
In-Reply-To: <1210273868.32052.104.camel@localhost.localdomain> (Simo Sorce's
	message of "Thu, 08 May 2008 15:11:08 -0400")
References: <mailman.633.1210263405.8133.krbdev@mit.edu>
	<6B0EE896-DEF0-4CB3-9BFC-22163ECFF333@jpl.nasa.gov>
	<1210273868.32052.104.camel@localhost.localdomain>
Message-ID: <tslmymzm9mm.fsf@mit.edu>

>>>>> "Simo" == Simo Sorce <ssorce at redhat.com> writes:

    Simo> Also being able to enforce respect of such flag in the
    Simo> kerberos/gssapi libraries would be a big advantage, but I am
    Simo> not sure that is always possible/wanted.

It is not always wanted; see the previous discussion.

From hartmans at MIT.EDU  Fri May  9 17:51:38 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Fri, 09 May 2008 17:51:38 -0400
Subject: OK-AS-DELEGATE FLAG setting.
In-Reply-To: <BB7E16A14DE689469A181EC770AFBF4D016758E2@exch-one.centrify.com>
	(Paul Moore's message of "Thu, 8 May 2008 15:15:36 -0700")
References: <mailman.633.1210263405.8133.krbdev@mit.edu>
	<6B0EE896-DEF0-4CB3-9BFC-22163ECFF333@jpl.nasa.gov>
	<1210273868.32052.104.camel@localhost.localdomain>
	<BB7E16A14DE689469A181EC770AFBF4D016758E2@exch-one.centrify.com>
Message-ID: <tsliqxnm9hx.fsf@mit.edu>

>>>>> "Paul" == Paul Moore <paul.moore at centrify.com> writes:

    Paul> The GSS layer should enforce the obedience of this flag. In
    Paul> the current MIT gss code it does not. This is very bad (we
    Paul> have reported this before). The KDC has set a flag saying
    Paul> 'don't forward this' and yet the MIT client code forwards it
    Paul> anyway. We offered a fix (we have it in place already) but
    Paul> were told 'no thanks'. I suspect that the reason the client
    Paul> side code ignores it is because the MIT KDC never sets it
    Paul> and so nobody in MIT has paid much attention to it. MS AD
    Paul> KDC uses it all the time. In fact AD's default mode is to
    Paul> set 'do not forward '

No. The problem is more complicated.  Basically the client should
implement the client's security policy.  One valid security policy is
delegate my decisions about trusted services to the KDC.  Under this
security policy, trusting the flag is a good idea.  Other valid
security policies exist, including ones that trust more or fewer
services.

Today, the code makes it very clear that the policy is entirely in the
hands of the client.  This is not ideal; we'd like to support the
delegate-to-kdc policy However we need to find a way to do that
without dropping policies that work today.  In the krb5 API it's
fairly obvious to see ways of extending it.  For GSS, it is harder to
see what you want to do.


From jhutz at cmu.edu  Fri May  9 17:52:01 2008
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Fri, 09 May 2008 17:52:01 -0400
Subject: Kerberos dev project for review: domain_realm
	mapping	via	KDC		referral
In-Reply-To: <E5AA630C-CC1E-463D-9612-06C65A0D309A@mit.edu>
References: <mailman.434713.1209443062.25182.krbdev@mit.edu>
	<DC1A82AB-7BEF-4746-88BF-E6487368E79F@jpl.nasa.gov>
	<BDA121F6B354E186F242FCD5@sirius.fac.cs.cmu.edu>
	<BDFBA2B3-4275-4BD8-B664-A822995AD831@mit.edu>
	<E91D7018F5E2C1E29F2CFFE5@sirius.fac.cs.cmu.edu>
	<E5AA630C-CC1E-463D-9612-06C65A0D309A@mit.edu>
Message-ID: <1C429F90778CC6BC94FB4424@sirius.fac.cs.cmu.edu>

--On Friday, May 09, 2008 03:26:18 PM -0400 Ken Raeburn <raeburn at mit.edu> 
wrote:

> Does that
> sound reasonable, or are there other reasons to suppress referral
> processing for a specific service name that really is host-based?

I think it is desirable to be able to suppress referral processing for a 
service which would otherwise be considered host-based.  For a particularly 
sensitive service, I might want to avoid issuing referrals for a mistyped 
name that looks like it belongs in another realm.  We have hosts with names 
containing 5 or even 6 labels; I'm sure I can construct examples in which 
mistyping one near the end or leaving one off entirely results in a name 
for which the KDC might issue a referral.

-- Jeff

From rra at stanford.edu  Fri May  9 20:04:07 2008
From: rra at stanford.edu (Russ Allbery)
Date: Fri, 09 May 2008 17:04:07 -0700
Subject: Fwd: Bug#480432: libkrb53: ret_flags check at
	g_accept_sec_context.c:248 looks wrong
Message-ID: <87wsm3rpmw.fsf@windlord.stanford.edu>


From rra at stanford.edu  Fri May  9 20:30:08 2008
From: rra at stanford.edu (Russ Allbery)
Date: Fri, 09 May 2008 17:30:08 -0700
Subject: Fwd: Bug#480434: libkrb53: Delegation fails if an SPNEGO credential
	is passed to gss_krb5_copy_ccache
Message-ID: <87mymzq9v3.fsf@windlord.stanford.edu>


From rra at stanford.edu  Fri May  9 20:30:37 2008
From: rra at stanford.edu (Russ Allbery)
Date: Fri, 09 May 2008 17:30:37 -0700
Subject: Fwd: Bug#480432: libkrb53: ret_flags check at
	g_accept_sec_context.c:248 looks wrong
In-Reply-To: <87wsm3rpmw.fsf@windlord.stanford.edu> (Russ Allbery's message of
	"Fri\, 09 May 2008 17\:04\:07 -0700")
References: <87wsm3rpmw.fsf@windlord.stanford.edu>
Message-ID: <87iqxnq9ua.fsf@windlord.stanford.edu>

Russ Allbery <rra at stanford.edu> writes:

> This analysis looks correct to me, but I'd like to get a second set of
> eyes before I commit it to the Debian krb5 packages.  Could you look
> this over and confirm?
>
> If so, I'll also commit it to the MIT repository.

Ah, forwarding mail not so helpful.

http://bugs.debian.org/480432

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

From rra at stanford.edu  Fri May  9 20:47:49 2008
From: rra at stanford.edu (Russ Allbery)
Date: Fri, 09 May 2008 17:47:49 -0700
Subject: Fwd: Bug#480434: libkrb53: Delegation fails if an SPNEGO
	credential is passed to gss_krb5_copy_ccache
In-Reply-To: <87mymzq9v3.fsf@windlord.stanford.edu> (Russ Allbery's message of
	"Fri\, 09 May 2008 17\:30\:08 -0700")
References: <87mymzq9v3.fsf@windlord.stanford.edu>
Message-ID: <87abizq91m.fsf@windlord.stanford.edu>

Russ Allbery <rra at stanford.edu> writes:

> Another patch that looks right, but for which I'd like to get a review
> before I go ahead with it (and again, I can commit this directly to the
> MIT tree as well if approved).
>
> Let me know if I should file these as bugs first, instead of creating a
> ticket on commit after approval here.

http://bugs.debian.org/480434

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

From rra at stanford.edu  Sat May 10 00:25:38 2008
From: rra at stanford.edu (Russ Allbery)
Date: Fri, 09 May 2008 21:25:38 -0700
Subject: License on kerberos.{schema,ldif}
Message-ID: <87bq3epyyl.fsf@windlord.stanford.edu>

There's no explicit license (but there is an explicit copyright) in
kerberos.schema and kerberos.ldif.  Are they covered under the same
license as the rest of the LDAP plugin?  Namely:

  Copyright (c) 2004-2005, Novell, Inc.
  All rights reserved.

  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions are met:

    * Redistributions of source code must retain the above copyright notice,
        this list of conditions and the following disclaimer.
    * Redistributions in binary form must reproduce the above copyright
        notice, this list of conditions and the following disclaimer in the
        documentation and/or other materials provided with the distribution.
    * The copyright holder's name is not used to endorse or promote products
        derived from this software without specific prior written permission.

  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
  AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
  LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
  CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
  SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
  INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
  CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
  POSSIBILITY OF SUCH DAMAGE.

I'm currently making that assumption, since it seems reasonably safe given
the context, but I wanted to double-check just to be sure.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

From jaltman at secure-endpoints.com  Sat May 10 01:59:23 2008
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Sat, 10 May 2008 01:59:23 -0400
Subject: Proposed modifications to replay cache to prevent false positives
In-Reply-To: <1ceadc2255ade945fef537f9a3959d53@mit.edu>
References: <20050602152141.C66A137010@arioch.imrryr.org>	<tslfyw04qar.fsf@cz.mit.edu>
	<f47b5821c51cd65d14bbeadd9262bf1a@mit.edu>	<tslacm84kk6.fsf@cz.mit.edu>
	<1ceadc2255ade945fef537f9a3959d53@mit.edu>
Message-ID: <482539BB.6080702@secure-endpoints.com>

Please review
   http://k5wiki.kerberos.org/wiki/Projects/replay_cache_collision_avoidance

Jeffrey Altman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20080510/e9d63fcb/smime.bin

From hartmans at MIT.EDU  Sat May 10 13:39:52 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Sat, 10 May 2008 13:39:52 -0400
Subject: libkdb-ldap and ABI stability
In-Reply-To: <87r6cg1396.fsf@windlord.stanford.edu> (Russ Allbery's message of
	"Mon, 05 May 2008 21:10:45 -0700")
References: <87r6cg1396.fsf@windlord.stanford.edu>
Message-ID: <tslve1mgis7.fsf@mit.edu>

>>>>> "Russ" == Russ Allbery <rra at stanford.edu> writes:

    Russ> On the other hand, that's a lot of hacking on MIT Kerberos's
    Russ> build system and special modifications I'd need to maintain
    Russ> for Debian, and your build system just installs it in the
    Russ> regular public library directory.

    Russ> So... what are the plans for this library?  Can I safely
    Russ> package it as a regular shared library and rest assured that
    Russ> the SONAME will change with any future backward-incompatible
    Russ> change to the interface, such as what's apparently currently
    Russ> in Subversion?  Will it ever have a public header?  Or would
    Russ> it be better to install it into /usr/lib/krb5 and use RPATH
    Russ> to find it (and if so, is that a patch you'd take back)?

I think you should package it with no package installing a .so  for it and add conflicts as appropriate when the functionality changes.

From hartmans at MIT.EDU  Sat May 10 13:44:36 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Sat, 10 May 2008 13:44:36 -0400
Subject: Kerberos dev project for review: domain_realm mapping via KDC
	referral
In-Reply-To: <BDA121F6B354E186F242FCD5@sirius.fac.cs.cmu.edu> (Jeffrey
	Hutzelman's message of "Fri, 02 May 2008 18:24:24 -0400")
References: <mailman.434713.1209443062.25182.krbdev@mit.edu>
	<DC1A82AB-7BEF-4746-88BF-E6487368E79F@jpl.nasa.gov>
	<BDA121F6B354E186F242FCD5@sirius.fac.cs.cmu.edu>
Message-ID: <tslr6cagikb.fsf@mit.edu>

>>>>> "Jeffrey" == Jeffrey Hutzelman <jhutz at cmu.edu> writes:

    Jeffrey> --On Tuesday, April 29, 2008 09:37:21 AM -0700 "Henry
    Jeffrey> B. Hotz"
    Jeffrey> <hotz at jpl.nasa.gov> wrote:

    >> Since "host-based" is the normal situation

    Jeffrey> That's a big assumption.  But it probably holds when the
    Jeffrey> requested service principal name type is NT-SRV-HST.
    Jeffrey> IMHO, this form of referrals should probably apply only
    Jeffrey> when the principal name is of that type or of type
    Jeffrey> NT-SRV-HST-DOMAIN (in which case you need to apply
    Jeffrey> domain_realm mapping to the _third_ component, not the
    Jeffrey> second).

    Jeffrey> It should not be applied when the requested name type is
    Jeffrey> NT-UNKNOWN, perhaps unless the first component is found
    Jeffrey> in a list of services for which such mapping should be
    Jeffrey> done.


I strongly agree with Jeff here.  I think that the name type is an
important part of referral processing.  We should default to on for
hostbased services and default to off for other services.  I'm not
convinced we need a negative list--a list of cases where even for
hostbased services you don't want referrals, but I do think we want a
positive list--for nt-unknown where you want to support hostbased
services.


If changes along these lines were made I could vote in support of the project.

From rra at stanford.edu  Sat May 10 14:22:28 2008
From: rra at stanford.edu (Russ Allbery)
Date: Sat, 10 May 2008 11:22:28 -0700
Subject: libkdb-ldap and ABI stability
In-Reply-To: <tslve1mgis7.fsf@mit.edu> (Sam Hartman's message of "Sat\,
	10 May 2008 13\:39\:52 -0400")
References: <87r6cg1396.fsf@windlord.stanford.edu> <tslve1mgis7.fsf@mit.edu>
Message-ID: <874p962f4r.fsf@windlord.stanford.edu>

Sam Hartman <hartmans at MIT.EDU> writes:
>>>>>> "Russ" == Russ Allbery <rra at stanford.edu> writes:

>     Russ> On the other hand, that's a lot of hacking on MIT Kerberos's
>     Russ> build system and special modifications I'd need to maintain
>     Russ> for Debian, and your build system just installs it in the
>     Russ> regular public library directory.

>     Russ> So... what are the plans for this library?  Can I safely
>     Russ> package it as a regular shared library and rest assured that
>     Russ> the SONAME will change with any future backward-incompatible
>     Russ> change to the interface, such as what's apparently currently
>     Russ> in Subversion?  Will it ever have a public header?  Or would
>     Russ> it be better to install it into /usr/lib/krb5 and use RPATH
>     Russ> to find it (and if so, is that a patch you'd take back)?

> I think you should package it with no package installing a .so for it
> and add conflicts as appropriate when the functionality changes.

It turned out to be fairly easy (two lines of Makefile.in changes and a
couple of lines in debian/rules) to put the library into /usr/lib/krb5
instead of /usr/lib, signalling that only the program and plugin shipped
with krb5-kdc-ldap should even try to use the library, and build the
program and the plugin with an RPATH pointing to that directory.  Since
there's no *.so and no header files for it, that seems right to me, and I
was planning on going that route.  Is there any reason that you can think
of why doing that would be a bad idea?

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

From rra at stanford.edu  Sat May 10 23:39:20 2008
From: rra at stanford.edu (Russ Allbery)
Date: Sat, 10 May 2008 20:39:20 -0700
Subject: Fwd: Bug#480432: libkrb53: ret_flags check at
	g_accept_sec_context.c:248 looks wrong
In-Reply-To: <87iqxnq9ua.fsf@windlord.stanford.edu> (Russ Allbery's message of
	"Fri\, 09 May 2008 17\:30\:37 -0700")
References: <87wsm3rpmw.fsf@windlord.stanford.edu>
	<87iqxnq9ua.fsf@windlord.stanford.edu>
Message-ID: <87fxspo6fr.fsf@windlord.stanford.edu>

Russ Allbery <rra at stanford.edu> writes:
> Russ Allbery <rra at stanford.edu> writes:

>> This analysis looks correct to me, but I'd like to get a second set of
>> eyes before I commit it to the Debian krb5 packages.  Could you look
>> this over and confirm?

>> If so, I'll also commit it to the MIT repository.

> Ah, forwarding mail not so helpful.

> http://bugs.debian.org/480432

This was ticket #5802, which is already resolved and was fixed in 1.6.3.
Sorry about that -- I should have checked that one first.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

From rra at stanford.edu  Sat May 10 23:40:49 2008
From: rra at stanford.edu (Russ Allbery)
Date: Sat, 10 May 2008 20:40:49 -0700
Subject: Fwd: Bug#480434: libkrb53: Delegation fails if an SPNEGO
	credential is passed to gss_krb5_copy_ccache
In-Reply-To: <87abizq91m.fsf@windlord.stanford.edu> (Russ Allbery's message of
	"Fri\, 09 May 2008 17\:47\:49 -0700")
References: <87mymzq9v3.fsf@windlord.stanford.edu>
	<87abizq91m.fsf@windlord.stanford.edu>
Message-ID: <87bq3do6da.fsf@windlord.stanford.edu>

Russ Allbery <rra at stanford.edu> writes:
> Russ Allbery <rra at stanford.edu> writes:

>> Another patch that looks right, but for which I'd like to get a review
>> before I go ahead with it (and again, I can commit this directly to the
>> MIT tree as well if approved).

>> Let me know if I should file these as bugs first, instead of creating a
>> ticket on commit after approval here.

> http://bugs.debian.org/480434

This is #5807.  The Debian bug has a slightly different fix; I don't know
which one is better from a coding style perspective.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

From debbugs at kdzbn.homelinux.net  Mon May 12 18:42:37 2008
From: debbugs at kdzbn.homelinux.net (Bryan Kadzban)
Date: Mon, 12 May 2008 18:42:37 -0400
Subject: Status of ticket 5807?
Message-ID: <4828C7DD.30802@kdzbn.homelinux.net>

I am attempting to use MIT Kerberos with mod_auth_kerb under Apache.
The clients use SPNEGO, and I can't really change that.  I need
delegation to work properly, as the scripts that are running under
Apache need to be able to get at resources protected by Kerberos, and
they need to do that as the user that logs in from the browser.

The problem is, I am running into the same problem as reported in ticket
5807: gssint_get_mechanism_cred is failing because the passed-in
credential's mechanism OID doesn't match what it was given.  (The mech
ID in the credential is for SPNEGO, not Kerberos or old-Kerberos.)

This issue seems to be a showstopper for what I'm trying to do (as far
as I can see anyway), since it seems to break the ability to save out a
delegated credential from SPNEGO; are there any plans on getting the
patch in ticket 5807 into a future Kerberos release?  Is there anything
I can do to help the patch along?

(Before I found ticket 5807, I wrote a very similar patch, which gets
the SPNEGO OID from a call to spnego_gss_get_mech_configs() function
instead of hardcoding it like the patch on bug 5807 does.  If there were
any objections to hardcoding the OID, the patch that I put together
*might* be acceptable; it's available at the Debian bugreport[1] if
anyone wants to look.)

Thanks!

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480434

From debbugs at kdzbn.homelinux.net  Mon May 12 19:21:53 2008
From: debbugs at kdzbn.homelinux.net (Bryan Kadzban)
Date: Mon, 12 May 2008 19:21:53 -0400
Subject: Status of ticket 5807?
In-Reply-To: <4828C7DD.30802@kdzbn.homelinux.net>
References: <4828C7DD.30802@kdzbn.homelinux.net>
Message-ID: <4828D111.608@kdzbn.homelinux.net>

Bryan Kadzban wrote:
> are there any plans on getting the patch in ticket 5807 into a future
> Kerberos release?  Is there anything I can do to help the patch
> along?

ACK!

Should have checked the archives more recently; I didn't realize the
reference to the Debian bug had already been posted here.  Sorry for the
noise...

Still, if there's anything I can do to help, let me know.

Thanks!

From carlosrainho at gmail.com  Tue May 13 09:29:35 2008
From: carlosrainho at gmail.com (Carlos Rainho)
Date: Tue, 13 May 2008 10:29:35 -0300
Subject: How Kerberize an application
Message-ID: <351696c80805130629l4626a82bwf3abfaf0a293611b@mail.gmail.com>

Hello,

I'm studying Science Computing in Gama Filho University at Rio de Janeiro,
Brazil. In my final project, I will implement securtiy in ALua, an
event-driven communication mechanism for developing distributed parallel
applications based on the interpreted language Lua (http://www.lua.org).

One way of this implementation is the usage of Kerberos. So, I need the
modeling of kerberos in linux (Fedora 8) to kerberize commands in ALua that
sends messages from one process for others processes in the same machine or
not. Summarizing, I want to know how kerberize any application in Linux.

I search for all the Internet, including site redhat.com, papers in
CiteSeer, and no modeling was found.

Can you help me?

Thanks,

-- 
Carlos Rainho

From kwebb at teradactyl.com  Tue May 13 11:53:01 2008
From: kwebb at teradactyl.com (Kristen J. Webb)
Date: Tue, 13 May 2008 09:53:01 -0600
Subject: How Kerberize an application
In-Reply-To: <351696c80805130629l4626a82bwf3abfaf0a293611b@mail.gmail.com>
References: <351696c80805130629l4626a82bwf3abfaf0a293611b@mail.gmail.com>
Message-ID: <4829B95D.8090201@teradactyl.com>

Hi Carlos,

For these types of questions, you
should be on the kerberos at mit.edu
mailing list.

I'm currently involved in the process,

Here is a good overview of how things work:

http://www.kerberos.org/software/tutorial.html

Alf Wachsmann's tutorial in Linux Journal
explains setting up your KDC and more.

http://www.linuxjournal.com/article/7336

There are examples programs in the download.

I've also been using IBM's online documentation
as well (for example, krb5_rd_req).

http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/apis/krb5_rd_req.htm

Hope that helps,
Kris

Carlos Rainho wrote:
> Hello,
> 
> I'm studying Science Computing in Gama Filho University at Rio de Janeiro,
> Brazil. In my final project, I will implement securtiy in ALua, an
> event-driven communication mechanism for developing distributed parallel
> applications based on the interpreted language Lua (http://www.lua.org).
> 
> One way of this implementation is the usage of Kerberos. So, I need the
> modeling of kerberos in linux (Fedora 8) to kerberize commands in ALua that
> sends messages from one process for others processes in the same machine or
> not. Summarizing, I want to know how kerberize any application in Linux.
> 
> I search for all the Internet, including site redhat.com, papers in
> CiteSeer, and no modeling was found.
> 
> Can you help me?
> 
> Thanks,
> 

-- 
Mr. Kristen J. Webb
Teradactyl LLC.

PHONE: 1-505-242-1091
EMAIL: kwebb at teradactyl.com
VISIT: http://www.teradactyl.com

  	Home of the

  True incremental Backup System
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5363 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20080513/16c539ef/smime.bin

From tlyu at MIT.EDU  Tue May 13 14:53:09 2008
From: tlyu at MIT.EDU (Tom Yu)
Date: Tue, 13 May 2008 14:53:09 -0400
Subject: what is this list for?
Message-ID: <ldvk5hyf33e.fsf@cathode-dark-space.mit.edu>

I notice that some people may be asking application development
questions here due to the policy described in our web page:

http://web.mit.edu/kerberos/mail-lists.html

    krbdev
    The Kerberos developers' mailing list. If you are a vendor
    shipping MIT Kerberos code, or shipping applications using MIT
    Kerberos, you should subscribe here. Mail about krb5-current often
    ends up going here.

Do we want to restrict this list exclusively to topics related to
development of the MIT Kerberos implementation?  Or do we want to also
allow application development topics on this list?  My recollection is
that historically, we have allowed application development topics on
this list.

In any case, we should document the list policy consistently.

-- 
Tom Yu
Development Manager
MIT Kerberos Consortium

From rra at stanford.edu  Tue May 13 14:57:12 2008
From: rra at stanford.edu (Russ Allbery)
Date: Tue, 13 May 2008 11:57:12 -0700
Subject: what is this list for?
In-Reply-To: <ldvk5hyf33e.fsf@cathode-dark-space.mit.edu> (Tom Yu's message of
	"Tue\, 13 May 2008 14\:53\:09 -0400")
References: <ldvk5hyf33e.fsf@cathode-dark-space.mit.edu>
Message-ID: <87bq3at4l3.fsf@windlord.stanford.edu>

Tom Yu <tlyu at MIT.EDU> writes:

> Do we want to restrict this list exclusively to topics related to
> development of the MIT Kerberos implementation?  Or do we want to also
> allow application development topics on this list?  My recollection is
> that historically, we have allowed application development topics on
> this list.
>
> In any case, we should document the list policy consistently.

Personally, I think kerberos at mit.edu is a fine list for application
development, and I'd rather use krbdev for development issues specifically
related to MIT Kerberos.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

From kpkoch at MIT.EDU  Tue May 13 15:01:35 2008
From: kpkoch at MIT.EDU (Kevin Koch)
Date: Tue, 13 May 2008 15:01:35 -0400
Subject: How Kerberize an application
In-Reply-To: <351696c80805130629l4626a82bwf3abfaf0a293611b@mail.gmail.com>
References: <351696c80805130629l4626a82bwf3abfaf0a293611b@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAANXVU5tFzQNMmhEVcp4H1MPCgAAAEAAAAPxfZUQVi+pAmhZRgzgQDjwBAAAAAA==@mit.edu>

Brian Tung's Kerberos book has examples of how to call Kerberos functions in
your code.

ISBN 0201379244.

http://www.amazon.com/Kerberos-Network-Authentication-Addison-Wesley-Network
ing/dp/0201379244/ref=sr_1_1?ie=UTF8&s=books&qid=1210702842&sr=8-1

Kevin Koch
Kerberos for Windows Lead Software Engineer
MIT Kerberos Consortium http://www.kerberos.org
Massachusetts Institute of Technology
304 Vassar St. W92-143
Cambridge, MA 02139
617-324-8949
kpkoch at mit.edu

-----Original Message-----
From: krbdev-bounces at MIT.EDU [mailto:krbdev-bounces at MIT.EDU] On Behalf Of
Carlos Rainho
Sent: Tuesday, May 13, 2008 9:30 AM
To: krbdev at mit.edu
Subject: How Kerberize an application

Hello,

I'm studying Science Computing in Gama Filho University at Rio de Janeiro,
Brazil. In my final project, I will implement securtiy in ALua, an
event-driven communication mechanism for developing distributed parallel
applications based on the interpreted language Lua (http://www.lua.org).

One way of this implementation is the usage of Kerberos. So, I need the
modeling of kerberos in linux (Fedora 8) to kerberize commands in ALua that
sends messages from one process for others processes in the same machine or
not. Summarizing, I want to know how kerberize any application in Linux.

I search for all the Internet, including site redhat.com, papers in
CiteSeer, and no modeling was found.

Can you help me?

Thanks,

-- 
Carlos Rainho
...


From William.Fiveash at sun.com  Tue May 13 17:06:20 2008
From: William.Fiveash at sun.com (Will Fiveash)
Date: Tue, 13 May 2008 16:06:20 -0500
Subject: what is this list for?
In-Reply-To: <87bq3at4l3.fsf@windlord.stanford.edu>
References: <ldvk5hyf33e.fsf@cathode-dark-space.mit.edu>
	<87bq3at4l3.fsf@windlord.stanford.edu>
Message-ID: <20080513210620.GA10859@sun.com>

On Tue, May 13, 2008 at 11:57:12AM -0700, Russ Allbery wrote:
> Tom Yu <tlyu at MIT.EDU> writes:
> 
> > Do we want to restrict this list exclusively to topics related to
> > development of the MIT Kerberos implementation?  Or do we want to also
> > allow application development topics on this list?  My recollection is
> > that historically, we have allowed application development topics on
> > this list.
> >
> > In any case, we should document the list policy consistently.
> 
> Personally, I think kerberos at mit.edu is a fine list for application
> development, and I'd rather use krbdev for development issues specifically
> related to MIT Kerberos.

But sometimes app dev impacts krb dev doesn't it (think API
changes/enhancements)?  In addition, there are quite a number krb use
questions on kerberos at mit.edu and it's more likely that app dev
questions may get lost in those threads.

I'm for app dev discussions relating to the krb/gss APIs being on
krbdev at mit.edu unless they obscure krb dev specific threads.

-- 
Will Fiveash
Sun Microsystems Inc.
http://opensolaris.org/os/project/kerberos/

From jaltman at secure-endpoints.com  Tue May 13 17:23:14 2008
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Tue, 13 May 2008 17:23:14 -0400
Subject: what is this list for?
In-Reply-To: <20080513210620.GA10859@sun.com>
References: <ldvk5hyf33e.fsf@cathode-dark-space.mit.edu>	<87bq3at4l3.fsf@windlord.stanford.edu>
	<20080513210620.GA10859@sun.com>
Message-ID: <482A06C2.1030600@secure-endpoints.com>

Will Fiveash wrote:

> I'm for app dev discussions relating to the krb/gss APIs being on
> krbdev at mit.edu unless they obscure krb dev specific threads.

krbdev is an MIT specific list.  kerberos is an agnostic list.
I believe that developers should not be trained to develop to the
MIT API.  I would not feel comfortable in this forum to answer
questions with Heimdal, Sishi, or other Kerberos implementation
specifics.

The traffic on the kerberos list is not high enough to for
dev questions to be lost there.   developers are end users of
the Kerberos/GSS apis.

Jeffrey Altman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20080513/b265e0ee/smime.bin

From tlyu at MIT.EDU  Tue May 13 19:19:22 2008
From: tlyu at MIT.EDU (Tom Yu)
Date: Tue, 13 May 2008 19:19:22 -0400
Subject: what is this list for?
In-Reply-To: <482A06C2.1030600@secure-endpoints.com> (Jeffrey Altman's message
	of "Tue, 13 May 2008 17:23:14 -0400")
References: <ldvk5hyf33e.fsf@cathode-dark-space.mit.edu>
	<87bq3at4l3.fsf@windlord.stanford.edu>
	<20080513210620.GA10859@sun.com>
	<482A06C2.1030600@secure-endpoints.com>
Message-ID: <ldvzlqt23np.fsf@cathode-dark-space.mit.edu>

Jeffrey Altman <jaltman at secure-endpoints.com> writes:

> Will Fiveash wrote:
>
>> I'm for app dev discussions relating to the krb/gss APIs being on
>> krbdev at mit.edu unless they obscure krb dev specific threads.
>
> krbdev is an MIT specific list.  kerberos is an agnostic list.
> I believe that developers should not be trained to develop to the
> MIT API.  I would not feel comfortable in this forum to answer
> questions with Heimdal, Sishi, or other Kerberos implementation
> specifics.

I meant to ask whether we should allow topics related to developing
applications using the MIT Kerberos APIs.  That is the sort of topic
that I recall seeing here historically.

From john at betelgeuse.us  Tue May 13 19:50:10 2008
From: john at betelgeuse.us (John W. M. Stevens)
Date: Tue, 13 May 2008 17:50:10 -0600
Subject: How Kerberize an application
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAANXVU5tFzQNMmhEVcp4H1MPCgAAAEAAAAPxfZUQVi+pAmhZRgzgQDjwBAAAAAA==@mit.edu>
References: <351696c80805130629l4626a82bwf3abfaf0a293611b@mail.gmail.com>
	<!&!AAAAAAAAAAAYAAAAAAAAANXVU5tFzQNMmhEVcp4H1MPCgAAAEAAAAPxfZUQVi+pAmhZRgzgQDjwBAAAAAA==@mit.edu>
Message-ID: <20080513235010.GA12851@betelgeuse.us>

On Tue, May 13, 2008 at 03:01:35PM -0400, Kevin Koch wrote:
> Brian Tung's Kerberos book has examples of how to call Kerberos functions in
> your code.
> 
> ISBN 0201379244.
> 
> http://www.amazon.com/Kerberos-Network-Authentication-Addison-Wesley-Network
> ing/dp/0201379244/ref=sr_1_1?ie=UTF8&s=books&qid=1210702842&sr=8-1
> 
> Kevin Koch
> Kerberos for Windows Lead Software Engineer
> MIT Kerberos Consortium http://www.kerberos.org
> Massachusetts Institute of Technology
> 304 Vassar St. W92-143
> Cambridge, MA 02139
> 617-324-8949
> kpkoch at mit.edu
> 
> -----Original Message-----
> From: krbdev-bounces at MIT.EDU [mailto:krbdev-bounces at MIT.EDU] On Behalf Of
> Carlos Rainho
> Sent: Tuesday, May 13, 2008 9:30 AM
> To: krbdev at mit.edu
> Subject: How Kerberize an application
> 
> Hello,
> 
> I'm studying Science Computing in Gama Filho University at Rio de Janeiro,
> Brazil. In my final project, I will implement securtiy in ALua, an
> event-driven communication mechanism for developing distributed parallel
> applications based on the interpreted language Lua (http://www.lua.org).
> 
> One way of this implementation is the usage of Kerberos. So, I need the
> modeling of kerberos in linux (Fedora 8) to kerberize commands in ALua that
> sends messages from one process for others processes in the same machine or
> not. Summarizing, I want to know how kerberize any application in Linux.

I developed something that sounds similiar to this for Ruby.  I've never
heard of Alua, but I'm betting the design patterns will be similar.

Feel free to email me higher level (design, pattern or reasoning) questions
if you think I could be of help.

Luck,
John S.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20080513/a6d1f62d/attachment.bin

From thomas.li at sinobot.com.cn  Tue May 13 21:20:44 2008
From: thomas.li at sinobot.com.cn (thomas.li)
Date: Wed, 14 May 2008 09:20:44 +0800
Subject: MIT KDC interoperability issue
References: <mailman.707.1210694649.23597.krbdev@mit.edu>
Message-ID: <200805140920358676853@sinobot.com.cn>

how to configure krb5.conf and kdc.conf to make interoperability with Windows KDC ? 

regardes
thomas

From niallain at gmail.com  Wed May 14 08:23:46 2008
From: niallain at gmail.com (Igor Mammedov)
Date: Wed, 14 May 2008 16:23:46 +0400
Subject: "Key table entry not found while getting initial credentials"
	+ KRB5KDC_ERR_PREAUTH_REQUIRED
In-Reply-To: <BAY129-W243AF58DB71515C7B8FD0ED1D90@phx.gbl>
References: <47F34AFC.2050502@gmail.com>
	<BAY129-W243AF58DB71515C7B8FD0ED1D90@phx.gbl>
Message-ID: <482AD9D2.8080103@gmail.com>

Arlene Berry wrote:
> Did anyone every respond on this?  I'm guessing it's bug #2131 which I
> reported a long time ago and which has never been fixed.  Here's a link
> to my report: 
> http://mailman.mit.edu/pipermail/krb5-bugs/2004-January/002162.html. 
> Basically, the problem is that the MIT library doesn't look at what's
> actually available in the key table when choosing encryption types for
> preauthentication encryption type negotiation.  Note the encryption
> types in your AS-REQ.  That is a list of all of the types that the
> library says it can do in descending order of preference.  Somewhere in
> the KRB-ERROR token's e-data will be a reply as to which of those types
> the server can do.  The MIT library will choose one (it must be choosing
> rc4-hmac since that one works) and will then look for the chosen type in
> the key table.  If it's not there you get the error.  The types that the
> MIT library submits is determined by the krb5.conf default_tkt_enctypes
> option which defaults to all of the types the library is capable of
> doing.  You can change default_tkt_enctypes to ensure that des-cbc-md5
> is chosen but doing so will change things for all applications on the host.

Nope, nobody has responded on it yet.
I've tried woodoo you suggested and if I put des-cbc-md5 in the beginning of 
the  default_tkt_enctypes list, It works.
However ordinary user or admin will look for another solution instead of jumping
around of krb5 stuff.

> 
>> Date: Wed, 2 Apr 2008 12:59:40 +0400
>> From: niallain at gmail.com
>> To: krb5-bugs at mit.edu
>> Subject: "Key table entry not found while getting initial credentials"
> + KRB5KDC_ERR_PREAUTH_REQUIRED
>> CC: krbdev at mit.edu
>>
>> Hi folks,
>> Maybe I've found a bug in krb5 libs code.
>> Here is the thing:
>> When we store user password in keytab with des-cbc-md5 encryption
>>
>> with "addent -password -p TESTUSERNAME -k 1 -e des-cbc-md5"
>>
>> we receive error KRB5KDC_ERR_PREAUTH_REQUIRED from the server and
>> kinit says "Key table entry not found while getting initial credentials".
>>
>> Also note that in the dump of the client-server conversation there is no
>> field "padata" in the request.
>>
>> -------------- Incorrect case --------------------
>> User Datagram Protocol, Src Port: 46944 (46944), Dst Port: kerberos (88)
>> Kerberos AS-REQ
>> Pvno: 5
>> MSG Type: AS-REQ (10)
>> KDC_REQ_BODY
>> Padding: 0
>> KDCOptions: 40000010 (Forwardable, Renewable OK)
>> Client Name (Principal): TESTUSERNAME
>> Realm: MY.TEST.REALM
>> Server Name (Unknown): krbtgt/MY.TEST.REALM
>> from: 2008-04-02 07:56:30 (Z)
>> till: 2008-04-03 07:56:30 (Z)
>> Nonce: 1207122990
>> Encryption Types: rc4-hmac des3-cbc-sha1 des-cbc-crc des-cbc-md5
>>
>> User Datagram Protocol, Src Port: kerberos (88), Dst Port: 46944 (46944)
>> Kerberos KRB-ERROR
>> Pvno: 5
>> MSG Type: KRB-ERROR (30)
>> stime: 2008-04-02 07:55:18 (Z)
>> susec: 502936
>> error_code: KRB5KDC_ERR_PREAUTH_REQUIRED (25)
>> Realm: MY.TEST.REALM
>> Server Name (Unknown): krbtgt/MY.TEST.REALM
>> e-data
>>
>> However if we add entry into keytab this way:
>>
>> "addent -password -p TESTUSERNAME -k 1 -e rc4-hmac"
>>
>> Then client sends "padata" in the request and the server replies with
> a valid TGT.
>>
>> So this is probably a bug in the client code (kinit or krb5 libs), if
> it is not then
>> could someone clarify why it works this way?
>>
>> ------------- Normal case --------------------------
>>
>> User Datagram Protocol, Src Port: 41142 (41142), Dst Port: kerberos (88)
>> Kerberos AS-REQ
>> Pvno: 5
>> MSG Type: AS-REQ (10)
>> padata: PA-ENC-TIMESTAMP
>> Type: PA-ENC-TIMESTAMP (2)
>> Value: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX... rc4-hmac
>> KDC_REQ_BODY
>> Padding: 0
>> KDCOptions: 40000010 (Forwardable, Renewable OK)
>> Client Name (Principal): TESTUSERNAME
>> Realm: MY.TEST.REALM
>> Server Name (Unknown): krbtgt/MY.TEST.REALM
>> from: 2008-04-02 08:05:01 (Z)
>> till: 2008-04-03 08:05:01 (Z)
>> Nonce: 1207123501
>> Encryption Types: rc4-hmac des3-cbc-sha1 des-cbc-crc des-cbc-md5
>>
>> User Datagram Protocol, Src Port: kerberos (88), Dst Port: 41142 (41142)
>> Kerberos AS-REP
>> Pvno: 5
>> MSG Type: AS-REP (11)
>> Client Realm: MY.TEST.REALM
>> Client Name (Principal): TESTUSERNAME
>> Ticket
>> enc-part rc4-hmac
>>
>>
>>
>>
>> --
>>
>> Best regards,
>>
>> -------------------------
>> Igor Mammedov,
>> niallain "at" gmail.com
>>
>>
>>
>>
>> _______________________________________________
>> krbdev mailing list krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> 
> ------------------------------------------------------------------------
> Express yourself wherever you are. Mobilize!
> <http://www.gowindowslive.com/Mobile/Landing/Messenger/Default.aspx?Locale=en-US?ocid=TAG_APRIL>


-- 

Best regards,

-------------------------
Igor Mammedov,
niallain "at" gmail.com





From raeburn at MIT.EDU  Wed May 14 11:04:10 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Wed, 14 May 2008 11:04:10 -0400
Subject: "Key table entry not found while getting initial credentials" +
	KRB5KDC_ERR_PREAUTH_REQUIRED
In-Reply-To: <482AD9D2.8080103@gmail.com>
References: <47F34AFC.2050502@gmail.com>
	<BAY129-W243AF58DB71515C7B8FD0ED1D90@phx.gbl>
	<482AD9D2.8080103@gmail.com>
Message-ID: <D8EE9914-E6CE-44D6-B880-EEB90FA14AE4@mit.edu>

Another workaround would be to put keys of all supported types into  
the keytab, not just one.  It's not a 100% solution, because if you  
upgrade the implementation and it adds new encryption types that the  
KDC also knows about, that won't automagically update the keytab  
file.  Or, save away the password itself and use it when getting new  
credentials; also not a great idea, depending on the use case and  
threat model.

For a server principal, it's expected that the KDC knows the set of  
encryption types available.  But for password-based user keys saved  
away, yes, perhaps we should be using the actual enctypes stored....

Ken

From jhutz at cmu.edu  Wed May 14 12:26:46 2008
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Wed, 14 May 2008 12:26:46 -0400
Subject: what is this list for?
In-Reply-To: <482A06C2.1030600@secure-endpoints.com>
References: <ldvk5hyf33e.fsf@cathode-dark-space.mit.edu>
	<87bq3at4l3.fsf@windlord.stanford.edu>	<20080513210620.GA10859@sun.com>
	<482A06C2.1030600@secure-endpoints.com>
Message-ID: <01D91AA516A97DA8DBFFF776@sirius.fac.cs.cmu.edu>

--On Tuesday, May 13, 2008 05:23:14 PM -0400 Jeffrey Altman 
<jaltman at secure-endpoints.com> wrote:

> krbdev is an MIT specific list.  kerberos is an agnostic list.
> I believe that developers should not be trained to develop to the
> MIT API.  I would not feel comfortable in this forum to answer
> questions with Heimdal, Sishi, or other Kerberos implementation
> specifics.

I'm inclined to agree -- this list is a fine place for issues related to 
developing MIT Kerberos, or for issues specific to the MIT API.  General 
questions should probably go to the kerberos list.

However...

> The traffic on the kerberos list is not high enough to for
> dev questions to be lost there.   developers are end users of
> the Kerberos/GSS apis.

The traffic on the kerberos list is significantly higher than here.  I am 
subscribed to both lists.  I read this one very nearly every day, but I 
haven't had time to read kerberos at mit.edu for almost a year.

-- Jeff

From hotz at jpl.nasa.gov  Wed May 14 15:21:03 2008
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Wed, 14 May 2008 12:21:03 -0700
Subject: "Key table entry not found while getting initial credentials"
	+	KRB5KDC_ERR_PREAUTH_REQUIRED
In-Reply-To: <mailman.775.1210781572.19981.krbdev@mit.edu>
References: <mailman.775.1210781572.19981.krbdev@mit.edu>
Message-ID: <42461D64-1FD4-4373-A4A4-90C5415EDF9D@jpl.nasa.gov>

I agree that's the desired behavior:  an AS_REQ based on a keytab  
should use the intersection of the enctypes supported in the library  
and the enctypes in the keytab for the principal in question.

I've had to deploy something like that, but my patch isn't general  
enough to be useful to this audience.

On May 14, 2008, at 9:12 AM, krbdev-request at mit.edu wrote:

> Date: Wed, 14 May 2008 11:04:10 -0400
> From: Ken Raeburn <raeburn at MIT.EDU>
> Subject: Re: "Key table entry not found while getting initial
> 	credentials" +	KRB5KDC_ERR_PREAUTH_REQUIRED
> To: Igor Mammedov <niallain at gmail.com>
> Cc: krbdev at mit.edu
> Message-ID: <D8EE9914-E6CE-44D6-B880-EEB90FA14AE4 at mit.edu>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> Another workaround would be to put keys of all supported types into
> the keytab, not just one.  It's not a 100% solution, because if you
> upgrade the implementation and it adds new encryption types that the
> KDC also knows about, that won't automagically update the keytab
> file.  Or, save away the password itself and use it when getting new
> credentials; also not a great idea, depending on the use case and
> threat model.
>
> For a server principal, it's expected that the KDC knows the set of
> encryption types available.  But for password-based user keys saved
> away, yes, perhaps we should be using the actual enctypes stored....
>
> Ken

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu




From klausk at linux.vnet.ibm.com  Wed May 14 17:53:12 2008
From: klausk at linux.vnet.ibm.com (Klaus Heinrich Kiwi)
Date: Wed, 14 May 2008 18:53:12 -0300
Subject: kdb-ldap plugin question: krbSubTrees realm attribute
Message-ID: <1210801992.15549.32.camel@klausk.br.ibm.com>

Hi.

 I've been working on patching the kdb-ldap plugin in order to support
the IBM LDAP Schema. For now I've been trying to figure out how the
current implementation works, and possibly what needs to be done in
order to support the IBM Schema using the current code as a base.

I'm curious about the 'krbSubTrees' attribute, found within the
krbRealmContainer objectclass.

Looking at the code and Admin guide, looks like an attribute configured
at realm creation time, where one can specify a list of subtrees where
the principals for the to-be-configured Realm will be placed. Does that
means that principals doesn't necessarily needs to be placed under a
krbRealmContainer?

In my basic testbed setup here I have the following:

?+dc=myDomain,dc=com					 /* base */
|+dn: cn=krbcontainer,dc=myDomain,dc=com		/* krbContainer */
 |+dn: cn=MYREALM,cn=krbcontainer,dc=myDomain,dc=com    /* krbRealmContainer */
  |-dn: krbPrincipalName=kadmin/pam at MYREALM,cn=MYREALM,cn=krbcontainer,dc=myDomain,dc=com
  |-... (more principals)

where my 'krbSubTrees=dc=myDomain,dc=com' (single-valued). Is this setup
correct? 
What happens if I had 'krbSubTrees=cn=realms,dc=myDomain,dc=com' or with
multiple values?


Thanks,

 --Klaus

-- 
Klaus Heinrich Kiwi
Security Development - IBM Linux Technology Center


From ssorce at redhat.com  Wed May 14 18:39:06 2008
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 14 May 2008 18:39:06 -0400
Subject: kdb-ldap plugin question: krbSubTrees realm attribute
In-Reply-To: <1210801992.15549.32.camel@klausk.br.ibm.com>
References: <1210801992.15549.32.camel@klausk.br.ibm.com>
Message-ID: <1210804746.28428.67.camel@localhost.localdomain>


On Wed, 2008-05-14 at 18:53 -0300, Klaus Heinrich Kiwi wrote:
> Hi.
> 
>  I've been working on patching the kdb-ldap plugin in order to support
> the IBM LDAP Schema. For now I've been trying to figure out how the
> current implementation works, and possibly what needs to be done in
> order to support the IBM Schema using the current code as a base.
> 
> I'm curious about the 'krbSubTrees' attribute, found within the
> krbRealmContainer objectclass.
> 
> Looking at the code and Admin guide, looks like an attribute configured
> at realm creation time, where one can specify a list of subtrees where
> the principals for the to-be-configured Realm will be placed. Does that
> means that principals doesn't necessarily needs to be placed under a
> krbRealmContainer?

Nope principals can be put anywhere in the tree, but they will be looked
up only in the defined krbSubTrees trees.

> In my basic testbed setup here I have the following:
> 
> ?+dc=myDomain,dc=com					 /* base */
> |+dn: cn=krbcontainer,dc=myDomain,dc=com		/* krbContainer */
>  |+dn: cn=MYREALM,cn=krbcontainer,dc=myDomain,dc=com    /* krbRealmContainer */
>   |-dn: krbPrincipalName=kadmin/pam at MYREALM,cn=MYREALM,cn=krbcontainer,dc=myDomain,dc=com
>   |-... (more principals)
> 
> where my 'krbSubTrees=dc=myDomain,dc=com' (single-valued). Is this setup
> correct? 

I use this setup in the FreeIPA project as we stick the keys to the user
accounts entries, works flawlessly.

> What happens if I had 'krbSubTrees=cn=realms,dc=myDomain,dc=com' or with

Only nodes of the cn=realms,dc=myDomain,dc=com will be searched for the
principals.

> multiple values?

multiple subtrees should be searched for the principals (I have no
tested this though).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York


From klausk at linux.vnet.ibm.com  Wed May 14 20:27:32 2008
From: klausk at linux.vnet.ibm.com (Klaus Heinrich Kiwi)
Date: Wed, 14 May 2008 21:27:32 -0300
Subject: kdb-ldap plugin question: krbSubTrees realm attribute
In-Reply-To: <1210804746.28428.67.camel@localhost.localdomain>
References: <1210801992.15549.32.camel@klausk.br.ibm.com>
	<1210804746.28428.67.camel@localhost.localdomain>
Message-ID: <1210811252.15549.46.camel@klausk.br.ibm.com>

Thanks Simo for your quick response.

> > What happens if I had 'krbSubTrees=cn=realms,dc=myDomain,dc=com' or with
> 
> Only nodes of the cn=realms,dc=myDomain,dc=com will be searched for the
> principals
> > multiple values?
> 
> multiple subtrees should be searched for the principals (I have no
> tested this though).
> 

Thanks. So just to check if I got it right. In case a
krbPrincContainerRef attribute is present, the administrator needs to be
sure that it points to the same dn pointed by at least one element of
krbSubTrees (in case krbSearchScope=one-level) or it's children (in case
krbSearchScope=subtree) - or else it will end up adding principals where
kerberos itself can't find them.

Thanks,
  -K

-- 
Klaus Heinrich Kiwi
Security Development - IBM Linux Technology Center


From rsavitha at novell.com  Thu May 15 07:50:37 2008
From: rsavitha at novell.com (Savitha R)
Date: Thu, 15 May 2008 05:50:37 -0600
Subject: kdb-ldap plugin question: krbSubTrees realm attribute
In-Reply-To: <1210811252.15549.46.camel@klausk.br.ibm.com>
References: <1210801992.15549.32.camel@klausk.br.ibm.com>
	<1210804746.28428.67.camel@localhost.localdomain>
	<1210811252.15549.46.camel@klausk.br.ibm.com>
Message-ID: <482C6FD8.C217.0053.0@novell.com>


>>> On Thu, May 15, 2008 at  5:57 AM, in message
<1210811252.15549.46.camel at klausk.br.ibm.com>, Klaus Heinrich Kiwi
<klausk at linux.vnet.ibm.com> wrote: 
> Thanks Simo for your quick response.
> 
>> > What happens if I had 'krbSubTrees=cn=realms,dc=myDomain,dc=com' or with
>> 
>> Only nodes of the cn=realms,dc=myDomain,dc=com will be searched for the
>> principals
>> > multiple values?
>> 
>> multiple subtrees should be searched for the principals (I have no
>> tested this though).
>> 
> 
> Thanks. So just to check if I got it right. In case a
> krbPrincContainerRef attribute is present, the administrator needs to be
> sure that it points to the same dn pointed by at least one element of
> krbSubTrees (in case krbSearchScope=one-level) or it's children (in case
> krbSearchScope=subtree) - or else it will end up adding principals where
> kerberos itself can't find them.
> 
Principals are searched for in the containers specified in krbsubtrees and
krbPrincContainerRef attributes and also in the Realm Container. So the 
krbPrincContainerRef need not be present in the krbsubtrees list.

-Savitha





From rra at stanford.edu  Thu May 15 10:34:45 2008
From: rra at stanford.edu (Russ Allbery)
Date: Thu, 15 May 2008 07:34:45 -0700
Subject: Implications of Debian OpenSSL flaw for MIT PKINIT
Message-ID: <87fxsjd4ai.fsf@windlord.stanford.edu>

I'm chasing the various angles of the OpenSSL vulnerability recently
discovered in Debian that caused it to not properly seed the random number
generator, and I want to double-check my understanding of the implications
for the PKINIT plugin.

My understanding is:

* MIT Kerberos itself does not generate long-term key pairs even when the
  PKINIT plugin is used, so any vulnerable long-term key pairs would have
  been generated outside of the MIT Kerberos software itself.  The PKINIT
  plugin only references existing key pairs and isn't responsible for key
  management.

* All of the random session key generation inside the PKINIT plugin is
  done using the regular MIT Kerberos random key functions, *not* the
  OpenSSL random number generator, and hence sessions created via PKINIT
  are not subject to this vulnerability.

Based on that understanding, it looks to me like MIT Kerberos is not in
itself affected.  Long-term key pairs used with PKINIT may be affected if
generated on an affected Debian system, but such generation is external to
MIT Kerberos.

Can you confirm whether my understanding is correct?

Thanks!

(Note that, regardless, the PKINIT plugin was not present in Debian etch,
so any problems would only be in Debian testing and unstable.)

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

From raeburn at MIT.EDU  Thu May 15 11:35:31 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Thu, 15 May 2008 11:35:31 -0400
Subject: Implications of Debian OpenSSL flaw for MIT PKINIT
In-Reply-To: <87fxsjd4ai.fsf@windlord.stanford.edu>
References: <87fxsjd4ai.fsf@windlord.stanford.edu>
Message-ID: <349BFB5D-DE79-43AC-B147-7DF8E1C0856B@mit.edu>

On May 15, 2008, at 10:34, Russ Allbery wrote:
> Based on that understanding, it looks to me like MIT Kerberos is not  
> in
> itself affected.  Long-term key pairs used with PKINIT may be  
> affected if
> generated on an affected Debian system, but such generation is  
> external to
> MIT Kerberos.
>
> Can you confirm whether my understanding is correct?

I believe it is correct, yes.

-- 
Ken Raeburn, Senior Programmer
MIT Kerberos Consortium


From david at wsg.net  Thu May 15 11:52:40 2008
From: david at wsg.net (David E. Cross)
Date: Thu, 15 May 2008 11:52:40 -0400
Subject: Multiple Realm Question...
Message-ID: <482C5C48.6040903@wsg.net>

.. Not entirely sure this is appropriate for krbdev... but it seems to 
relate directly to the MIT codebase, and I haven't found any answers in 
FAQs, etc..

I am looking to setup multiple realms on a single KDC, specifically the 
"right" way to do this.
It _seems_ that the architecture is in place to do all of it with a 
single database, all of the principals within the "principal" file have 
their REALMs as part of the key, the per-realm secret is setup by 
default to be .k5.REALM.. so it seems it can all share a single 
database.  However when I try to kdb5_util -r SECOND.REALM -s  it dies 
on an error that the principal database already exists.

Must I have multiple principal files?  If so, why, it seems like a fair 
bit of thought was put in place to allow sharing.   If its just a limit 
on creation (it seems to be), can I (should I) kdb5_util dump/load/merge 
my way around it?

Thank you.

-- 
David E. Cross

From rra at stanford.edu  Thu May 15 12:00:41 2008
From: rra at stanford.edu (Russ Allbery)
Date: Thu, 15 May 2008 09:00:41 -0700
Subject: Implications of Debian OpenSSL flaw for MIT PKINIT
In-Reply-To: <349BFB5D-DE79-43AC-B147-7DF8E1C0856B@mit.edu> (Ken Raeburn's
	message of "Thu\, 15 May 2008 11\:35\:31 -0400")
References: <87fxsjd4ai.fsf@windlord.stanford.edu>
	<349BFB5D-DE79-43AC-B147-7DF8E1C0856B@mit.edu>
Message-ID: <87zlqra76e.fsf@windlord.stanford.edu>

Ken Raeburn <raeburn at MIT.EDU> writes:
> On May 15, 2008, at 10:34, Russ Allbery wrote:

>> Based on that understanding, it looks to me like MIT Kerberos is not in
>> itself affected.  Long-term key pairs used with PKINIT may be affected
>> if generated on an affected Debian system, but such generation is
>> external to MIT Kerberos.

>> Can you confirm whether my understanding is correct?

> I believe it is correct, yes.

Thanks, Ken!

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

From hotz at jpl.nasa.gov  Thu May 15 14:02:49 2008
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Thu, 15 May 2008 11:02:49 -0700
Subject: what is this list for?
In-Reply-To: <mailman.41183.1210867278.4386.krbdev@mit.edu>
References: <mailman.41183.1210867278.4386.krbdev@mit.edu>
Message-ID: <904A6C8D-2A58-4EA7-A8C6-CF731E223C77@jpl.nasa.gov>


On May 15, 2008, at 9:01 AM, krbdev-request at mit.edu wrote:

>> The traffic on the kerberos list is not high enough to for
>> dev questions to be lost there.   developers are end users of
>> the Kerberos/GSS apis.
>
> The traffic on the kerberos list is significantly higher than here.   
> I am
> subscribed to both lists.  I read this one very nearly every day,  
> but I
> haven't had time to read kerberos at mit.edu for almost a year.
>
> -- Jeff

Second that, and I think it's been even longer for the MIT folks.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu




From deengert at anl.gov  Thu May 15 14:13:57 2008
From: deengert at anl.gov (Douglas E. Engert)
Date: Thu, 15 May 2008 13:13:57 -0500
Subject: libpam-krb5  on Ubuntu 8.04  with MIT Kerberos and PKINIT
Message-ID: <482C7D65.6010700@anl.gov>

I was trying to get the PKINIT working on Ubuntu 8.04
which comes with:
    libpam-krb5 3.10-1
    krb5-pkinit 1.6.dfsg.3~beta1-2ubuntu1

I had to make a change to the libpam-krb5 auth.c to remove a test for
a bug that appears to be fixed in krb5-1.6.3 I just changed the #ifdef
to not include the call to clear out the opts structure.


--- ,auth.c     2007-12-28 23:42:52.000000000 -0600
+++ auth.c      2008-05-15 10:55:26.000000000 -0500
@@ -139,7 +139,7 @@
  set_credential_options(struct pam_args *args, krb5_get_init_creds_opt *opts,
                         int service)
  {
-#ifdef HAVE_KRB5_MIT
+#ifdef HAVE_KRB5_MIT_OLDER_THEN_1_6_3
      /* Work around a bug in MIT Kerberos where allocating the credential
         structure with opt_alloc doesn't initialize it.  This workaround
         will probably be removed eventually when the broken versions of 1.6
         are obsolete.

         We can't do this for Heimdal because it will destroy the private
         structure in the allocated opt struct. */
      krb5_get_init_creds_opt_init(opts);
  #endif


Can you verify that the above code is not needed?

With the above change and change to /etc/pam.d/* and /etc/krb5.conf
I can get gdm and gnome-screensaver to use either a smart card or a password.

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

From rra at stanford.edu  Thu May 15 14:43:52 2008
From: rra at stanford.edu (Russ Allbery)
Date: Thu, 15 May 2008 11:43:52 -0700
Subject: libpam-krb5  on Ubuntu 8.04  with MIT Kerberos and PKINIT
In-Reply-To: <482C7D65.6010700@anl.gov> (Douglas E. Engert's message of "Thu\,
	15 May 2008 13\:13\:57 -0500")
References: <482C7D65.6010700@anl.gov>
Message-ID: <8763tf8l1z.fsf@windlord.stanford.edu>

"Douglas E. Engert" <deengert at anl.gov> writes:

> I was trying to get the PKINIT working on Ubuntu 8.04
> which comes with:
>     libpam-krb5 3.10-1
>     krb5-pkinit 1.6.dfsg.3~beta1-2ubuntu1
>
> I had to make a change to the libpam-krb5 auth.c to remove a test for
> a bug that appears to be fixed in krb5-1.6.3 I just changed the #ifdef
> to not include the call to clear out the opts structure.

The bug was fixed in 1.6.3, but I didn't think it was fixed in such a way
as to make that code break anything.  Not running that fixed something?
Does MIT now do what Heimdal does and zero out the allocated memory as
well when one runs opt_init?

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

From deengert at anl.gov  Thu May 15 15:52:10 2008
From: deengert at anl.gov (Douglas E. Engert)
Date: Thu, 15 May 2008 14:52:10 -0500
Subject: libpam-krb5  on Ubuntu 8.04  with MIT Kerberos and PKINIT
In-Reply-To: <8763tf8l1z.fsf@windlord.stanford.edu>
References: <482C7D65.6010700@anl.gov> <8763tf8l1z.fsf@windlord.stanford.edu>
Message-ID: <482C946A.2070800@anl.gov>



Russ Allbery wrote:
> "Douglas E. Engert" <deengert at anl.gov> writes:
> 
>> I was trying to get the PKINIT working on Ubuntu 8.04
>> which comes with:
>>     libpam-krb5 3.10-1
>>     krb5-pkinit 1.6.dfsg.3~beta1-2ubuntu1
>>
>> I had to make a change to the libpam-krb5 auth.c to remove a test for
>> a bug that appears to be fixed in krb5-1.6.3 I just changed the #ifdef
>> to not include the call to clear out the opts structure.
> 
> The bug was fixed in 1.6.3, but I didn't think it was fixed in such a way
> as to make that code break anything. Not running that fixed something?

The pkinit would not work with the call krb5_get_init_creds_opt_init(opts)
code being called. It looks like it sets the
opt->flag = KRB5_GET_INIT_CREDS_OPT_CHG_PWD_PRMPT
and thus looses the KRB5_GET_INIT_CREDS_OPT_EXTENDED flag. Not sure
if krb5_get_init_creds_opt_set_pa failed or stored something.

In any case, the PKINIT worked when I remove the call the
krb5_get_init_creds_opt_init.

> Does MIT now do what Heimdal does and zero out the allocated memory as
> well when one runs opt_init?

I believe so, it looks like calloc is used by krb5int_gic_opte_alloc and
krb5int_gic_opte_private_alloc in 1.6.3-beta1

I would hope one of the MIT people could comment.

> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

From rra at stanford.edu  Thu May 15 16:30:26 2008
From: rra at stanford.edu (Russ Allbery)
Date: Thu, 15 May 2008 13:30:26 -0700
Subject: libpam-krb5  on Ubuntu 8.04  with MIT Kerberos and PKINIT
In-Reply-To: <482C946A.2070800@anl.gov> (Douglas E. Engert's message of "Thu\,
	15 May 2008 14\:52\:10 -0500")
References: <482C7D65.6010700@anl.gov> <8763tf8l1z.fsf@windlord.stanford.edu>
	<482C946A.2070800@anl.gov>
Message-ID: <87mymr71jx.fsf@windlord.stanford.edu>

"Douglas E. Engert" <deengert at anl.gov> writes:

> The pkinit would not work with the call krb5_get_init_creds_opt_init(opts)
> code being called. It looks like it sets the
> opt->flag = KRB5_GET_INIT_CREDS_OPT_CHG_PWD_PRMPT
> and thus looses the KRB5_GET_INIT_CREDS_OPT_EXTENDED flag. Not sure
> if krb5_get_init_creds_opt_set_pa failed or stored something.

Oh, okay.  In that case, I'm going to just drop this code completely,
since the only affected versions were MIT Kerberos 1.6 prior to the 1.6.3
pre-releases.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

From david at wsg.net  Thu May 15 17:23:20 2008
From: david at wsg.net (David E. Cross)
Date: Thu, 15 May 2008 17:23:20 -0400
Subject: Multiple Realm Question...
In-Reply-To: <482C5C48.6040903@wsg.net>
References: <482C5C48.6040903@wsg.net>
Message-ID: <482CA9C8.800@wsg.net>

Ok, I've poked around some more and what I have found does not leave me 
with warm fuzzies going forward at any level.

So, I started by playing it safe and having 2 separate directories.  
This mostly worked.  The issue was that kadmind doesn't seem to like to 
have 2 principal databases with 2 private keys (stash files), and 2 
keytabs.  I would get inconsistent errors trying to "kadmin -r REALM1" 
or "kadmin -r REALM2".

I decided to try the single directory, single "principal" database 
approach.  I did this via a kdb5_util dump, kdb5_util load -update to 
merge the databases together.  It worked, sorta.  kdc seems happy with 
it, but again kadmind has issues.  This time the issues were that from 
REALM2 I can see REALM1's principals, and to the extent that kadmin 
policy allows me to, I can change keys.. which actually winds up 
corrupting REALM1's keys, as the master passwords are different (duh).  
So at this point I am not sure where this leaves me, other then having 
multiple images (which sucks for a few reasons).  it seems like all of 
this was designed to work.. it just wasn't ever coded/tested.


BTW: below are the errors I get from kadmin when doing the 2 directory, 
2 realm setup:

May 15 18:26:30 kerberos.domain kadmind[93592](Notice):     Unspecified 
GSS failure.  Minor code may provide more information
May 15 18:26:30 kerberos.domain kadmind[93592](Notice):     Key table 
entry not found
May 15 18:26:30 kerberos.domain kadmind[93592](Notice):    GSS-API error 
strings complete.
May 15 18:26:30 kerberos.domain  kadmind[93592](Notice): Authentication 
attempt failed: 10.x.y.z, GSS-API error strings are:

Any hints here, or do I need to go code spellunking?

-- 
David E. Cross

David E. Cross wrote:
> .. Not entirely sure this is appropriate for krbdev... but it seems to 
> relate directly to the MIT codebase, and I haven't found any answers in 
> FAQs, etc..
>
> I am looking to setup multiple realms on a single KDC, specifically the 
> "right" way to do this.
> It _seems_ that the architecture is in place to do all of it with a 
> single database, all of the principals within the "principal" file have 
> their REALMs as part of the key, the per-realm secret is setup by 
> default to be .k5.REALM.. so it seems it can all share a single 
> database.  However when I try to kdb5_util -r SECOND.REALM -s  it dies 
> on an error that the principal database already exists.
>
> Must I have multiple principal files?  If so, why, it seems like a fair 
> bit of thought was put in place to allow sharing.   If its just a limit 
> on creation (it seems to be), can I (should I) kdb5_util dump/load/merge 
> my way around it?
>
> Thank you.
>
>   


From mooney at dogbert.cc.ndsu.NoDak.edu  Thu May 15 17:37:40 2008
From: mooney at dogbert.cc.ndsu.NoDak.edu (Tim Mooney)
Date: Thu, 15 May 2008 16:37:40 -0500 (CDT)
Subject: Multiple Realm Question...
In-Reply-To: <482CA9C8.800@wsg.net>
References: <482C5C48.6040903@wsg.net> <482CA9C8.800@wsg.net>
Message-ID: <alpine.SOC.1.10.0805151630520.9271@dogbert.cc.ndsu.NoDak.edu>

In regard to: Re: Multiple Realm Question..., David E. Cross said (at...:

> So, I started by playing it safe and having 2 separate directories.
> This mostly worked.  The issue was that kadmind doesn't seem to like to
> have 2 principal databases with 2 private keys (stash files), and 2
> keytabs.  I would get inconsistent errors trying to "kadmin -r REALM1"
> or "kadmin -r REALM2".

We've served multiple realms from one host for several years.  What's
worked for us is

- one kdc process serving multiple separate databases, in multiple
   separate directories.

- a kadmind process for each realm.  kadmind obviously needs to listen
   on different ports for different realms, if you only have one IP address
   associated with the box.

- on any secondary servers, one kpropd for each realm, also each on a
   separate port.


I've posted information on how to set this up previously, and someone else
has done a more thorough "How To" guide on the same process.  Do some
searching (don't forget to search Usenet groups, as it was probably posted
to the "general use" mailing list, which is gatewayed to a newsgroup)
and you should turn up the necessary info on how to do this.

Tim
-- 
Tim Mooney                              mooney at dogbert.cc.ndsu.NoDak.edu
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

From david at wsg.net  Thu May 15 18:27:59 2008
From: david at wsg.net (David E. Cross)
Date: Thu, 15 May 2008 18:27:59 -0400
Subject: Multiple Realm Question...
In-Reply-To: <alpine.SOC.1.10.0805151630520.9271@dogbert.cc.ndsu.NoDak.edu>
References: <482C5C48.6040903@wsg.net> <482CA9C8.800@wsg.net>
	<alpine.SOC.1.10.0805151630520.9271@dogbert.cc.ndsu.NoDak.edu>
Message-ID: <482CB8EF.6000304@wsg.net>

Separate ports, etc.. is a really kludgy solution, and according to the 
documentation (for kadmind even) in multiple places it shouldn't be 
needed.  For example:

keytab    Kadmind  requires a keytab containing correct entries for the
    kadmin/admin and kadmin/changepw principals for  every  realm
    that  kadmind  will  answer  requests for.

-r realm   ...  kadmind will  answer requests for any realm that exists 
in the local KDC
    database and for which the appropriate  principals  are  in  its
    keytab.

-- 
David E. Cross

Tim Mooney wrote:
> In regard to: Re: Multiple Realm Question..., David E. Cross said (at...:
>
>> So, I started by playing it safe and having 2 separate directories.
>> This mostly worked.  The issue was that kadmind doesn't seem to like to
>> have 2 principal databases with 2 private keys (stash files), and 2
>> keytabs.  I would get inconsistent errors trying to "kadmin -r REALM1"
>> or "kadmin -r REALM2".
>
> We've served multiple realms from one host for several years.  What's
> worked for us is
>
> - one kdc process serving multiple separate databases, in multiple
>   separate directories.
>
> - a kadmind process for each realm.  kadmind obviously needs to listen
>   on different ports for different realms, if you only have one IP 
> address
>   associated with the box.
>
> - on any secondary servers, one kpropd for each realm, also each on a
>   separate port.
>
>
> I've posted information on how to set this up previously, and someone 
> else
> has done a more thorough "How To" guide on the same process.  Do some
> searching (don't forget to search Usenet groups, as it was probably 
> posted
> to the "general use" mailing list, which is gatewayed to a newsgroup)
> and you should turn up the necessary info on how to do this.
>
> Tim


From cglidden at ncipher.com  Thu May 15 18:36:59 2008
From: cglidden at ncipher.com (Chris Glidden)
Date: Thu, 15 May 2008 18:36:59 -0400
Subject: MIT Kerberos KDC crypto tasks offloaded to HSM
Message-ID: <35AE7DFF274F5346BD8C5A7A079F2EECF935CB@mailstore-us01.ncipher.com>

Hello-

 

Is there a public location where I might be able to view a Kerberos roadmap?

 

I am curious if there has ever been any thought directed to securing the KDC
master/root key with a Hardware Security Module.

 

nCipher's products can be used to secure important encryption keys (and
associated algorithms) to add security to applications by shifting key
generation, use, storage, and authorization out of the OS and into a
dedicated piece of hardware.  Common deployments include PKI (securing
Certificate Authority keys), database encryption, identity management
applications, custom crypto applications for PCI compliance, among others.

 

I am asking because I was approached by a large financial institution that
uses MIT Kerberos that is interested in exploring the possibility of
integrating their KDC with an HSM.  The customer's Kerberos infrastructure
is both substantial and critical to their operations, so they are looking to
add any and all security that they possibly can.

 

It is possible to communicate with our HSM via the following APIs: PKCS#11,
Java CSP (JCE), Microsoft CAPI (don't laugh), or OpenSSL compiled with CHIL
(cryptographic hardware integration library) support.  We also have our own
native API, but that might not be the easiest solution as it involves
writing new code, rather than altering existing work.

 

I am curious to hear people's thoughts on this subject.

 

Thank you,

 

Chris

 

--

CHRISTOPHER GLIDDEN

Sales Engineer

 

nCIPHER

cglidden at ncipher.com

C: 857-222-4269

F: 781-998-7875

http://www.ncipher.com

 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3121 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20080515/4da797c5/smime-0001.bin

From raeburn at MIT.EDU  Thu May 15 20:44:11 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Thu, 15 May 2008 20:44:11 -0400
Subject: MIT Kerberos KDC crypto tasks offloaded to HSM
In-Reply-To: <35AE7DFF274F5346BD8C5A7A079F2EECF935CB@mailstore-us01.ncipher.com>
References: <35AE7DFF274F5346BD8C5A7A079F2EECF935CB@mailstore-us01.ncipher.com>
Message-ID: <A4BFAFB0-5761-4484-9BD3-1F10AA903DF2@mit.edu>

On May 15, 2008, at 18:36, Chris Glidden wrote:
> Is there a public location where I might be able to view a Kerberos  
> roadmap?

Hmm... at http://www.kerberos.org/events/Board-4-7-08/index.html there  
are some slides from presentations given at the last Kerberos  
Consortium board meeting; it looks like no post-meeting report has  
been posted though.  Based on feedback from some of the Consortium  
sponsors, we've been re-evaluating some of our plans.

> I am curious if there has ever been any thought directed to securing  
> the KDC
> master/root key with a Hardware Security Module.

Are you thinking of something along the lines of the secure  
coprocessor KDC integration project done by Naomaru Itoi at UMich  
several years back? (http://portal.acm.org/citation.cfm?id=1251315)

In this project, most of the core security work of the KDC was moved  
into a tamper-resistant coprocessor card.  In order to protect not  
just the KDC master key, but also the long-lived secret keys of users  
and services, the manipulation of various Kerberos messages, including  
such things as decoding and encoding some ASN.1 types, was pushed into  
the coprocessor, while such things as database access (with entries  
partially encrypted when outside the coprocessor card) and network  
access were left outside.  And even for systems without such  
coprocessors, the separation of functionality might be beneficial  
anyways.

The idea comes up now and then, but usually not with enough interest  
overall for it to become a priority for us.  Of course, the more  
demand there is for it, the more that can change...


-- 
Ken Raeburn, Senior Programmer
MIT Kerberos Consortium


From snambakam at likewisesoftware.com  Fri May 16 13:50:05 2008
From: snambakam at likewisesoftware.com (Sriram Nambakam)
Date: Fri, 16 May 2008 13:50:05 -0400
Subject: Question about clock skew error handling
Message-ID: <A4670A1B9F4A714DA683071F29FC5A390D383079@ms08.mse3.exchange.ms>

We would appreciate it if someone could shed more light on the right way
to handle clock skew errors from Kerberos.

 

When krb5_get_init_creds_password is called, krb5_get_in_tkt  in
get_in_tkt.c is called. That function sends the KRB5_AS_REQ and receives
the reply. Here is the code which looks at the error reply:

    if ((retval = send_as_request(context, &request, &time_now,
&err_reply,

                      &as_reply, &use_master)))

        goto cleanup;

 

    if (err_reply) {

        if (err_reply->error == KDC_ERR_PREAUTH_REQUIRED &&

            err_reply->e_data.length > 0) {

        retval = decode_krb5_padata_sequence(&err_reply->e_data,

                             &preauth_to_use);

        krb5_free_error(context, err_reply);

        if (retval)

            goto cleanup;

            continue;

        } else {

           retval = (krb5_error_code) err_reply->error  +
ERROR_TABLE_BASE_krb5;

           krb5_free_error(context, err_reply);

           goto cleanup;

        }

    } else if (!as_reply) {

 

 

If the server replies with an error that is not
KDC_ERR_PREAUTH_REQUIRED, like KRB_AP_ERR_SKEW, then the error code is
returned and the rest of the krb5_error structure is thrown away. We
would like to use the stime field of the krb5_error structure to
automatically synchronize the clock with krb5_set_real_time.

 

Is it deliberate that Krb5 does not want to let the API have access to
the real time reported in the clock skew error?

 

Is it okay to patch Krb5 to have this functionality?

 

Some of our vendors use a time service such as NTP.

Also, we provide our own time sync service, wherein we can query an
active directory domain controller to get the current time and sync the
system time appropriately. However, there are still some cases where we
get Kerberos errors with respect to clock skew.

 

Thanks

Sriram


From ss488 at cornell.edu  Fri May 16 15:36:07 2008
From: ss488 at cornell.edu (Shivakeshav Santi)
Date: Fri, 16 May 2008 15:36:07 -0400
Subject: runtime or compile time flags for debug logs on KDC
Message-ID: <6.2.1.2.2.20080516153334.04593670@postoffice10.mail.cornell.edu>

HI,

    Are there any runtime or compile time flags that I can use that will 
get me the debug logs on the KDC(krb5kdc.log). If not is modifying the 
source and recompiling the only option ?

Thank you for your time.

Thanks,


Shivakeshav Santi

Programmer Analyst/Spec

Cornell Information Technologies
120 Maple Avenue
Cornell University
Tel :6072551916(O)
       6075926806(M)
       6073302080(H)

Ability may get you to the top, but only character will keep you there .....





From raeburn at MIT.EDU  Fri May 16 17:27:03 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Fri, 16 May 2008 17:27:03 -0400
Subject: Implications of Debian OpenSSL flaw for MIT PKINIT
In-Reply-To: <87zlqra76e.fsf@windlord.stanford.edu>
References: <87fxsjd4ai.fsf@windlord.stanford.edu>
	<349BFB5D-DE79-43AC-B147-7DF8E1C0856B@mit.edu>
	<87zlqra76e.fsf@windlord.stanford.edu>
Message-ID: <DC7404AF-878F-4C07-ACEF-A829CEA246FA@mit.edu>

In some further off-list discussions with Love and Russ, it was  
pointed out that there is some risk after all in the DH key  
generation.  Russ will be sending an update to the Debian security  
folks to post.

Ken

From klausk at linux.vnet.ibm.com  Mon May 19 15:31:08 2008
From: klausk at linux.vnet.ibm.com (Klaus Heinrich Kiwi)
Date: Mon, 19 May 2008 16:31:08 -0300
Subject: realm policyreferece attribute in krb5_ldap_read_realm_params()
	function
Message-ID: <1211225468.11251.20.camel@klausk.br.ibm.com>

Hi,

 looking at the krb5_ldap_read_realm_params() function (file:
src/plugins/kdb/ldap/libkdb_ldap/ldap_realm.c), I'm trying to understand
where does the rlparams->policyreference value comes from, since it's
used in the conditional around line 1368.

I was hoping to find a query to "krbTicketPolicyReference" along with
other krbRealmContainer attributes right above this line.

>From my initial analysis, looks like if *mask doesn't bring any of the
LDAP_REALM_MAXTICKETLIFE, LDAP_REALM_MAXRENEWLIFE or
LDAP_REALM_KRBTICKETFLAGS flags, the code to query those from the policy
reference dn will always be skipped since rlparams->policyreference is
always NULL (even if there *is* a krbTicketPolicyReference attribute in
the Realm Container object).

Any comments are welcome.

 -Klaus

-- 
Klaus Heinrich Kiwi
Security Development - IBM Linux Technology Center


From jaltman at secure-endpoints.com  Tue May 20 15:04:52 2008
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Tue, 20 May 2008 15:04:52 -0400
Subject: Proposed modifications to replay cache to prevent false positives
In-Reply-To: <482539BB.6080702@secure-endpoints.com>
References: <20050602152141.C66A137010@arioch.imrryr.org>	<tslfyw04qar.fsf@cz.mit.edu>	<f47b5821c51cd65d14bbeadd9262bf1a@mit.edu>	<tslacm84kk6.fsf@cz.mit.edu>	<1ceadc2255ade945fef537f9a3959d53@mit.edu>
	<482539BB.6080702@secure-endpoints.com>
Message-ID: <483320D4.3070905@secure-endpoints.com>

Jeffrey Altman wrote:
> Please review
>   http://k5wiki.kerberos.org/wiki/Projects/replay_cache_collision_avoidance
> 
> Jeffrey Altman

Tom, Ken:

Have you had an opportunity to review the Replay Cache Collision 
Avoidance proposal that was posted?

Jeffrey Altman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20080520/9a4daf37/smime.bin

From raeburn at MIT.EDU  Tue May 20 15:30:53 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Tue, 20 May 2008 15:30:53 -0400
Subject: Proposed modifications to replay cache to prevent false positives
In-Reply-To: <482539BB.6080702@secure-endpoints.com>
References: <20050602152141.C66A137010@arioch.imrryr.org>	<tslfyw04qar.fsf@cz.mit.edu>
	<f47b5821c51cd65d14bbeadd9262bf1a@mit.edu>	<tslacm84kk6.fsf@cz.mit.edu>
	<1ceadc2255ade945fef537f9a3959d53@mit.edu>
	<482539BB.6080702@secure-endpoints.com>
Message-ID: <02EBA2F9-E936-413B-8406-0DD4F748621C@mit.edu>

(Sorry, I guess I didn't actually *finish* this email and sent it  
off...)

> variable - authenticator-hash == base64-encoded hash string with NUL  
> terminator
Plaintext or encrypted version?

> krb5_uint32 - length == 1 or (strlen(base64-encoded cleartext  
> authenticator) + 1)
> variable - NUL or base64-encoded cleartext authenticator with NUL  
> terminator

Is the authenticator optional, or are there specific reasons why it  
should be present or absent?

Storing the full authenticator concerns me.  We're talking about much  
more than doubling the size of the replay cache data.  (The base64  
encoding will expand the principal name strings by a factor of 4/3 in  
the additional copy, and that's without the overhead of all the other  
stuff in the authenticator.  And really, do we need to cache the  
number 5, the application tag, etc?)  Without the authenticator, we're  
still doubling the number of records, but at least the new records are  
likely to be around the same size or smaller.

If we've got a good hash function or HMAC, the hash value should be  
enough.

I think we could improve the performance if we eventually transition  
to a state where usually (except in cases of mixed versions or  
configurations) the records in the file all have the same fairly small  
size.  Having a small set of values in the "server" field, like only  
server principal names and hash-type numbers, could also be a way to  
reduce memory use, if that turns out to be an issue.  But without  
numbers indicating that there are real problems, actually doing that  
may be premature...

> krb5_int32 - hash-type
> krb5_timestamp - 0

Won't an old server reading this decide that this entry has expired  
and can be purged if/when the replay cache gets rewritten?

Do the hash type number assignments match number assignments we use  
anywhere else, or is this a new list?

If the authenticator isn't stored, how does the code know when the  
entry can be discarded?

> This record would be followed by the existing record consisting of  
> the client and server principal names, the time stamp and the  
> microseconds value. A complete entry therefore takes up two existing  
> records.

How is the code expected to determine from the first record that it's  
the new style, and the second record follows?  By the 0 timestamp?

Will old servers preserve the ordering (and pairing) of records in the  
rcache file?  Are the two entries actually required to be paired up?

If you put the normal timestamp back and store the hash type some  
other way, can the two records be stored (and potentially moved around  
during file rewriting) independently?

Ken

From Nicolas.Williams at sun.com  Tue May 20 16:16:24 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 20 May 2008 15:16:24 -0500
Subject: Proposed modifications to replay cache to prevent false positives
In-Reply-To: <482539BB.6080702@secure-endpoints.com>
References: <20050602152141.C66A137010@arioch.imrryr.org>
	<tslfyw04qar.fsf@cz.mit.edu>
	<f47b5821c51cd65d14bbeadd9262bf1a@mit.edu>
	<tslacm84kk6.fsf@cz.mit.edu>
	<1ceadc2255ade945fef537f9a3959d53@mit.edu>
	<482539BB.6080702@secure-endpoints.com>
Message-ID: <20080520201624.GX26388@Sun.COM>

On Sat, May 10, 2008 at 01:59:23AM -0400, Jeffrey Altman wrote:
> Please review
>   http://k5wiki.kerberos.org/wiki/Projects/replay_cache_collision_avoidance

B-trees won't help that much, and may possibly hurt.  Unless...

Will F. greatly improved the performance of the replay cache on Solaris.
The improvement was phenomenal, but fsync() is still the gating factor,
so you get even more perf by putting the rcache in a tmpfs filesystem.

Putting the rcache on tmpfs is technically a problem: any vulnerability
that can allow an attacker to panic your system will allow the attacker
to replay AP-REQs.  One solution to that is to not use protocols that
are susceptible to replay attacks (e.g., use SSHv2 instead or r-cmds).
Another is to reduce the skew time on the server to something related to
its time to boot.

I propose that in addition to whatever you do for rcache perf, we do the
following:

 - provide an option to set the server-side skew to some number of
   seconds, which in general should be estimated time to boot * 2

 - provide an option to put the rcache on tmpfs or tmpfs-like
   filesystems

With such an option then a B-tree may be useful.

An rcache implementation as a daemon reached via IPC would be even
better.

Nico
-- 

From raeburn at MIT.EDU  Tue May 20 18:33:13 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Tue, 20 May 2008 18:33:13 -0400
Subject: Proposed modifications to replay cache to prevent false positives
In-Reply-To: <20080520201624.GX26388@Sun.COM>
References: <20050602152141.C66A137010@arioch.imrryr.org>
	<tslfyw04qar.fsf@cz.mit.edu>
	<f47b5821c51cd65d14bbeadd9262bf1a@mit.edu>
	<tslacm84kk6.fsf@cz.mit.edu>
	<1ceadc2255ade945fef537f9a3959d53@mit.edu>
	<482539BB.6080702@secure-endpoints.com>
	<20080520201624.GX26388@Sun.COM>
Message-ID: <40A902FE-6807-416E-B1E8-C28C7D406383@mit.edu>

On May 20, 2008, at 16:16, Nicolas Williams wrote:
> B-trees won't help that much, and may possibly hurt.  Unless...

I think part of the intent in this project was to retain backwards  
compatibility with the existing implementation in terms of the on-disk  
format.  (E.g., mixing OS-vendor and MIT binaries without breaking  
things, when the MIT code has Jeff's shiny new replay cache and the OS- 
vendor code is based on a slightly older MIT release.)  I wouldn't see  
a problem with the introduction of a new rcache type that uses a  
different file format, though; it'd let you run the old code until you  
were sure all the implementations on the machine supported the new  
code, and then start using the new stuff.

> Will F. greatly improved the performance of the replay cache on  
> Solaris.

Not surprising; our code is horribly inefficient at doing the i/o, at  
the very least.  (I think we've also got race conditions between  
processes.)  And we could probably do something more clever with the  
in-memory version than a fixed-size hash table with a lame hash  
function.  It may also be worthwhile distinguishing and optimizing two  
different cases, the short-lived server that handles only one client  
and then exits (e.g., telnetd), versus the long-lived server that  
handles a large number of clients (e.g., slapd).

> - provide an option to set the server-side skew to some number of
>   seconds, which in general should be estimated time to boot * 2

[libdefaults]->clockskew is used (and defaults to 300s)

> - provide an option to put the rcache on tmpfs or tmpfs-like
>   filesystems

setenv KRB5RCACHEDIR /path/to/tmpfs
(or TMPDIR)

The path prefix is always used, unfortunately; you can't just make the  
pathname be part of the rcache name.  Nor can it be configured via  
krb5.conf.

> An rcache implementation as a daemon reached via IPC would be even
> better.

Yes, we've discussed it, but that's a bit more work. :)

Ken

From Nicolas.Williams at sun.com  Tue May 20 18:48:07 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 20 May 2008 17:48:07 -0500
Subject: Proposed modifications to replay cache to prevent false positives
In-Reply-To: <40A902FE-6807-416E-B1E8-C28C7D406383@mit.edu>
References: <20050602152141.C66A137010@arioch.imrryr.org>
	<tslfyw04qar.fsf@cz.mit.edu>
	<f47b5821c51cd65d14bbeadd9262bf1a@mit.edu>
	<tslacm84kk6.fsf@cz.mit.edu>
	<1ceadc2255ade945fef537f9a3959d53@mit.edu>
	<482539BB.6080702@secure-endpoints.com>
	<20080520201624.GX26388@Sun.COM>
	<40A902FE-6807-416E-B1E8-C28C7D406383@mit.edu>
Message-ID: <20080520224807.GG26388@Sun.COM>

On Tue, May 20, 2008 at 06:33:13PM -0400, Ken Raeburn wrote:
> On May 20, 2008, at 16:16, Nicolas Williams wrote:
> >B-trees won't help that much, and may possibly hurt.  Unless...
> 
> I think part of the intent in this project was to retain backwards  
> compatibility with the existing implementation in terms of the on-disk  
> format.  ...

Yes, I know, but since B-trees were mentioned I thought I'd point out
what needs to be done to make B-trees helpful, perf-wise, rather than
hurtful.

> >Will F. greatly improved the performance of the replay cache on  
> >Solaris.
> 
> Not surprising; our code is horribly inefficient at doing the i/o, at  
> the very least.  (I think we've also got race conditions between  
> processes.)  And we could probably do something more clever with the  
> in-memory version than a fixed-size hash table with a lame hash  
> function.  It may also be worthwhile distinguishing and optimizing two  
> different cases, the short-lived server that handles only one client  
> and then exits (e.g., telnetd), versus the long-lived server that  
> handles a large number of clients (e.g., slapd).

Will profiled the code and found unnecessary gettimeofday() syscalls in
the main loop and function calls in the main loop which when turned to
macros greatly reduce overhead.

> >- provide an option to set the server-side skew to some number of
> >  seconds, which in general should be estimated time to boot * 2
> 
> [libdefaults]->clockskew is used (and defaults to 300s)

Yes, yes.  I'd like that to be somewhat more automatic.  One boolean in
the config, instead of a numeric.

> >- provide an option to put the rcache on tmpfs or tmpfs-like
> >  filesystems
> 
> setenv KRB5RCACHEDIR /path/to/tmpfs
> (or TMPDIR)

Again, if you know you have clockskew set based on estimated time to
boot then you can just put the default location on tmpfs.  Of course,
that means knowing what that ought to be, but that can be a ./configure
option.

> >An rcache implementation as a daemon reached via IPC would be even
> >better.
> 
> Yes, we've discussed it, but that's a bit more work. :)

Yes, and if it must be portable...  On Solaris the best IPC for this is
doors, but that's not portable, sadly.

Nico
-- 

From elric at imrryr.org  Wed May 21 00:01:32 2008
From: elric at imrryr.org (Roland Dowdeswell)
Date: Wed, 21 May 2008 00:01:32 -0400
Subject: Proposed modifications to replay cache to prevent false positives
In-Reply-To: Your message of "Tue, 20 May 2008 15:30:53 EDT."
	<02EBA2F9-E936-413B-8406-0DD4F748621C@mit.edu> 
Message-ID: <20080521040132.7DC01373FD@arioch.imrryr.org>

On 1211311853 seconds since the Beginning of the UNIX epoch
Ken Raeburn wrote:
>

>(Sorry, I guess I didn't actually *finish* this email and sent it  
>off...)
>
>> variable - authenticator-hash == base64-encoded hash string with NUL  
>> terminator
>Plaintext or encrypted version?

I would imagine that a hash of the encrypted authenticator would
be a more useful thing to store as that is what you are attempting
to detect replays of.  It also is less likely to collide than the
plaintext of the authenticator as the encrypted authenticator:

	1.  may be encrypted with different keys if used with a
	    different ticket, and

	2.  has a randomly selected IV.

These facts would substantially reduce the likelihood that
authenticators would collide.  And, in fact, the authenticator
structure in krb5.h:

/* the unencrypted version */
typedef struct _krb5_authenticator {
    krb5_magic magic;
    krb5_principal client;              /* client name/realm */
    krb5_checksum *checksum;    /* checksum, includes type, optional */
    krb5_int32 cusec;                   /* client usec portion */
    krb5_timestamp ctime;               /* client sec portion */
    krb5_keyblock *subkey;              /* true session key, optional */
    krb5_ui_4 seq_number;               /* sequence #, optional */
    krb5_authdata **authorization_data; /* New add by Ari, auth data */ 
} krb5_authenticator; 

does not contain non-optional data which is guaranteed or even
incredibly likely[1] to be different between authenticators.

The IV/key combination however is quite likely to be different
between authenticators especially in conjunction with the other
data.  Even with a 64 bit block size, the infrequent but persistent
replay collisions which I see in the field would not occur if the
randomly selected IVs are chosen with a PRNG which doesn't bzero()
out its internal state to silence unitialised variable warnings.

Using the ciphertext of the authenticator also seems more elegant
to me as that is the actual data which would be replayed to the
server.

[1]	I've certainly seen time collisions in practice and everything
	else that might be randomly generated is marked as optional.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/

From elric at imrryr.org  Wed May 21 01:00:29 2008
From: elric at imrryr.org (Roland Dowdeswell)
Date: Wed, 21 May 2008 01:00:29 -0400
Subject: flags for allowing tix
Message-ID: <20080521050029.509EC373FD@arioch.imrryr.org>

I've noticed that in the MIT kdc there are a number of flags for
enabling and disabling the issuance of tickets in various circumstances.
My thoughts on the topic began when I decided that I'd like a flag
on a principal to disable AS_REQs _from_ that princ.  This would
make sense if you know that a principal will solely be used as a
service and would never AS_REQ.

I had a quick look at the flags defined for these requests supported
by the MIT kdc and it seems that their definitions are not terribly
orthogonal which strikes me as being a tad inelegant.  For example,
-allow_tix will disable tickets to and from a principal.  -allow_svr
will disallow TGS_REQs or AS_REQs to a principal.  -allow_tgs_req
disallows TGS_REQs to a principal.

-allow_tgs_req is contained in -allow_svr which is contained in
-allow_tix.

		AS_REQ	from	for	TGS_REQ	from	for
allow_tix		x	x			x
allow_tgs_req						x
allow_svr			x			x

Or something close to it is the current state.

Maybe it would make sense to come up with a more expressive syntax
which allows any possible combination and regards the existing
flags as synonyms for groups of flags?

Or perhaps just add -allow_as_req_from which would turn off AS_REQs
from the principal in question?

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/

From tlyu at MIT.EDU  Wed May 21 01:18:21 2008
From: tlyu at MIT.EDU (Tom Yu)
Date: Wed, 21 May 2008 01:18:21 -0400
Subject: flags for allowing tix
In-Reply-To: <20080521050029.509EC373FD@arioch.imrryr.org> (Roland
	Dowdeswell's message of "Wed, 21 May 2008 01:00:29 -0400")
References: <20080521050029.509EC373FD@arioch.imrryr.org>
Message-ID: <ldvve18z142.fsf@cathode-dark-space.mit.edu>

Roland Dowdeswell <elric at imrryr.org> writes:

> I've noticed that in the MIT kdc there are a number of flags for
> enabling and disabling the issuance of tickets in various circumstances.
> My thoughts on the topic began when I decided that I'd like a flag
> on a principal to disable AS_REQs _from_ that princ.  This would
> make sense if you know that a principal will solely be used as a
> service and would never AS_REQ.

Could you please elaborate on the situations where you might want to
impose this restriction on a (service) principal?  Keep in mind that
the principal will not be able to change its own key as long as that
flag is set.

I will grant that the non-orthogonality of the flags looks inelegant.
I also think that any attempt to make this set of flags more
orthogonal should also consider requests for user-to-user tickets.

From elric at imrryr.org  Wed May 21 11:59:30 2008
From: elric at imrryr.org (Roland Dowdeswell)
Date: Wed, 21 May 2008 11:59:30 -0400
Subject: flags for allowing tix 
In-Reply-To: Your message of "Wed, 21 May 2008 01:18:21 EDT."
	<ldvve18z142.fsf@cathode-dark-space.mit.edu> 
Message-ID: <20080521155930.CE55537098@arioch.imrryr.org>

On 1211347101 seconds since the Beginning of the UNIX epoch
Tom Yu wrote:
>

>Roland Dowdeswell <elric at imrryr.org> writes:
>
>> I've noticed that in the MIT kdc there are a number of flags for
>> enabling and disabling the issuance of tickets in various circumstances.
>> My thoughts on the topic began when I decided that I'd like a flag
>> on a principal to disable AS_REQs _from_ that princ.  This would
>> make sense if you know that a principal will solely be used as a
>> service and would never AS_REQ.
>
>Could you please elaborate on the situations where you might want to
>impose this restriction on a (service) principal?  Keep in mind that
>the principal will not be able to change its own key as long as that
>flag is set.

We do not let services manage their own keys.  We have an infrastructure
in place to do this for us.

I would like to impose this restriction to improve security and
control the environment in a more granular fashion.  That is, if
I know in advance that a service will not be making AS_REQs then
it seems that it would be good form to prevent it.  I have seen
badly Kerberised applications such as uw-imap which blindly chop
realms off Kerberos principals in order to compare them to usernames.
I can easily imagine that some applications might just chop the
instance off as well.  Granted, these applications should be fixed.
But I would also like to be able to reduce the exposure by ensuring
that tickets are not granted if they are not required.

>I will grant that the non-orthogonality of the flags looks inelegant.
>I also think that any attempt to make this set of flags more
>orthogonal should also consider requests for user-to-user tickets.

Yes.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/

From hotz at jpl.nasa.gov  Wed May 21 23:41:01 2008
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Wed, 21 May 2008 23:41:01 -0400
Subject: Proposed modifications to replay cache to prevent false positives
In-Reply-To: <mailman.148116.1211342532.4386.krbdev@mit.edu>
References: <mailman.148116.1211342532.4386.krbdev@mit.edu>
Message-ID: <CC490EF6-4514-42BC-BB3D-340B1715F7F2@jpl.nasa.gov>


On May 21, 2008, at 12:02 AM, krbdev-request at mit.edu wrote:

> I think part of the intent in this project was to retain backwards
> compatibility with the existing implementation in terms of the on-disk
> format.  (E.g., mixing OS-vendor and MIT binaries without breaking
> things, when the MIT code has Jeff's shiny new replay cache and the  
> OS-
> vendor code is based on a slightly older MIT release.)  I wouldn't see
> a problem with the introduction of a new rcache type that uses a
> different file format, though; it'd let you run the old code until you
> were sure all the implementations on the machine supported the new
> code, and then start using the new stuff.

Is there a real example where this is useful?  I can't, for example,  
imagine multiple web servers on a machine where they didn't all use  
the same build.  (Well, OK, I can imagine that they might run on  
different ports and be optimized differently enough to wind up with  
different kerb libs, but I would treat this as an unsupported corner  
case.  Just make the name convention different enough that they don't  
damage each other.)

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu




From tlyu at MIT.EDU  Wed May 21 23:42:33 2008
From: tlyu at MIT.EDU (Tom Yu)
Date: Wed, 21 May 2008 23:42:33 -0400
Subject: Fwd: Bug#480434: libkrb53: Delegation fails if an SPNEGO
	credential is passed to gss_krb5_copy_ccache
In-Reply-To: <87bq3do6da.fsf@windlord.stanford.edu> (Russ Allbery's message of
	"Sat, 10 May 2008 20:40:49 -0700")
References: <87mymzq9v3.fsf@windlord.stanford.edu>
	<87abizq91m.fsf@windlord.stanford.edu>
	<87bq3do6da.fsf@windlord.stanford.edu>
Message-ID: <ldvabijroly.fsf@cathode-dark-space.mit.edu>

Russ Allbery <rra at stanford.edu> writes:

> Russ Allbery <rra at stanford.edu> writes:
>> Russ Allbery <rra at stanford.edu> writes:
>
>>> Another patch that looks right, but for which I'd like to get a review
>>> before I go ahead with it (and again, I can commit this directly to the
>>> MIT tree as well if approved).
>
>>> Let me know if I should file these as bugs first, instead of creating a
>>> ticket on commit after approval here.
>
>> http://bugs.debian.org/480434
>
> This is #5807.  The Debian bug has a slightly different fix; I don't know
> which one is better from a coding style perspective.

They are very similar.  I am slightly inclined to go with the Debian
patch, but I don't think it's that important.

We should note that this is an interim solution and that we should
have a better way of dealing with the general problem of "unwrapping"
objects produced by pseudo-mechanisms.

Does anyone have strong opinions on which patch is best?

From Nicolas.Williams at sun.com  Thu May 22 00:06:30 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 21 May 2008 23:06:30 -0500
Subject: Proposed modifications to replay cache to prevent false positives
In-Reply-To: <CC490EF6-4514-42BC-BB3D-340B1715F7F2@jpl.nasa.gov>
References: <mailman.148116.1211342532.4386.krbdev@mit.edu>
	<CC490EF6-4514-42BC-BB3D-340B1715F7F2@jpl.nasa.gov>
Message-ID: <20080522040630.GD26388@Sun.COM>

On Wed, May 21, 2008 at 11:41:01PM -0400, Henry B. Hotz wrote:
> On May 21, 2008, at 12:02 AM, krbdev-request at mit.edu wrote:
> > I think part of the intent in this project was to retain backwards
> > compatibility with the existing implementation in terms of the on-disk
> > format.  (E.g., mixing OS-vendor and MIT binaries without breaking
> > ...
> 
> Is there a real example where this is useful?  I can't, for example,  
> imagine multiple web servers on a machine where they didn't all use  
> the same build.  (Well, OK, I can imagine that they might run on  
> different ports and be optimized differently enough to wind up with  
> different kerb libs, but I would treat this as an unsupported corner  
> case.  Just make the name convention different enough that they don't  
> damage each other.)

In the case of ccache format there is a real use for this: JGSS plus
whatever the OS's native implementation of Kerberos V is.  This happens
a lot.

But for rcache I'm not sure that file format backwards compatibility
matters that much.  Yes, if you're using one app built w/ MIT krb5 and
another built with Solaris krb5, both accepting contexts with the same
service principal, then you have a problem.

As with ccache format, a version number that is configurable through
krb5.conf can solve the problem... at the expense of bloat.

Nico
-- 

From Nicolas.Williams at sun.com  Thu May 22 00:16:44 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 21 May 2008 23:16:44 -0500
Subject: Proposed modifications to replay cache to prevent false positives
In-Reply-To: <20080522040630.GD26388@Sun.COM>
References: <mailman.148116.1211342532.4386.krbdev@mit.edu>
	<CC490EF6-4514-42BC-BB3D-340B1715F7F2@jpl.nasa.gov>
	<20080522040630.GD26388@Sun.COM>
Message-ID: <20080522041644.GU13526@Sun.COM>

I should add that I doubt that mixing of server krb5 implementations
sharing one principal happens much.

Also, Heimdal has a different rcache format.  So, I suspect there's no
real need to be backwards compatible with rcache file formats, but then,
to be conservative we can just retain an option for compat.

From elric at imrryr.org  Thu May 22 03:03:09 2008
From: elric at imrryr.org (Roland Dowdeswell)
Date: Thu, 22 May 2008 03:03:09 -0400
Subject: Proposed modifications to replay cache to prevent false positives
In-Reply-To: Your message of "Wed, 21 May 2008 23:16:44 CDT."
	<20080522041644.GU13526@Sun.COM> 
Message-ID: <20080522070309.3F529373FD@arioch.imrryr.org>

On 1211429804 seconds since the Beginning of the UNIX epoch
Nicolas Williams wrote:
>

>I should add that I doubt that mixing of server krb5 implementations
>sharing one principal happens much.
>
>Also, Heimdal has a different rcache format.  So, I suspect there's no
>real need to be backwards compatible with rcache file formats, but then,
>to be conservative we can just retain an option for compat.

At work, I certainly share rcaches between different krb5
implementations on, I think, at least over 20K machines.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/

From rsavitha at novell.com  Thu May 22 06:15:01 2008
From: rsavitha at novell.com (Savitha R)
Date: Thu, 22 May 2008 04:15:01 -0600
Subject: realm policyreferece attribute in
	krb5_ldap_read_realm_params()function
In-Reply-To: <1211225468.11251.20.camel@klausk.br.ibm.com>
References: <1211225468.11251.20.camel@klausk.br.ibm.com>
Message-ID: <483594FD.C217.0053.0@novell.com>

The current implementation does not make use of the policy reference at 
the realm object level. If you look at kdb5_ldap_util, it does not provide an 
option for you to set this attribute. The code to read the policy object in 
krb5_ldap_read_realm_params() never gets executed.

We had initially thought of supporting the policy reference at the realm level.
But later felt that it is sufficient to go with the attributes directly on the realm
object since we dont expect too many realm objects and configuring it directly 
on the realm wouldn't be an issue.

-Savitha

>>> On Tue, May 20, 2008 at  1:01 AM, in message
<1211225468.11251.20.camel at klausk.br.ibm.com>, Klaus Heinrich Kiwi
<klausk at linux.vnet.ibm.com> wrote: 
> Hi,
> 
>  looking at the krb5_ldap_read_realm_params() function (file:
> src/plugins/kdb/ldap/libkdb_ldap/ldap_realm.c), I'm trying to understand
> where does the rlparams->policyreference value comes from, since it's
> used in the conditional around line 1368.
> 
> I was hoping to find a query to "krbTicketPolicyReference" along with
> other krbRealmContainer attributes right above this line.
> 
>>From my initial analysis, looks like if *mask doesn't bring any of the
> LDAP_REALM_MAXTICKETLIFE, LDAP_REALM_MAXRENEWLIFE or
> LDAP_REALM_KRBTICKETFLAGS flags, the code to query those from the policy
> reference dn will always be skipped since rlparams->policyreference is
> always NULL (even if there *is* a krbTicketPolicyReference attribute in
> the Realm Container object).
> 
> Any comments are welcome.
> 
>  -Klaus





From William.Fiveash at sun.com  Thu May 22 13:45:44 2008
From: William.Fiveash at sun.com (Will Fiveash)
Date: Thu, 22 May 2008 12:45:44 -0500
Subject: Proposed modifications to replay cache to prevent false positives
In-Reply-To: <20080522070309.3F529373FD@arioch.imrryr.org>
References: <20080522041644.GU13526@Sun.COM>
	<20080522070309.3F529373FD@arioch.imrryr.org>
Message-ID: <20080522174544.GB19978@sun.com>

On Thu, May 22, 2008 at 03:03:09AM -0400, Roland Dowdeswell wrote:
> On 1211429804 seconds since the Beginning of the UNIX epoch
> Nicolas Williams wrote:
> >
> 
> >I should add that I doubt that mixing of server krb5 implementations
> >sharing one principal happens much.
> >
> >Also, Heimdal has a different rcache format.  So, I suspect there's no
> >real need to be backwards compatible with rcache file formats, but then,
> >to be conservative we can just retain an option for compat.
> 
> At work, I certainly share rcaches between different krb5
> implementations on, I think, at least over 20K machines.

This seems risky to me if I understand the above.  Note that the default
location for rcaches in Solaris is under /var/krb5/rcache which may
differ from other krb implementations.  If one is running services using
krb auth with differing krb implementations but using a common service
principal care should be taken to configure the various krb flavors to
use a common rcache (assuming they all support the same rcache format).
Otherwise a replay attack is possible if the services are using
different rcaches for the same service principal.

-- 
Will Fiveash
Sun Microsystems Inc.
http://opensolaris.org/os/project/kerberos/

From raeburn at MIT.EDU  Thu May 22 14:48:44 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Thu, 22 May 2008 14:48:44 -0400
Subject: Proposed modifications to replay cache to prevent false positives
In-Reply-To: <20080520224807.GG26388@Sun.COM>
References: <20050602152141.C66A137010@arioch.imrryr.org>
	<tslfyw04qar.fsf@cz.mit.edu>
	<f47b5821c51cd65d14bbeadd9262bf1a@mit.edu>
	<tslacm84kk6.fsf@cz.mit.edu>
	<1ceadc2255ade945fef537f9a3959d53@mit.edu>
	<482539BB.6080702@secure-endpoints.com>
	<20080520201624.GX26388@Sun.COM>
	<40A902FE-6807-416E-B1E8-C28C7D406383@mit.edu>
	<20080520224807.GG26388@Sun.COM>
Message-ID: <F6F16624-2446-4DFE-ABCE-7E526029D6D6@MIT.EDU>

On May 20, 2008, at 18:48, Nicolas Williams wrote:
> Will profiled the code and found unnecessary gettimeofday() syscalls  
> in
> the main loop

Are we talking about something along the lines of http://isda-maven1.mit.edu:8060/changelog/krb5/?cs=15799 
  or something on top of that?

> and function calls in the main loop which when turned to
> macros greatly reduce overhead.

I'm inclined to say that an optimizing compiler should just DTRT.   
Though in our default configuration, the configure script wouldn't  
normally turn on optimization for Sun's compiler...  (Historically,  
some compilers have had trouble with using both -g and -O, and so  
autoconf normally gives you just -g if you're not using gcc.)

If it's still a problem, we can look at making functions explicitly  
inline, or converting them to macros.  But we should confirm that it's  
(still) a problem, first.

>>> - provide an option to set the server-side skew to some number of
>>> seconds, which in general should be estimated time to boot * 2
>>
>> [libdefaults]->clockskew is used (and defaults to 300s)
>
> Yes, yes.  I'd like that to be somewhat more automatic.  One boolean  
> in
> the config, instead of a numeric.

And the Kerberos library should magically know how long it takes the  
machine to boot, and use that value?  That's going to vary a lot  
depending on operating system, cpu, file system configuration, etc.

Ken

From Nicolas.Williams at sun.com  Thu May 22 15:31:43 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 22 May 2008 14:31:43 -0500
Subject: Proposed modifications to replay cache to prevent false positives
In-Reply-To: <F6F16624-2446-4DFE-ABCE-7E526029D6D6@MIT.EDU>
References: <20050602152141.C66A137010@arioch.imrryr.org>
	<tslfyw04qar.fsf@cz.mit.edu>
	<f47b5821c51cd65d14bbeadd9262bf1a@mit.edu>
	<tslacm84kk6.fsf@cz.mit.edu>
	<1ceadc2255ade945fef537f9a3959d53@mit.edu>
	<482539BB.6080702@secure-endpoints.com>
	<20080520201624.GX26388@Sun.COM>
	<40A902FE-6807-416E-B1E8-C28C7D406383@mit.edu>
	<20080520224807.GG26388@Sun.COM>
	<F6F16624-2446-4DFE-ABCE-7E526029D6D6@MIT.EDU>
Message-ID: <20080522193143.GM26388@Sun.COM>

On Thu, May 22, 2008 at 02:48:44PM -0400, Ken Raeburn wrote:
> On May 20, 2008, at 18:48, Nicolas Williams wrote:
> >Will profiled the code and found unnecessary gettimeofday() syscalls  
> >in
> >the main loop
> 
> Are we talking about something along the lines of 
> http://isda-maven1.mit.edu:8060/changelog/krb5/?cs=15799 or something on 
>  top of that?

Something like that.  I'll have to compare that to our code, but I can't
today.

> >and function calls in the main loop which when turned to
> >macros greatly reduce overhead.
> 
> I'm inclined to say that an optimizing compiler should just DTRT.   

Sure, but several years ago Sun Studio wasn't doing it.

> Though in our default configuration, the configure script wouldn't  
> normally turn on optimization for Sun's compiler...  (Historically,  
> some compilers have had trouble with using both -g and -O, and so  
> autoconf normally gives you just -g if you're not using gcc.)
> 
> If it's still a problem, we can look at making functions explicitly  
> inline, or converting them to macros.  But we should confirm that it's  
> (still) a problem, first.

OK.

> >>>- provide an option to set the server-side skew to some number of
> >>>seconds, which in general should be estimated time to boot * 2
> >>
> >>[libdefaults]->clockskew is used (and defaults to 300s)
> >
> >Yes, yes.  I'd like that to be somewhat more automatic.  One boolean  
> >in
> >the config, instead of a numeric.
> 
> And the Kerberos library should magically know how long it takes the  
> machine to boot, and use that value?  That's going to vary a lot  
> depending on operating system, cpu, file system configuration, etc.

Yes.  I know.  I said "estimated" because the kernel can only tell you
how long it took to get to multi-user-server runlevel from the point
where it could start keeping time; the kernel can't tell you how long it
took the previous boot phases to complete (POST, BIOS, boot loaders,
...).

From Nicolas.Williams at sun.com  Thu May 22 15:32:45 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 22 May 2008 14:32:45 -0500
Subject: Proposed modifications to replay cache to prevent false positives
In-Reply-To: <20080522070309.3F529373FD@arioch.imrryr.org>
References: <20080522041644.GU13526@Sun.COM>
	<20080522070309.3F529373FD@arioch.imrryr.org>
Message-ID: <20080522193245.GN26388@Sun.COM>

On Thu, May 22, 2008 at 03:03:09AM -0400, Roland Dowdeswell wrote:
> At work, I certainly share rcaches between different krb5
> implementations on, I think, at least over 20K machines.

OK, this is *very* good to know.  A requirement then is to have at least
an option for backwards compat.

From mohamed.chaari at orange-ftgroup.com  Fri May 23 06:27:24 2008
From: mohamed.chaari at orange-ftgroup.com (mohamed.chaari@orange-ftgroup.com)
Date: Fri, 23 May 2008 12:27:24 +0200
Subject: IAKERB
Message-ID: <BAF83494CE653943A97B9F755016A0660614B132@ftrdmel1>

Hello,

I'm working in a project using kerberos.
In a draft, I have read that I must use IAKERB as a proxy for ad-hoc
networks, but I dont know how to use it. Is there a specific proxy that
I had to install or there is no preference between proxies?

Thanks,

Regards,
Mohamed.

From jaltman at secure-endpoints.com  Tue May 27 21:49:51 2008
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Tue, 27 May 2008 21:49:51 -0400
Subject: Fwd: [modauthkerb] [SOLVED] 'Request is a replay' + Basic auth
In-Reply-To: <BB181937-C78F-4AB9-88C7-2699C040FFE7@jpl.nasa.gov>
References: <87irc8urzs.fsf@kosh.bigo.ensc.de>
	<BB181937-C78F-4AB9-88C7-2699C040FFE7@jpl.nasa.gov>
Message-ID: <483CBA3F.2040807@secure-endpoints.com>

Hank:

Thanks for this.   The analysis is slightly wrong but the end result
is correct.   The 'authtime' value has one second accuracy.  As a result
when it is used as input to krb5_set_real_time() which has microsecond
accuracy the current microseconds value from the system clock is rounded
off.  The end result is an increased likelihood that there will be
collisions.

krb5_set_real_time() is only called from within verify_as_reply() as is
therefore only used with input values with one second accuracy.  I believe
the correct fix is to modify krb5_set_real_time() to ignore the 
microseconds
input value. 

Jeffrey Altman

bcc: krb5-bugs

Henry B. Hotz wrote:
> Hope this is of some use.
>
> Begin forwarded message:
>
>> From: Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de>
>> Date: April 7, 2007 11:24:55 AM EDT
>> To: modauthkerb-help at lists.sourceforge.net
>> Subject: [modauthkerb] [SOLVED] 'Request is a replay' + Basic auth
>>
>> Hello,
>>
>> I had a longstanding problem that mod_auth_kerb failed with
>>
>> | Request is a replay
>>
>> when doing Basic Auth and making lot of requests (e.g. SVN, webpages
>> with much images).
>>
>> The problem was the setting of
>>
>> | [defaults]
>> |    kdc_timesync         = 1
>>
>> in /etc/krb5.conf. Turning it off seems to make things work fine.
>>
>>
>> Explanation: The option above is used to correct timestamps of tickets.
>> Unfortunately, MIT KRB5 (1.4 - 1.6) uses a precision of one second for
>> this calibration[1] while the system time (which is e.g. used for 
>> creating
>> tickets) uses a precision of microseconds.
>>
>> Now, the following happens:
>>
>> 1. Client verifies KDC
>>
>> 2. Client receives an authtime reply from the KDC
>>
>>   Time in reply  might be 1175958621 seconds
>>   Time at client might be 1175958621 seconds and 900000 microseconds
>>
>> 3. Client will now use corrected times by subtracting 900000 
>> microseconds
>>   from the system time
>>
>> 4. 100 microseconds later, the client requests the ticket
>>
>>   Time at client is now       1175958621 seconds and 900100 microseconds
>>   Corrected time in ticket is 1175958621 seconds and    100 microseconds
>>
>> 5. The same steps happens in e.g. 10 other threads. Since time between
>>   2. and 4. will be nearly constant (same code will be executed), it is
>>   very likely that two tickets with the same timestamp will be 
>> requested.
>>
>>   This results into the 'Request is a replay' error.
>>
>>
>>   Turning off the time calibration ensures that ticket time is different
>>   for all threads (scheduling needs more than 1 us for task switching
>>   and krb5 tries to handle this too).
>>
>>
>>
>> Enrico
>>
>> Footnotes:
>> [1] See lib/krb5/krb/get_in_tkt.c which makes
>>    | krb5_set_real_time(context,
>>    |                    as_reply->enc_part2->times.authtime, 0);
>>                         ~~~~~~~~~~~~ seconds ~~~~~~~~~~~~~~ ~us~
>>
>> ------------------------------------------------------------------------- 
>>
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to 
>> share your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________ 
>>
>> modauthkerb-help mailing list
>> modauthkerb-help at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/modauthkerb-help
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20080527/a68aa0de/smime.bin

From GMachin at sandia.gov  Thu May 29 15:38:05 2008
From: GMachin at sandia.gov (Machin, Glenn D)
Date: Thu, 29 May 2008 13:38:05 -0600
Subject: GSSAPI - context lifetime
Message-ID: <9C71AD778A20DC47A9A1F89BFDD2C83B2367E2B0E5@ES05SNLNT.srn.sandia.gov>

I apologize if this is not the right forum for this question.

The gss_wrap and seal routines are dependent on the context endtime. The context endtime is derived from the service ticket lifetime. For a gssftp session if multiple data transfers exceed the ticket lifetime the gssftp session fails.

Can someone tell me why the context is tied to ticket lifetime?

Could we change the endtime to indefinite by specifying GSS_C_INDEFINITE for
time_req on the init_sec_context() and on the server by specifying a NULL for time_rec on the accept_sec_context()?




Glenn




From rra at stanford.edu  Thu May 29 17:23:09 2008
From: rra at stanford.edu (Russ Allbery)
Date: Thu, 29 May 2008 14:23:09 -0700
Subject: GSSAPI - context lifetime
In-Reply-To: <9C71AD778A20DC47A9A1F89BFDD2C83B2367E2B0E5@ES05SNLNT.srn.sandia.gov>
	(Glenn D. Machin's message of "Thu\,
	29 May 2008 13\:38\:05 -0600")
References: <9C71AD778A20DC47A9A1F89BFDD2C83B2367E2B0E5@ES05SNLNT.srn.sandia.gov>
Message-ID: <87k5hcls8y.fsf@windlord.stanford.edu>

"Machin, Glenn D" <GMachin at sandia.gov> writes:

> I apologize if this is not the right forum for this question.
>
> The gss_wrap and seal routines are dependent on the context endtime. The
> context endtime is derived from the service ticket lifetime. For a
> gssftp session if multiple data transfers exceed the ticket lifetime the
> gssftp session fails.
>
> Can someone tell me why the context is tied to ticket lifetime?

Because all products of a Kerberos authentication should be tied to a
ticket lifetime.  Otherwise, the ticket lifetime isn't meaningfully
enforced; someone who obtains a ticket at some point could authenticate to
a service and simply stay authenticated, and there would be no good way of
rejecting their later operations.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

From jaltman at secure-endpoints.com  Thu May 29 17:35:20 2008
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Thu, 29 May 2008 17:35:20 -0400
Subject: GSSAPI - context lifetime
In-Reply-To: <87k5hcls8y.fsf@windlord.stanford.edu>
References: <9C71AD778A20DC47A9A1F89BFDD2C83B2367E2B0E5@ES05SNLNT.srn.sandia.gov>
	<87k5hcls8y.fsf@windlord.stanford.edu>
Message-ID: <483F2198.30602@secure-endpoints.com>

Russ Allbery wrote:
> "Machin, Glenn D" <GMachin at sandia.gov> writes:
> 
>> I apologize if this is not the right forum for this question.
>>
>> The gss_wrap and seal routines are dependent on the context endtime. The
>> context endtime is derived from the service ticket lifetime. For a
>> gssftp session if multiple data transfers exceed the ticket lifetime the
>> gssftp session fails.
>>
>> Can someone tell me why the context is tied to ticket lifetime?
> 
> Because all products of a Kerberos authentication should be tied to a
> ticket lifetime.  Otherwise, the ticket lifetime isn't meaningfully
> enforced; someone who obtains a ticket at some point could authenticate to
> a service and simply stay authenticated, and there would be no good way of
> rejecting their later operations.

While I understand the rationale for this decision I disagree with it.
We do not expect an SSH, Telnet or console logon session to be dropped 
when the Kerberos session ticket used to perform the authentication 
expires.

I suspect the real reason that the GSSAPI context is forced to expire in 
sync with the kerberos ticket is because someone decided that the 
kerberos ticket session key should not be used beyond the ticket 
lifetime because it might not be strong enough.

If a service wants to force new authentications after some period of 
time that is perfectly reasonable.  However, I do not believe it is 
appropriate for the GSS-API to force periodic and arbitrary 
authentications on all protocols that happen to make use of GSSAPI
with a Kerberos v5 mechanism.

I would very much like to see this restriction removed.

Jeffrey Altman
Secure Endpoints Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20080529/d5f35a71/smime.bin

From Nicolas.Williams at sun.com  Thu May 29 17:45:22 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 29 May 2008 16:45:22 -0500
Subject: GSSAPI - context lifetime
In-Reply-To: <87k5hcls8y.fsf@windlord.stanford.edu>
References: <9C71AD778A20DC47A9A1F89BFDD2C83B2367E2B0E5@ES05SNLNT.srn.sandia.gov>
	<87k5hcls8y.fsf@windlord.stanford.edu>
Message-ID: <20080529214522.GL2735@Sun.COM>

On Thu, May 29, 2008 at 02:23:09PM -0700, Russ Allbery wrote:
> "Machin, Glenn D" <GMachin at sandia.gov> writes:
> 
> > I apologize if this is not the right forum for this question.
> >
> > The gss_wrap and seal routines are dependent on the context endtime. The
> > context endtime is derived from the service ticket lifetime. For a
> > gssftp session if multiple data transfers exceed the ticket lifetime the
> > gssftp session fails.
> >
> > Can someone tell me why the context is tied to ticket lifetime?
> 
> Because all products of a Kerberos authentication should be tied to a
> ticket lifetime.  Otherwise, the ticket lifetime isn't meaningfully
> enforced; someone who obtains a ticket at some point could authenticate to
> a service and simply stay authenticated, and there would be no good way of
> rejecting their later operations.

You'd think.  And I agree.

But this actually cause problems for SASL/GSSAPI (and probably, come to
think of it, SASL/GS2) applications.  This includes IMAP, a very popular
protocol whose clients don't always make re-connecting totally
transparent.

Specifically:

 - SASL has no way to re-do authentication, nor even to send an error
   message saying "your context has expired," nor do SASL apps tend to
   have a way to resume a broken session.

 - To be pedantic security contexts expire not only when the tickets do,
   but when the keys have been used too much or too long.  But for some
   enctypes "too much" isn't all that much, which can lead to context
   expiration prior to ticket expiration, which means you can't just get
   very long-lived tickets to work-around the SASL issue unless you're
   getting AES tickets (which by now is probably no big deal).

   Of course, issuing long-lived service tickets is a bad idea since
   there's no revocation protocol.

Nico
-- 

From Nicolas.Williams at sun.com  Thu May 29 17:49:49 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 29 May 2008 16:49:49 -0500
Subject: GSSAPI - context lifetime
In-Reply-To: <483F2198.30602@secure-endpoints.com>
References: <9C71AD778A20DC47A9A1F89BFDD2C83B2367E2B0E5@ES05SNLNT.srn.sandia.gov>
	<87k5hcls8y.fsf@windlord.stanford.edu>
	<483F2198.30602@secure-endpoints.com>
Message-ID: <20080529214949.GN2735@Sun.COM>

On Thu, May 29, 2008 at 05:35:20PM -0400, Jeffrey Altman wrote:
> If a service wants to force new authentications after some period of 
> time that is perfectly reasonable.  However, I do not believe it is 
> appropriate for the GSS-API to force periodic and arbitrary 
> authentications on all protocols that happen to make use of GSSAPI
> with a Kerberos v5 mechanism.
> 
> I would very much like to see this restriction removed.

I agree.  Ideally GSS_S_CONTEXT_EXPIRED should be seen as an advisory
major status code, or even as a minor status code to go with
GSS_S_COMPLETE.  I.e., gss_get_mic() should succeed but still tell you
that the context expired.  This would be particularly useful in the
context of overused keys.

I agree: the app should be in charge of deciding whether the context
expiration is relevant.  But that doesn't mean that apps that would want
to drop connections when tickets expire do so explicitly, and making
this change might break them (but I don't mind doing so).

Nico
-- 

From Nicolas.Williams at sun.com  Thu May 29 17:50:29 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 29 May 2008 16:50:29 -0500
Subject: GSSAPI - context lifetime
In-Reply-To: <20080529214522.GL2735@Sun.COM>
References: <9C71AD778A20DC47A9A1F89BFDD2C83B2367E2B0E5@ES05SNLNT.srn.sandia.gov>
	<87k5hcls8y.fsf@windlord.stanford.edu>
	<20080529214522.GL2735@Sun.COM>
Message-ID: <20080529215028.GC2734@Sun.COM>

On Thu, May 29, 2008 at 04:45:22PM -0500, Nicolas Williams wrote:
> On Thu, May 29, 2008 at 02:23:09PM -0700, Russ Allbery wrote:
> > Because all products of a Kerberos authentication should be tied to a
> > ticket lifetime.  Otherwise, the ticket lifetime isn't meaningfully
> > enforced; someone who obtains a ticket at some point could authenticate to
> > a service and simply stay authenticated, and there would be no good way of
> > rejecting their later operations.
> 
> You'd think.  And I agree.

Well, I just disagreed with me.

From deengert at anl.gov  Thu May 29 17:55:35 2008
From: deengert at anl.gov (Douglas E. Engert)
Date: Thu, 29 May 2008 16:55:35 -0500
Subject: GSSAPI - context lifetime
In-Reply-To: <87k5hcls8y.fsf@windlord.stanford.edu>
References: <9C71AD778A20DC47A9A1F89BFDD2C83B2367E2B0E5@ES05SNLNT.srn.sandia.gov>
	<87k5hcls8y.fsf@windlord.stanford.edu>
Message-ID: <483F2657.8010005@anl.gov>



Russ Allbery wrote:
> "Machin, Glenn D" <GMachin at sandia.gov> writes:
> 
>> I apologize if this is not the right forum for this question.
>>
>> The gss_wrap and seal routines are dependent on the context endtime. The
>> context endtime is derived from the service ticket lifetime. For a
>> gssftp session if multiple data transfers exceed the ticket lifetime the
>> gssftp session fails.
>>
>> Can someone tell me why the context is tied to ticket lifetime?
> 
> Because all products of a Kerberos authentication should be tied to a
> ticket lifetime.  Otherwise, the ticket lifetime isn't meaningfully
> enforced; someone who obtains a ticket at some point could authenticate to
> a service and simply stay authenticated, and there would be no good way of
> rejecting their later operations.

Rsh and rlogin with Kerberos have no time limit on their connection. SSH has
no time limit on its connection, even when authenticating using GSS.

Sessions using certificates, passwords or other authentications don't
have timeouts.

I would argue: It should be a policy decision of the service as to the
length of a session. The ticket lifetime *COULD* be used in the decision,
but it should not be forced by the GSSAPI, unless requested by the service
or client.

> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

From hartmans at MIT.EDU  Thu May 29 22:04:40 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Thu, 29 May 2008 22:04:40 -0400 (EDT)
Subject: build problam with 1.6.4 beta1
Message-ID: <20080530020440.E611CA6C01E@luminous.suchdamage.org>



I'm having trouble getting the debian package to configure on 1.6.4
beta1.  The debian build scripts run configure as follows:

cd build && ../src/configure CFLAGS="-g  -O2 -D_REENTRANT" \
                --prefix=/usr --localstatedir=/etc --mandir=/usr/share/man \
                --with-system-et --with-system-ss --enable-fakeka \
                --enable-shared --with-ldap --without-tcl \
                --build i486-linux-gnu


Things work fine until it gets to running configure in pkinit.  Then
it complains that the definition of CFLAGS in the cache differs from
the definition on the command line and that I need to run distclean.
It seems that the one of the CFLAGS values is being prepended with an
extra space.

I am still trying to track down why this is the case.

From tlyu at MIT.EDU  Thu May 29 23:03:22 2008
From: tlyu at MIT.EDU (Tom Yu)
Date: Thu, 29 May 2008 23:03:22 -0400
Subject: build problam with 1.6.4 beta1
In-Reply-To: <20080530020440.E611CA6C01E@luminous.suchdamage.org> (Sam
	Hartman's message of "Thu, 29 May 2008 22:04:40 -0400 (EDT)")
References: <20080530020440.E611CA6C01E@luminous.suchdamage.org>
Message-ID: <ldv1w3kmr2d.fsf@cathode-dark-space.mit.edu>

hartmans at MIT.EDU (Sam Hartman) writes:

> I'm having trouble getting the debian package to configure on 1.6.4
> beta1.  The debian build scripts run configure as follows:
>
> cd build && ../src/configure CFLAGS="-g  -O2 -D_REENTRANT" \
>                 --prefix=/usr --localstatedir=/etc --mandir=/usr/share/man \
>                 --with-system-et --with-system-ss --enable-fakeka \
>                 --enable-shared --with-ldap --without-tcl \
>                 --build i486-linux-gnu
>
>
> Things work fine until it gets to running configure in pkinit.  Then
> it complains that the definition of CFLAGS in the cache differs from
> the definition on the command line and that I need to run distclean.
> It seems that the one of the CFLAGS values is being prepended with an
> extra space.
>
> I am still trying to track down why this is the case.

Note that you have two spaces between the "-g" and the "-O2" above.
Also, what is the output of

grep CFLAGS config.cache

From hartmans at MIT.EDU  Fri May 30 07:11:34 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Fri, 30 May 2008 07:11:34 -0400
Subject: build problam with 1.6.4 beta1
In-Reply-To: <ldv1w3kmr2d.fsf@cathode-dark-space.mit.edu> (Tom Yu's message of
	"Thu, 29 May 2008 23:03:22 -0400")
References: <20080530020440.E611CA6C01E@luminous.suchdamage.org>
	<ldv1w3kmr2d.fsf@cathode-dark-space.mit.edu>
Message-ID: <tsld4n46o7t.fsf@mit.edu>

It was the double space between -g and -O2.

That's kind of bogus but is easy to fix.

From simon at sxw.org.uk  Fri May 30 08:04:00 2008
From: simon at sxw.org.uk (Simon Wilkinson)
Date: Fri, 30 May 2008 13:04:00 +0100
Subject: GSSAPI - context lifetime
In-Reply-To: <87k5hcls8y.fsf@windlord.stanford.edu>
References: <9C71AD778A20DC47A9A1F89BFDD2C83B2367E2B0E5@ES05SNLNT.srn.sandia.gov>
	<87k5hcls8y.fsf@windlord.stanford.edu>
Message-ID: <B45AA870-D9DA-489B-8F08-5B34139518BE@sxw.org.uk>


On 29 May 2008, at 22:23, Russ Allbery wrote:

> Because all products of a Kerberos authentication should be tied to a
> ticket lifetime.  Otherwise, the ticket lifetime isn't meaningfully
> enforced; someone who obtains a ticket at some point could  
> authenticate to
> a service and simply stay authenticated, and there would be no good  
> way of
> rejecting their later operations.

This issue appears from time to time on the OpenLDAP list.  
Unfortunately, Heimdal and MIT have different behaviours in this area  
- Heimdal allows gss_wrap() and unwrap() to be used within an expired  
context. The OpenLDAP code fails to handle the situation where these  
calls fail within the SASL layer, and hangs when attempting to  
perform connections with an expired context. Essentially, this means  
that MIT Kerberos cannot be used to back the GSSAPI SASL mechanism  
within their replication code, without requiring a server restart  
every time the GSS context expires.

S.


From gmachin at sandia.gov  Fri May 30 12:08:09 2008
From: gmachin at sandia.gov (Glenn Machin)
Date: Fri, 30 May 2008 10:08:09 -0600
Subject: GSSAPI - context lifetime
In-Reply-To: <483F2657.8010005@anl.gov>
References: <9C71AD778A20DC47A9A1F89BFDD2C83B2367E2B0E5@ES05SNLNT.srn.sandia.gov>
	<87k5hcls8y.fsf@windlord.stanford.edu> <483F2657.8010005@anl.gov>
Message-ID: <48402669.7050404@sandia.gov>

It appears that Heimdal sets the context lifetime to that of the ticket, 
but ignores it in wrap/unwrap.   GSS_S_CONTEXT_EXPIRED is a possible 
return value so I don't know if this is in violation of the RFC.  

If you take into account that the Kerberos krb5_auth_context  does not 
have the concept of a context lifetime, one might argue that the 
kerberos mechanism does not have a context lifetime, only a credential 
lifetime.  However the API has been around for some time that suddenly 
not having a context lifetime could have a affect on applications.   
 From the discussion on this email thread its clear that the checking of 
the context lifetime in wrap/unwrap is a usability issue.

So can we just ignore the context lifetime in the wrap/unwrap?  It seems 
to me that would have less of an impact to applications.



Glenn




Douglas E. Engert wrote:
> Russ Allbery wrote:
>   
>> "Machin, Glenn D" <GMachin at sandia.gov> writes:
>>
>>     
>>> I apologize if this is not the right forum for this question.
>>>
>>> The gss_wrap and seal routines are dependent on the context endtime. The
>>> context endtime is derived from the service ticket lifetime. For a
>>> gssftp session if multiple data transfers exceed the ticket lifetime the
>>> gssftp session fails.
>>>
>>> Can someone tell me why the context is tied to ticket lifetime?
>>>       
>> Because all products of a Kerberos authentication should be tied to a
>> ticket lifetime.  Otherwise, the ticket lifetime isn't meaningfully
>> enforced; someone who obtains a ticket at some point could authenticate to
>> a service and simply stay authenticated, and there would be no good way of
>> rejecting their later operations.
>>     
>
> Rsh and rlogin with Kerberos have no time limit on their connection. SSH has
> no time limit on its connection, even when authenticating using GSS.
>
> Sessions using certificates, passwords or other authentications don't
> have timeouts.
>
> I would argue: It should be a policy decision of the service as to the
> length of a session. The ticket lifetime *COULD* be used in the decision,
> but it should not be forced by the GSSAPI, unless requested by the service
> or client.
>
>   
>
> --
>
>   Douglas E. Engert  <DEEngert at anl.gov>
>   Argonne National Laboratory
>   9700 South Cass Avenue
>   Argonne, Illinois  60439
>   (630) 252-5444
>
>   



From Nicolas.Williams at sun.com  Fri May 30 12:28:34 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 30 May 2008 11:28:34 -0500
Subject: GSSAPI - context lifetime
In-Reply-To: <48402669.7050404@sandia.gov>
References: <9C71AD778A20DC47A9A1F89BFDD2C83B2367E2B0E5@ES05SNLNT.srn.sandia.gov>
	<87k5hcls8y.fsf@windlord.stanford.edu>
	<483F2657.8010005@anl.gov> <48402669.7050404@sandia.gov>
Message-ID: <20080530162834.GW2735@Sun.COM>

On Fri, May 30, 2008 at 10:08:09AM -0600, Glenn Machin wrote:
> It appears that Heimdal sets the context lifetime to that of the ticket, 
> but ignores it in wrap/unwrap.   GSS_S_CONTEXT_EXPIRED is a possible 
> return value so I don't know if this is in violation of the RFC.  

Note: the RFC in question would be 4121, since RFC2743 does mandate that
GSS_S_CONTEXT_EXPIRED be used.  RFC4120 and RFC3961/3962 would be the
places to look for key lifetime.

RFC4121 says nothing about context expiration and RFC2743 doesn't have
enough text from which to guess what the right behaviour would be for
any one mechanism.

Therefore implementors are left to guess what to do here.  It's not
surprising that two implementors chose different behaviours.

>  From the discussion on this email thread its clear that the checking of 
> the context lifetime in wrap/unwrap is a usability issue.
> 
> So can we just ignore the context lifetime in the wrap/unwrap?  It seems 
> to me that would have less of an impact to applications.

I support this.  What about key usage though?  The obvious advice here
is: use AES.  But what should the mechanism do when the key is 1DES and
the app is doing bulk, high bandwidth data transfers?

Nico
-- 

From rra at stanford.edu  Fri May 30 13:12:35 2008
From: rra at stanford.edu (Russ Allbery)
Date: Fri, 30 May 2008 10:12:35 -0700
Subject: GSSAPI - context lifetime
In-Reply-To: <B45AA870-D9DA-489B-8F08-5B34139518BE@sxw.org.uk> (Simon
	Wilkinson's message of "Fri\, 30 May 2008 13\:04\:00 +0100")
References: <9C71AD778A20DC47A9A1F89BFDD2C83B2367E2B0E5@ES05SNLNT.srn.sandia.gov>
	<87k5hcls8y.fsf@windlord.stanford.edu>
	<B45AA870-D9DA-489B-8F08-5B34139518BE@sxw.org.uk>
Message-ID: <87zlq7g1h8.fsf@windlord.stanford.edu>

Simon Wilkinson <simon at sxw.org.uk> writes:

> This issue appears from time to time on the OpenLDAP list.
> Unfortunately, Heimdal and MIT have different behaviours in this area -
> Heimdal allows gss_wrap() and unwrap() to be used within an expired
> context. The OpenLDAP code fails to handle the situation where these
> calls fail within the SASL layer, and hangs when attempting to perform
> connections with an expired context. Essentially, this means that MIT
> Kerberos cannot be used to back the GSSAPI SASL mechanism within their
> replication code, without requiring a server restart every time the GSS
> context expires.

Yeah, the problem with SASL not knowing how to reauthenticate or see
expiration of sessions is a major problem, and I agree that this makes a
completely "formally" proper treatment of session expiration hard enough
that it may not be a good idea.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

From GMachin at sandia.gov  Fri May 30 17:00:38 2008
From: GMachin at sandia.gov (Machin, Glenn D)
Date: Fri, 30 May 2008 15:00:38 -0600
Subject: GSSAPI - context lifetime
In-Reply-To: <20080530162834.GW2735@Sun.COM>
References: <9C71AD778A20DC47A9A1F89BFDD2C83B2367E2B0E5@ES05SNLNT.srn.sandia.gov>
	<87k5hcls8y.fsf@windlord.stanford.edu> <483F2657.8010005@anl.gov>
	<48402669.7050404@sandia.gov> <20080530162834.GW2735@Sun.COM>
Message-ID: <9C71AD778A20DC47A9A1F89BFDD2C83B2367E2B181@ES05SNLNT.srn.sandia.gov>

> What about key usage though?  The obvious advice here
> is: use AES.  But what should the mechanism do when the key
> is 1DES and
> the app is doing bulk, high bandwidth data transfers?


I don't think that this is something that wrap/unwrap needs to be concerned with. First only the application can determine how much data will be moved during the session. Then if you change the behavior of the code based upon the key type, you could create all sorts of confusion to the end user.  My gssftp of 2 large files works from system A to system B but not from system A to system C, all because A to B used AES and A to C used DES.

I agree that the strongest key should be negotiated between the initiator and acceptor. Allowing the initiator or acceptor to limit the types negotiated would be beneficial. But once the context is established don't change the behavior.



Glenn





> -----Original Message-----
> From: Nicolas Williams [mailto:Nicolas.Williams at sun.com]
> Sent: Friday, May 30, 2008 10:29 AM
> To: Machin, Glenn D
> Cc: Douglas E. Engert; 'krbdev at mit.edu'
> Subject: Re: GSSAPI - context lifetime
>
> On Fri, May 30, 2008 at 10:08:09AM -0600, Glenn Machin wrote:
> > It appears that Heimdal sets the context lifetime to that
> of the ticket,
> > but ignores it in wrap/unwrap.   GSS_S_CONTEXT_EXPIRED is a possible
> > return value so I don't know if this is in violation of the RFC.
>
> Note: the RFC in question would be 4121, since RFC2743 does
> mandate that
> GSS_S_CONTEXT_EXPIRED be used.  RFC4120 and RFC3961/3962 would be the
> places to look for key lifetime.
>
> RFC4121 says nothing about context expiration and RFC2743 doesn't have
> enough text from which to guess what the right behaviour would be for
> any one mechanism.
>
> Therefore implementors are left to guess what to do here.  It's not
> surprising that two implementors chose different behaviours.
>
> >  From the discussion on this email thread its clear that
> the checking of
> > the context lifetime in wrap/unwrap is a usability issue.
> >
> > So can we just ignore the context lifetime in the
> wrap/unwrap?  It seems
> > to me that would have less of an impact to applications.
>
> I support this.  What about key usage though?  The obvious advice here
> is: use AES.  But what should the mechanism do when the key
> is 1DES and
> the app is doing bulk, high bandwidth data transfers?
>
> Nico
> --
>
>



From Nicolas.Williams at sun.com  Fri May 30 20:33:04 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 30 May 2008 19:33:04 -0500
Subject: GSSAPI - context lifetime
In-Reply-To: <9C71AD778A20DC47A9A1F89BFDD2C83B2367E2B181@ES05SNLNT.srn.sandia.gov>
References: <9C71AD778A20DC47A9A1F89BFDD2C83B2367E2B0E5@ES05SNLNT.srn.sandia.gov>
	<87k5hcls8y.fsf@windlord.stanford.edu>
	<483F2657.8010005@anl.gov> <48402669.7050404@sandia.gov>
	<20080530162834.GW2735@Sun.COM>
	<9C71AD778A20DC47A9A1F89BFDD2C83B2367E2B181@ES05SNLNT.srn.sandia.gov>
Message-ID: <20080531003303.GH2735@Sun.COM>

On Fri, May 30, 2008 at 03:00:38PM -0600, Machin, Glenn D wrote:
> > What about key usage though?  The obvious advice here
> > is: use AES.  But what should the mechanism do when the key
> > is 1DES and
> > the app is doing bulk, high bandwidth data transfers?
> 
> 
> I don't think that this is something that wrap/unwrap needs to be
> concerned with. First only the application can determine how much data
> will be moved during the session. Then if you change the behavior of

The issue isn't how much data _will_ the app move, but how much data
_has been_ moved.

> the code based upon the key type, you could create all sorts of
> confusion to the end user.  My gssftp of 2 large files works from
> system A to system B but not from system A to system C, all because A
> to B used AES and A to C used DES.

I agree.  It'd be better to just have a minor status code to indicate
key overuse while still indicating overall success.