From rra at stanford.edu  Sat Aug  1 14:46:47 2009
From: rra at stanford.edu (Russ Allbery)
Date: Sat, 01 Aug 2009 11:46:47 -0700
Subject: Integration of k5start/krenew functionality
In-Reply-To: <2C47D576-AE6E-4D92-8718-484FD881AF9D@mit.edu> (Ken Raeburn's
	message of "Fri\, 31 Jul 2009 22\:24\:44 -0400")
References: <200907311906.n6VJ63pH013021@outgoing.mit.edu>
	<2C47D576-AE6E-4D92-8718-484FD881AF9D@mit.edu>
Message-ID: <87vdl7qsmg.fsf@windlord.stanford.edu>

Ken Raeburn <raeburn at MIT.EDU> writes:

> I'm also of two minds as to how much Kerberos programs should be going
> out of their way to do AFS things, rather than providing hooks and
> letting someone choose to run AFS programs.  We don't do anything
> special for NFS or Zephyr or other Kerberos-using technologies.  (I
> wonder if we should look at some of the event signaling systems present
> on many systems these days, as a way to advertise "TGT in ccache foo
> updated" to any interested process, so it can get new AFS tokens or
> update Zephyr session key data etc.  There are already some notification
> hooks in some of the ccache code.  Just a thought...)

I suspect most people here know this, but to be sure, there's no way that
one can do what k5start and krenew do without adding the AFS support
directly into the program or at least in something else run in the same
process.  A subprocess can't put the command in a separate PAG and obtain
tokens within that PAG.  Without having the AFS support directly in the
k5start/krenew program, you have to do workarounds that are difficult to
explain to the average end-user, such as invoking a separate wrapper
script that uses pagsh and runs aklog separately.  Simplifying that is a
design requirement for us, since we have people use krenew who have no
prior experience with Kerberos or AFS.

> As for these specific programs -- I think there's a lot of duplicated
> functionality between kinit and k5start, so having one program with a
> few more options may be better...

Certainly that's happened in the past -- k4start started as a fix for
Kerberos v4 kinit, which had fairly broken and insufficient command line
options, and most of the same problems were fixed in kinit for Kerberos
v5.

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

From ghudson at MIT.EDU  Sat Aug  1 15:44:18 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Sat, 01 Aug 2009 15:44:18 -0400
Subject: Integration of k5start/krenew functionality
In-Reply-To: <2C47D576-AE6E-4D92-8718-484FD881AF9D@mit.edu>
References: <200907311906.n6VJ63pH013021@outgoing.mit.edu>
	<2C47D576-AE6E-4D92-8718-484FD881AF9D@mit.edu>
Message-ID: <1249155858.7683.39.camel@ray>

On Fri, 2009-07-31 at 22:24 -0400, Ken Raeburn wrote:
> I've wondered before if some of this functionality should be pulled  
> into the library or existing programs.  For example, various means  
> could be used to express to the library, "if credentials have expired  
> or are about to, use this keytab entry to renew them automatically",  
> or "after successful TGT acquisition, call this function".

I thought about this as well.  There's a certain elegance in having a
credentials cache which is actually a cache, backed by a key in a keytab
which can be used for AS requests, but I think the full design would run
into some uncomfortable questions which are better answered outside of
libkrb5.  For instance, when the caller asks for a service ticket, how
long should the TGT have left in it for us to use the existing TGT
instead of requesting a new one?  When doing an AS request, what
parameters do we use, and do we want to use FAST or PKINIT or any other
preauth?

> I'm also of two minds as to how much Kerberos programs should be going  
> out of their way to do AFS things, rather than providing hooks and  
> letting someone choose to run AFS programs.

I don't really like the idea of adding setpag calls into kinit.  I think
we have an AFS dependency in login.krb5, but that will get better with
the unbundling of krb5-appl.

So I'm leaning towards keeping the external command hook (the
aklog-shaped hole) and make people use pagsh for the PAG if necessary.
That's probably a good reason not to use the names k5start and krenew.



From rra at stanford.edu  Sat Aug  1 15:52:24 2009
From: rra at stanford.edu (Russ Allbery)
Date: Sat, 01 Aug 2009 12:52:24 -0700
Subject: Integration of k5start/krenew functionality
In-Reply-To: <1249155858.7683.39.camel@ray> (Greg Hudson's message of "Sat\,
	01 Aug 2009 15\:44\:18 -0400")
References: <200907311906.n6VJ63pH013021@outgoing.mit.edu>
	<2C47D576-AE6E-4D92-8718-484FD881AF9D@mit.edu>
	<1249155858.7683.39.camel@ray>
Message-ID: <87d47fqpl3.fsf@windlord.stanford.edu>

Greg Hudson <ghudson at MIT.EDU> writes:

> So I'm leaning towards keeping the external command hook (the
> aklog-shaped hole) and make people use pagsh for the PAG if necessary.
> That's probably a good reason not to use the names k5start and krenew.

Unless you're adopting the programs verbatim and will be tracking
upgrades, I would prefer that you didn't use the names regardless,
although you may if you want.  I have no intention of stopping you or
anything, but I think it would be confusing to have multiple programs with
the same name but different functionality or different flags, and it would
cause us problems in Debian and at Stanford if the MIT Kerberos
distribution conflicted with the kstart package.

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

From kenh at cmf.nrl.navy.mil  Sat Aug  1 18:33:10 2009
From: kenh at cmf.nrl.navy.mil (Ken Hornstein)
Date: Sat, 01 Aug 2009 18:33:10 -0400
Subject: Integration of k5start/krenew functionality
In-Reply-To: <1249155858.7683.39.camel@ray>
Message-ID: <200908012233.n71MXAv8012227@hedwig.cmf.nrl.navy.mil>

>So I'm leaning towards keeping the external command hook (the
>aklog-shaped hole) and make people use pagsh for the PAG if necessary.
>That's probably a good reason not to use the names k5start and krenew.

Just my two cents ...

If my choices are to use Russ's commands (k5start and krenew) or use some
combination of pagsh/MIT programs that may know about aklog .... well,
the choice is easy: I would use Russ's programs in a heartbeat.  It's
just easier (I have enough time getting the levels of quoting right
when using multiple levels of shell interpretation .... I can't imagine
what an unsophisticated user would do).

If the goal is to support AFS, then I think you should go whole-hog.  If
you're only going to support it half-assed ... well, what is the point,
exactly?  If there are other possible consumers of this functionality,
then of course this makes sense.

--Ken

From raeburn at MIT.EDU  Sat Aug  1 19:17:27 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Sat, 1 Aug 2009 19:17:27 -0400
Subject: Integration of k5start/krenew functionality
In-Reply-To: <1249155858.7683.39.camel@ray>
References: <200907311906.n6VJ63pH013021@outgoing.mit.edu>
	<2C47D576-AE6E-4D92-8718-484FD881AF9D@mit.edu>
	<1249155858.7683.39.camel@ray>
Message-ID: <41EA02FC-5F57-49BE-A867-A478D009D019@mit.edu>

On Aug 1, 2009, at 15:44, Greg Hudson wrote:
> I thought about this as well.  There's a certain elegance in having a
> credentials cache which is actually a cache, backed by a key in a  
> keytab
> which can be used for AS requests, but I think the full design would  
> run
> into some uncomfortable questions which are better answered outside of
> libkrb5.

Yeah, there are issue to be settled.

>  For instance, when the caller asks for a service ticket, how
> long should the TGT have left in it for us to use the existing TGT
> instead of requesting a new one?

I'd say either 0 or $clockskew.  For anything more, in "normal" cases  
we'd ... uh, well, maybe we'd use "klist" enhanced with the "-H"  
option from Russ's tools, and if it fails, run "kinit" to forcibly  
renew the credentials *now*.  That could still be done, though I'm not  
sure how we'd work the UI if the keytab+ccache thing were done with  
just a new ccache type.  If it's a new datum in an existing ccache  
type, we could just have kinit look for that datum and bypass the  
whole password-asking step.

I don't recall if minimum remaining lifetime (or in absolute terms,  
earliest expiration time) is one of the attributes that can be  
specified for fetching credentials.  If it is, or it can be supported,  
that would be a way for an application to specify that it wants  
credentials valid for at least X time.

>  When doing an AS request, what
> parameters do we use, and do we want to use FAST or PKINIT or any  
> other
> preauth?

That's probably an argument for attaching some (extensible) datum in  
the ccache, instead of just pairing a keytab and a ccache.

Ken

From raeburn at MIT.EDU  Sat Aug  1 19:32:52 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Sat, 1 Aug 2009 19:32:52 -0400
Subject: Integration of k5start/krenew functionality
In-Reply-To: <200908012233.n71MXAv8012227@hedwig.cmf.nrl.navy.mil>
References: <200908012233.n71MXAv8012227@hedwig.cmf.nrl.navy.mil>
Message-ID: <6061AFC8-2E0A-481B-BC16-0E5ACFD70BDF@mit.edu>

On Aug 1, 2009, at 18:33, Ken Hornstein wrote:
> If my choices are to use Russ's commands (k5start and krenew) or use  
> some
> combination of pagsh/MIT programs that may know about aklog .... well,
> the choice is easy: I would use Russ's programs in a heartbeat.  It's
> just easier (I have enough time getting the levels of quoting right
> when using multiple levels of shell interpretation .... I can't  
> imagine
> what an unsophisticated user would do).

I'd be okay with providing plugins and/or scripts tailored for AFS  
support, that can do things like run setpag/pagsh and get the quoting  
right for you.  I don't think it should be quite so integral to our  
basic tools, nor should we have yet another configure-time option  
resulting in different flavors of packages to install.

> If the goal is to support AFS, then I think you should go whole- 
> hog.  If
> you're only going to support it half-assed ... well, what is the  
> point,
> exactly?  If there are other possible consumers of this functionality,
> then of course this makes sense.

My concern is that AFS isn't unique -- how many different Kerberos- 
based packages should we add specific code and configure-time options  
for?  How many programs need to do something interesting when Kerberos  
tickets are updated?

The PAG issue Russ brings up is important.  Maybe that does make AFS  
unique... or maybe it's just the only moderately successful such  
package so far in the Kerberos context.  (Linux keyring sessions?)   
I'm not familiar enough with usage of his tools to know if there's an  
alternative (exec pagsh telling it to exec our program but without the  
"create a PAG" option?).  So, yeah, maybe the AFS support does need to  
be in the same process.  Can we do it with a tiny plugin module that  
can either be installed or not depending on whether you need the AFS  
support, so we don't have to recompile the Kerberos code itself?  (Or  
even code we ship that tries a dlopen of the AFS library.)  Then if  
the command-line flag for a new PAG is given, and the support isn't  
installed, we just print an error.

Ken

From ghudson at MIT.EDU  Sun Aug  2 23:47:45 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Sun, 02 Aug 2009 23:47:45 -0400
Subject: Integration of k5start/krenew functionality
In-Reply-To: <200908012233.n71MXAv8012227@hedwig.cmf.nrl.navy.mil>
References: <200908012233.n71MXAv8012227@hedwig.cmf.nrl.navy.mil>
Message-ID: <1249271265.7683.56.camel@ray>

On Sat, 2009-08-01 at 18:33 -0400, Ken Hornstein wrote:
> If the goal is to support AFS, then I think you should go whole-hog.

AFS support is not a primary goal.  Given that krenew and k5start will
continue to be maintained externally, I am now wondering if perhaps the
project scope should be narrowed substantially to limit the amount of UI
real estate used.  So I am thinking of dropping the krenew use case,
eliminating the aklog-shaped external program hook, and supporting only
one style of k5start use case--for example, only operation as a process
wrapper, and not as a background process or check-and-renew utility.

> It's just easier (I have enough time getting the levels of quoting
> right when using multiple levels of shell interpretation .... I can't
> imagine what an unsophisticated user would do).

I don't want to go too deep down the conversational rabbit-hole here,
but process wrappers like pagsh and k5start generally use exec() rather
than passing their arguments to a shell, so they don't add multiple
levels of shell interpretation.

The other Ken wrote:
> Can we do it with a tiny plugin module that can either be installed or
> not depending on whether you need the AFS support,

I am reluctant to add any build dependencies of any kind on AFS, because
AFS depends on krb5.  We already have a bit of a loop with login.krb5,
but that will be fixed by unbundling the applications.  I don't even
know how Debian manages the existing dependency loop, but it can't be
pretty.

Finally, in regards to coupling a ccache to a keytab at the library
level: I have even more reservations on this front after thinking about
it further.  The as-req code path is fundamentally more complicated than
the tgs-req code path because of the open-ended nature of the preauth
framework.  For example, you might need pkinit to perform an as-req, and
pkinit relies on OpenSSL, which does not want to be linked into the same
process as GPL'd code.  I'm very uncomfortable with the idea of
krb5_get_credentials() potentially performing an as-req at this time.



From raeburn at MIT.EDU  Mon Aug  3 03:48:28 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Mon, 3 Aug 2009 03:48:28 -0400
Subject: Integration of k5start/krenew functionality
In-Reply-To: <1249271265.7683.56.camel@ray>
References: <200908012233.n71MXAv8012227@hedwig.cmf.nrl.navy.mil>
	<1249271265.7683.56.camel@ray>
Message-ID: <9D916297-1B2C-4F6A-9191-3413AA2FF500@mit.edu>

On Aug 2, 2009, at 23:47, Greg Hudson wrote:
>> Can we do it with a tiny plugin module that can either be installed  
>> or
>> not depending on whether you need the AFS support,
>
> I am reluctant to add any build dependencies of any kind on AFS,  
> because
> AFS depends on krb5.

Actually, I was thinking the plugin wouldn't be in the krb5  
distribution, but a separate thing (maybe in krb5-appl, which already  
depends on both krb5 and optionally openafs, or maybe folded into the  
openafs package, except for the mit-vs-heimdal issues).  In terms of  
build dependencies, it would depend on Kerberos, but not the other way  
around.  The basic Kerberos package would just have a callback hook  
for a somewhat specialized purpose.

> Finally, in regards to coupling a ccache to a keytab at the library
> level: I have even more reservations on this front after thinking  
> about
> it further.  The as-req code path is fundamentally more complicated  
> than
> the tgs-req code path because of the open-ended nature of the preauth
> framework.  For example, you might need pkinit to perform an as-req,  
> and
> pkinit relies on OpenSSL, which does not want to be linked into the  
> same
> process as GPL'd code.  I'm very uncomfortable with the idea of
> krb5_get_credentials() potentially performing an as-req at this time.

Good point; I hadn't thought of that.

Ken

From lha at kth.se  Mon Aug  3 04:04:52 2009
From: lha at kth.se (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=)
Date: Mon, 3 Aug 2009 10:04:52 +0200
Subject: Integration of k5start/krenew functionality
In-Reply-To: <1249271265.7683.56.camel@ray>
References: <200908012233.n71MXAv8012227@hedwig.cmf.nrl.navy.mil>
	<1249271265.7683.56.camel@ray>
Message-ID: <76B04772-CC4E-4481-A807-A30C1D425D6B@kth.se>


3 aug 2009 kl. 05:47 skrev Greg Hudson:

> For example, you might need pkinit to perform an as-req, and
> pkinit relies on OpenSSL, which does not want to be linked into the  
> same
> process as GPL'd code

Use heimdal openssl compat layer, hcrypto, that's enough to get pkinit  
working when running on GPL-only platforms.

hcrypto is licensed under a 3clause bsd license.

The license issue should be no problem.

Love



From jhutz at cmu.edu  Mon Aug  3 10:08:47 2009
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Mon, 03 Aug 2009 10:08:47 -0400
Subject: Integration of k5start/krenew functionality
In-Reply-To: <8424_1249271290_n733mA9N004303_1249271265.7683.56.camel@ray>
References: <200908012233.n71MXAv8012227@hedwig.cmf.nrl.navy.mil>
	<8424_1249271290_n733mA9N004303_1249271265.7683.56.camel@ray>
Message-ID: <3B93B33BFFB9074D0C1C07D5@atlantis.pc.cs.cmu.edu>

--On Sunday, August 02, 2009 11:47:45 PM -0400 Greg Hudson 
<ghudson at mit.edu> wrote:

> AFS support is not a primary goal.  Given that krenew and k5start will
> continue to be maintained externally, I am now wondering if perhaps the
> project scope should be narrowed substantially to limit the amount of UI
> real estate used.  So I am thinking of dropping the krenew use case,
> eliminating the aklog-shaped external program hook, and supporting only
> one style of k5start use case--for example, only operation as a process
> wrapper, and not as a background process or check-and-renew utility.

This sounds like a reasonable approach to me.  As you note, introducing an 
AFS dependency into krb5 would be annoying, since AFS already has krb5 
dependencies and is only likely to grow more.  Kerberos ought to 
concentrate on Kerberos, and leave the complex tie-lots-of-things-together 
tools to someone else.


> The other Ken wrote:
>> Can we do it with a tiny plugin module that can either be installed or
>> not depending on whether you need the AFS support,
>
> I am reluctant to add any build dependencies of any kind on AFS, because
> AFS depends on krb5.

I agree.  However, I can see how it might be useful to have a hole into 
which such a plugin might be dropped.  The plugin itself could then be 
shipped with AFS, which would also resolve issues about knowing exactly 
what it needs to do, which is likely to change over time.

-- Jeff

From kenh at cmf.nrl.navy.mil  Mon Aug  3 10:22:33 2009
From: kenh at cmf.nrl.navy.mil (Ken Hornstein)
Date: Mon, 03 Aug 2009 10:22:33 -0400
Subject: Integration of k5start/krenew functionality
In-Reply-To: <1249271265.7683.56.camel@ray>
Message-ID: <200908031422.n73EMXug029228@hedwig.cmf.nrl.navy.mil>

>On Sat, 2009-08-01 at 18:33 -0400, Ken Hornstein wrote:
>> If the goal is to support AFS, then I think you should go whole-hog.
>
>AFS support is not a primary goal.  Given that krenew and k5start will
>continue to be maintained externally, I am now wondering if perhaps the
>project scope should be narrowed substantially to limit the amount of UI
>real estate used.  So I am thinking of dropping the krenew use case,
>eliminating the aklog-shaped external program hook, and supporting only
>one style of k5start use case--for example, only operation as a process
>wrapper, and not as a background process or check-and-renew utility.

Again, I personally have no problem with this ... I just think you need
to pick one or the other.  If MIT prefers to focus on core Kerberos
functionality and just leave AFS support to third-party tools, I think
that's reasonable.

>> It's just easier (I have enough time getting the levels of quoting
>> right when using multiple levels of shell interpretation .... I can't
>> imagine what an unsophisticated user would do).
>
>I don't want to go too deep down the conversational rabbit-hole here,
>but process wrappers like pagsh and k5start generally use exec() rather
>than passing their arguments to a shell, so they don't add multiple
>levels of shell interpretation.

So ... you've USED pagsh, right?  It invokes /bin/sh with the exact
arguments you give on the command line.  That means you need to build
up a command line using -c ... and I've found complicated quoting there
can get hairy very quickly.  Russ's tools were just easier.

--Ken

From rra at stanford.edu  Mon Aug  3 15:05:27 2009
From: rra at stanford.edu (Russ Allbery)
Date: Mon, 03 Aug 2009 12:05:27 -0700
Subject: Integration of k5start/krenew functionality
In-Reply-To: <200908031422.n73EMXug029228@hedwig.cmf.nrl.navy.mil> (Ken
	Hornstein's message of "Mon\, 03 Aug 2009 10\:22\:33 -0400")
References: <200908031422.n73EMXug029228@hedwig.cmf.nrl.navy.mil>
Message-ID: <87d47cd8g8.fsf@windlord.stanford.edu>

Ken Hornstein <kenh at cmf.nrl.navy.mil> writes:

> So ... you've USED pagsh, right?  It invokes /bin/sh with the exact
> arguments you give on the command line.  That means you need to build up
> a command line using -c ... and I've found complicated quoting there can
> get hairy very quickly.  Russ's tools were just easier.

I think the assumption that people are making here is that you'd create a
generic wrapper script that would look something like:

    #!/usr/bin/pagsh
    aklog && exec "$@"

and then run something like

    kinit -k -t /path/to/keytab -- afs-wrapper command arg arg arg

The problem with the simplistic approach, of course, is that since the
command is now in a separate PAG from the running k5start process, there's
no way to renew those AFS tokens.  The afs-wrapper script would have to be
more sophisticated than this, since it would need to wake up periodically
to check whether the ticket cache has been updated and then re-run aklog
appropriately.  Since that's exactly the same logic that k5start needs for
renewing the ticket cache, k5start's design is simpler and has less that
can go wrong.

BTW, on the side of pulling k5start options into kinit, one that would be
very useful and is simple to implement would be k5start's -U option, which
says to determine the principal with which to authenticate by reading the
keytab and using the principal of the first entry in the keytab.  We
discovered with k5start that this is a *huge* help for scripts.  We have a
variety of scripts that are now generic rather than customized for each
service or host since the only thing that changed was the principal as
which they should run and that's now read from their keytab.

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

From hartmans at MIT.EDU  Tue Aug  4 13:04:13 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 04 Aug 2009 13:04:13 -0400
Subject: Integration of k5start/krenew functionality
In-Reply-To: <1249271265.7683.56.camel@ray> (Greg Hudson's message of "Sun\,
	02 Aug 2009 23\:47\:45 -0400")
References: <200908012233.n71MXAv8012227@hedwig.cmf.nrl.navy.mil>
	<1249271265.7683.56.camel@ray>
Message-ID: <tsl4osnjysy.fsf@mit.edu>

I find it very difficult to comment on this because I don't understand
the use case.  I'm not complaining--I like how this was handled very
much, but internal discussions between MIT and an OS vendor are not
(and should not generally be) my business.

So, I'll give some priorities to consider.

1) If the problem is political, look for political solutions.  I.E. if
the existing k5start would be good enough, but the OS vendor is
concerned that Russ is not a large enough organization to rely on,
look into working with Russ to provide better support/fallback options
in case Russ gets kidnapped by aliens.

2) Slightly different interfaces that are hard to tell apart are
really annoying.  If it is not going to be the same code, don't call it k5start.

3) Duplication of interface is also incredibly annoying. I think as an
administrator I'd rather something that was plug compatible either to
k5start or to kcm (although with a different name if it was not going
to follow identical evolution) than something entirely new.

4) If you do decide to have a new interface try to clearly describe why your use case is different than the existing interface, so I can figure out when I should be using your thing rather than k5start.  

5) Plugins are good.  AFS, Linux keyring management (establisg a session keyring), etc all could use plugins.  Depending on things like pagsh is administrator-hostile.

--Sam

From lukeh at padl.com  Tue Aug  4 13:44:24 2009
From: lukeh at padl.com (Luke Howard)
Date: Tue, 4 Aug 2009 19:44:24 +0200
Subject: krb5_pac_verify and server key enctype extraction
In-Reply-To: <B862F448-4476-45CC-96B0-334A3C3CAD3F@padl.com>
References: <4A5D13B6.4090006@sun.com>
	<05B5918B-EE2B-40F9-B617-6928B4CFDACD@padl.com>
	<4A5E01F3.30803@Sun.COM>
	<38D16C49-7F9C-4463-BA08-3F9139F056CD@padl.com>
	<4A64903D.1040402@Sun.COM>
	<B862F448-4476-45CC-96B0-334A3C3CAD3F@padl.com>
Message-ID: <1C8E4123-F173-43A7-A718-9E8B29A9837B@padl.com>


> Yeah, it took me a while to realise that that was I had always done.
> But yes, we should do what Sam suggests for 1.8.

So: Sam's suggestion is to expose the verified PAC via the recently  
published GSS naming extensions draft. This sounds reasonable to me.

Love: did Heimdal always verify the PAC in gss_accept_sec_context()?  
This is an issue for MIT, because 1.7 we shipped APIs for extracting  
authorisation data. An application unaware of which GSS-API  
implementation it is using cannot be sure whether the PAC was verified  
after calling gss_accept_sec_context().

regards,

-- Luke

From Natalie.Li at Sun.COM  Tue Aug  4 14:05:40 2009
From: Natalie.Li at Sun.COM (Natalie Li)
Date: Tue, 04 Aug 2009 11:05:40 -0700
Subject: krb5_pac_verify and server key enctype extraction
In-Reply-To: <1C8E4123-F173-43A7-A718-9E8B29A9837B@padl.com>
References: <4A5D13B6.4090006@sun.com>
	<05B5918B-EE2B-40F9-B617-6928B4CFDACD@padl.com>
	<4A5E01F3.30803@Sun.COM>
	<38D16C49-7F9C-4463-BA08-3F9139F056CD@padl.com>
	<4A64903D.1040402@Sun.COM>
	<B862F448-4476-45CC-96B0-334A3C3CAD3F@padl.com>
	<1C8E4123-F173-43A7-A718-9E8B29A9837B@padl.com>
Message-ID: <4A787874.3030704@Sun.COM>

Luke,

Could you please send out a pointer to the GSS naming extensions draft?

Thanks,

Natalie

Luke Howard wrote:
>
>> Yeah, it took me a while to realise that that was I had always done.  
>> But yes, we should do what Sam suggests for 1.8.
>
> So: Sam's suggestion is to expose the verified PAC via the recently 
> published GSS naming extensions draft. This sounds reasonable to me.
>
> Love: did Heimdal /always/ verify the PAC in gss_accept_sec_context()? 
> This is an issue for MIT, because 1.7 we shipped APIs for extracting 
> authorisation data. An application unaware of which GSS-API 
> implementation it is using cannot be sure whether the PAC was verified 
> after calling gss_accept_sec_context().
>
> regards,
>
> -- Luke


From lukeh at padl.com  Tue Aug  4 14:11:38 2009
From: lukeh at padl.com (Luke Howard)
Date: Tue, 4 Aug 2009 20:11:38 +0200
Subject: krb5_pac_verify and server key enctype extraction
In-Reply-To: <4A787874.3030704@Sun.COM>
References: <4A5D13B6.4090006@sun.com>
	<05B5918B-EE2B-40F9-B617-6928B4CFDACD@padl.com>
	<4A5E01F3.30803@Sun.COM>
	<38D16C49-7F9C-4463-BA08-3F9139F056CD@padl.com>
	<4A64903D.1040402@Sun.COM>
	<B862F448-4476-45CC-96B0-334A3C3CAD3F@padl.com>
	<1C8E4123-F173-43A7-A718-9E8B29A9837B@padl.com>
	<4A787874.3030704@Sun.COM>
Message-ID: <8752B9FD-7421-484E-AAED-635E038A6CFA@padl.com>

http://tools.ietf.org/html/draft-ietf-kitten-gssapi-naming-exts-05

On 04/08/2009, at 8:05 PM, Natalie Li wrote:

> Luke,
>
> Could you please send out a pointer to the GSS naming extensions  
> draft?
>
> Thanks,
>
> Natalie
>
> Luke Howard wrote:
>>
>>
>>> Yeah, it took me a while to realise that that was I had always done.
>>> But yes, we should do what Sam suggests for 1.8.
>>
>> So: Sam's suggestion is to expose the verified PAC via the recently  
>> published GSS naming extensions draft. This sounds reasonable to me.
>>
>> Love: did Heimdal always verify the PAC in  
>> gss_accept_sec_context()? This is an issue for MIT, because 1.7 we  
>> shipped APIs for extracting authorisation data. An application  
>> unaware of which GSS-API implementation it is using cannot be sure  
>> whether the PAC was verified after calling gss_accept_sec_context().
>>
>> regards,
>>
>> -- Luke
>

--
www.padl.com | www.fghr.net


From lha at apple.com  Tue Aug  4 13:57:24 2009
From: lha at apple.com (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=)
Date: Tue, 04 Aug 2009 19:57:24 +0200
Subject: krb5_pac_verify and server key enctype extraction
In-Reply-To: <1C8E4123-F173-43A7-A718-9E8B29A9837B@padl.com>
References: <4A5D13B6.4090006@sun.com>
	<05B5918B-EE2B-40F9-B617-6928B4CFDACD@padl.com>
	<4A5E01F3.30803@Sun.COM>
	<38D16C49-7F9C-4463-BA08-3F9139F056CD@padl.com>
	<4A64903D.1040402@Sun.COM>
	<B862F448-4476-45CC-96B0-334A3C3CAD3F@padl.com>
	<1C8E4123-F173-43A7-A718-9E8B29A9837B@padl.com>
Message-ID: <58A2A16F-FB53-4CD4-B8F3-64C66066515D@apple.com>

> Love: did Heimdal always verify the PAC in gss_accept_sec_context()?
> This is an issue for MIT, because 1.7 we shipped APIs for extracting
> authorisation data. An application unaware of which GSS-API
> implementation it is using cannot be sure whether the PAC was verified
> after calling gss_accept_sec_context().

Heimdal with extracting API have always verifed the PAC, this so samba  
didn't need to do this work. I grew tired of poking more and more  
holes though gss-api to expose kerberos inner workings that PAC and  
other things depends on.

Love



From hotz at jpl.nasa.gov  Tue Aug  4 14:43:43 2009
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Tue, 4 Aug 2009 11:43:43 -0700
Subject: Integration of k5start/krenew functionality
In-Reply-To: <mailman.635.1249402678.8313.krbdev@mit.edu>
References: <mailman.635.1249402678.8313.krbdev@mit.edu>
Message-ID: <D99788DD-72F0-4BF9-BA2C-23D65EB05EDF@jpl.nasa.gov>


On Aug 4, 2009, at 9:17 AM, krbdev-request at mit.edu wrote:

> BTW, on the side of pulling k5start options into kinit, one that  
> would be
> very useful and is simple to implement would be k5start's -U option,  
> which
> says to determine the principal with which to authenticate by  
> reading the
> keytab and using the principal of the first entry in the keytab.


For our k5start-equivalent we also deploy a modified kinit that reads  
the enctype of that entry and uses it instead of the library default.   
Simplifies keytab file creation across platforms with different kerb  
libs/enctype support.
------------------------------------------------------
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 hotz at jpl.nasa.gov  Tue Aug  4 18:07:38 2009
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Tue, 4 Aug 2009 15:07:38 -0700
Subject: Integration of k5start/krenew functionality
In-Reply-To: <mailman.507.1249143063.10547.krbdev@mit.edu>
References: <mailman.507.1249143063.10547.krbdev@mit.edu>
Message-ID: <DF0F9427-F625-429D-9B70-7F2C62AB2DA9@jpl.nasa.gov>


On Aug 1, 2009, at 9:11 AM, krbdev-request at mit.edu wrote:

> Plus maybe that keytab-auto-kinit library enhancement.


It didn't hit me right away, but the idea of connecting the keytab to  
the ccache instead of to an explicit kinit-like operation makes an  
awful lot of sense.  In fact it really ought to be connected to the  
tgt specifically.  Not sure how to implement that without major  
surgery, but that's a different issue.

------------------------------------------------------
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 jhutz at cmu.edu  Tue Aug  4 19:51:18 2009
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Tue, 04 Aug 2009 19:51:18 -0400
Subject: Integration of k5start/krenew functionality
In-Reply-To: <6900_1249405482_n74H4f9C026127_tsl4osnjysy.fsf@mit.edu>
References: <200908012233.n71MXAv8012227@hedwig.cmf.nrl.navy.mil>
	<1249271265.7683.56.camel@ray>
	<6900_1249405482_n74H4f9C026127_tsl4osnjysy.fsf@mit.edu>
Message-ID: <27E500F5E4C22D8A4A059416@MINBAR.FAC.CS.CMU.EDU>

--On Tuesday, August 04, 2009 01:04:13 PM -0400 Sam Hartman 
<hartmans at mit.edu> wrote:

> 5) Plugins are good.  AFS, Linux keyring management (establisg a session
> keyring), etc all could use plugins.  Depending on things like pagsh is
> administrator-hostile.

What do you think of the argument that "complex" credential management, 
such as automatically maintaining AFS credentials and setting up a new PAG, 
keyring, SSH agent, etc. should be left entirely to external tools such as 
kstart and not distributed with Kerberos at all?

Do we want a situation where, for example, Kerberos and AFS are aware of 
each other, and if you install both you get something more than the sum of 
the pieces?  Or is the problem better solved by a separate tool which is 
based on public interfaces exported by both?

-- Jeff

From hartmans at MIT.EDU  Wed Aug  5 08:49:41 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 05 Aug 2009 08:49:41 -0400
Subject: Integration of k5start/krenew functionality
In-Reply-To: <27E500F5E4C22D8A4A059416@MINBAR.FAC.CS.CMU.EDU> (Jeffrey
	Hutzelman's message of "Tue\, 04 Aug 2009 19\:51\:18 -0400")
References: <200908012233.n71MXAv8012227@hedwig.cmf.nrl.navy.mil>
	<1249271265.7683.56.camel@ray>
	<6900_1249405482_n74H4f9C026127_tsl4osnjysy.fsf@mit.edu>
	<27E500F5E4C22D8A4A059416@MINBAR.FAC.CS.CMU.EDU>
Message-ID: <tslk51ih1cq.fsf@mit.edu>

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

8    Jeffrey> --On Tuesday, August 04, 2009 01:04:13 PM -0400 Sam
    Jeffrey> Hartman
    Jeffrey> <hartmans at mit.edu> wrote:

>8 5) Plugins are good.  AFS, Linux keyring management (establisg a session
    >> keyring), etc all could use plugins.  Depending on things like
    >> pagsh is administrator-hostile.

    Jeffrey> What do you think of the argument that "complex"
    Jeffrey> credential management, such as automatically maintaining
    Jeffrey> AFS credentials and setting up a new PAG, keyring, SSH
    Jeffrey> agent, etc. should be left entirely to external tools
    Jeffrey> such as kstart and not distributed with Kerberos at all?

I mostly don't buy it.  In its white papers, the consortium has taken
the position that Kerberos is part of fairly complex interdependent
systems basically in all the environments that use Kerberos.

I don't think the simple use cases are interesting to anyone
particularly.

I can think of a couple of specific exceptions.  For example
maintaining credentials for the system account.  If one of those use
cases happens to be the real motivating use case for this work, then
sticking very closely to that use case seems good.

This project runs the real danger of creating a partial solution that
no one really wants that is strictly less useful than k5start.
Whatever can be done to avoid that is good, and if possible locking in
on a specific enough use case would be an example of such a way out.

--Sam

From deengert at anl.gov  Wed Aug  5 09:53:45 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Wed, 05 Aug 2009 08:53:45 -0500
Subject: Integration of k5start/krenew functionality
In-Reply-To: <27E500F5E4C22D8A4A059416@MINBAR.FAC.CS.CMU.EDU>
References: <200908012233.n71MXAv8012227@hedwig.cmf.nrl.navy.mil>	<1249271265.7683.56.camel@ray>	<6900_1249405482_n74H4f9C026127_tsl4osnjysy.fsf@mit.edu>
	<27E500F5E4C22D8A4A059416@MINBAR.FAC.CS.CMU.EDU>
Message-ID: <4A798EE9.8030608@anl.gov>



Jeffrey Hutzelman wrote:
> --On Tuesday, August 04, 2009 01:04:13 PM -0400 Sam Hartman 
> <hartmans at mit.edu> wrote:
> 
>> 5) Plugins are good.  AFS, Linux keyring management (establisg a session
>> keyring), etc all could use plugins.  Depending on things like pagsh is
>> administrator-hostile.
> 
> What do you think of the argument that "complex" credential management, 
> such as automatically maintaining AFS credentials and setting up a new PAG, 
> keyring, SSH agent, etc. should be left entirely to external tools such as 
> kstart and not distributed with Kerberos at all?
> 
> Do we want a situation where, for example, Kerberos and AFS are aware of 
> each other, and if you install both you get something more than the sum of 
> the pieces?  Or is the problem better solved by a separate tool which is 
> based on public interfaces exported by both?

Other examples of credentials could be included in this mix, including
Kx509 and NFSv4 use of tickets in the kernel.

Many of the issues have been addressed in login and screen unlock,
when credentials are renewed, and pam modules handle obtaining
additional credentials. Could pam be used from kinit much like screen unlock?




> 
> -- Jeff
> _______________________________________________
> 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 jhutz at cmu.edu  Wed Aug  5 10:02:20 2009
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Wed, 05 Aug 2009 10:02:20 -0400
Subject: Integration of k5start/krenew functionality
In-Reply-To: <4A798EE9.8030608@anl.gov>
References: <200908012233.n71MXAv8012227@hedwig.cmf.nrl.navy.mil>
	<1249271265.7683.56.camel@ray>
	<6900_1249405482_n74H4f9C026127_tsl4osnjysy.fsf@mit.edu>
	<27E500F5E4C22D8A4A059416@MINBAR.FAC.CS.CMU.EDU>
	<4A798EE9.8030608@anl.gov>
Message-ID: <4432DF9E5A1BC2FA5C884AD6@atlantis.pc.cs.cmu.edu>

--On Wednesday, August 05, 2009 08:53:45 AM -0500 "Douglas E. Engert" 
<deengert at anl.gov> wrote:

> Many of the issues have been addressed in login and screen unlock,
> when credentials are renewed, and pam modules handle obtaining
> additional credentials. Could pam be used from kinit much like screen
> unlock?

Probably not.  Login and screen unlock use PAM for authentication, and 
updating other credentials is done as a side-effect.  In the case of a 
screensaver, you're not starting a new session, so pam_open_session() is 
never called, but pam_setcred(PAM_REFRESH_CRED) is, so modules can handle 
token acquisition at that time.  For a hypothetical kinit, you again 
couldn't call pam_open_session(), but since you're not using PAM for 
authentication, you _also_ can't call pam_setcred, which can be used only 
after pam_authenticate() succeeds.

It's also not portable to platforms that don't use PAM, and unfortunately 
there are still a number of those, probably including some that MIT 
Kerberos cares about.

-- Jeff

From erinn.looneytriggs at gmail.com  Wed Aug  5 16:16:45 2009
From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs)
Date: Wed, 05 Aug 2009 14:16:45 -0600
Subject: Compiling with --with-kdc-kdb-update fails
Message-ID: <4A79E8AD.5000508@gmail.com>

So it looks like this has been an issue for a long time, and I certainly
hope I am not missing some important response about this, my appologies
if I am. This option is not covered in the krb5-install.html guide
(which oddly is referred to by the README as install.html which doesn't
exist) but it is an option when doing a ./configure --help.

Here are the salient errors though these have been documented before:
/usr/bin/ld: Dwarf Error: Offset (2273) greater than or equal to
.debug_str size (942).
do_as_req.o: In function `process_as_req':
/home/looneytr/Download/krb5-1.7/src/kdc/do_as_req.c:695: undefined
reference to `krb5_db_set_name'
/home/looneytr/Download/krb5-1.7/src/kdc/do_as_req.c:697: undefined
reference to `krb5_db_init'


There appears to be three bugs related to this issue:
989 krb5 1.2.2 build fails in kdc/do_as_req.c with --with-kdc-kdb-update
5668 DAL changes break --with-kdc-kdb-update build
5716 Build issues --with-kdc-kdb-update HPUX 11.23 and Linux x86_64

Bug 989 includes a patch and shows its progress as pending though that
is from six years ago.

We have come up with two solutions to this issue though neither is perfect.

One comment/ifdef out this section of code:
krb5_db_fini(kdc_context);
  if (kdc_active_realm->realm_dbname)
    krb5_db_set_name(kdc_active_realm->realm_context,
                     kdc_active_realm->realm_dbname);
  krb5_db_init(kdc_context);
  /* Reset master key */
  krb5_db_set_mkey(kdc_context, &kdc_active_realm->realm_mkey);

Though we are unsure of what those functions do exactly so this does not
seem like a great option.

Or two:
  krb5_db_fini(kdc_context);
  if (kdc_active_realm->realm_dbname)
    if ((errcode =
krb5_set_default_realm(kdc_active_realm->realm_context, kdc_active_realm->
realm_dbname))) {
      return errcode;
    }
  if((errcode = krb5_db_open(kdc_active_realm->realm_context, NULL ,
KRB5_KDB_OPEN_RW | KRB5_
KDB_SRV_TYPE_KDC)))
    return errcode;
  /* Reset master key */
  krb5_db_set_mkey(kdc_context, &kdc_active_realm->realm_mkey);

Though with this option and our testing has yielded a rather sizable
memory leak (couple hundred megs over a couple million kinits).

Both of these were taken from the groups here.

I guess the question that I really have is, is there any planned fix for
this issue or is this option being unofficially deprecated as it is not
referenced in the krb5-install.html? Given that option two above yields
a memory leak is option one a safe one?

Given that this is a rather handy peice of functionality it would be
great if it would continue to be maintained but as this has been broken
for years now I am trying to get a gauge on what the course is for this
particular config option.

Thanks,
-Erinn


From lukeh at padl.com  Fri Aug  7 19:28:43 2009
From: lukeh at padl.com (Luke Howard)
Date: Sat, 8 Aug 2009 01:28:43 +0200
Subject: KRB5KDC_ERR_ETYPE_NOSUPP in protocol transition
In-Reply-To: <3B2A5612-4F71-4BA4-AD57-00ADFB964D64@padl.com>
References: <4A6D70C4.30805@gs-lab.com>
	<6A83EB1F-A560-41E5-8B75-EB2A92F8414C@padl.com>
	<4A6FCED6.6010109@gs-lab.com>
	<3B2A5612-4F71-4BA4-AD57-00ADFB964D64@padl.com>
Message-ID: <ABCC993B-E6C0-4D48-B505-51AE68F3C24D@padl.com>

If anyone is able to test this in a multiple-domain environment, that  
would be great. I've tested in two domains, but it would be good to  
know it works with three and more.

Code in the users/lhoward/s4u branch. Test program in src/tests/gssapi/ 
t_s4u.c.

-- Luke

On 31/07/2009, at 2:01 PM, Luke Howard wrote:

> See http://k5wiki.kerberos.org/wiki/Projects/Services4User, too.
>
> -- Luke
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>

--
www.padl.com | www.fghr.net


From raeburn at MIT.EDU  Wed Aug 12 14:30:22 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Wed, 12 Aug 2009 14:30:22 -0400
Subject: Compiling with --with-kdc-kdb-update fails
In-Reply-To: <4A79E8AD.5000508@gmail.com>
References: <4A79E8AD.5000508@gmail.com>
Message-ID: <69FA945F-0F4C-4FFD-8C8D-1FCC0C8F34B3@mit.edu>

On Aug 5, 2009, at 16:16, Erinn Looney-Triggs wrote:
> So it looks like this has been an issue for a long time, and I  
> certainly
> hope I am not missing some important response about this, my  
> appologies
> if I am.

Yep, it's been there a long while, but your email finally prompted me  
to dust off some patches I had in progress for addressing it.  I've  
just checked in some changes on the development trunk, if you're  
willing to try them out.  My fix is a bit similar to your #2 approach,  
so it's possible the memory leak you encountered may still be there  
for now.

ken

From Qiang.Xu at fujixerox.com  Thu Aug 13 21:22:33 2009
From: Qiang.Xu at fujixerox.com (Xu, Qiang (FXSGSC))
Date: Fri, 14 Aug 2009 09:22:33 +0800
Subject: IPv6 handling in SASL LDAP binding
In-Reply-To: <1b8d56200908130536q3335c4b5l1d2e327f9f7a7d3a@mail.gmail.com>
References: <D8C9BC7FFCF8154FB7141EB8DB609C172DE4ACBA01@SGPAPHQ-EXSCC01.dc01.fujixerox.net>
	<ldvhc072spu.fsf@cathode-dark-space.mit.edu>
	<D8C9BC7FFCF8154FB7141EB8DB609C172DE4CD80D4@SGPAPHQ-EXSCC01.dc01.fujixerox.net>
	<87ab5ysn2t.fsf@windlord.stanford.edu>
	<D8C9BC7FFCF8154FB7141EB8DB609C172DE4CD826E@SGPAPHQ-EXSCC01.dc01.fujixerox.net>
	<D8C9BC7FFCF8154FB7141EB8DB609C172E71BC1EA0@SGPAPHQ-EXSCC01.dc01.fujixerox.net>
	<87ocqtdjib.fsf@windlord.stanford.edu>
	<D8C9BC7FFCF8154FB7141EB8DB609C172E71C06A44@SGPAPHQ-EXSCC01.dc01.fujixerox.net>
	<1b8d56200908070600q71031ea1jebc679b98ef6729e@mail.gmail.com>
	<D8C9BC7FFCF8154FB7141EB8DB609C172E71CB6FCC@SGPAPHQ-EXSCC01.dc01.fujixerox.net>
	<1b8d56200908130536q3335c4b5l1d2e327f9f7a7d3a@mail.gmail.com>
Message-ID: <D8C9BC7FFCF8154FB7141EB8DB609C172E71CFA22A@SGPAPHQ-EXSCC01.dc01.fujixerox.net>

> -----Original Message-----
> From: Andrew Cobaugh [mailto:phalenor at gmail.com] 
> Sent: Thursday, August 13, 2009 8:36 PM
> To: Xu, Qiang (FXSGSC)
> Cc: Alexey Melnikov; kerberos at mit.edu
> Subject: Re: IPv6 handling in SASL LDAP binding
> 
> On Thu, Aug 13, 2009 at 6:41 AM, Xu, Qiang 
> (FXSGSC)<Qiang.Xu at fujixerox.com> wrote:
> >
> > P.S. Can I ask why the numerical IPv6 address is not 
> supported in MIT distribution?
> 
> Using IP addresses in files like krb5.conf is generally 
> discouraged, as it's easier to change a single entry in dns 
> than it is to change a file on every machine. We don't even 
> specify the kdcs in krb5.conf in our environment, relying 
> entirely on srv records for kdc discovery.
> 
> I suppose this could be considered a bug, if anyone cared.

In my testing, I found both hostname and IPv4 address works for kinit (in original MIT distribution), but not IPv6 address: 
=========================================================
/* The content of /etc/krb5.conf with hostname */
[realms]
 XCIPV6.COM = {
  kdc = crius:88
  default_domain = xcipv6.com
 }

/* Kerberos authentication result */
qxu at durian(pts/3):/etc[117]$ kinit XCTEST100 at XCIPV6.COM
Password for XCTEST100 at XCIPV6.COM:
qxu at durian(pts/3):/etc[118]$ klist
Ticket cache: FILE:/tmp/krb5cc_20153
Default principal: XCTEST100 at XCIPV6.COM

Valid starting     Expires            Service principal
08/14/09 09:02:48  08/14/09 19:03:53  krbtgt/XCIPV6.COM at XCIPV6.COM
        renew until 08/15/09 09:02:48

/* The content of /etc/krb5.conf with IPv4 */
[realms]
 XCIPV6.COM = {
  kdc = 13.198.97.42:88
  default_domain = xcipv6.com
 }

/* Kerberos authentication result */
qxu at durian(pts/3):/etc[122]$ klist
Ticket cache: FILE:/tmp/krb5cc_20153
Default principal: XCTEST100 at XCIPV6.COM

Valid starting     Expires            Service principal
08/14/09 09:05:14  08/14/09 19:05:39  krbtgt/XCIPV6.COM at XCIPV6.COM
        renew until 08/15/09 09:05:14

/* The content of /etc/krb5.conf with IPv6 address */
[realms]
 XCIPV6.COM = {
  kdc = [3ffe:2000:0:1::100]:88
  default_domain = xcipv6.com
 }

/* Kerberos authentication result */
qxu at durian(pts/3):/etc[112]$ kinit XCTEST100 at XCIPV6.COM
kinit(v5): Cannot resolve network address for KDC in realm XCIPV6.COM while getting initial credentials
=========================================================
Personally, I think if numerical IPv4 address is supported for kdc entry in /etc/krb5.conf, so should be for numerical IPv6 address. 

Would MIT developers want to fix this as a bug? The related source code is the function "krb5_locate_srv_conf_1()" in the file "krb5-1.7/src/lib/krb5/os/locate_kdc.c".

Thanks,
Xu Qiang


From swm at alcove.com.au  Fri Aug 14 18:28:45 2009
From: swm at alcove.com.au (Gavin Sherry)
Date: Sat, 15 Aug 2009 00:28:45 +0200
Subject: make check fails on AIX 5.3
Message-ID: <73daaa720908141528l4df8ccbbi230c8bd1827f26cd@mail.gmail.com>

Hi all,

I am able to build Kerberos 1.7 on AIX 5.3 (both 32 and 64 bit). However,
neither build passes make check.

configure is only being passed the following: --without-tcl. GCC is version
4.2.4.

The checks which fail are:

t_locate_kdc ATHENA.MIT.EDU
walktree-tests
testdb -r FOO.TEST.REALM -P footes create -s

These all fail in the same way: a assertion fails and core is dumped.

Assertion failed: __EX, file  threads.c, line 350

The back trace always looks something like the follow (here, specifically
for t_locate_kdc):

#0  0xd01247d4 in pthread_kill () from /usr/lib/libpthreads.a(shr_xpg5.o)
#1  0xd0124248 in _p_raise () from /usr/lib/libpthreads.a(shr_xpg5.o)
#2  0xd0356bdc in raise () from /usr/lib/libc.a(shr.o)
#3  0xd03b4efc in abort () from /usr/lib/libc.a(shr.o)
#4  0xd03bfe70 in __assert_c99 () from /usr/lib/libc.a(shr.o)
#5  0xd24af644 in krb5int_key_register (keynum=K5_KEY_COM_ERR,
destructor=@0xf03cfbb4: 0xcf94) at threads.c:350
#6  0xd2201d48 in com_err_initialize () at error_message.c:58
#7  0xd2201c80 in com_err_initialize__aux () at error_message.c:42
#8  0xd0115fb8 in pthread_once () from /usr/lib/libpthreads.a(shr_xpg5.o)
#9  0xd22021a4 in error_message (code=-1429577725) at error_message.c:162
#10 0x10001e9c in krb5_locate_srv_conf_1 (context=0x20009988,
realm=0x2ff22a08, name=0x1000c490 "kdc", addrlist=0x2ff22940, get_masters=0,
socktype=0, udpport=88, sec_udpport=750,
    family=0) at locate_kdc.c:336
#11 0x10003064 in prof_locate_server (context=0x20009988, realm=0x2ff22a08,
addrlist=0x2ff22940, svc=locate_service_kdc, socktype=0, family=0) at
locate_kdc.c:743
#12 0x1000337c in krb5int_locate_server (context=0x20009988,
realm=0x2ff22a08, addrlist=0x20001550, svc=locate_service_kdc, socktype=0,
family=0) at locate_kdc.c:818
#13 0x10003584 in krb5_locate_kdc (context=0x20009988, realm=0x2ff22a08,
addrlist=0x20001550, get_masters=0, socktype=0, family=0) at
locate_kdc.c:862
#14 0x10003ae0 in main (argc=2, argv=0x2ff22ac8) at t_locate_kdc.c:123

The issue is that com_err_initialize() is being called more than once. The
first time, it is done via krb5int_initialize_library(), the second via the
bt above. This should be guarded by pthread_once(), but that's not working
(although, I've verified that in a trivial program pthread_once() is
behaving as expected).

Here's some more debugging info. Before the first call,
com_err_initialize__once is set to:

$2 = {once = {__on_word = {0, 0, 0, 0, 0, 0, 0, 2, 0 <repeats 20 times>}},
error = 0, did_run = 0, fn = @0xf08d61dc: 0xd21f3eb4
<com_err_initialize__aux>}

After the first call:

$4 = {once = {__on_word = {1, 0, 0, 0, 0, 0, 0, 9, 0 <repeats 20 times>}},
error = 0, did_run = 1, fn = @0xf08d61dc: 0xd21f3eb4
<com_err_initialize__aux>}

Before the second call:

$5 = {once = {__on_word = {2, 0, 0, 0, 0, 0, 270008407, 9, 1, 0 <repeats 19
times>}}, error = 0, did_run = 1, fn = @0xf08df2dc: 0xd21eefb4
<com_err_initialize__aux>}

Now, I set a watch point in the debugging to stop when this structure is
changed. GDB does not break between the first and second calls. This might
be a short coming of GDB, I'm not sure.

So, something screwy is happening with pthreads here. Other applications
which use pthreads appear to be working correctly so it's possible this is
something to do with KRB.

This is surely not enough information to go on. Please let me know what
other information I can provide so that we can track down the issue.

Thanks,
Gavin

From raeburn at MIT.EDU  Sat Aug 15 02:17:57 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Sat, 15 Aug 2009 02:17:57 -0400
Subject: make check fails on AIX 5.3
In-Reply-To: <73daaa720908141528l4df8ccbbi230c8bd1827f26cd@mail.gmail.com>
References: <73daaa720908141528l4df8ccbbi230c8bd1827f26cd@mail.gmail.com>
Message-ID: <FF48A27E-FD4A-4FA5-94D3-AD179E978FF9@mit.edu>

On Aug 14, 2009, at 18:28, Gavin Sherry wrote:
> The issue is that com_err_initialize() is being called more than  
> once. The
> first time, it is done via krb5int_initialize_library(), the second  
> via the
> bt above. This should be guarded by pthread_once(), but that's not  
> working
> (although, I've verified that in a trivial program pthread_once() is
> behaving as expected).

Strange....  We do definitely depend on pthread_once behaving itself.

> Here's some more debugging info. Before the first call,
> com_err_initialize__once is set to:
>
> $2 = {once = {__on_word = {0, 0, 0, 0, 0, 0, 0, 2, 0 <repeats 20  
> times>}},
> error = 0, did_run = 0, fn = @0xf08d61dc: 0xd21f3eb4
> <com_err_initialize__aux>}
>
> After the first call:
>
> $4 = {once = {__on_word = {1, 0, 0, 0, 0, 0, 0, 9, 0 <repeats 20  
> times>}},
> error = 0, did_run = 1, fn = @0xf08d61dc: 0xd21f3eb4
> <com_err_initialize__aux>}
>
> Before the second call:
>
> $5 = {once = {__on_word = {2, 0, 0, 0, 0, 0, 270008407, 9, 1, 0  
> <repeats 19
> times>}}, error = 0, did_run = 1, fn = @0xf08df2dc: 0xd21eefb4
> <com_err_initialize__aux>}

I'm not 100% sure when you say "call" which function you're referring  
to.  Is "after the first call" after com_err_initialize__aux returns  
but pthread_once is still in progress, or after pthread_once returns?

It's also very interesting to me, though, that the "fn" field changes  
value in between $4 and $5, but it still seems to refer to the same  
function address.  Is it possible two copies of the library have been  
loaded at different addresses, with different com_err_initialize__*  
values, but sharing a common libkrb5support library with its internal  
thread-support data?  If that's so, I could imagine gdb showing you  
different locations for "print com_err_initialize__once" depending on  
the current execution context.  Try printing the addresses of these  
symbols in each context, and/or using "info sharedlibrary" in gdb.

Getting only one copy of the krb5 library (and friends) is also kind  
of assumed in our code -- or, at least, if you get multiple copies,  
you get multiple copies of the whole set with symbolic references  
resolved within each set.  We may or may not be setting all the right  
flags to encourage the OS to make the latter happen....

> Now, I set a watch point in the debugging to stop when this  
> structure is
> changed. GDB does not break between the first and second calls. This  
> might
> be a short coming of GDB, I'm not sure.

Yeah, there are sometimes environments or cases where it doesn't seem  
to work well.  Make sure you report that, especially if you can narrow  
down a simple test case.  If your watch expression is something like  
"com_err_initialize__once.once.__on_word[0]", and the problem really  
is loading two libraries (or copies of the same library) that define  
com_err_initialize__once, it's an interesting question whether the  
watchpoint should trip as a result of the execution location (program  
counter) changing so that gdb would find one version of the variable  
instead of the other.  But if it is the same location the whole time,  
and it changes without the watchpoint tripping, it sounds like a gdb  
bug.

Ken

From ghudson at MIT.EDU  Mon Aug 17 15:41:00 2009
From: ghudson at MIT.EDU (ghudson@MIT.EDU)
Date: Mon, 17 Aug 2009 15:41:00 -0400 (EDT)
Subject: Heads up: kadm5 initialization API change in 1.8
Message-ID: <200908171941.n7HJf0io014438@outgoing.mit.edu>

In http://mailman.mit.edu/pipermail/kerberos/2009-August/015186.html
it was noted that kadmin.local isn't printing extended error messages
under most circumstances.

This is because libkadm5 uses its own internal context inside server
handles.  My understanding is that krb5 contexts used to be considered
cheap, so it was fine to keep a bunch of them around for no reason
other than API convenience, but that's not true now that we have
extended error messages.  The presence of multiple contexts makes it
much less likely that good error information will make its way back to
the user.

In kadm5/admin.h we include the disclaimer:

 * - We may make arbitrary incompatible changes between feature
 *   releases (e.g. from 1.7 to 1.8).

Taking advantage of that liberty, I have modified all of the
kadm5_init functions on the trunk to accept a krb5_context parameter.
A comment indicates that the context must be initialized with
kadm5_init_krb5_context, that the context must survive as long as the
server handle, and that it is the caller's responsibility to free the
context.

From rra at stanford.edu  Mon Aug 17 15:48:47 2009
From: rra at stanford.edu (Russ Allbery)
Date: Mon, 17 Aug 2009 12:48:47 -0700
Subject: Heads up: kadm5 initialization API change in 1.8
In-Reply-To: <200908171941.n7HJf0io014438@outgoing.mit.edu> (ghudson@mit.edu's
	message of "Mon, 17 Aug 2009 15:41:00 -0400 (EDT)")
References: <200908171941.n7HJf0io014438@outgoing.mit.edu>
Message-ID: <87ws52cjc0.fsf@windlord.stanford.edu>

ghudson at mit.edu writes:

> In kadm5/admin.h we include the disclaimer:

>  * - We may make arbitrary incompatible changes between feature
>  *   releases (e.g. from 1.7 to 1.8).

> Taking advantage of that liberty, I have modified all of the kadm5_init
> functions on the trunk to accept a krb5_context parameter.  A comment
> indicates that the context must be initialized with
> kadm5_init_krb5_context, that the context must survive as long as the
> server handle, and that it is the caller's responsibility to free the
> context.

I didn't see a Makefile patch in your commit, so just to double-check:  I
believe this change to a function signature makes the new shared library
ABI incompatible with the previous ABI and therefore requires a version
increase in the SONAME.

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

From ghudson at MIT.EDU  Mon Aug 17 16:07:56 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Mon, 17 Aug 2009 16:07:56 -0400
Subject: Heads up: kadm5 initialization API change in 1.8
In-Reply-To: <87ws52cjc0.fsf@windlord.stanford.edu>
References: <200908171941.n7HJf0io014438@outgoing.mit.edu>
	<87ws52cjc0.fsf@windlord.stanford.edu>
Message-ID: <1250539676.6898.58.camel@ray>

On Mon, 2009-08-17 at 15:48 -0400, Russ Allbery wrote:
> I didn't see a Makefile patch in your commit, so just to double-check:  I
> believe this change to a function signature makes the new shared library
> ABI incompatible with the previous ABI and therefore requires a version
> increase in the SONAME.

Done.  Thanks for the reminder.



From Nicolas.Williams at sun.com  Mon Aug 17 16:06:28 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 17 Aug 2009 15:06:28 -0500
Subject: Heads up: kadm5 initialization API change in 1.8
In-Reply-To: <200908171941.n7HJf0io014438@outgoing.mit.edu>
References: <200908171941.n7HJf0io014438@outgoing.mit.edu>
Message-ID: <20090817200627.GZ1043@Sun.COM>

On Mon, Aug 17, 2009 at 03:41:00PM -0400, ghudson at mit.edu wrote:
> This is because libkadm5 uses its own internal context inside server
> handles.  My understanding is that krb5 contexts used to be considered
> cheap, so it was fine to keep a bunch of them around for no reason
> other than API convenience, but that's not true now that we have
> extended error messages.  The presence of multiple contexts makes it
> much less likely that good error information will make its way back to
> the user.

But all the kadm5 server functions already take a server handle, and
that server handle already has a krb5_context field, so it should be
possible to always use the same krb5_context.  What am I missing?

Nico
-- 

From manojm at us.ibm.com  Mon Aug 17 16:42:15 2009
From: manojm at us.ibm.com (Manoj Mohan)
Date: Mon, 17 Aug 2009 15:42:15 -0500
Subject: Not able to find to kadmin, kdb5_util
Message-ID: <OFDACDF55F.8C6517EF-ON87257615.007113E2-86257615.0071B87D@us.ibm.com>





Hi,

Do I need to install something special on HP-UX. I can see that patches
look good..

[rp5470e6:/opt/krb5core] uname -a
HP-UX rp5470e6 B.11.11 U 9000/800 1194494646 unlimited-user license

#swlist -lproduct | grep -i gss
  GSS-API               B.11.11        GSS-API Version 1.0
  PHSS_29487            1.0            GSS-API Version 1.0 Cumulative patch

[rp5470e6:/opt/krb5core] ls
bin/      contrib/  include/  lib/      sbin/     share/.
[rp5470e6:/opt/krb5core] ls bin
kdestroy*  kinit*     klist*     kpasswd*   kvno*
[rp5470e6:/opt/krb5core] ls sbin
ktutil*

I don't see the admin directory in /opt/krb5core which we usually see the
kdmain/kdamin.local and/or kdb5_util.

Regards,
Manoj

From ghudson at MIT.EDU  Mon Aug 17 18:50:57 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Mon, 17 Aug 2009 18:50:57 -0400
Subject: Heads up: kadm5 initialization API change in 1.8
In-Reply-To: <20090817200627.GZ1043@Sun.COM>
References: <200908171941.n7HJf0io014438@outgoing.mit.edu>
	<20090817200627.GZ1043@Sun.COM>
Message-ID: <1250549457.6898.60.camel@ray>

On Mon, 2009-08-17 at 16:06 -0400, Nicolas Williams wrote:
> But all the kadm5 server functions already take a server handle, and
> that server handle already has a krb5_context field, so it should be
> possible to always use the same krb5_context.  What am I missing?

Prior to my change, the caller has no access to that context.  Moreover,
if a failure happens during initialization (which is the most common
case), the context is destroyed before the caller receives the error
code, taking with it any hope of retrieving the extended error
information.



From Nicolas.Williams at sun.com  Mon Aug 17 18:56:35 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 17 Aug 2009 17:56:35 -0500
Subject: Heads up: kadm5 initialization API change in 1.8
In-Reply-To: <1250549457.6898.60.camel@ray>
References: <200908171941.n7HJf0io014438@outgoing.mit.edu>
	<20090817200627.GZ1043@Sun.COM> <1250549457.6898.60.camel@ray>
Message-ID: <20090817225635.GE1043@Sun.COM>

On Mon, Aug 17, 2009 at 06:50:57PM -0400, Greg Hudson wrote:
> On Mon, 2009-08-17 at 16:06 -0400, Nicolas Williams wrote:
> > But all the kadm5 server functions already take a server handle, and
> > that server handle already has a krb5_context field, so it should be
> > possible to always use the same krb5_context.  What am I missing?
> 
> Prior to my change, the caller has no access to that context.  Moreover,
> if a failure happens during initialization (which is the most common
> case), the context is destroyed before the caller receives the error
> code, taking with it any hope of retrieving the extended error
> information.

Got it.

Thanks.

From tlyu at MIT.EDU  Mon Aug 17 19:15:38 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Mon, 17 Aug 2009 19:15:38 -0400
Subject: krb5 anonymous SVN repository migrated
Message-ID: <ldv1vnaqbfp.fsf@cathode-dark-space.mit.edu>

The anonymous-access SVN repository for the MIT krb5 source tree
(anonsvn.mit.edu) has been migrated to a different host.  The SVN URL
remains the same:

    svn://anonsvn.mit.edu/krb5

The ViewVC source browser also remains accessible at

    http://anonsvn.mit.edu/viewvc/krb5/

though many people probably prefer the FishEye source browser at

    http://src.mit.edu/fisheye/browse/krb5

The IP address and host for anonsvn.mit.edu have changed, but there
should be no visible change in functionality.  Please let us know if
you notice problems with this migration.  Thanks.

-- 
Tom Yu
Development Team Leader
MIT Kerberos Consortium

From lukeh at padl.com  Tue Aug 18 09:24:25 2009
From: lukeh at padl.com (Luke Howard)
Date: Tue, 18 Aug 2009 15:24:25 +0200
Subject: Services4User review
Message-ID: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>

Hello,

I'd love some feedback on the S4U2{Self,Proxy} design at:

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

(particularly the "Open Issues" section)

Implementation is in the users/lhoward/s4u branch.

cheers,

-- Luke

--
www.padl.com | www.fghr.net

From ghudson at MIT.EDU  Tue Aug 18 09:58:31 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Tue, 18 Aug 2009 09:58:31 -0400
Subject: Integration of k5start/krenew functionality
In-Reply-To: <200907311906.n6VJ63pH013021@outgoing.mit.edu>
References: <200907311906.n6VJ63pH013021@outgoing.mit.edu>
Message-ID: <1250603911.6898.73.camel@ray>

After further consideration, it appears that kstart meets the current
needs for process credential management, as long as it is being
maintained, and there is no need to duplicate a subset of that
functionality in the krb5 tree.

This functionality might rear its head again in the context of a Unix
CCAPI port, for which there are other possible drivers, but that hasn't
been fleshed out enough for a full project proposal.

Thanks for the educational feedback.



From swm at alcove.com.au  Tue Aug 18 11:49:43 2009
From: swm at alcove.com.au (Gavin Sherry)
Date: Tue, 18 Aug 2009 17:49:43 +0200
Subject: make check fails on AIX 5.3
In-Reply-To: <FF48A27E-FD4A-4FA5-94D3-AD179E978FF9@mit.edu>
References: <73daaa720908141528l4df8ccbbi230c8bd1827f26cd@mail.gmail.com>
	<FF48A27E-FD4A-4FA5-94D3-AD179E978FF9@mit.edu>
Message-ID: <73daaa720908180849h31ccf28v84f78aa9c0145c64@mail.gmail.com>

2009/8/15 Ken Raeburn <raeburn at mit.edu>

> On Aug 14, 2009, at 18:28, Gavin Sherry wrote:
>
>> The issue is that com_err_initialize() is being called more than once. The
>> first time, it is done via krb5int_initialize_library(), the second via
>> the
>> bt above. This should be guarded by pthread_once(), but that's not working
>> (although, I've verified that in a trivial program pthread_once() is
>> behaving as expected).
>>
>
> Strange....  We do definitely depend on pthread_once behaving itself.
>

Yes, it seems like a reasonable expectation :).


>
>
>  Here's some more debugging info. Before the first call,
>> com_err_initialize__once is set to:
>>
>> $2 = {once = {__on_word = {0, 0, 0, 0, 0, 0, 0, 2, 0 <repeats 20 times>}},
>> error = 0, did_run = 0, fn = @0xf08d61dc: 0xd21f3eb4
>> <com_err_initialize__aux>}
>>
>> After the first call:
>>
>> $4 = {once = {__on_word = {1, 0, 0, 0, 0, 0, 0, 9, 0 <repeats 20 times>}},
>> error = 0, did_run = 1, fn = @0xf08d61dc: 0xd21f3eb4
>> <com_err_initialize__aux>}
>>
>> Before the second call:
>>
>> $5 = {once = {__on_word = {2, 0, 0, 0, 0, 0, 270008407, 9, 1, 0 <repeats
>> 19
>> times>}}, error = 0, did_run = 1, fn = @0xf08df2dc: 0xd21eefb4
>> <com_err_initialize__aux>}
>>
>
> I'm not 100% sure when you say "call" which function you're referring to.
>  Is "after the first call" after com_err_initialize__aux returns but
> pthread_once is still in progress, or after pthread_once returns?


I'll make this clearer:

Here's the value before pthread_once() is invoked:

$1 = {once = {__on_word = {0, 0, 0, 0, 0, 0, 270246039, 9, 1, 0 <repeats 19
times>}}, error = 0, did_run = 0,
  fn = @0xf08d61dc: 0xd21f3eb4 <com_err_initialize__aux>}

Once pthread_once() is invoked, this is changed to:

$2 = {once = {__on_word = {2, 0, 0, 0, 0, 0, 270246039, 9, 1, 0 <repeats 19
times>}}, error = 0, did_run = 0,
  fn = @0xf08d61dc: 0xd21f3eb4 <com_err_initialize__aux>}

At the end of pthread_once():

$3 = {once = {__on_word = {1, 0, 0, 0, 0, 0, 270246039, 9, 1, 0 <repeats 19
times>}}, error = 0, did_run = 1,
  fn = @0xf08d61dc: 0xd21f3eb4 <com_err_initialize__aux>}

Then, when com_err_initialize__aux() is invoked again:

$4 = {once = {__on_word = {2, 0, 0, 0, 0, 0, 270246039, 9, 1, 0 <repeats 19
times>}}, error = 0, did_run = 0,
  fn = @0xf08df2dc: 0xd21eefb4 <com_err_initialize__aux>}

It does not break inside pthread_once() here, when it detects the data
change. I think your theory looks correct. At the first call to
com_err_initialize__aux:

(gdb) print &com_err_initialize__once
$6 = (k5_init_t *) 0xf08d600c

And the second time:

(gdb) print &com_err_initialize__once
$7 = (k5_init_t *) 0xf08df10c

Oh, and this:

(gdb) break error_message
Breakpoint 4 at 0xd21f48d0: file error_message.c, line 121. (2 locations)

(gdb) info watchpoints
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   <MULTIPLE> 0xd21f3ec8
        breakpoint already hit 1 time
1.1                         y     0xd21f3ec8 in com_err_initialize__aux at
error_message.c:126
1.2                         y     0xd21eefc8 in com_err_initialize__aux at
error_message.c:126
...

So, it seems that the libraries are loaded twice. I'm not sure how to fix
this though.

>
>
> It's also very interesting to me, though, that the "fn" field changes value
> in between $4 and $5, but it still seems to refer to the same function
> address.


Excellent point.


>  Is it possible two copies of the library have been loaded at different
> addresses, with different com_err_initialize__* values, but sharing a common
> libkrb5support library with its internal thread-support data?  If that's so,
> I could imagine gdb showing you different locations for "print
> com_err_initialize__once" depending on the current execution context.  Try
> printing the addresses of these symbols in each context, and/or using "info
> sharedlibrary" in gdb.
>

Right. So, the first time com_err_initialize__aux() (stopped at the that
function):

(gdb) info sharedlibrary
Text Range              Data Range              Syms    Shared Object
Library
0xd0142124-0xd0145cee   0xf047d000-0xf04bf4c8   Yes
/usr/lib/libpthreads.a(shr_comm.o)
0xd0961d80-0xd0aead7f   0xf04c44c8-0xf0532638   Yes
/usr/lib/librtl.a(shr.o)
0xd21f8150-0xd2200a6b   0xf08d0bc0-0xf08d1284   Yes
/home/build/gsherry/tools/krb5/1.6.2/dist/aix5_ppc_32/lib/libkrb5support.so
0xd21f3150-0xd21f7021   0xf08d5f70-0xf08d63c8   Yes
/home/build/gsherry/tools/krb5/1.6.2/dist/aix5_ppc_32/lib/libcom_err.so
0xd246b150-0xd24acaac   0xf08d2f46-0xf08d4740   Yes
/home/build/gsherry/tools/krb5/1.6.2/dist/aix5_ppc_32/lib/libk5crypto.so
0xd0274180-0xd02a4ccb   0xf020f000-0xf0213048   Yes
/usr/lib/libpthreads.a(shr.o)
0xd014121c-0xd014193e   0xf0427508-0xf0427630   Yes
/usr/lib/libcrypt.a(shr.o)
0xd21ee250-0xd21f2121   0xf08df070-0xf08df4c8   Yes
/home/build/gsherry/tools/krb5/1.6.2/dist/aix5_ppc_32/lib/libcom_err.a(libcom_err.so)
0xd21e52d0-0xd21edbeb   0xf08ddd40-0xf08de404   Yes
/home/build/gsherry/tools/krb5/1.6.2/dist/aix5_ppc_32/lib/libkrb5support.a(libkrb5support.so)
0xd238b250-0xd246a4b6   0xf08d7556-0xf08dc540   Yes
/home/build/gsherry/tools/krb5/1.6.2/dist/aix5_ppc_32/lib/libkrb5.a(libkrb5.so)
0xd019721c-0xd01988ae   0xf02140f8-0xf02140f8   Yes
/usr/lib/libpthreads_compat.a(shr.o)
0xd0336500-0xd05e390d   0xf037eb40-0xf04266d8   Yes
/usr/lib/libc.a(shr.o)

Second time we call the function:

(gdb) info sharedlibrary
Text Range              Data Range              Syms    Shared Object
Library
0xd0142124-0xd0145cee   0xf047d000-0xf04bf4c8   Yes
/usr/lib/libpthreads.a(shr_comm.o)
0xd0961d80-0xd0aead7f   0xf04c44c8-0xf0532638   Yes
/usr/lib/librtl.a(shr.o)
0xd21f8150-0xd2200a6b   0xf08d0bc0-0xf08d1284   Yes
/home/build/gsherry/tools/krb5/1.6.2/dist/aix5_ppc_32/lib/libkrb5support.so
0xd21f3150-0xd21f7021   0xf08d5f70-0xf08d63c8   Yes
/home/build/gsherry/tools/krb5/1.6.2/dist/aix5_ppc_32/lib/libcom_err.so
0xd246b150-0xd24acaac   0xf08d2f46-0xf08d4740   Yes
/home/build/gsherry/tools/krb5/1.6.2/dist/aix5_ppc_32/lib/libk5crypto.so
0xd0274180-0xd02a4ccb   0xf020f000-0xf0213048   Yes
/usr/lib/libpthreads.a(shr.o)
0xd014121c-0xd014193e   0xf0427508-0xf0427630   Yes
/usr/lib/libcrypt.a(shr.o)
0xd21ee250-0xd21f2121   0xf08df070-0xf08df4c8   Yes
/home/build/gsherry/tools/krb5/1.6.2/dist/aix5_ppc_32/lib/libcom_err.a(libcom_err.so)
0xd21e52d0-0xd21edbeb   0xf08ddd40-0xf08de404   Yes
/home/build/gsherry/tools/krb5/1.6.2/dist/aix5_ppc_32/lib/libkrb5support.a(libkrb5support.so)
0xd238b250-0xd246a4b6   0xf08d7556-0xf08dc540   Yes
/home/build/gsherry/tools/krb5/1.6.2/dist/aix5_ppc_32/lib/libkrb5.a(libkrb5.so)
0xd019721c-0xd01988ae   0xf02140f8-0xf02140f8   Yes
/usr/lib/libpthreads_compat.a(shr.o)
0xd0336500-0xd05e390d   0xf037eb40-0xf04266d8   Yes
/usr/lib/libc.a(shr.o)


>
> Getting only one copy of the krb5 library (and friends) is also kind of
> assumed in our code -- or, at least, if you get multiple copies, you get
> multiple copies of the whole set with symbolic references resolved within
> each set.  We may or may not be setting all the right flags to encourage the
> OS to make the latter happen....


Some of the krb5 libraries seem to be duplicated above.


>
>
>  Now, I set a watch point in the debugging to stop when this structure is
>> changed. GDB does not break between the first and second calls. This might
>> be a short coming of GDB, I'm not sure.
>>
>
> Yeah, there are sometimes environments or cases where it doesn't seem to
> work well.  Make sure you report that, especially if you can narrow down a
> simple test case.  If your watch expression is something like
> "com_err_initialize__once.once.__on_word[0]", and the problem really is
> loading two libraries (or copies of the same library) that define
> com_err_initialize__once, it's an interesting question whether the
> watchpoint should trip as a result of the execution location (program
> counter) changing so that gdb would find one version of the variable instead
> of the other.  But if it is the same location the whole time, and it changes
> without the watchpoint tripping, it sounds like a gdb bug.
>

I'll investigate that.


>
> Ken
>

Thanks,
Gavin

From swm at alcove.com.au  Tue Aug 18 12:02:10 2009
From: swm at alcove.com.au (Gavin Sherry)
Date: Tue, 18 Aug 2009 18:02:10 +0200
Subject: make check fails on AIX 5.3
In-Reply-To: <73daaa720908180849h31ccf28v84f78aa9c0145c64@mail.gmail.com>
References: <73daaa720908141528l4df8ccbbi230c8bd1827f26cd@mail.gmail.com>
	<FF48A27E-FD4A-4FA5-94D3-AD179E978FF9@mit.edu>
	<73daaa720908180849h31ccf28v84f78aa9c0145c64@mail.gmail.com>
Message-ID: <73daaa720908180902y48ef7e33ya2a2abdce60d4c67@mail.gmail.com>

2009/8/18 Gavin Sherry <swm at alcove.com.au>

>
> It does not break inside pthread_once() here, when it detects the data
> change. I think your theory looks correct. At the first call to
> com_err_initialize__aux:
>
> (gdb) print &com_err_initialize__once
> $6 = (k5_init_t *) 0xf08d600c
>
> And the second time:
>
> (gdb) print &com_err_initialize__once
> $7 = (k5_init_t *) 0xf08df10c
>
> Oh, and this:
>
> (gdb) break error_message
> Breakpoint 4 at 0xd21f48d0: file error_message.c, line 121. (2 locations)
>
> (gdb) info watchpoints
> Num     Type           Disp Enb Address    What
> 1       breakpoint     keep y   <MULTIPLE> 0xd21f3ec8
>         breakpoint already hit 1 time
> 1.1                         y     0xd21f3ec8 in com_err_initialize__aux at
> error_message.c:126
> 1.2                         y     0xd21eefc8 in com_err_initialize__aux at
> error_message.c:126
> ...
>
> So, it seems that the libraries are loaded twice. I'm not sure how to fix
> this though.
>

The actual GCC command line being run is:

gcc -L../../../lib
-Wl,-blibpath:/home/build/gsherry/tools/krb5/1.6.2/dist/aix5_ppc_32/lib::/usr/lib:/lib
-g -O0 -D_THREAD_SAFE  -L/usr/lib/threads
-DLIBDIR=\"/home/build/gsherry/tools/krb5/1.6.2/dist/aix5_ppc_32/lib\"
-I../../../include -I./../../../include -I./../../../util/profile
-DKRB5_DEPRECATED=1 -DKRB5_PRIVATE=1  -g -O0 -D_THREAD_SAFE   -o
t_locate_kdc t_locate_kdc.o \
        -lkrb5 -lk5crypto -lcom_err -lkrb5support  -lpthreads_compat
-lpthreads

The -lpthreads_compat was added by me at the recommendation of a IBM
threading support list but it has no effect. The reasons are the same with
and without it.

Removing the -Wl,-blibpath string doesn't help either.

Thanks,
Gavin

From rra at stanford.edu  Tue Aug 18 14:01:35 2009
From: rra at stanford.edu (Russ Allbery)
Date: Tue, 18 Aug 2009 11:01:35 -0700
Subject: Integration of k5start/krenew functionality
In-Reply-To: <1250603911.6898.73.camel@ray> (Greg Hudson's message of "Tue, 18
	Aug 2009 09:58:31 -0400")
References: <200907311906.n6VJ63pH013021@outgoing.mit.edu>
	<1250603911.6898.73.camel@ray>
Message-ID: <87my5xrog0.fsf@windlord.stanford.edu>

Greg Hudson <ghudson at MIT.EDU> writes:

> After further consideration, it appears that kstart meets the current
> needs for process credential management, as long as it is being
> maintained, and there is no need to duplicate a subset of that
> functionality in the krb5 tree.

> This functionality might rear its head again in the context of a Unix
> CCAPI port, for which there are other possible drivers, but that hasn't
> been fleshed out enough for a full project proposal.

I'd be very happy to work with you on supporting the CCAPI in k5start and
krenew when that time comes, although I can't promise a specific timeline
since I maintain k5start between higher-priority work projects.

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

From swm at alcove.com.au  Thu Aug 20 02:51:59 2009
From: swm at alcove.com.au (Gavin Sherry)
Date: Thu, 20 Aug 2009 08:51:59 +0200
Subject: make check fails on AIX 5.3
In-Reply-To: <73daaa720908180902y48ef7e33ya2a2abdce60d4c67@mail.gmail.com>
References: <73daaa720908141528l4df8ccbbi230c8bd1827f26cd@mail.gmail.com>
	<FF48A27E-FD4A-4FA5-94D3-AD179E978FF9@mit.edu>
	<73daaa720908180849h31ccf28v84f78aa9c0145c64@mail.gmail.com>
	<73daaa720908180902y48ef7e33ya2a2abdce60d4c67@mail.gmail.com>
Message-ID: <73daaa720908192351p2bf3ad16mb7cd27a5cd46ac06@mail.gmail.com>

2009/8/18 Gavin Sherry <swm at alcove.com.au>

> 2009/8/18 Gavin Sherry <swm at alcove.com.au>
>
>>
>> It does not break inside pthread_once() here, when it detects the data
>> change. I think your theory looks correct. At the first call to
>> com_err_initialize__aux:
>>
>> (gdb) print &com_err_initialize__once
>> $6 = (k5_init_t *) 0xf08d600c
>>
>> And the second time:
>>
>> (gdb) print &com_err_initialize__once
>> $7 = (k5_init_t *) 0xf08df10c
>>
>> Oh, and this:
>>
>> (gdb) break error_message
>> Breakpoint 4 at 0xd21f48d0: file error_message.c, line 121. (2 locations)
>>
>> (gdb) info watchpoints
>> Num     Type           Disp Enb Address    What
>> 1       breakpoint     keep y   <MULTIPLE> 0xd21f3ec8
>>         breakpoint already hit 1 time
>> 1.1                         y     0xd21f3ec8 in com_err_initialize__aux at
>> error_message.c:126
>> 1.2                         y     0xd21eefc8 in com_err_initialize__aux at
>> error_message.c:126
>> ...
>>
>> So, it seems that the libraries are loaded twice. I'm not sure how to fix
>> this though.
>>
>
> The actual GCC command line being run is:
>
> gcc -L../../../lib
> -Wl,-blibpath:/home/build/gsherry/tools/krb5/1.6.2/dist/aix5_ppc_32/lib::/usr/lib:/lib
> -g -O0 -D_THREAD_SAFE  -L/usr/lib/threads
> -DLIBDIR=\"/home/build/gsherry/tools/krb5/1.6.2/dist/aix5_ppc_32/lib\"
> -I../../../include -I./../../../include -I./../../../util/profile
> -DKRB5_DEPRECATED=1 -DKRB5_PRIVATE=1  -g -O0 -D_THREAD_SAFE   -o
> t_locate_kdc t_locate_kdc.o \
>         -lkrb5 -lk5crypto -lcom_err -lkrb5support  -lpthreads_compat
> -lpthreads
>
> The -lpthreads_compat was added by me at the recommendation of a IBM
> threading support list but it has no effect. The reasons are the same with
> and without it.
>
> Removing the -Wl,-blibpath string doesn't help either.
>

Running with the duplicate library idea, I arranged for LDFLAGS to be set to
-Xlinker -brtl. This tells the linker to prefer shared over non-shared
libraries and presumably prevents linking against both formats. -brtl is
used already in the build process, but only when generating shared libraries
themselves. Having this argument passed to the linker for executables fixes
the problem, with all checks now passing on AIX 5.3.

Thanks,
Gavin

From Nicolas.Williams at sun.com  Thu Aug 20 15:06:44 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 20 Aug 2009 14:06:44 -0500
Subject: Services4User review
In-Reply-To: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
Message-ID: <20090820190644.GD1043@Sun.COM>

On Tue, Aug 18, 2009 at 03:24:25PM +0200, Luke Howard wrote:
> I'd love some feedback on the S4U2{Self,Proxy} design at:
> 
> 	http://k5wiki.kerberos.org/wiki/Projects/Services4User
> 
> (particularly the "Open Issues" section)

The description of the GSS functions is not enough for me to understand
them.  But in any case, I see both of these as credential
handle-centric, not security context-centric.

So I would propose GSS extensions for obtaining S4U2Proxy credentials
handles from delegated credential handles returned by
GSS_Accept_sec_context().

Delegated credential handles need not correspond to delegated
credentials in the RFC1964/4121 sense, nor should it be necessary that
the caller of GSS_Init_sec_context() have explicitly requested
credential delegation -- in the S4U2{Self,Proxy} the delegation is
specified in the authz-data of the initiator's service Ticket, and the
decision to delegate could be made by the KDC.

One wrinkle: is it OK for GSS_Accept_sec_context() to return delegated
credentials when the initiator did not explicitly request it but the
mechanism either does it by its own nature (e.g., LIPKEY) or a third
part forces it (e.g., a KDC with S4U2Proxy support)?  IMO yes, it would
be, but see below.  However, others might disagree, and that's the only
case in which I think we might need a security context-specific
extensions: to allow the acceptor to accept S4U2Proxy creds, and to
allow traditional delegated creds and S4U2Proxy creds to be separated.

Another wrinkle: what if a client does delegate a credential in the
RFC1964/4121 sense _and_ its KDC does the S4U2Proxy thing?  If you call
GSS_Store_cred() on the delegated credential handle you'd lose the
S4U2Proxy component in existing implementations.  But this is a local
matter, easily fixed.

My proposal:

 - Let gss_accept_sec_context() always output a delegated cred handle in
   the krb5 case, even when there's no traditional credential delegation
   on the part of the initiator.  Let gss_store_cred() fail if there's
   no traditional "forwarded Ticket" in the delegated credential.

 - For S4U2Proxy add gss_acquire_cred_impersonate_deleg() with two
   credential handle inputs:

    - service_cred_handle (the caller's own cred handle)
    - subject_cred_handle (the delegated credential whose subject is to
      be impersonated)

   and let it output a new cred handle corresponding to "the subject as
   impersonated by the service".

 - For S4U2Self add gss_acquire_cred_impersonate() with these inputs:

    - desired_subject_name (the name of the subject to impersonate)
    - input_cred_handle (the service's own credentials)
    - desired_cred_usage (the type of desired credentials)
    - desired_mechs (set of mechanism OIDs for which creds are desired)
    - time_req (requested credential lifetime)

   and which outputs a new cred handle corresponding to the "the desired
   subject as impersonated by the service".

Also, are you sure that there are no non-GSS-API applications where
S4U2{self,Proxy} might be needed?

Nico
-- 

From Nicolas.Williams at sun.com  Thu Aug 20 15:50:21 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 20 Aug 2009 14:50:21 -0500
Subject: Services4User review
In-Reply-To: <20090820190644.GD1043@Sun.COM>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
Message-ID: <20090820195021.GG1043@Sun.COM>

On Thu, Aug 20, 2009 at 02:06:44PM -0500, Nicolas Williams wrote:
>  - For S4U2Proxy add gss_acquire_cred_impersonate_deleg() with two
>    credential handle inputs:

Er, gss_acquire_cred_impersonate_cred() would be a better name.

>  - For S4U2Self add gss_acquire_cred_impersonate() with these inputs:

And here gss_acquire_cred_impersonate_name() would be a better name too.

From lukeh at padl.com  Thu Aug 20 16:33:06 2009
From: lukeh at padl.com (Luke Howard)
Date: Thu, 20 Aug 2009 22:33:06 +0200
Subject: Services4User review
In-Reply-To: <20090820190644.GD1043@Sun.COM>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
Message-ID: <342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>

Hi Nico,

> Delegated credential handles need not correspond to delegated
> credentials in the RFC1964/4121 sense, nor should it be necessary that
> the caller of GSS_Init_sec_context() have explicitly requested
> credential delegation -- in the S4U2{Self,Proxy} the delegation is
> specified in the authz-data of the initiator's service Ticket, and the
> decision to delegate could be made by the KDC.

I'm not sure if I understand this: could you point me to where in [MS- 
SFU] it says that delegation is specified in the authorization data of  
the initiator's service ticket?

> One wrinkle: is it OK for GSS_Accept_sec_context() to return delegated
> credentials when the initiator did not explicitly request it but the
> mechanism either does it by its own nature (e.g., LIPKEY) or a third
> part forces it (e.g., a KDC with S4U2Proxy support)?  IMO yes, it  
> would
> be, but see below.  However, others might disagree, and that's the  
> only
> case in which I think we might need a security context-specific
> extensions: to allow the acceptor to accept S4U2Proxy creds, and to
> allow traditional delegated creds and S4U2Proxy creds to be separated.
>
> Another wrinkle: what if a client does delegate a credential in the
> RFC1964/4121 sense _and_ its KDC does the S4U2Proxy thing?  If you  
> call
> GSS_Store_cred() on the delegated credential handle you'd lose the
> S4U2Proxy component in existing implementations.  But this is a local
> matter, easily fixed.

In practice I'm not sure if this is a big issue. In the current  
implementation unconstrained delegation (ie. forwarded credentials)  
take precedence.

> - Let gss_accept_sec_context() always output a delegated cred handle  
> in
>   the krb5 case, even when there's no traditional credential  
> delegation
>   on the part of the initiator.  Let gss_store_cred() fail if there's
>   no traditional "forwarded Ticket" in the delegated credential.

Note we don't have gss_store_cred() yet.

> - For S4U2Proxy add gss_acquire_cred_impersonate_deleg() with two
>   credential handle inputs:
>
>    - service_cred_handle (the caller's own cred handle)
>    - subject_cred_handle (the delegated credential whose subject is to
>      be impersonated)
>
>   and let it output a new cred handle corresponding to "the subject as
>   impersonated by the service".

Where does one specify the service to which to delegate to? Would that  
be another input?

> - For S4U2Self add gss_acquire_cred_impersonate() with these inputs:
>
>    - desired_subject_name (the name of the subject to impersonate)
>    - input_cred_handle (the service's own credentials)
>    - desired_cred_usage (the type of desired credentials)
>    - desired_mechs (set of mechanism OIDs for which creds are desired)
>    - time_req (requested credential lifetime)
>
>   and which outputs a new cred handle corresponding to the "the  
> desired
>   subject as impersonated by the service".

OK, this looks reasonable.

> Also, are you sure that there are no non-GSS-API applications where
> S4U2{self,Proxy} might be needed?


I'm not sure, but I think for 1.8 I'd prefer to expose at GSS-API  
first, and then for a future release we can think about exposing the  
underlying krb5 APIs. I don't feel too strongly about this though.

How do others feel about this? The proposed changes seem reasonable to  
me. One change is that I was initially planning to make these  
mechanism-specific APIs; do we want to commit to introducing new  
mechanism-agnostic APIs?

cheers,

-- Luke

From Nicolas.Williams at sun.com  Thu Aug 20 16:46:15 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 20 Aug 2009 15:46:15 -0500
Subject: Services4User review
In-Reply-To: <342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
Message-ID: <20090820204615.GI1043@Sun.COM>

On Thu, Aug 20, 2009 at 10:33:06PM +0200, Luke Howard wrote:
> >Delegated credential handles need not correspond to delegated
> >credentials in the RFC1964/4121 sense, nor should it be necessary that
> >the caller of GSS_Init_sec_context() have explicitly requested
> >credential delegation -- in the S4U2{Self,Proxy} the delegation is
> >specified in the authz-data of the initiator's service Ticket, and the
> >decision to delegate could be made by the KDC.
> 
> I'm not sure if I understand this: could you point me to where in [MS- 
> SFU] it says that delegation is specified in the authorization data of  
> the initiator's service ticket?

Oh, forget the authz-data thing -- clearly it's the whole of the
initiator's service Ticket that matters (the KDC might use authz-data in
it, but that's another story).  Excuse the brain-fart.

> > [proposal and two wrinkles]
> 
> In practice I'm not sure if this is a big issue. In the current  
> implementation unconstrained delegation (ie. forwarded credentials)  
> take precedence.

Sure.

> >- Let gss_accept_sec_context() always output a delegated cred handle  
> >in
> >  the krb5 case, even when there's no traditional credential  
> >delegation
> >  on the part of the initiator.  Let gss_store_cred() fail if there's
> >  no traditional "forwarded Ticket" in the delegated credential.
> 
> Note we don't have gss_store_cred() yet.

We do.  It's useful, though really only in sshd :)

> >- For S4U2Proxy add gss_acquire_cred_impersonate_deleg() with two
> >  credential handle inputs:
> >
> >   - service_cred_handle (the caller's own cred handle)
> >   - subject_cred_handle (the delegated credential whose subject is to
> >     be impersonated)
> >
> >  and let it output a new cred handle corresponding to "the subject as
> >  impersonated by the service".
> 
> Where does one specify the service to which to delegate to? Would that  
> be another input?

That would be the target_name from the subsequent gss_init_sec_context()
call.

> >Also, are you sure that there are no non-GSS-API applications where
> >S4U2{self,Proxy} might be needed?
> 
> I'm not sure, but I think for 1.8 I'd prefer to expose at GSS-API  
> first, and then for a future release we can think about exposing the  
> underlying krb5 APIs. I don't feel too strongly about this though.

Sure.

> How do others feel about this? The proposed changes seem reasonable to  
> me. One change is that I was initially planning to make these  
> mechanism-specific APIs; do we want to commit to introducing new  
> mechanism-agnostic APIs?

I think these should be mechanism-agnostic.  A PKIX equivalent for
constrained delegation and impersonation is easily imaginable.

Nico
-- 

From Nicolas.Williams at sun.com  Thu Aug 20 17:51:52 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 20 Aug 2009 16:51:52 -0500
Subject: Services4User review
In-Reply-To: <20090820204615.GI1043@Sun.COM>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM>
Message-ID: <20090820215151.GL1043@Sun.COM>

Following up from our IM chat, the GSS exts should be really be based on
the existing gss_acquire/add_cred() functions, and in two variants: one
for S4U2Self, with an additional impersonator_cred_handle input
argument, and one for S4U2Proxy, with that same additional argument and
a subject_cred_handle instead of desired_name.

/* S4U2SELF */
OM_uint32
gss_acquire_cred_with_cred(
	OM_uint32		*minor_status,
	const gss_cred_id_t	impersonator_cred_handle,
	const gss_name_t	desired_name,
	OM_uint32		time_req,
	const gss_OID_set	desired_mechs,
	gss_cred_usage_t	cred_usage,
	gss_cred_id_t		*output_cred_handle,
	gss_OID_set		*actual_mechs,
	OM_uint32		*time_rec
);

OM_uint32
gss_add_cred_with_cred(
	OM_uint32		*minor_status,
	const gss_cred_id_t	impersonator_cred_handle,
	const gss_cred_id_t	input_cred_handle,
	const gss_name_t	desired_name,
	const gss_OID		desired_mech,
	gss_cred_usage_t	cred_usage,
	OM_uint32		initiator_time_req,
	OM_uint32		acceptor_time_req,
	gss_cred_id_t		*output_cred_handle,
	gss_OID_set		*actual_mechs,
	OM_uint32		*initiator_time_rec,
	OM_uint32		*acceptor_time_rec,
);

/* S4U2PROXY */
OM_uint32
gss_acquire_cred_with_creds(
	OM_uint32		*minor_status,
	const gss_cred_id_t	impersonator_cred_handle,
	const gss_cred_id_t	subject_cred_handle,
	OM_uint32		time_req,
	const gss_OID_set	desired_mechs,
	gss_cred_usage_t	cred_usage,
	gss_cred_id_t		*output_cred_handle,
	gss_OID_set		*actual_mechs,
	OM_uint32		*time_rec
);

OM_uint32
gss_add_cred_with_cred(
	OM_uint32		*minor_status,
	const gss_cred_id_t	impersonator_cred_handle,
	const gss_cred_id_t	subject_cred_handle,
	const gss_cred_id_t	input_cred_handle,
	const gss_OID		desired_mech,
	gss_cred_usage_t	cred_usage,
	OM_uint32		initiator_time_req,
	OM_uint32		acceptor_time_req,
	gss_cred_id_t		*output_cred_handle,
	gss_OID_set		*actual_mechs,
	OM_uint32		*initiator_time_rec,
	OM_uint32		*acceptor_time_rec,
);

From lukeh at padl.com  Fri Aug 21 02:04:26 2009
From: lukeh at padl.com (Luke Howard)
Date: Fri, 21 Aug 2009 08:04:26 +0200
Subject: Services4User review
In-Reply-To: <20090820215151.GL1043@Sun.COM>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM> <20090820215151.GL1043@Sun.COM>
Message-ID: <BCE5B78F-101E-442A-9C55-D393DE6BAE5F@padl.com>


On 20/08/2009, at 11:51 PM, Nicolas Williams wrote:

> Following up from our IM chat, the GSS exts should be really be  
> based on
> the existing gss_acquire/add_cred() functions, and in two variants:  
> one
> for S4U2Self, with an additional impersonator_cred_handle input
> argument, and one for S4U2Proxy, with that same additional argument  
> and
> a subject_cred_handle instead of desired_name.
>
> /* S4U2SELF */
> OM_uint32
> gss_acquire_cred_with_cred(

gss_acquire_cred_with_name, yes?

> OM_uint32
> gss_add_cred_with_cred(

gss_add_cred_with_name?

-- Luke

From lukeh at padl.com  Fri Aug 21 04:47:26 2009
From: lukeh at padl.com (Luke Howard)
Date: Fri, 21 Aug 2009 10:47:26 +0200
Subject: Services4User review
In-Reply-To: <20090820215151.GL1043@Sun.COM>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM> <20090820215151.GL1043@Sun.COM>
Message-ID: <B512D8CB-C715-4DF6-BDFF-8668219F7B0D@padl.com>

>
> OM_uint32
> gss_add_cred_with_{name,cred}(
> 	OM_uint32		*minor_status,
> 	const gss_cred_id_t	impersonator_cred_handle,
> 	const gss_cred_id_t	input_cred_handle,


Would it be more consistent for input_cred_handle to be before  
impersonator_cred_handle?

-- Luke


From lukeh at padl.com  Fri Aug 21 05:03:48 2009
From: lukeh at padl.com (Luke Howard)
Date: Fri, 21 Aug 2009 11:03:48 +0200
Subject: Services4User review
In-Reply-To: <B512D8CB-C715-4DF6-BDFF-8668219F7B0D@padl.com>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM> <20090820215151.GL1043@Sun.COM>
	<B512D8CB-C715-4DF6-BDFF-8668219F7B0D@padl.com>
Message-ID: <D0C028FD-2EDB-493B-B248-4A14911F027A@padl.com>


On 21/08/2009, at 10:47 AM, Luke Howard wrote:

>>
>> OM_uint32
>> gss_add_cred_with_{name,cred}(
>> 	OM_uint32		*minor_status,
>> 	const gss_cred_id_t	impersonator_cred_handle,
>> 	const gss_cred_id_t	input_cred_handle,
>
>
> Would it be more consistent for input_cred_handle to be before
> impersonator_cred_handle?

Also, input_cred_handle should not be const, I think?

-- Luke

From sanribu at gmail.com  Fri Aug 21 07:23:28 2009
From: sanribu at gmail.com (Santiago Rivas)
Date: Fri, 21 Aug 2009 13:23:28 +0200
Subject: Validating Kerberos tickets
Message-ID: <711a961b0908210423r40748e0dla1fc9a66303b24c@mail.gmail.com>

Hi everyone,

I have recently started working with Kerberos v5 and I have read many
manuals and documents explaining the protocol and showing some short sample
code. I'm writing a custom C / Java application and I want to "kerberize" it
in order to achieve Single Sign-On. Up to now, I'm able to generate both tgt
and tgs tickets on the client, but the main challenge I find is how to
validate the tgs ticket once it's recieved by the server side of the
application... Any help? Thanks in advance!

PD: I would appreciate to see some source code or read specific
documentation on this task.

From lukeh at padl.com  Fri Aug 21 07:36:22 2009
From: lukeh at padl.com (Luke Howard)
Date: Fri, 21 Aug 2009 13:36:22 +0200
Subject: Services4User review
In-Reply-To: <20090820215151.GL1043@Sun.COM>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM> <20090820215151.GL1043@Sun.COM>
Message-ID: <59E81504-EE5B-4D07-8CF1-B272815A5352@padl.com>


On 20/08/2009, at 11:51 PM, Nicolas Williams wrote:

> Following up from our IM chat, the GSS exts should be really be  
> based on
> the existing gss_acquire/add_cred() functions, and in two variants:  
> one
> for S4U2Self, with an additional impersonator_cred_handle input
> argument, and one for S4U2Proxy, with that same additional argument  
> and
> a subject_cred_handle instead of desired_name.


OK, I've updated:

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

and have committed an implementation to the s4u branch.

This is a bit more work for the application developer, but  
architecturally it seems better.

cheers,

-- Luke

From deengert at anl.gov  Fri Aug 21 10:26:15 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Fri, 21 Aug 2009 09:26:15 -0500
Subject: Validating Kerberos tickets
In-Reply-To: <711a961b0908210423r40748e0dla1fc9a66303b24c@mail.gmail.com>
References: <711a961b0908210423r40748e0dla1fc9a66303b24c@mail.gmail.com>
Message-ID: <4A8EAE87.6040204@anl.gov>



Santiago Rivas wrote:
> Hi everyone,
> 
> I have recently started working with Kerberos v5 and I have read many
> manuals and documents explaining the protocol and showing some short sample
> code. I'm writing a custom C / Java application and I want to "kerberize" it
> in order to achieve Single Sign-On. Up to now, I'm able to generate both tgt
> and tgs tickets on the client, but the main challenge I find is how to
> validate the tgs ticket once it's recieved by the server side of the
> application... Any help? Thanks in advance!

You say it is C / Java, If you are calling Kerberos from Java, have you looked at:

http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/single-signon.html

You might be better off use the GSS-API rather then Kerberos directly.
The above URL has an example for that too.

Goolge for java kerberos  to find other references.


> 
> PD: I would appreciate to see some source code or read specific
> documentation on this task.
> _______________________________________________
> 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 hartmans at MIT.EDU  Fri Aug 21 11:23:04 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Fri, 21 Aug 2009 11:23:04 -0400
Subject: Validating Kerberos tickets
In-Reply-To: <711a961b0908210423r40748e0dla1fc9a66303b24c@mail.gmail.com>
	(Santiago Rivas's message of "Fri\, 21 Aug 2009 13\:23\:28 +0200")
References: <711a961b0908210423r40748e0dla1fc9a66303b24c@mail.gmail.com>
Message-ID: <tsl4os1nqcn.fsf@mit.edu>

The Kerberos Consortium has a set of white papers that should help you.
See
http://www.kerberos.org/software/whitepapers.html

The Role of Kerberos in Modern Information Systems goes through
several things you might mean by validating tickets and trying to
achieve single sign-on.  Once you figure that out, there is a paper on
integrating Kerberos into an application that covers the basic
concepts and includes pointers to examples for C and Java.

From lukeh at padl.com  Fri Aug 21 11:36:51 2009
From: lukeh at padl.com (Luke Howard)
Date: Fri, 21 Aug 2009 17:36:51 +0200
Subject: Services4User review
In-Reply-To: <20090820215151.GL1043@Sun.COM>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM> <20090820215151.GL1043@Sun.COM>
Message-ID: <29EE0B0A-BA59-4C81-9D0D-98095EE7B7BE@padl.com>

>
> /* S4U2PROXY */
> OM_uint32
> gss_acquire_cred_with_creds(

Could you argue that it would be better to do away with this function,  
and allow the "delegated" credential handle to be passed directly into  
gss_init_sec_context()?

Or would this introduce problems for other mechanisms?

-- Luke

From Nicolas.Williams at sun.com  Fri Aug 21 11:34:12 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 21 Aug 2009 10:34:12 -0500
Subject: Services4User review
In-Reply-To: <BCE5B78F-101E-442A-9C55-D393DE6BAE5F@padl.com>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM> <20090820215151.GL1043@Sun.COM>
	<BCE5B78F-101E-442A-9C55-D393DE6BAE5F@padl.com>
Message-ID: <20090821153411.GR1043@Sun.COM>

On Fri, Aug 21, 2009 at 08:04:26AM +0200, Luke Howard wrote:
> 
> On 20/08/2009, at 11:51 PM, Nicolas Williams wrote:
> 
> >Following up from our IM chat, the GSS exts should be really be  
> >based on
> >the existing gss_acquire/add_cred() functions, and in two variants:  
> >one
> >for S4U2Self, with an additional impersonator_cred_handle input
> >argument, and one for S4U2Proxy, with that same additional argument  
> >and
> >a subject_cred_handle instead of desired_name.
> >
> >/* S4U2SELF */
> >OM_uint32
> >gss_acquire_cred_with_cred(
> 
> gss_acquire_cred_with_name, yes?

There's alread a desired_name in gss_a*_cred() :)

The S4U2Self idea is that we're using one principal's credential to get
a credential for another principal.

We could call that gss_a*_impersonation_cred() too, or any number of
variants.  you and I both felt that "impersonate" was likely to be
confusing, but the alternatives seem confusing too :(

From Nicolas.Williams at sun.com  Fri Aug 21 11:34:39 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 21 Aug 2009 10:34:39 -0500
Subject: Services4User review
In-Reply-To: <B512D8CB-C715-4DF6-BDFF-8668219F7B0D@padl.com>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM> <20090820215151.GL1043@Sun.COM>
	<B512D8CB-C715-4DF6-BDFF-8668219F7B0D@padl.com>
Message-ID: <20090821153438.GS1043@Sun.COM>

On Fri, Aug 21, 2009 at 10:47:26AM +0200, Luke Howard wrote:
> >
> >OM_uint32
> >gss_add_cred_with_{name,cred}(
> >	OM_uint32		*minor_status,
> >	const gss_cred_id_t	impersonator_cred_handle,
> >	const gss_cred_id_t	input_cred_handle,
> 
> 
> Would it be more consistent for input_cred_handle to be before  
> impersonator_cred_handle?

Ah, yes, it would be.

From lukeh at padl.com  Fri Aug 21 11:46:19 2009
From: lukeh at padl.com (Luke Howard)
Date: Fri, 21 Aug 2009 17:46:19 +0200
Subject: Services4User review
In-Reply-To: <29EE0B0A-BA59-4C81-9D0D-98095EE7B7BE@padl.com>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM> <20090820215151.GL1043@Sun.COM>
	<29EE0B0A-BA59-4C81-9D0D-98095EE7B7BE@padl.com>
Message-ID: <B8DD1612-727A-47A1-87D0-07D2BB2791EF@padl.com>


On 21/08/2009, at 5:36 PM, Luke Howard wrote:

>>
>> /* S4U2PROXY */
>> OM_uint32
>> gss_acquire_cred_with_creds(
>
> Could you argue that it would be better to do away with this function,
> and allow the "delegated" credential handle to be passed directly into
> gss_init_sec_context()?

That would require that impersonator_cred_handle and  
verifier_cred_handle refer to the same credentials, which may not be a  
safe assumption.

-- Luke

From Nicolas.Williams at sun.com  Fri Aug 21 11:36:25 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 21 Aug 2009 10:36:25 -0500
Subject: Services4User review
In-Reply-To: <D0C028FD-2EDB-493B-B248-4A14911F027A@padl.com>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM> <20090820215151.GL1043@Sun.COM>
	<B512D8CB-C715-4DF6-BDFF-8668219F7B0D@padl.com>
	<D0C028FD-2EDB-493B-B248-4A14911F027A@padl.com>
Message-ID: <20090821153625.GT1043@Sun.COM>

On Fri, Aug 21, 2009 at 11:03:48AM +0200, Luke Howard wrote:
> 
> On 21/08/2009, at 10:47 AM, Luke Howard wrote:
> 
> >>
> >>OM_uint32
> >>gss_add_cred_with_{name,cred}(
> >>	OM_uint32		*minor_status,
> >>	const gss_cred_id_t	impersonator_cred_handle,
> >>	const gss_cred_id_t	input_cred_handle,
> >
> >
> >Would it be more consistent for input_cred_handle to be before
> >impersonator_cred_handle?
> 
> Also, input_cred_handle should not be const, I think?

Well, if there's no output_cred_handle pointer then gss_add_cred() will
modify the given input_cred_handle (one of the two must be provided).
So input_cred_handle is not input-only.  But as far as C is concerned
that doesn't matter, so const is OK, though misleading.

From lukeh at padl.com  Fri Aug 21 11:55:31 2009
From: lukeh at padl.com (Luke Howard)
Date: Fri, 21 Aug 2009 17:55:31 +0200
Subject: Services4User review
In-Reply-To: <20090821153411.GR1043@Sun.COM>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM> <20090820215151.GL1043@Sun.COM>
	<BCE5B78F-101E-442A-9C55-D393DE6BAE5F@padl.com>
	<20090821153411.GR1043@Sun.COM>
Message-ID: <6F37DC7F-311D-448D-AB19-63985F9B7283@padl.com>

> There's alread a desired_name in gss_a*_cred() :)

Hmm, I think having two functions distinguished by a plural is even  
more confusing.

-- Luke

From lukeh at padl.com  Fri Aug 21 12:02:30 2009
From: lukeh at padl.com (Luke Howard)
Date: Fri, 21 Aug 2009 18:02:30 +0200
Subject: Services4User review
In-Reply-To: <20090821153438.GS1043@Sun.COM>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM> <20090820215151.GL1043@Sun.COM>
	<B512D8CB-C715-4DF6-BDFF-8668219F7B0D@padl.com>
	<20090821153438.GS1043@Sun.COM>
Message-ID: <FA9E44F5-1356-4B99-8E3B-21EC3FA49A70@padl.com>

OK, fixed

On 21/08/2009, at 5:34 PM, Nicolas Williams wrote:

> On Fri, Aug 21, 2009 at 10:47:26AM +0200, Luke Howard wrote:
>>>
>>> OM_uint32
>>> gss_add_cred_with_{name,cred}(
>>> 	OM_uint32		*minor_status,
>>> 	const gss_cred_id_t	impersonator_cred_handle,
>>> 	const gss_cred_id_t	input_cred_handle,
>>
>>
>> Would it be more consistent for input_cred_handle to be before
>> impersonator_cred_handle?
>
> Ah, yes, it would be.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>

--
www.padl.com | www.fghr.net


From lukeh at padl.com  Fri Aug 21 12:02:55 2009
From: lukeh at padl.com (Luke Howard)
Date: Fri, 21 Aug 2009 18:02:55 +0200
Subject: Services4User review
In-Reply-To: <20090821153625.GT1043@Sun.COM>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM> <20090820215151.GL1043@Sun.COM>
	<B512D8CB-C715-4DF6-BDFF-8668219F7B0D@padl.com>
	<D0C028FD-2EDB-493B-B248-4A14911F027A@padl.com>
	<20090821153625.GT1043@Sun.COM>
Message-ID: <51CFFF42-0779-4EA4-936C-629851A8807B@padl.com>

>>
> Well, if there's no output_cred_handle pointer then gss_add_cred()  
> will
> modify the given input_cred_handle (one of the two must be provided).
> So input_cred_handle is not input-only.  But as far as C is concerned
> that doesn't matter, so const is OK, though misleading.

So, I would prefer to make it non-const in that case.

-- Luke

From Nicolas.Williams at sun.com  Fri Aug 21 12:15:29 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 21 Aug 2009 11:15:29 -0500
Subject: Services4User review
In-Reply-To: <6F37DC7F-311D-448D-AB19-63985F9B7283@padl.com>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM> <20090820215151.GL1043@Sun.COM>
	<BCE5B78F-101E-442A-9C55-D393DE6BAE5F@padl.com>
	<20090821153411.GR1043@Sun.COM>
	<6F37DC7F-311D-448D-AB19-63985F9B7283@padl.com>
Message-ID: <20090821161529.GW1043@Sun.COM>

On Fri, Aug 21, 2009 at 05:55:31PM +0200, Luke Howard wrote:
> > There's alread a desired_name in gss_a*_cred() :)
> 
> Hmm, I think having two functions distinguished by a plural is even  
> more confusing.

Yes.  Let's go back to using the word "impersonate" in the function
names:

S4U2SELF:  gss_a*_cred_impersonate_name()
S4U2PROXY: gss_a*_cred_impersonate_cred()


From Nicolas.Williams at sun.com  Fri Aug 21 12:26:13 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 21 Aug 2009 11:26:13 -0500
Subject: Services4User review
In-Reply-To: <29EE0B0A-BA59-4C81-9D0D-98095EE7B7BE@padl.com>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM> <20090820215151.GL1043@Sun.COM>
	<29EE0B0A-BA59-4C81-9D0D-98095EE7B7BE@padl.com>
Message-ID: <20090821162613.GX1043@Sun.COM>

On Fri, Aug 21, 2009 at 05:36:51PM +0200, Luke Howard wrote:
> >
> >/* S4U2PROXY */
> >OM_uint32
> >gss_acquire_cred_with_creds(
> 
> Could you argue that it would be better to do away with this function,  
> and allow the "delegated" credential handle to be passed directly into  
> gss_init_sec_context()?

But where would the host's credentials go?  Sure, you could use
GSS_C_NO_CREDENTIAL for the host creds, but then you'd need a req flag
to tell the mechanism to do that, and that's not very robust: mechglue
can know whether a mech supports a new function/method, but not whether
it supports a new flag (well, there's extended inquiry, yes, and you
could find out from ret_flags after the fact, but still, that's all
rather awkward, don't you think?).

Sure, you could have a gss_init_sec_context_impersonate() that takes two
cred handles.  And so on, but I prefer to do all this purely at the cred
level for several reasons:

 - You can pass an impersonation cred around to any interface that takes
   a gss_cred_id_t:

    - gss_inquire_cred*()
    - gss_init/accept_sec_context()
    - gss_store_cred()
    - sasl_set_prop() (Cyrus SASL has option for passing in GSS creds to
      use)
    - ...

 - The cred-level abstraction fits very well in my mind; the fact that
   for the krb5 mechanism the actual KDC exchanges to get proxy creds
   would happen later, in the actual gss_init_sec_context() calls is
   irrelevant.

    - Other mechanisms might only need to get a proxy cred once (think
      of a PKIX-like mechanism).

    - One could imagine alternative ways to design S4U2PROXY for
      Kerberos where the proxy gets a TGT to impersonate the subject,
      but the TGT carries authz-data that constrains what service
      principals it can be used to get service tickets for.

      In this case the cred-level abstraction is much better.

> Or would this introduce problems for other mechanisms?

IMO: yes, it would, and even for alternative designs of S4U2PROXY.

From lukeh at padl.com  Fri Aug 21 12:46:41 2009
From: lukeh at padl.com (Luke Howard)
Date: Fri, 21 Aug 2009 18:46:41 +0200
Subject: Services4User review
In-Reply-To: <20090821161529.GW1043@Sun.COM>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM> <20090820215151.GL1043@Sun.COM>
	<BCE5B78F-101E-442A-9C55-D393DE6BAE5F@padl.com>
	<20090821153411.GR1043@Sun.COM>
	<6F37DC7F-311D-448D-AB19-63985F9B7283@padl.com>
	<20090821161529.GW1043@Sun.COM>
Message-ID: <63E1364C-CF3A-4B5D-8BF3-501DD6987A62@padl.com>

OK, committed in r22562.

On 21/08/2009, at 6:15 PM, Nicolas Williams wrote:

> On Fri, Aug 21, 2009 at 05:55:31PM +0200, Luke Howard wrote:
>>> There's alread a desired_name in gss_a*_cred() :)
>>
>> Hmm, I think having two functions distinguished by a plural is even
>> more confusing.
>
> Yes.  Let's go back to using the word "impersonate" in the function
> names:
>
> S4U2SELF:  gss_a*_cred_impersonate_name()
> S4U2PROXY: gss_a*_cred_impersonate_cred()
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>

--
www.padl.com | www.fghr.net


From lukeh at padl.com  Fri Aug 21 12:53:11 2009
From: lukeh at padl.com (Luke Howard)
Date: Fri, 21 Aug 2009 18:53:11 +0200
Subject: Services4User review
In-Reply-To: <20090821162613.GX1043@Sun.COM>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM> <20090820215151.GL1043@Sun.COM>
	<29EE0B0A-BA59-4C81-9D0D-98095EE7B7BE@padl.com>
	<20090821162613.GX1043@Sun.COM>
Message-ID: <39D9F40F-976F-4B7A-8A74-637C8B4CB2B1@padl.com>

> But where would the host's credentials go?  Sure, you could use

<hypothetical>
If the acceptor and impersonate credentials are the same thing (which,  
for constrained delegation in the Kerberos world, they must be), then  
a single acceptor credential handle with GSS_C_BOTH would work:

gss_accept_sec_context() could then return a credentials handle  
containing both the verifier's initiator credentials and the evidence  
ticket (ie. from the initiator to the acceptor).  
(gss_acquire_cred_impersonate_cred() does just this.)
</hypothetical>

Anyway, I'm fine with the existing design :-)

>    - One could imagine alternative ways to design S4U2PROXY for
>      Kerberos where the proxy gets a TGT to impersonate the subject,
>      but the TGT carries authz-data that constrains what service
>      principals it can be used to get service tickets for.

Ah yes, that would be interesting too!

-- Luke

From lukeh at padl.com  Sat Aug 22 07:17:09 2009
From: lukeh at padl.com (Luke Howard)
Date: Sat, 22 Aug 2009 13:17:09 +0200
Subject: Services4User review
In-Reply-To: <39D9F40F-976F-4B7A-8A74-637C8B4CB2B1@padl.com>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM> <20090820215151.GL1043@Sun.COM>
	<29EE0B0A-BA59-4C81-9D0D-98095EE7B7BE@padl.com>
	<20090821162613.GX1043@Sun.COM>
	<39D9F40F-976F-4B7A-8A74-637C8B4CB2B1@padl.com>
Message-ID: <34CDE2FE-C3C7-4235-8BEC-5450E63C828C@padl.com>

Not so hypothetical. I realise I misunderstood some attributes of  
Nico's original suggestion.

So, now: a delegated credentials handle is always returned by  
gss_accept_sec_context() (and GSS_C_DELEG_FLAG is set). That handle  
can be passed into gss_init_sec_context(): the actual constrained  
delegation request is deferred until then, because only then is the  
target name known.

Similarly, an impersonation credential handle from  
gss_acquire_cred_impersonate_name() can also be passed to  
gss_init_sec_context(). (The S4U2Self request is not deferred.)

Under the hood, there is a flag set in the credentials handle that  
indicates it is a "proxy" handle, in which case the impersonator's TGT  
is also present (necessary to perform the S4U2Proxy request). This is  
only the case for forwardable tickets; if the initiator's ticket is  
not forwardable, or S4U2Self issued a non-forwardable ticket, then a  
normal, TGT-less credentials handle is returned, and the only valid  
target is the impersonator.

I've updated the wiki and the code.

-- Luke

On 21/08/2009, at 6:53 PM, Luke Howard wrote:

>> But where would the host's credentials go?  Sure, you could use
>
> <hypothetical>
> If the acceptor and impersonate credentials are the same thing (which,
> for constrained delegation in the Kerberos world, they must be), then
> a single acceptor credential handle with GSS_C_BOTH would work:
>
> gss_accept_sec_context() could then return a credentials handle
> containing both the verifier's initiator credentials and the evidence
> ticket (ie. from the initiator to the acceptor).
> (gss_acquire_cred_impersonate_cred() does just this.)
> </hypothetical>
>
> Anyway, I'm fine with the existing design :-)
>
>>   - One could imagine alternative ways to design S4U2PROXY for
>>     Kerberos where the proxy gets a TGT to impersonate the subject,
>>     but the TGT carries authz-data that constrains what service
>>     principals it can be used to get service tickets for.
>
> Ah yes, that would be interesting too!
>
> -- Luke
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>

--
www.padl.com | www.fghr.net


From lukeh at padl.com  Sat Aug 22 07:20:41 2009
From: lukeh at padl.com (Luke Howard)
Date: Sat, 22 Aug 2009 13:20:41 +0200
Subject: Services4User review
In-Reply-To: <34CDE2FE-C3C7-4235-8BEC-5450E63C828C@padl.com>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM> <20090820215151.GL1043@Sun.COM>
	<29EE0B0A-BA59-4C81-9D0D-98095EE7B7BE@padl.com>
	<20090821162613.GX1043@Sun.COM>
	<39D9F40F-976F-4B7A-8A74-637C8B4CB2B1@padl.com>
	<34CDE2FE-C3C7-4235-8BEC-5450E63C828C@padl.com>
Message-ID: <A9524BA5-23D6-4CBA-A2F6-E7CAC89D7F6F@padl.com>

And the really cool thing is that the application developer does not  
have to use any new APIs to use constrained delegation (and only one  
to use protocol transition). The API is exactly the same as it is for  
"unconstrained" delegation.

(Of course, whether constrained delegation will be successful is  
subject to the policy of the KDC.)

-- Luke

From Nicolas.Williams at sun.com  Mon Aug 24 01:24:58 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 24 Aug 2009 00:24:58 -0500
Subject: Services4User review
In-Reply-To: <A9524BA5-23D6-4CBA-A2F6-E7CAC89D7F6F@padl.com>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<20090820190644.GD1043@Sun.COM>
	<342A5190-3B48-4D0A-8C3A-3891A8365A17@padl.com>
	<20090820204615.GI1043@Sun.COM> <20090820215151.GL1043@Sun.COM>
	<29EE0B0A-BA59-4C81-9D0D-98095EE7B7BE@padl.com>
	<20090821162613.GX1043@Sun.COM>
	<39D9F40F-976F-4B7A-8A74-637C8B4CB2B1@padl.com>
	<34CDE2FE-C3C7-4235-8BEC-5450E63C828C@padl.com>
	<A9524BA5-23D6-4CBA-A2F6-E7CAC89D7F6F@padl.com>
Message-ID: <20090824052457.GA1043@Sun.COM>

On Sat, Aug 22, 2009 at 01:20:41PM +0200, Luke Howard wrote:
> And the really cool thing is that the application developer does not  
> have to use any new APIs to use constrained delegation (and only one  
> to use protocol transition). The API is exactly the same as it is for  
> "unconstrained" delegation.

Indeed, and it will work for both S4U2{Self, Proxy}.  Of course, there
are also new APIs that can be used, but they may well be unnecessary to
the point that you can just not bother with them.

To get gss_store_cred() to store such creds though will require ccache
extensions and krb5_get_credentials() work.  But that's another story.
And it will likely not be necessary for a while (plus, MIT krb5 doesn't
have gss_store_cred()).

> (Of course, whether constrained delegation will be successful is  
> subject to the policy of the KDC.)

Of course.

From sanribu at gmail.com  Mon Aug 24 07:10:51 2009
From: sanribu at gmail.com (Santiago Rivas)
Date: Mon, 24 Aug 2009 13:10:51 +0200
Subject: Validating Kerberos tickets
In-Reply-To: <4A8EAE87.6040204@anl.gov>
References: <711a961b0908210423r40748e0dla1fc9a66303b24c@mail.gmail.com>
	<4A8EAE87.6040204@anl.gov>
Message-ID: <711a961b0908240410i1d4bf58cs6a74996f80d60234@mail.gmail.com>

Hi, Douglas

I had already read that document (in my opinion, a very good one!). But it
does not contain enough information for my purpose: the client-side of the
application is running through a web browser and it is written in Java. I'm
using GSS-API with JAAS, which I agree that makes things a lot easier. But
the point is that server-side must be written in C, in order to compile it
into a DLL. I have searched for a C-GSSAPI framework... with poor results.
I have downloaded several archives from:

http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/gssapi/

But I'm not able to get it working for Visual Studio. Is there any website
where I can download an open source C GSSAPI framework?

Thanks a lot!

Regards,
Santiago


2009/8/21 Douglas E. Engert <deengert at anl.gov>

>
>
> Santiago Rivas wrote:
>
>> Hi everyone,
>>
>> I have recently started working with Kerberos v5 and I have read many
>> manuals and documents explaining the protocol and showing some short
>> sample
>> code. I'm writing a custom C / Java application and I want to "kerberize"
>> it
>> in order to achieve Single Sign-On. Up to now, I'm able to generate both
>> tgt
>> and tgs tickets on the client, but the main challenge I find is how to
>> validate the tgs ticket once it's recieved by the server side of the
>> application... Any help? Thanks in advance!
>>
>
> You say it is C / Java, If you are calling Kerberos from Java, have you
> looked at:
>
> http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/single-signon.html
>
> You might be better off use the GSS-API rather then Kerberos directly.
> The above URL has an example for that too.
>
> Goolge for java kerberos  to find other references.
>
>
>
>> PD: I would appreciate to see some source code or read specific
>> documentation on this task.
>> _______________________________________________
>> 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 sanribu at gmail.com  Mon Aug 24 07:12:54 2009
From: sanribu at gmail.com (Santiago Rivas)
Date: Mon, 24 Aug 2009 13:12:54 +0200
Subject: Validating Kerberos tickets
In-Reply-To: <tsl4os1nqcn.fsf@mit.edu>
References: <711a961b0908210423r40748e0dla1fc9a66303b24c@mail.gmail.com>
	<tsl4os1nqcn.fsf@mit.edu>
Message-ID: <711a961b0908240412n846a159me4c6342340c0ea1a@mail.gmail.com>

Thank you very much, Sam

I will have a look at those papers...

Regards,
Santiago

2009/8/21 Sam Hartman <hartmans at mit.edu>

> The Kerberos Consortium has a set of white papers that should help you.
> See
> http://www.kerberos.org/software/whitepapers.html
>
> The Role of Kerberos in Modern Information Systems goes through
> several things you might mean by validating tickets and trying to
> achieve single sign-on.  Once you figure that out, there is a paper on
> integrating Kerberos into an application that covers the basic
> concepts and includes pointers to examples for C and Java.
>

From deengert at anl.gov  Mon Aug 24 10:13:32 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Mon, 24 Aug 2009 09:13:32 -0500
Subject: Validating Kerberos tickets
In-Reply-To: <711a961b0908240410i1d4bf58cs6a74996f80d60234@mail.gmail.com>
References: <711a961b0908210423r40748e0dla1fc9a66303b24c@mail.gmail.com>	
	<4A8EAE87.6040204@anl.gov>
	<711a961b0908240410i1d4bf58cs6a74996f80d60234@mail.gmail.com>
Message-ID: <4A92A00C.7040007@anl.gov>




Santiago Rivas wrote:
> Hi, Douglas
>  
> I had already read that document (in my opinion, a very good one!). But 
> it does not contain enough information for my purpose: the client-side 
> of the application is running through a web browser and it is written in 
> Java. I'm using GSS-API with JAAS, which I agree that makes things a lot 
> easier. But the point is that server-side must be written in C, in order 
> to compile it into a DLL. I have searched for a C-GSSAPI framework... 
> with poor results.

So the server is on Windows. Then you might be able to use the Microsoft SSPI
on the server, as SSPI uses the same protocol as GSSAPI. I have done SSPI
clients to GSS-API servers on Unix, but not the other way.

> I have downloaded several archives from:
>  
> http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/gssapi/
>  
> But I'm not able to get it working for Visual Studio. Is there any 
> website where I can download an open source C GSSAPI framework?
>  
> Thanks a lot!
>  
> Regards,
> Santiago
> 
> 
> 2009/8/21 Douglas E. Engert <deengert at anl.gov <mailto:deengert at anl.gov>>
> 
> 
> 
>     Santiago Rivas wrote:
> 
>         Hi everyone,
> 
>         I have recently started working with Kerberos v5 and I have read
>         many
>         manuals and documents explaining the protocol and showing some
>         short sample
>         code. I'm writing a custom C / Java application and I want to
>         "kerberize" it
>         in order to achieve Single Sign-On. Up to now, I'm able to
>         generate both tgt
>         and tgs tickets on the client, but the main challenge I find is
>         how to
>         validate the tgs ticket once it's recieved by the server side of the
>         application... Any help? Thanks in advance!
> 
> 
>     You say it is C / Java, If you are calling Kerberos from Java, have
>     you looked at:
> 
>     http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/single-signon.html
> 
>     You might be better off use the GSS-API rather then Kerberos directly.
>     The above URL has an example for that too.
> 
>     Goolge for java kerberos  to find other references.
> 
> 
> 
>         PD: I would appreciate to see some source code or read specific
>         documentation on this task.
>         _______________________________________________
>         krbdev mailing list             krbdev at mit.edu
>         <mailto:krbdev at mit.edu>
>         https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> 
> 
>     -- 
> 
>      Douglas E. Engert  <DEEngert at anl.gov <mailto:DEEngert at anl.gov>>
>      Argonne National Laboratory
>      9700 South Cass Avenue
>      Argonne, Illinois  60439
>      (630) 252-5444
> 
> 

-- 

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

From ghudson at MIT.EDU  Mon Aug 24 16:49:51 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Mon, 24 Aug 2009 16:49:51 -0400
Subject: Services4User review
In-Reply-To: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
Message-ID: <1251146991.20047.133.camel@ray>

I have made a first pass over about half of the changes on your user
branch.  I will need to do a more comprehensive second pass after doing
some more background reading (I read the Microsoft S4U specification,
but there are limitations to my GSSAPI understanding, and I also simply
need to block out more time).  But since you're going to be doing a
bunch of ongoing krb5 work, I want to bring up some coding practices
issues.  Some of this is nitpicky.

* Do not make lines overflowing 79 columns if possible.  Examples:
  - kdc_util.c line 923
  - kdc_process_s4u2self_rep (multiple cases)
  - kdc_process_s4u2self_req (multiple cases)
  - process_tgs_req
  - do_tgs_req.c line 701
  - kvno.c line 42 (text output also overflows; previously bad)
  - kvno.c line 94 (can use ANSI C string concatenation)
  - kvno.c line 283 (previously bad)
  - kvno.c line 288, 303
  - t_s4u.c line 53
  - s4u_gss_glue.c line 134, 292
  - g_acquire_cred_imp_cred.c line 190, 191

* Do not put parens around return expressions:
  - g_acquire_cred_imp_cred.c
  - g_acquire_cred_imp_name.c
  (These may be the result of copying existing code.)

* Code documentation was good in many places, but I noted some holes:
  - verify_s4u_x509_user_checksum should explain why it's trying two
ways.
  - kdc_process_s4u2self_rep is a bad name.  "kdc_process_*" was
previously used only for examining request data, and is a bad name
prefix even then.  In this case you are composing reply data.  Also,
this function should have a leading comment explaining what it does,
unless you can come up with a name and parameter names which are super
self-explanatory.
  - krb5int_send_tgs grew a new callback parameter; its meaning should
be documented in a comment before the function definition in send_tgs.c

Part of the issue here is that we do not commonly document internal
function contracts, and would like to change that.  It's a huge job to
fix this for all of our existing code, but we should at least document
new functions we add when they're not trivially obvious.

* Do not cast the return value of malloc; examples:
  - kdc_process_s4u2self_rep
  - kdc_process_s4u2self_req
  - add_pa_data_element
  - kg_compose_deleg_cred
  - g_acquire_cred_imp_cred.c
  - gss_acquire_cred_impersonate_name
  - gss_add_cred_impersonate_name

* Do not void-cast return values which are almost always ignored.  (This
is specified in the coding practices document on the wiki, but is I
believe the general practice in krb5 code, and is also a good
readability practice in my opinion.)  I didn't collect examples here,
but I saw void casts for memset, memcpy, and the gss_release functions.
For the purposes of static analysis, I think Coverity has a good
approach here: it will only complain about the lack of a void cast when
it can statistically determine that the return value is usually used.

* Do not add space between sizeof and the following open paren.  I
didn't collect examples here.

* Do not check for nullity before calling free or krb5_free functions.
(I don't think this is in the coding practices document but is what
we're moving towards.)  Examples:
  - kdc_process_s4u2self_rep cleanup
  - (do_tgs_req.c line 988 but mixed in with others)
  - do_v5_kvno cleanup
  - init_sec_context.c:get_credentials cleanup
  - kg_compose_deleg_cred cleanup
  - gss_add_cred_impersonate_cred cleanup
  - gss_add_cred_impersonate_name cleanup

* In kdc_process_s4u2self_req:
  - Use a cleanup handler, not "free everything and exit" flow control
  - Initialize *s4u_x509_user to NULL at start, use a temporary during
    construction, and ssign the temporary to the output value just
    before returning success

* Trailing blank lines added to some files; examples:
  - kdc_preauth.c
  - krb5_gss_glue.c
  - acquire_cred.c

* Unrelated #if 0s added to ksetpwd.c.

* We are trying to avoid large functions which are hard to see on a
screenful of text or understand within your head.  This means if you're
writing a large function, or adding to a moderately-sized or large
function, you should look for opportunities to naturally break things up
into helper functions.  Some places where I noted opportunities for this
include:
  - kdc_process_s4u2self_req, pa_type == KRB5_PADATA_S4U_X509_USER
    conditional block
  - kdc_process_s4u2self_req, is_local_principal conditional block
  - init_sec_context.c:get_credentials, new proxy_cred conditional

* In krb5_gss_cred_id_rec you introduce some bitfields where none were
present.  I don't know if it is important to contain the size of id_rec
structures, and using bitfields can expand the size of the code which
processes those fields, which at times can be more undesirable than
allocating a bit more memory in an infrequently-used structure.  I am
not sure how the balance comes out in this case, but please be aware of
the tradeoff.




From lukeh at padl.com  Mon Aug 24 17:14:00 2009
From: lukeh at padl.com (Luke Howard)
Date: Mon, 24 Aug 2009 23:14:00 +0200
Subject: Services4User review
In-Reply-To: <1251146991.20047.133.camel@ray>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<1251146991.20047.133.camel@ray>
Message-ID: <43C6229D-9D62-4574-A6BB-F9E6A60E2CA9@padl.com>

> * Do not make lines overflowing 79 columns if possible.  Examples:

Yeah, that's a bad habit of mine. I need to get a VT100.

> * Do not put parens around return expressions:
>  - g_acquire_cred_imp_cred.c
>  - g_acquire_cred_imp_name.c
>  (These may be the result of copying existing code.)

Right, I agree in principle, but I wanted to make it compatible with  
the existing Sun convention.

>  - kdc_process_s4u2self_rep is a bad name.  "kdc_process_*" was
> previously used only for examining request data, and is a bad name
> prefix even then.  In this case you are composing reply data.  Also,

Right, I attempted to keep it consistent with _req but, that makes  
sense. Do you want to fix these things or shall I?

> * Do not check for nullity before calling free or krb5_free functions.
> (I don't think this is in the coding practices document but is what
> we're moving towards.)  Examples:

Right, I was curious about that; my habit is not to check for nullity,  
but I generally followed the existing practice which does.

> * Unrelated #if 0s added to ksetpwd.c.

 From memory, that's a security issue, printing the password to the  
standard output... but yes, unrelated.

Thanks for the comments. I may not have hours to address these until  
next week.

-- Luke

From Nicolas.Williams at sun.com  Mon Aug 24 17:14:25 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 24 Aug 2009 16:14:25 -0500
Subject: Services4User review
In-Reply-To: <1251146991.20047.133.camel@ray>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<1251146991.20047.133.camel@ray>
Message-ID: <20090824211425.GD1033@Sun.COM>

On Mon, Aug 24, 2009 at 04:49:51PM -0400, Greg Hudson wrote:
> * Do not put parens around return expressions:
>   - g_acquire_cred_imp_cred.c
>   - g_acquire_cred_imp_name.c
>   (These may be the result of copying existing code.)

Putting parens around return expressions is a Solaris C-style dictum.
If this code is based on Solaris' libgss, then I recommend adhering to
the Solaris C-style if possible, for now.

http://opensolaris.org/os/community/on/
http://opensolaris.org/os/community/documentation/getting_started_docs/cstyle.ms.pdf
http://opensolaris.org/os/community/documentation/getting_started_docs/cstyle.ms

That applies to just a few of your other comments (e.g., put a space
between sizeof and the parenthesized type expression).

> * In krb5_gss_cred_id_rec you introduce some bitfields where none were
> present.  I don't know if it is important to contain the size of id_rec
> structures, and using bitfields can expand the size of the code which
> processes those fields, which at times can be more undesirable than
> allocating a bit more memory in an infrequently-used structure.  I am
> not sure how the balance comes out in this case, but please be aware of
> the tradeoff.

The *gss_*rec* structs are all private.  Their size and layout can be
changed at any time without trouble.

I prefer bitfields where possible, and for several reasons:

 - I wouldn't presume to be able to write more optimal code than the
   compiler -- hard data is needed (and even then, there's more than one
   compiler).

 - These flags are not referenced in performance sensitive fastpaths.

 - Bitfields are clearer, more elegant, and easier to use that CPP
   symbols and bit-wise expressions.

Nico
-- 

From lukeh at padl.com  Mon Aug 24 17:40:31 2009
From: lukeh at padl.com (Luke Howard)
Date: Mon, 24 Aug 2009 23:40:31 +0200
Subject: Services4User review
In-Reply-To: <20090824211425.GD1033@Sun.COM>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<1251146991.20047.133.camel@ray> <20090824211425.GD1033@Sun.COM>
Message-ID: <35A0653A-30FF-4B14-9C38-6644168775E1@padl.com>

> Putting parens around return expressions is a Solaris C-style dictum.
> If this code is based on Solaris' libgss, then I recommend adhering to
> the Solaris C-style if possible, for now.

Right, when in Rome... I always try to make stuff fit the existing  
pattern. But I'm not religious. :)

-- Luke

From manojm at us.ibm.com  Mon Aug 24 17:50:08 2009
From: manojm at us.ibm.com (Manoj Mohan)
Date: Mon, 24 Aug 2009 16:50:08 -0500
Subject: gss_import_name() fails on HPUX .. need help
Message-ID: <OFCD9F08C6.40176866-ON8725761C.0076F52E-8625761C.0077EF6B@us.ibm.com>



Hi,

I was able to setup my client server programs successfully when
KDC/client/server were on same host (linux).
However, when I am trying to keep KDC on linux, and client/server on HP..
its failing in gss_import_name on the
client side with error or GSS_S_CALL_INACCESSIBLE_READ.

I tried to google this, but most of the links were indicating the patch
could be an issue.. but apparently that seems to
be okay.
Do I need to install something special on HP-UX. I can see that patches
look good..

$ swlist -lproduct | grep -i gss
  GSS-API               B.11.11        GSS-API Version 1.0
  PHSS_29487            1.0            GSS-API Version 1.0 Cumulative patch

........
    name_buffer.length = strlen("ol_vardhan_al/neto.abcdef.abc.com");
    name_buffer.value = server_name;
    maj_stat = gss_import_name(&min_stat, &name_buffer, mech_type,
&target_name);
..................

On KDC, I can see that ol_vardhan_al/neto.abcdef.abc.com entry is there
(via list_principals)

Any idea.. what I am missing?

Regards,
Manoj

From brahmareddy at tataelxsi.co.in  Tue Aug 25 05:54:30 2009
From: brahmareddy at tataelxsi.co.in (Brahma Reddy)
Date: Tue, 25 Aug 2009 15:24:30 +0530
Subject: Regarding ASN.1 PER encoding
References: 4d569c330711120708h6b0a9c8bxa164dae022a88210@mail.gmail.com
Message-ID: <4A93B4D6.9090609@tataelxsi.co.in>

Hi,

I am currently using ASN1C-0.9.21 Compiler downloaded from 
http://sourceforge.net/projects/asn1c/
I got struct while encoding enumerated type
(ASN to C conversion is successful but while using APIs like 
*per_encoder* to encode the structure given below,not able to encode).

_ASN Format__ _

*-- ASN1START *
* EUTRA-RRC-Definitions DEFINITIONS AUTOMATIC TAGS ::= *
* BEGIN *
* Paging ::= SEQUENCE { *
* countMSB-Uplink INTEGER(0..100), *
* systemInfoModification ENUMERATED {true,no} OPTIONAL, -- Need ON *
* etws-Indication ENUMERATED {true,no} OPTIONAL, -- Need ON *
* nonCriticalExtension SEQUENCE {} OPTIONAL -- Need OP *
* } *
*END *
*-- ASN1STOP *

(In this compiler Enumerated implemented using Integer type)
* help me in encoding this structure*..
Thanks...........

Thanks&Regards,
D.B.Reddy


From tlyu at MIT.EDU  Tue Aug 25 08:38:27 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Tue, 25 Aug 2009 08:38:27 -0400
Subject: Regarding ASN.1 PER encoding
In-Reply-To: <4A93B4D6.9090609@tataelxsi.co.in> (Brahma Reddy's message of
	"Tue, 25 Aug 2009 05:54:30 -0400")
References: <4A93B4D6.9090609@tataelxsi.co.in>
Message-ID: <ldvprakukzg.fsf@cathode-dark-space.mit.edu>

Brahma Reddy <brahmareddy at tataelxsi.co.in> writes:

> Hi,
>
> I am currently using ASN1C-0.9.21 Compiler downloaded from 
> http://sourceforge.net/projects/asn1c/
> I got struct while encoding enumerated type
> (ASN to C conversion is successful but while using APIs like 
> *per_encoder* to encode the structure given below,not able to encode).
>
> _ASN Format__ _
>
> *-- ASN1START *
> * EUTRA-RRC-Definitions DEFINITIONS AUTOMATIC TAGS ::= *
> * BEGIN *
> * Paging ::= SEQUENCE { *
> * countMSB-Uplink INTEGER(0..100), *
> * systemInfoModification ENUMERATED {true,no} OPTIONAL, -- Need ON *
> * etws-Indication ENUMERATED {true,no} OPTIONAL, -- Need ON *
> * nonCriticalExtension SEQUENCE {} OPTIONAL -- Need OP *
> * } *
> *END *
> *-- ASN1STOP *

Does the ASN.1 you quoted above relate to Kerberos?  If you are
looking for general ASN.1 help, or ASN1C help, this mailing list is
probably not the right place.  You would probably get more useful
answers on a mailing list devoted to ASN1C.

From tlyu at MIT.EDU  Tue Aug 25 08:39:57 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Tue, 25 Aug 2009 08:39:57 -0400
Subject: gss_import_name() fails on HPUX .. need help
In-Reply-To: <OFCD9F08C6.40176866-ON8725761C.0076F52E-8625761C.0077EF6B@us.ibm.com>
	(Manoj Mohan's message of "Mon, 24 Aug 2009 17:50:08 -0400")
References: <OFCD9F08C6.40176866-ON8725761C.0076F52E-8625761C.0077EF6B@us.ibm.com>
Message-ID: <ldvk50sukwy.fsf@cathode-dark-space.mit.edu>

Manoj Mohan <manojm at us.ibm.com> writes:

> Hi,
>
> I was able to setup my client server programs successfully when
> KDC/client/server were on same host (linux).
> However, when I am trying to keep KDC on linux, and client/server on HP..
> its failing in gss_import_name on the
> client side with error or GSS_S_CALL_INACCESSIBLE_READ.
>
> I tried to google this, but most of the links were indicating the patch
> could be an issue.. but apparently that seems to
> be okay.
> Do I need to install something special on HP-UX. I can see that patches
> look good..
>
> $ swlist -lproduct | grep -i gss
>   GSS-API               B.11.11        GSS-API Version 1.0
>   PHSS_29487            1.0            GSS-API Version 1.0 Cumulative patch
>
> ........
>     name_buffer.length = strlen("ol_vardhan_al/neto.abcdef.abc.com");
>     name_buffer.value = server_name;
>     maj_stat = gss_import_name(&min_stat, &name_buffer, mech_type,
> &target_name);
> ..................
>
> On KDC, I can see that ol_vardhan_al/neto.abcdef.abc.com entry is there
> (via list_principals)
>
> Any idea.. what I am missing?

You do not appear to have quoted the source code that sets the
"server_name" variable.  It is difficult to tell what the problem may
be without having this information.

From john at betelgeuse.us  Tue Aug 25 09:46:35 2009
From: john at betelgeuse.us (John W. M. Stevens)
Date: Tue, 25 Aug 2009 07:46:35 -0600
Subject: Ticket File Cached in Memory?
Message-ID: <20090825134635.GA29119@betelgeuse.us>

Hi,

I'm developing an authenticated peer-to-peer, messaging service that uses
Kerberos 5.

So far, so good, thanks to a few pithy pointers from this list.  I've
gotten far enough along to be doing performance testing, and the system
is thrashing on opening, reading and closing the file used to store
tickets.

The obvious solution would be to have the tickets cached in memory, but
I can't find any suggestions on how to do that, or even if it is possible.

And, too, I've got a file handle leak (on the ticket file) somewhere, but
that won't matter if I can't speed things up a bit.  And if I speed it up
by caching, that bug won't really matter any more.

Any hints or pointers to what I should be reading to help me figure
how/if memory vs. file caching is possible?

Thanks!
John S.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090825/90309c63/attachment.bin

From sanribu at gmail.com  Tue Aug 25 10:56:41 2009
From: sanribu at gmail.com (Santiago Rivas)
Date: Tue, 25 Aug 2009 16:56:41 +0200
Subject: Validating Kerberos tickets
In-Reply-To: <4A92A00C.7040007@anl.gov>
References: <711a961b0908210423r40748e0dla1fc9a66303b24c@mail.gmail.com>
	<4A8EAE87.6040204@anl.gov>
	<711a961b0908240410i1d4bf58cs6a74996f80d60234@mail.gmail.com>
	<4A92A00C.7040007@anl.gov>
Message-ID: <711a961b0908250756w8f1133fg18ae7bcaf6c844a6@mail.gmail.com>

Well, both the KDC and the client-side of the application are
running on different Debian GNU/Linux machines. But the client could also be
executed on a Windows machine, since it is written in Java.

You are right, Douglas, the server-side of my application is currently
running on a Windows machine, but I'm planning the development of the
same functionality for a Linux machine. So the challenge is to write it in
C, but I don't know where to download C GSSAPI libraries from... Are there
any free C GSSAPI frameworks availible on the web to download?

Thanks again for your help!

Regards,
Santiago

2009/8/24 Douglas E. Engert <deengert at anl.gov>

>
>
>
> Santiago Rivas wrote:
>
>> Hi, Douglas
>>  I had already read that document (in my opinion, a very good one!). But
>> it does not contain enough information for my purpose: the client-side of
>> the application is running through a web browser and it is written in Java.
>> I'm using GSS-API with JAAS, which I agree that makes things a lot easier.
>> But the point is that server-side must be written in C, in order to compile
>> it into a DLL. I have searched for a C-GSSAPI framework... with poor
>> results.
>>
>
> So the server is on Windows. Then you might be able to use the Microsoft
> SSPI
> on the server, as SSPI uses the same protocol as GSSAPI. I have done SSPI
> clients to GSS-API servers on Unix, but not the other way.
>
>  I have downloaded several archives from:
>>
>> http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/gssapi/
>>  But I'm not able to get it working for Visual Studio. Is there any
>> website where I can download an open source C GSSAPI framework?
>>  Thanks a lot!
>>  Regards,
>> Santiago
>>
>>
>> 2009/8/21 Douglas E. Engert <deengert at anl.gov <mailto:deengert at anl.gov>>
>>
>>
>>
>>    Santiago Rivas wrote:
>>
>>        Hi everyone,
>>
>>        I have recently started working with Kerberos v5 and I have read
>>        many
>>        manuals and documents explaining the protocol and showing some
>>        short sample
>>        code. I'm writing a custom C / Java application and I want to
>>        "kerberize" it
>>        in order to achieve Single Sign-On. Up to now, I'm able to
>>        generate both tgt
>>        and tgs tickets on the client, but the main challenge I find is
>>        how to
>>        validate the tgs ticket once it's recieved by the server side of
>> the
>>        application... Any help? Thanks in advance!
>>
>>
>>    You say it is C / Java, If you are calling Kerberos from Java, have
>>    you looked at:
>>
>>
>> http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/single-signon.html
>>
>>    You might be better off use the GSS-API rather then Kerberos directly.
>>    The above URL has an example for that too.
>>
>>    Goolge for java kerberos  to find other references.
>>
>>
>>
>>        PD: I would appreciate to see some source code or read specific
>>        documentation on this task.
>>        _______________________________________________
>>        krbdev mailing list             krbdev at mit.edu
>>        <mailto:krbdev at mit.edu>
>>        https://mailman.mit.edu/mailman/listinfo/krbdev
>>
>>
>>
>>    --
>>     Douglas E. Engert  <DEEngert at anl.gov <mailto:DEEngert at anl.gov>>
>>     Argonne National Laboratory
>>     9700 South Cass Avenue
>>     Argonne, Illinois  60439
>>     (630) 252-5444
>>
>>
>>
> --
>
>  Douglas E. Engert  <DEEngert at anl.gov>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439
>  (630) 252-5444
>

From ghudson at MIT.EDU  Tue Aug 25 12:02:30 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Tue, 25 Aug 2009 12:02:30 -0400
Subject: Services4User review
In-Reply-To: <20090824211425.GD1033@Sun.COM>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<1251146991.20047.133.camel@ray>  <20090824211425.GD1033@Sun.COM>
Message-ID: <1251216150.2171.18.camel@equal-rites.mit.edu>

On Mon, 2009-08-24 at 17:14 -0400, Nicolas Williams wrote:
> http://opensolaris.org/os/community/on/
> http://opensolaris.org/os/community/documentation/getting_started_docs/cstyle.ms.pdf
> http://opensolaris.org/os/community/documentation/getting_started_docs/cstyle.ms

The latter two links are coming up not found, as are the links to the C
style guide on the first page.  As for the larger issue of whether to
use the Sun style or the krb5 style for GSSAPI code, I'm about to
discuss that in a meeting and will likely have more to say later.

Regarding bitfields: I was not suggesting using flag fields and bitwise
arithmetic over bitfields.  The previous code just used a pair of ints,
while the new code uses three 1-bit bitfields.  The idea is to sacrifice
a bit of heap space to give the compiler an easier job, not to try to
write better code than the compiler can.  Whether the flags are accessed
on performance-sensitive paths is irrelevant; the concern is code size,
not speed, so the question is how many times the flags are accessed in
the code, not how often at runtime.  Basically, I am questioning whether
this is premature optimization.



From deengert at anl.gov  Tue Aug 25 12:33:04 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Tue, 25 Aug 2009 11:33:04 -0500
Subject: Validating Kerberos tickets
In-Reply-To: <711a961b0908250756w8f1133fg18ae7bcaf6c844a6@mail.gmail.com>
References: <711a961b0908210423r40748e0dla1fc9a66303b24c@mail.gmail.com>	<4A8EAE87.6040204@anl.gov>	<711a961b0908240410i1d4bf58cs6a74996f80d60234@mail.gmail.com>	<4A92A00C.7040007@anl.gov>
	<711a961b0908250756w8f1133fg18ae7bcaf6c844a6@mail.gmail.com>
Message-ID: <4A941240.9090904@anl.gov>



Santiago Rivas wrote:
> Well, both the KDC and the client-side of the application are
> running on different Debian GNU/Linux machines. But the client could also be
> executed on a Windows machine, since it is written in Java.
> 
> You are right, Douglas, the server-side of my application is currently
> running on a Windows machine, but I'm planning the development of the
> same functionality for a Linux machine. So the challenge is to write it in
> C, but I don't know where to download C GSSAPI libraries from... Are there
> any free C GSSAPI frameworks availible on the web to download?

The MIT Kerberos comes with the GSSAPI library and headers, so I am not sure what
your are missing. When you say framework, are you looking for examples, or how to
avoid having to make the GSSAPI calls yourself.  There are lots of gssapi examples
available, including the ones in the Kerberos distribution, in the  appl/gss-sample
directory.

One example of this is the Globus GSSAPI assist libraries, that do some of the GSSAPI
calls for your. It was originally designed to work with the Globus gsi mechanism
but should work as well with the Kerberos mechanism.


> 
> Thanks again for your help!
> 
> Regards,
> Santiago
> 
> 2009/8/24 Douglas E. Engert <deengert at anl.gov>
> 
>>
>>
>> Santiago Rivas wrote:
>>
>>> Hi, Douglas
>>>  I had already read that document (in my opinion, a very good one!). But
>>> it does not contain enough information for my purpose: the client-side of
>>> the application is running through a web browser and it is written in Java.
>>> I'm using GSS-API with JAAS, which I agree that makes things a lot easier.
>>> But the point is that server-side must be written in C, in order to compile
>>> it into a DLL. I have searched for a C-GSSAPI framework... with poor
>>> results.
>>>
>> So the server is on Windows. Then you might be able to use the Microsoft
>> SSPI
>> on the server, as SSPI uses the same protocol as GSSAPI. I have done SSPI
>> clients to GSS-API servers on Unix, but not the other way.
>>
>>  I have downloaded several archives from:
>>> http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/gssapi/
>>>  But I'm not able to get it working for Visual Studio. Is there any
>>> website where I can download an open source C GSSAPI framework?
>>>  Thanks a lot!
>>>  Regards,
>>> Santiago
>>>
>>>
>>> 2009/8/21 Douglas E. Engert <deengert at anl.gov <mailto:deengert at anl.gov>>
>>>
>>>
>>>
>>>    Santiago Rivas wrote:
>>>
>>>        Hi everyone,
>>>
>>>        I have recently started working with Kerberos v5 and I have read
>>>        many
>>>        manuals and documents explaining the protocol and showing some
>>>        short sample
>>>        code. I'm writing a custom C / Java application and I want to
>>>        "kerberize" it
>>>        in order to achieve Single Sign-On. Up to now, I'm able to
>>>        generate both tgt
>>>        and tgs tickets on the client, but the main challenge I find is
>>>        how to
>>>        validate the tgs ticket once it's recieved by the server side of
>>> the
>>>        application... Any help? Thanks in advance!
>>>
>>>
>>>    You say it is C / Java, If you are calling Kerberos from Java, have
>>>    you looked at:
>>>
>>>
>>> http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/single-signon.html
>>>
>>>    You might be better off use the GSS-API rather then Kerberos directly.
>>>    The above URL has an example for that too.
>>>
>>>    Goolge for java kerberos  to find other references.
>>>
>>>
>>>
>>>        PD: I would appreciate to see some source code or read specific
>>>        documentation on this task.
>>>        _______________________________________________
>>>        krbdev mailing list             krbdev at mit.edu
>>>        <mailto:krbdev at mit.edu>
>>>        https://mailman.mit.edu/mailman/listinfo/krbdev
>>>
>>>
>>>
>>>    --
>>>     Douglas E. Engert  <DEEngert at anl.gov <mailto:DEEngert at anl.gov>>
>>>     Argonne National Laboratory
>>>     9700 South Cass Avenue
>>>     Argonne, Illinois  60439
>>>     (630) 252-5444
>>>
>>>
>>>
>> --
>>
>>  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
> 
> 

-- 

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

From tlyu at MIT.EDU  Tue Aug 25 18:57:09 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Tue, 25 Aug 2009 18:57:09 -0400
Subject: updated build instructions for developers
Message-ID: <ldvd46jpkmy.fsf@cathode-dark-space.mit.edu>

I recently expanded (and renamed) a minimal wiki page that was
previously about building krb5 from checked-out source code.  I made
it more generally applicable to other builds (from release tarballs,
etc.).  The page now lists (though not exhaustively) build
prerequisites and provides suggestions about separate build trees and
"maintainer mode".  Hopefully it will be more useful to developers
now.  Please feel free to comment or edit. (You need to register for a
wiki account to make edits.)  The URL is:

    http://k5wiki.kerberos.org/wiki/Building

-- 
Tom Yu
Development Team Leader
MIT Kerberos Consortium

From lukeh at padl.com  Wed Aug 26 09:03:40 2009
From: lukeh at padl.com (Luke Howard)
Date: Wed, 26 Aug 2009 15:03:40 +0200
Subject: Naming extensions implementation
Message-ID: <7C484B65-3E6B-4229-A143-ACDDAA2A2CBE@padl.com>

See:

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

Note: this code is still a very rough implementation, it is not ready  
for review yet. The branch is users/lhoward/authdata.

However, today you can use it (see t_namingexts) to:

	* retrieve MS PAC buffers individually
	* determine whether the PAC was verified
	* plug in new authorization data verifiers/serializers
	* submit additional authorization data from initiator to acceptor

All public APIs are at the GSS layer and mirror draft-ietf-kitten- 
gssapi-naming-exts (with some slight changes).

cheers,

-- Luke	
--
www.padl.com | www.fghr.net

From ghudson at MIT.EDU  Wed Aug 26 12:10:59 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Wed, 26 Aug 2009 12:10:59 -0400
Subject: Ticket File Cached in Memory?
In-Reply-To: <20090825134635.GA29119@betelgeuse.us>
References: <20090825134635.GA29119@betelgeuse.us>
Message-ID: <1251303059.20047.165.camel@ray>

On Tue, 2009-08-25 at 09:46 -0400, John W. M. Stevens wrote:
> The obvious solution would be to have the tickets cached in memory, but
> I can't find any suggestions on how to do that, or even if it is possible.

We have a memory ccache type, which you can use by setting a credentials
cache name of MEMORY:somestring, where somestring serves to
differentiate memory ccaches within a process.

These caches cannot be shared between processes.  I believe that makes
it tricky to use one transparently, since a credentials cache is
ordinarily shared between kinit (to initialize the cache with an AS-REQ)
and an application.  I have not looked into this myself, but I believe
you would have to write application code to pull a TGT out of a normal
(say, file-based) credentials cache and copy it into the memory ccache.



From lukeh at padl.com  Wed Aug 26 13:09:17 2009
From: lukeh at padl.com (Luke Howard)
Date: Wed, 26 Aug 2009 19:09:17 +0200
Subject: Delegated creds and SPNEGO
Message-ID: <30369993-D0E0-4CA2-9021-1EDEAE813783@padl.com>

There was a bug a while ago (looks like 319351 at Red Hat, not sure  
about the MIT RT number) regarding delegated creds and SPNEGO.

It was fixed by changing gssint_get_mechanism_cred() in the mechglue  
to not unwrap SPNEGO credentials. However, this changes the behaviour  
of everything that calls gssint_get_mechanism_cred(). It means that  
using gss_acquire_cred() for SPNEGO credentials returns  
GSS_S_DUPLICATE_ELEMENT.

Sun fixed the same issue explicitly in the delegated credentials path  
(it is also a workaround, but it did have the advantage of not being a  
special case for SPNEGO).

So, I'm wondering: was this fixed correctly? Is the expectation that,  
when using pseudo-mechanisms, you will acquire credentials for the  
pseudo-mechanism or for the concrete mechanism? If it's the former,  
well, it doesn't work right now. I ask because it impacts some other  
work.

-- Luke
--
www.padl.com | www.fghr.net

From lha at kth.se  Wed Aug 26 13:45:17 2009
From: lha at kth.se (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=)
Date: Wed, 26 Aug 2009 10:45:17 -0700
Subject: Delegated creds and SPNEGO
In-Reply-To: <30369993-D0E0-4CA2-9021-1EDEAE813783@padl.com>
References: <30369993-D0E0-4CA2-9021-1EDEAE813783@padl.com>
Message-ID: <B66AADF1-11D8-4667-A1CC-83A86D7CD736@kth.se>


26 aug 2009 kl. 10:09 skrev Luke Howard:

> So, I'm wondering: was this fixed correctly? Is the expectation that,
> when using pseudo-mechanisms

pseudo mechs are mostly broken. basically every time you add a new  
pseudo or combined mech you are running into this problems what you  
described

for example acquiring NTLM initator credentials to use with SPNEGO is,  
well complicated and have performance problem since it will probably  
get kerberos initator credentials at the same time.

I don't even think its possible to tell ISC what you want it to do.

Does this discussion belong on KITTEN ?

Special casing SPNEGO is bad since that cuts out all other pseudo  
combined mechs (like compression).

Love


From lukeh at padl.com  Wed Aug 26 13:49:00 2009
From: lukeh at padl.com (Luke Howard)
Date: Wed, 26 Aug 2009 19:49:00 +0200
Subject: Delegated creds and SPNEGO
In-Reply-To: <B66AADF1-11D8-4667-A1CC-83A86D7CD736@kth.se>
References: <30369993-D0E0-4CA2-9021-1EDEAE813783@padl.com>
	<B66AADF1-11D8-4667-A1CC-83A86D7CD736@kth.se>
Message-ID: <10D70B9D-6F17-48C4-8627-F3D4459131A4@padl.com>


On 26/08/2009, at 7:45 PM, Love H?rnquist ?strand wrote:

>
> 26 aug 2009 kl. 10:09 skrev Luke Howard:
>
>> So, I'm wondering: was this fixed correctly? Is the expectation that,
>> when using pseudo-mechanisms
>
> pseudo mechs are mostly broken. basically every time you add a new  
> pseudo or combined mech you are running into this problems what you  
> described

Sun fixed it without explicitly checking for SPNEGO, instead making  
the assumption that pseudo-mechs do not wrap credential handles. The  
comment in the source is:

"If we got back an OID different from the original token OID, assume  
the delegated_cred is already a proper union_cred and just return it.  
Don't try to re-wrap it. This is for SPNEGO or other pseudo-mechanisms."

(cf. http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libgss/g_accept_sec_context.c)

-- Luke

PS. MIT/Sun: are there plans to resync Sun's SPNEGO and mechglue  
changes?

From Nicolas.Williams at sun.com  Wed Aug 26 14:10:01 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 26 Aug 2009 13:10:01 -0500
Subject: Delegated creds and SPNEGO
In-Reply-To: <B66AADF1-11D8-4667-A1CC-83A86D7CD736@kth.se>
References: <30369993-D0E0-4CA2-9021-1EDEAE813783@padl.com>
	<B66AADF1-11D8-4667-A1CC-83A86D7CD736@kth.se>
Message-ID: <20090826181001.GD1033@Sun.COM>

On Wed, Aug 26, 2009 at 10:45:17AM -0700, Love H?rnquist ?strand wrote:
> 26 aug 2009 kl. 10:09 skrev Luke Howard:
> > So, I'm wondering: was this fixed correctly? Is the expectation that,
> > when using pseudo-mechanisms
> 
> pseudo mechs are mostly broken. basically every time you add a new  
> pseudo or combined mech you are running into this problems what you  
> described

I mostly agree.  You can get by with no SPNEGO-specials in libgss
though.  The only place where a special is needed is in
gss_accept_sec_context() in the case where: a) there's a delegated cred
and b) actual_mech != the OID in the initial context token.

Solaris' libgss assumes that in that case the delegated credential
returned by the pseudo-mechanism is a libgss credential returned to the
pseudo-mechanism by a libgss gss_accept_sec_context() call for the
underlying mechanism.  Thus Solaris has no code to check for SPNEGO in
libgss, though it does have a SPNEGO-special.

The gss_ctx_id_t returned by gss_init/accept_sec_context() where SPNEGO
was used is still a SPNEGO context.  We could apply the same hack as we
do for delegated credentials though, which would allow us to avoid
having to have SPNEGO-wrapped MNs for the MNs returned by gss_inquire/
accept_sec_context().

> for example acquiring NTLM initator credentials to use with SPNEGO is,  
> well complicated and have performance problem since it will probably  
> get kerberos initator credentials at the same time.

Bad example.  That's supposed to work like this:

 - optional: import a desired name
 - required: call gss_acquire/add_cred() with SPNEGO as a desired_mech,
   and, if you have one, a desired name (see above)
 - optional: call gss_set_neg_mechs() on the acquired credential to set
   the mechs that SPNEGO may negotiate
 - required: call gss_init/accept_sec_context() with the resulting
   credential handle

Internally SPNEGO must extract the neg_mechs set from its cred handle
when its gss_init/accept_sec_context() method is called, and from that
it must extract the desired_name, import a new gss_name_t, and use the
result to acquire a cred handle for the optimistic and negotiated mechs,
and pass that to the re-entered gss_init/accept_sec_context().

I believe that works.

> I don't even think its possible to tell ISC what you want it to do.

I don't agree.  See above.

> Does this discussion belong on KITTEN ?

Only if we find a problem we cannot surmount, and even if we can
surmount all such problems, we should document SPNEGO-specials as
implementor advice in an FYI.

> Special casing SPNEGO is bad

Yes.

>                              since that cuts out all other pseudo  
> combined mechs (like compression).

Not sure I follow.

Nico
-- 

From Nicolas.Williams at sun.com  Wed Aug 26 14:11:37 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 26 Aug 2009 13:11:37 -0500
Subject: Delegated creds and SPNEGO
In-Reply-To: <10D70B9D-6F17-48C4-8627-F3D4459131A4@padl.com>
References: <30369993-D0E0-4CA2-9021-1EDEAE813783@padl.com>
	<B66AADF1-11D8-4667-A1CC-83A86D7CD736@kth.se>
	<10D70B9D-6F17-48C4-8627-F3D4459131A4@padl.com>
Message-ID: <20090826181137.GE1033@Sun.COM>

On Wed, Aug 26, 2009 at 07:49:00PM +0200, Luke Howard wrote:
> Sun fixed it without explicitly checking for SPNEGO, instead making  
> the assumption that pseudo-mechs do not wrap credential handles. The  
> comment in the source is:

Hmm, not quite.  This doesn't apply to all pseudo-mechs -- it applies
only to pseudo-mechs that set actual_mech to something other than their
own OID.  SPNEGO does that.  Stackable pseudo-mechs need not.


From tlyu at MIT.EDU  Wed Aug 26 15:11:17 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Wed, 26 Aug 2009 15:11:17 -0400
Subject: Services4User review
In-Reply-To: <1251216150.2171.18.camel@equal-rites.mit.edu> (Greg Hudson's
	message of "Tue, 25 Aug 2009 12:02:30 -0400")
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<1251146991.20047.133.camel@ray> <20090824211425.GD1033@Sun.COM>
	<1251216150.2171.18.camel@equal-rites.mit.edu>
Message-ID: <ldveiqyl7ai.fsf@cathode-dark-space.mit.edu>

Greg Hudson <ghudson at MIT.EDU> writes:

> On Mon, 2009-08-24 at 17:14 -0400, Nicolas Williams wrote:
>> http://opensolaris.org/os/community/on/
>> http://opensolaris.org/os/community/documentation/getting_started_docs/cstyle.ms.pdf
>> http://opensolaris.org/os/community/documentation/getting_started_docs/cstyle.ms
>
> The latter two links are coming up not found, as are the links to the C
> style guide on the first page.  As for the larger issue of whether to
> use the Sun style or the krb5 style for GSSAPI code, I'm about to
> discuss that in a meeting and will likely have more to say later.

The broken URLs above are actually present as broken links some other
OpenSolaris pages.  Has there been some rearrangement of the site?  Is
there a more authoritative location for SunOS cstyle?

From Nicolas.Williams at sun.com  Wed Aug 26 15:10:58 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 26 Aug 2009 14:10:58 -0500
Subject: Services4User review
In-Reply-To: <ldveiqyl7ai.fsf@cathode-dark-space.mit.edu>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<1251146991.20047.133.camel@ray> <20090824211425.GD1033@Sun.COM>
	<1251216150.2171.18.camel@equal-rites.mit.edu>
	<ldveiqyl7ai.fsf@cathode-dark-space.mit.edu>
Message-ID: <20090826191058.GI1033@Sun.COM>

On Wed, Aug 26, 2009 at 03:11:17PM -0400, Tom Yu wrote:
> Greg Hudson <ghudson at MIT.EDU> writes:
> 
> > On Mon, 2009-08-24 at 17:14 -0400, Nicolas Williams wrote:
> >> http://opensolaris.org/os/community/on/
> >> http://opensolaris.org/os/community/documentation/getting_started_docs/cstyle.ms.pdf
> >> http://opensolaris.org/os/community/documentation/getting_started_docs/cstyle.ms
> >
> > The latter two links are coming up not found, as are the links to the C
> > style guide on the first page.  As for the larger issue of whether to
> > use the Sun style or the krb5 style for GSSAPI code, I'm about to
> > discuss that in a meeting and will likely have more to say later.
> 
> The broken URLs above are actually present as broken links some other
> OpenSolaris pages.  Has there been some rearrangement of the site?  Is
> there a more authoritative location for SunOS cstyle?

Yes.  They're being fixed.  I'll post an update when the links are fixed
or replaced.

Nico
-- 

From lha at kth.se  Thu Aug 27 00:09:32 2009
From: lha at kth.se (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=)
Date: Wed, 26 Aug 2009 21:09:32 -0700
Subject: Delegated creds and SPNEGO
In-Reply-To: <20090826181001.GD1033@Sun.COM>
References: <30369993-D0E0-4CA2-9021-1EDEAE813783@padl.com>
	<B66AADF1-11D8-4667-A1CC-83A86D7CD736@kth.se>
	<20090826181001.GD1033@Sun.COM>
Message-ID: <7144CBED-795B-48AB-BD95-EA761676E977@kth.se>


26 aug 2009 kl. 11:10 skrev Nicolas Williams:

> On Wed, Aug 26, 2009 at 10:45:17AM -0700, Love H?rnquist ?strand  
> wrote:
>> 26 aug 2009 kl. 10:09 skrev Luke Howard:
>>> So, I'm wondering: was this fixed correctly? Is the expectation  
>>> that,
>>> when using pseudo-mechanisms
>>
>> pseudo mechs are mostly broken. basically every time you add a new
>> pseudo or combined mech you are running into this problems what you
>> described
>
> I mostly agree.  You can get by with no SPNEGO-specials in libgss
> though.  The only place where a special is needed is in
> gss_accept_sec_context() in the case where: a) there's a delegated  
> cred
> and b) actual_mech != the OID in the initial context token.
>
> Solaris' libgss assumes that in that case the delegated credential
> returned by the pseudo-mechanism is a libgss credential returned to  
> the
> pseudo-mechanism by a libgss gss_accept_sec_context() call for the
> underlying mechanism.  Thus Solaris has no code to check for SPNEGO in
> libgss, though it does have a SPNEGO-special.
>
> The gss_ctx_id_t returned by gss_init/accept_sec_context() where  
> SPNEGO
> was used is still a SPNEGO context.  We could apply the same hack as  
> we
> do for delegated credentials though, which would allow us to avoid
> having to have SPNEGO-wrapped MNs for the MNs returned by gss_inquire/
> accept_sec_context().
>
>> for example acquiring NTLM initator credentials to use with SPNEGO  
>> is,
>> well complicated and have performance problem since it will probably
>> get kerberos initator credentials at the same time.
>
> Bad example.  That's supposed to work like this:
>
> - optional: import a desired name
> - required: call gss_acquire/add_cred() with SPNEGO as a desired_mech,
>   and, if you have one, a desired name (see above)

How does this get you only NTLM credentials and not Kerberos  
credentials ? Getting Kerberos credential might have side-effects you  
don't want to trigger.

> - optional: call gss_set_neg_mechs() on the acquired credential to set
>   the mechs that SPNEGO may negotiate
> - required: call gss_init/accept_sec_context() with the resulting
>   credential handle
>
> Internally SPNEGO must extract the neg_mechs set from its cred handle
> when its gss_init/accept_sec_context() method is called, and from that
> it must extract the desired_name, import a new gss_name_t, and use the
> result to acquire a cred handle for the optimistic and negotiated  
> mechs,
> and pass that to the re-entered gss_init/accept_sec_context().
>
> I believe that works.

And then you delegate, get your delegated credentials on the acceptor,  
how to turn that back into SPNEGO/.... credentials so that you can use  
SPNEGO/compression/whatever-psuedo-mech again ?

>> I don't even think its possible to tell ISC what you want it to do.
>
> I don't agree.  See above.
>
>> Does this discussion belong on KITTEN ?
>
> Only if we find a problem we cannot surmount, and even if we can
> surmount all such problems, we should document SPNEGO-specials as
> implementor advice in an FYI.
>
>> Special casing SPNEGO is bad
>
> Yes.
>
>>                             since that cuts out all other pseudo
>> combined mechs (like compression).
>
> Not sure I follow.

if you special case SPNEGO, you also need to special case all other  
combined mechs.

Love



From lha at kth.se  Thu Aug 27 01:39:51 2009
From: lha at kth.se (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=)
Date: Wed, 26 Aug 2009 22:39:51 -0700
Subject: Delegated creds and SPNEGO
In-Reply-To: <20090827050710.GN1033@Sun.COM>
References: <30369993-D0E0-4CA2-9021-1EDEAE813783@padl.com>
	<B66AADF1-11D8-4667-A1CC-83A86D7CD736@kth.se>
	<20090826181001.GD1033@Sun.COM>
	<7144CBED-795B-48AB-BD95-EA761676E977@kth.se>
	<20090827050710.GN1033@Sun.COM>
Message-ID: <FE4A0FB5-3D34-4815-AEC5-D87C094E3C4F@kth.se>


26 aug 2009 kl. 22:07 skrev Nicolas Williams:

> On Wed, Aug 26, 2009 at 09:09:32PM -0700, Love H?rnquist ?strand  
> wrote:
>> 26 aug 2009 kl. 11:10 skrev Nicolas Williams:
>>> Bad example.  That's supposed to work like this:
>>>
>>> - optional: import a desired name
>>> - required: call gss_acquire/add_cred() with SPNEGO as a  
>>> desired_mech,
>>> and, if you have one, a desired name (see above)
>>
>> How does this get you only NTLM credentials and not Kerberos
>> credentials ? Getting Kerberos credential might have side-effects you
>> don't want to trigger.
>
> SPNEGO should defer re-entering gss_acquire/add_cred() until the next
> step in the list below happens:
>
>>> - optional: call gss_set_neg_mechs() on the acquired credential to  
>>> set
>>> the mechs that SPNEGO may negotiate
>>> - required: call gss_init/accept_sec_context() with the resulting
>>> credential handle
>>>
>>> [...]
>
>> And then you delegate, get your delegated credentials on the  
>> acceptor,
>> how to turn that back into SPNEGO/.... credentials so that you can  
>> use
>> SPNEGO/compression/whatever-psuedo-mech again ?
>
> You must first store them somewhere with gss_store_cred(), so that you
> can re-acquire; gss_store_cred(), like gss_acquire/add_cred() and
> GSS_C_NO_CREDENTIAL, refers to the "current credential store".   
> Setting
> up credential stores and changing the current credential store are
> outsire the scope of the GSS-API and really are OS-dependent matters
> (e.g., putenv("KRB5CCNAME=...")? setuid()?  setup keyrings?  PAGs?   
> all
> OS-specific).

gss_store_cred() is mostly unusable for just that reason, you can't  
use it inside a multi threaded application, and you are not sure how  
it will affect other processes if you call it. for example, two proxy  
smb fileservers store credentails for the same user, one might  
overwrite credentials for another process.

>
>>>>                           since that cuts out all other pseudo
>>>> combined mechs (like compression).
>>>
>>> Not sure I follow.
>>
>> if you special case SPNEGO, you also need to special case all other
>> combined mechs.
>
> Our special case does not actually check for the SPNEGO OID.  It's a
> very simple special case (if (have_deleg_cred && actual_mech !=
> initial_context_token_mech) then expect the mech to have returned a
> mechglue cred, not a mech cred).  It could use a tiny tweak for the  
> case
> of composite mechs (instead of actual_mech !=  
> initial_context_token_mech
> it needs to check that initial_context_token_mech is equal to or a
> prefix of actual_mech).

Then you force all composed mechs to use mechglue layer credentials,  
so they can't have their own credentials. Somethings that you  
recommend doing for gss_acquire_cred (ie defer acquire until later)  
above.

Love




From Nicolas.Williams at sun.com  Thu Aug 27 01:07:10 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 27 Aug 2009 00:07:10 -0500
Subject: Delegated creds and SPNEGO
In-Reply-To: <7144CBED-795B-48AB-BD95-EA761676E977@kth.se>
References: <30369993-D0E0-4CA2-9021-1EDEAE813783@padl.com>
	<B66AADF1-11D8-4667-A1CC-83A86D7CD736@kth.se>
	<20090826181001.GD1033@Sun.COM>
	<7144CBED-795B-48AB-BD95-EA761676E977@kth.se>
Message-ID: <20090827050710.GN1033@Sun.COM>

On Wed, Aug 26, 2009 at 09:09:32PM -0700, Love H?rnquist ?strand wrote:
> 26 aug 2009 kl. 11:10 skrev Nicolas Williams:
> >Bad example.  That's supposed to work like this:
> >
> >- optional: import a desired name
> >- required: call gss_acquire/add_cred() with SPNEGO as a desired_mech,
> >  and, if you have one, a desired name (see above)
> 
> How does this get you only NTLM credentials and not Kerberos  
> credentials ? Getting Kerberos credential might have side-effects you  
> don't want to trigger.

SPNEGO should defer re-entering gss_acquire/add_cred() until the next
step in the list below happens:

> >- optional: call gss_set_neg_mechs() on the acquired credential to set
> >  the mechs that SPNEGO may negotiate
> >- required: call gss_init/accept_sec_context() with the resulting
> >  credential handle
> > 
> > [...]

> And then you delegate, get your delegated credentials on the acceptor,  
> how to turn that back into SPNEGO/.... credentials so that you can use  
> SPNEGO/compression/whatever-psuedo-mech again ?

You must first store them somewhere with gss_store_cred(), so that you
can re-acquire; gss_store_cred(), like gss_acquire/add_cred() and
GSS_C_NO_CREDENTIAL, refers to the "current credential store".  Setting
up credential stores and changing the current credential store are
outsire the scope of the GSS-API and really are OS-dependent matters
(e.g., putenv("KRB5CCNAME=...")? setuid()?  setup keyrings?  PAGs?  all
OS-specific).

> >>                            since that cuts out all other pseudo
> >>combined mechs (like compression).
> >
> >Not sure I follow.
> 
> if you special case SPNEGO, you also need to special case all other  
> combined mechs.

Our special case does not actually check for the SPNEGO OID.  It's a
very simple special case (if (have_deleg_cred && actual_mech !=
initial_context_token_mech) then expect the mech to have returned a
mechglue cred, not a mech cred).  It could use a tiny tweak for the case
of composite mechs (instead of actual_mech != initial_context_token_mech
it needs to check that initial_context_token_mech is equal to or a
prefix of actual_mech).

Nico
-- 

From Akos.Frohner at cern.ch  Thu Aug 27 04:51:52 2009
From: Akos.Frohner at cern.ch (FROHNER Akos)
Date: Thu, 27 Aug 2009 10:51:52 +0200
Subject: Ticket File Cached in Memory?
In-Reply-To: <1251303059.20047.165.camel@ray>
	<20090825134635.GA29119@betelgeuse.us>
References: <20090825134635.GA29119@betelgeuse.us>
	<1251303059.20047.165.camel@ray>
	<20090825134635.GA29119@betelgeuse.us>
Message-ID: <20090827085152.GB6493@pcitgm06.cern.ch>

Hi,

On Tue, 2009-08-25 15:46:35 +0200, John W. M. Stevens wrote:
[...]
> Any hints or pointers to what I should be reading to help me figure
> how/if memory vs. file caching is possible?
> 
> Thanks!
> John S.

According to our experience the bottleneck is rather in
the replay cache.


On Wed, 2009-08-26 18:10:59 +0200, Greg Hudson wrote:
> On Tue, 2009-08-25 at 09:46 -0400, John W. M. Stevens wrote:
> > The obvious solution would be to have the tickets cached in memory, but
> > I can't find any suggestions on how to do that, or even if it is possible.
> 
> We have a memory ccache type, which you can use by setting a credentials
> cache name of MEMORY:somestring, where somestring serves to
> differentiate memory ccaches within a process.

Unfortunately I could not find a memory backed per-process replay cache
for the MIT implementation yet. 

-- 
?kos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4143 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090827/d30f813f/smime.bin

From ghudson at MIT.EDU  Thu Aug 27 08:23:41 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Thu, 27 Aug 2009 08:23:41 -0400
Subject: Services4User review
In-Reply-To: <20090824211425.GD1033@Sun.COM>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<1251146991.20047.133.camel@ray>  <20090824211425.GD1033@Sun.COM>
Message-ID: <1251375821.20047.204.camel@ray>

On Mon, 2009-08-24 at 17:14 -0400, Nicolas Williams wrote:
> Putting parens around return expressions is a Solaris C-style dictum.
> If this code is based on Solaris' libgss, then I recommend adhering to
> the Solaris C-style if possible, for now.

To sort of close the loop on this:

* For now, it is preferrable for to use the Solaris C style within those
parts of libgss (specifically mechglue).  So, ignore my formatting
comments within that directory where they disagree with the Sun
guidelines.

* The eventual fate of that code is a bit unclear unclear.  Will didn't
think there were any particular plans for a merge in one direction or
the other, but I'm still concerned that we might want to retain merge
compatibility if only for the sake of shuttling patches back and forth.
(For instance, I think I may have discovered a memory leak in the
mechglue gss_accept_context, which Sun might be interested to know
about.)



From ghudson at MIT.EDU  Thu Aug 27 08:42:29 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Thu, 27 Aug 2009 08:42:29 -0400
Subject: Ticket File Cached in Memory?
In-Reply-To: <20090827085152.GB6493@pcitgm06.cern.ch>
References: <20090825134635.GA29119@betelgeuse.us>
	<1251303059.20047.165.camel@ray> <20090825134635.GA29119@betelgeuse.us>
	<20090827085152.GB6493@pcitgm06.cern.ch>
Message-ID: <1251376949.20047.224.camel@ray>

On Thu, 2009-08-27 at 04:51 -0400, FROHNER Akos wrote:
> According to our experience the bottleneck is rather in
> the replay cache.

Not all protocols require a replay cache.  You can turn ours off by
setting KRB5RCACHETYPE=none in the environment.

One way to protect the server from replays is to design the protocol so
that the server sends a nonce to the client and requires the client to
play it back (with stream protection, of course).

In an ideal world, even that much should be unnecessary if you are doing
mutual authentication and stream protection, and not protecting any
application data with the authenticator checksum.  This is because
ideally, the server would pick a fresh subkey each time the client
authenticates.  Unfortunately, the server's use of subkeys is kind of
spotty at this time (for instance, for GSSAPI, it won't do so if the
client appears too old) and I believe was nonexistent prior to krb5 1.7.

We're aware that our replay cache implementation is often a bottleneck,
and I should have probably thought to mention it earlier.



From john at betelgeuse.us  Thu Aug 27 09:41:25 2009
From: john at betelgeuse.us (John W. M. Stevens)
Date: Thu, 27 Aug 2009 07:41:25 -0600
Subject: Ticket File Cached in Memory?
In-Reply-To: <1251376949.20047.224.camel@ray>
References: <20090825134635.GA29119@betelgeuse.us>
	<1251303059.20047.165.camel@ray>
	<20090825134635.GA29119@betelgeuse.us>
	<20090827085152.GB6493@pcitgm06.cern.ch>
	<1251376949.20047.224.camel@ray>
Message-ID: <20090827134125.GA6747@betelgeuse.us>

On Thu, Aug 27, 2009 at 08:42:29AM -0400, Greg Hudson wrote:
> On Thu, 2009-08-27 at 04:51 -0400, FROHNER Akos wrote:
> > According to our experience the bottleneck is rather in
> > the replay cache.
> 
> Not all protocols require a replay cache.  You can turn ours off by
> setting KRB5RCACHETYPE=none in the environment.

Good pointer.  Thanks!

> One way to protect the server from replays is to design the protocol so
> that the server sends a nonce to the client and requires the client to
> play it back (with stream protection, of course).

The core design, in a few sentences, is that of an event messaging
(as in: OO messaging) system (asynchronous, parameters allowed but
no returns) between "peers" where each peer has to be a kind of
server, in that it can accept connections, authenticate them, then
hand off the connection to a sub-process to process.

I initially started off with just authentication (no message encryption),
but decided that I would add encryption after some thought.

In a high load test, with a lot of short lived peer-to-peer connections,
the system is seeing a lot of disk thrash.  This really didn't occur
until after I added message encryption, and in that process I did
attempt to turn on replay detection, so I might very well be
chasing down the wrong path.

> In an ideal world, even that much should be unnecessary if you are doing
> mutual authentication and stream protection,

And ideally this system would have a lower risk of replay due to the
short lived nature of the connections.

> and not protecting any
> application data with the authenticator checksum.  This is because
> ideally, the server would pick a fresh subkey each time the client
> authenticates.  Unfortunately, the server's use of subkeys is kind of
> spotty at this time (for instance, for GSSAPI, it won't do so if the
> client appears too old) and I believe was nonexistent prior to krb5 1.7.

I'm going to have to do some reading to understand this last
part.  Thanks for the input, though.

> We're aware that our replay cache implementation is often a bottleneck,
> and I should have probably thought to mention it earlier.

Is the replay cache stored in a file that, in the default install, is
given a temporary name and put into a temporary directory?

Thanks,
John S.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090827/ff6ac13e/attachment-0001.bin

From Akos.Frohner at cern.ch  Thu Aug 27 09:47:26 2009
From: Akos.Frohner at cern.ch (FROHNER Akos)
Date: Thu, 27 Aug 2009 15:47:26 +0200
Subject: Ticket File Cached in Memory?
In-Reply-To: <1251376949.20047.224.camel@ray>
References: <20090825134635.GA29119@betelgeuse.us>
	<1251303059.20047.165.camel@ray>
	<20090825134635.GA29119@betelgeuse.us>
	<20090827085152.GB6493@pcitgm06.cern.ch>
	<1251376949.20047.224.camel@ray>
Message-ID: <20090827134726.GE6493@pcitgm06.cern.ch>

On Thu, 2009-08-27 14:42:29 +0200, Greg Hudson wrote:
[...]
> One way to protect the server from replays is to design the protocol so
> that the server sends a nonce to the client and requires the client to
> play it back (with stream protection, of course).

Unfortunately our protocol does not make use of stream protection,
just uses Kerberos as one of the GSS-API authentication methods.

--
Akos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4143 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090827/de70afe6/smime.bin

From ghudson at MIT.EDU  Thu Aug 27 11:12:35 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Thu, 27 Aug 2009 11:12:35 -0400
Subject: Ticket File Cached in Memory?
In-Reply-To: <20090827134125.GA6747@betelgeuse.us>
References: <20090825134635.GA29119@betelgeuse.us>
	<1251303059.20047.165.camel@ray> <20090825134635.GA29119@betelgeuse.us>
	<20090827085152.GB6493@pcitgm06.cern.ch>
	<1251376949.20047.224.camel@ray>
	<20090827134125.GA6747@betelgeuse.us>
Message-ID: <1251385955.20047.236.camel@ray>

On Thu, 2009-08-27 at 09:41 -0400, John W. M. Stevens wrote:
> The core design, in a few sentences, is that of an event messaging
> (as in: OO messaging) system (asynchronous, parameters allowed but
> no returns) between "peers" where each peer has to be a kind of
> server, in that it can accept connections, authenticate them, then
> hand off the connection to a sub-process to process.

One option for this kind of protocol is to assign each message a unique
identifier, and essentially do your own replay detection.  (This also
works to eliminate retransmits, although that may not be an issue in the
first place with your architecture.)

> Is the replay cache stored in a file that, in the default install, is
> given a temporary name and put into a temporary directory?

Yes, generally in /var/tmp.  The name isn't actually temporary; it's
generally something like /var/tmp/host_0, where "host" is the name of
the service and 0 is the uid of the process.




From Nicolas.Williams at sun.com  Thu Aug 27 11:54:16 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 27 Aug 2009 10:54:16 -0500
Subject: Delegated creds and SPNEGO
In-Reply-To: <FE4A0FB5-3D34-4815-AEC5-D87C094E3C4F@kth.se>
References: <30369993-D0E0-4CA2-9021-1EDEAE813783@padl.com>
	<B66AADF1-11D8-4667-A1CC-83A86D7CD736@kth.se>
	<20090826181001.GD1033@Sun.COM>
	<7144CBED-795B-48AB-BD95-EA761676E977@kth.se>
	<20090827050710.GN1033@Sun.COM>
	<FE4A0FB5-3D34-4815-AEC5-D87C094E3C4F@kth.se>
Message-ID: <20090827155415.GP1033@Sun.COM>

On Wed, Aug 26, 2009 at 10:39:51PM -0700, Love H?rnquist ?strand wrote:
> 26 aug 2009 kl. 22:07 skrev Nicolas Williams:
> >You must first store them somewhere with gss_store_cred(), so that
> >you can re-acquire; gss_store_cred(), like gss_acquire/add_cred() and
> >GSS_C_NO_CREDENTIAL, refers to the "current credential store".
> >Setting up credential stores and changing the current credential
> >store are outsire the scope of the GSS-API and really are
> >OS-dependent matters (e.g., putenv("KRB5CCNAME=...")? setuid()?
> >setup keyrings?  PAGs?   all OS-specific).
> 
> gss_store_cred() is mostly unusable for just that reason, you can't  
> use it inside a multi threaded application, and you are not sure how  
> it will affect other processes if you call it. for example, two proxy  
> smb fileservers store credentails for the same user, one might  
> overwrite credentials for another process.

That's not necessarily true.  For example, it's not true on Linux, since
you can setup your per-thread keyrings appropriately and off it goes.

And we could introduce a notion of credential store handles.  This would
entail:

a) functions to create and release credentials stores;
b) a function to get a handle to the current credential store, and one
   to set the current credential store to a given handle;
c) new versions of gss_acquire/add/store_cred() that take a credential
   store handle;
d) OS-specific functions for finding and manipulating other processes'/
   threads' notion of current credential stores.

> >Our special case does not actually check for the SPNEGO OID.  It's a
> >very simple special case (if (have_deleg_cred && actual_mech !=
> >initial_context_token_mech) then expect the mech to have returned a
> >mechglue cred, not a mech cred).  It could use a tiny tweak for the
> >case of composite mechs (instead of actual_mech !=
> >initial_context_token_mech it needs to check that
> >initial_context_token_mech is equal to or a prefix of actual_mech).
> 
> Then you force all composed mechs to use mechglue layer credentials,  
> so they can't have their own credentials. Somethings that you  
> recommend doing for gss_acquire_cred (ie defer acquire until later)  
> above.

I got the sense of the check backwards, sorry, it should be:

	if (have_deleg_cred && actual_mech != init_ctx_tok_mech &&
	    !is_prefix(init_ctx_tok_mech, actual_mech))
		expect deleg cred to be a mechglue cred;

A stackable mech that returns a composite mech as the actual_mech will
be able to (will have to) have its own wrapper for the delegated
credentials.

Nico
-- 

From sanribu at gmail.com  Thu Aug 27 13:14:14 2009
From: sanribu at gmail.com (Santiago Rivas)
Date: Thu, 27 Aug 2009 19:14:14 +0200
Subject: Validating Kerberos tickets
In-Reply-To: <4A941240.9090904@anl.gov>
References: <711a961b0908210423r40748e0dla1fc9a66303b24c@mail.gmail.com>
	<4A8EAE87.6040204@anl.gov>
	<711a961b0908240410i1d4bf58cs6a74996f80d60234@mail.gmail.com>
	<4A92A00C.7040007@anl.gov>
	<711a961b0908250756w8f1133fg18ae7bcaf6c844a6@mail.gmail.com>
	<4A941240.9090904@anl.gov>
Message-ID: <711a961b0908271014i51cad702ndfbd7c1ec0fc51f3@mail.gmail.com>

I must apologize, Douglas

I didn't take the time to explore MIT website and dowload Kerberos
release(s). That's exactly what I was talking about when I asked for the
"framework" (all the library files pacekd in the krb5/kwf tar and zip
files).

Now that I have got them, there is a lot of "hands on" left for me.

Thanks again! (and sorry if I drove you a little crazy)

Regards,
Santiago

2009/8/25 Douglas E. Engert <deengert at anl.gov>

>
>
> Santiago Rivas wrote:
>
>> Well, both the KDC and the client-side of the application are
>> running on different Debian GNU/Linux machines. But the client could also
>> be
>> executed on a Windows machine, since it is written in Java.
>>
>> You are right, Douglas, the server-side of my application is currently
>> running on a Windows machine, but I'm planning the development of the
>> same functionality for a Linux machine. So the challenge is to write it in
>> C, but I don't know where to download C GSSAPI libraries from... Are there
>> any free C GSSAPI frameworks availible on the web to download?
>>
>
> The MIT Kerberos comes with the GSSAPI library and headers, so I am not
> sure what
> your are missing. When you say framework, are you looking for examples, or
> how to
> avoid having to make the GSSAPI calls yourself.  There are lots of gssapi
> examples
> available, including the ones in the Kerberos distribution, in the
>  appl/gss-sample
> directory.
>
> One example of this is the Globus GSSAPI assist libraries, that do some of
> the GSSAPI
> calls for your. It was originally designed to work with the Globus gsi
> mechanism
> but should work as well with the Kerberos mechanism.
>
>
>
>> Thanks again for your help!
>>
>> Regards,
>> Santiago
>>
>> 2009/8/24 Douglas E. Engert <deengert at anl.gov>
>>
>>
>>>
>>> Santiago Rivas wrote:
>>>
>>> Hi, Douglas
>>>>  I had already read that document (in my opinion, a very good one!). But
>>>> it does not contain enough information for my purpose: the client-side
>>>> of
>>>> the application is running through a web browser and it is written in
>>>> Java.
>>>> I'm using GSS-API with JAAS, which I agree that makes things a lot
>>>> easier.
>>>> But the point is that server-side must be written in C, in order to
>>>> compile
>>>> it into a DLL. I have searched for a C-GSSAPI framework... with poor
>>>> results.
>>>>
>>>> So the server is on Windows. Then you might be able to use the Microsoft
>>> SSPI
>>> on the server, as SSPI uses the same protocol as GSSAPI. I have done SSPI
>>> clients to GSS-API servers on Unix, but not the other way.
>>>
>>>  I have downloaded several archives from:
>>>
>>>>
>>>> http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/gssapi/
>>>>  But I'm not able to get it working for Visual Studio. Is there any
>>>> website where I can download an open source C GSSAPI framework?
>>>>  Thanks a lot!
>>>>  Regards,
>>>> Santiago
>>>>
>>>>
>>>> 2009/8/21 Douglas E. Engert <deengert at anl.gov <mailto:deengert at anl.gov
>>>> >>
>>>>
>>>>
>>>>
>>>>   Santiago Rivas wrote:
>>>>
>>>>       Hi everyone,
>>>>
>>>>       I have recently started working with Kerberos v5 and I have read
>>>>       many
>>>>       manuals and documents explaining the protocol and showing some
>>>>       short sample
>>>>       code. I'm writing a custom C / Java application and I want to
>>>>       "kerberize" it
>>>>       in order to achieve Single Sign-On. Up to now, I'm able to
>>>>       generate both tgt
>>>>       and tgs tickets on the client, but the main challenge I find is
>>>>       how to
>>>>       validate the tgs ticket once it's recieved by the server side of
>>>> the
>>>>       application... Any help? Thanks in advance!
>>>>
>>>>
>>>>   You say it is C / Java, If you are calling Kerberos from Java, have
>>>>   you looked at:
>>>>
>>>>
>>>>
>>>> http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/single-signon.html
>>>>
>>>>   You might be better off use the GSS-API rather then Kerberos directly.
>>>>   The above URL has an example for that too.
>>>>
>>>>   Goolge for java kerberos  to find other references.
>>>>
>>>>
>>>>
>>>>       PD: I would appreciate to see some source code or read specific
>>>>       documentation on this task.
>>>>       _______________________________________________
>>>>       krbdev mailing list             krbdev at mit.edu
>>>>       <mailto:krbdev at mit.edu>
>>>>       https://mailman.mit.edu/mailman/listinfo/krbdev
>>>>
>>>>
>>>>
>>>>   --
>>>>    Douglas E. Engert  <DEEngert at anl.gov <mailto:DEEngert at anl.gov>>
>>>>    Argonne National Laboratory
>>>>    9700 South Cass Avenue
>>>>    Argonne, Illinois  60439
>>>>    (630) 252-5444
>>>>
>>>>
>>>>
>>>> --
>>>
>>>  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
>>
>>
>>
> --
>
>  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  Thu Aug 27 12:47:30 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 27 Aug 2009 11:47:30 -0500
Subject: Delegated creds and SPNEGO
In-Reply-To: <20090827155415.GP1033@Sun.COM>
References: <30369993-D0E0-4CA2-9021-1EDEAE813783@padl.com>
	<B66AADF1-11D8-4667-A1CC-83A86D7CD736@kth.se>
	<20090826181001.GD1033@Sun.COM>
	<7144CBED-795B-48AB-BD95-EA761676E977@kth.se>
	<20090827050710.GN1033@Sun.COM>
	<FE4A0FB5-3D34-4815-AEC5-D87C094E3C4F@kth.se>
	<20090827155415.GP1033@Sun.COM>
Message-ID: <20090827164729.GU1033@Sun.COM>

On Thu, Aug 27, 2009 at 10:54:16AM -0500, Nicolas Williams wrote:
> On Wed, Aug 26, 2009 at 10:39:51PM -0700, Love H?rnquist ?strand wrote:
> > gss_store_cred() is mostly unusable for just that reason, you can't  
> > use it inside a multi threaded application, and you are not sure how  
> > it will affect other processes if you call it. for example, two proxy  
> > smb fileservers store credentails for the same user, one might  
> > overwrite credentials for another process.
> 
> That's not necessarily true.  For example, it's not true on Linux, since
> you can setup your per-thread keyrings appropriately and off it goes.
> 
> And we could introduce a notion of credential store handles.  This would
> entail:
> 
> a) functions to create and release credentials stores;
> b) a function to get a handle to the current credential store, and one
>    to set the current credential store to a given handle;
> c) new versions of gss_acquire/add/store_cred() that take a credential
>    store handle;

I'm pretty sure I mentioned this at KITTEN long ago...  Anyways,
explicit credential store handles would be very nice.  They'd have to
expose the granularity of current credential store associations in the
OS's process model, but otherwise they'd fully abstract details such as
"PAGs", "keyrings", etcetera, though they wouldn't abstract the details
of setting up new PAGs or session keyrings.  API-wise it'd look like:

a) GSS_Init_cred_store()                    -> status, CREDSTORE HANDLE
   GSS_Release_cred_store(CREDSTORE HANDLE) -> status

b) GSS_Get_current_cred_store(scope)        -> status, CREDSTORE HANDLE
   GSS_Set_current_cred_store(scope, CREDSTORE HANDLE) -> status

   Input "scope" argument: GSS_C_CS_SCOPE_{THREAD,PROCESS,SESSION,USER}.

c) GSS_Acquire_cred_from_store(..., CREDSTORE HANDLE) -> ...
   GSS_Add_cred_from_store(..., CREDSTORE HANDLE)     -> ...
   GSS_Store_cred_into_store(..., CREDSTORE HANDLE)   -> ...

   Same as GSS_Add/Acquire/Store_cred(), but with an extra input
   argument: a credential store handle.
   
   Default credential store handle symbol: GSS_C_NO_CRED_STORE.

Nico
-- 

From krishnag at likewise.com  Fri Aug 28 16:28:22 2009
From: krishnag at likewise.com (Krishna Ganugapati)
Date: Fri, 28 Aug 2009 16:28:22 -0400
Subject: Integrating our gss-ntlm so with krb5-1.7
Message-ID: <23447137FA0DAA4D95EF535FF356BE46031289CA@mse3be2.mse3.exchange.ms>

Hello all,

 

Sorry if this is the wrong alias...

 

Likewise has just moved to krb5-1.7.  Part of Likewise's offering
includes an ntlm gss library. Basically we have a shared object library
libgssntlm.so which has  functions like ntlm_gss_initialize_sec_ctxt,
ntlm_gss_accept_sec_ctx, and so on...

 

My understanding is that krb5-1.7 can dynamically load shared object
libraries in its spnego implementation, thereby allow implementations of
ntlm. Question is how do we make our ntlm library available to the
spnego router. Is there a configuration file that we need to add our .so
to?

 

Thanks

 

Krishna


From lukeh at padl.com  Fri Aug 28 19:52:27 2009
From: lukeh at padl.com (Luke Howard)
Date: Sat, 29 Aug 2009 01:52:27 +0200
Subject: Integrating our gss-ntlm so with krb5-1.7
In-Reply-To: <23447137FA0DAA4D95EF535FF356BE46031289CA@mse3be2.mse3.exchange.ms>
References: <23447137FA0DAA4D95EF535FF356BE46031289CA@mse3be2.mse3.exchange.ms>
Message-ID: <1939FA1D-4D49-49A9-8703-1BB18FC11CC6@padl.com>

> My understanding is that krb5-1.7 can dynamically load shared object
> libraries in its spnego implementation, thereby allow  
> implementations of
> ntlm. Question is how do we make our ntlm library available to the
> spnego router. Is there a configuration file that we need to add  
> our .so
> to?


cat >> $etcdir/gss/mech
ntlm			1.3.6.1.4.1.311.2.2.10	mech_ntlm.so
^D

-- Luke

From lukeh at padl.com  Fri Aug 28 19:56:56 2009
From: lukeh at padl.com (Luke Howard)
Date: Sat, 29 Aug 2009 01:56:56 +0200
Subject: Integrating our gss-ntlm so with krb5-1.7
In-Reply-To: <23447137FA0DAA4D95EF535FF356BE46031289CA@mse3be2.mse3.exchange.ms>
References: <23447137FA0DAA4D95EF535FF356BE46031289CA@mse3be2.mse3.exchange.ms>
Message-ID: <3A380AA6-AAAE-4BE1-8B35-4B6949B2E9CC@padl.com>

> Likewise has just moved to krb5-1.7.  Part of Likewise's offering
> includes an ntlm gss library. Basically we have a shared object  
> library
> libgssntlm.so which has  functions like ntlm_gss_initialize_sec_ctxt,
> ntlm_gss_accept_sec_ctx, and so on...

The configuration file needs to point to the actual shared object  
name. In DSfW and Solaris, it's typically named mech_foo.so (to  
distinguish it from a library that can be linked against). But  
libgssntlm.so is fine too.

You'll need to rename your symbols to gss_init_sec_context,  
gss_accept_sec_context, etc.

-- Luke

From lukeh at padl.com  Sat Aug 29 04:08:08 2009
From: lukeh at padl.com (Luke Howard)
Date: Sat, 29 Aug 2009 10:08:08 +0200
Subject: Services4User review
In-Reply-To: <1251375821.20047.204.camel@ray>
References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com>
	<1251146991.20047.133.camel@ray> <20090824211425.GD1033@Sun.COM>
	<1251375821.20047.204.camel@ray>
Message-ID: <2600C6F8-73DD-43E0-9E49-6A5F71702608@padl.com>

> * The eventual fate of that code is a bit unclear unclear.  Will  
> didn't
> think there were any particular plans for a merge in one direction or
> the other, but I'm still concerned that we might want to retain merge
> compatibility if only for the sake of shuttling patches back and  
> forth.
> (For instance, I think I may have discovered a memory leak in the
> mechglue gss_accept_context, which Sun might be interested to know
> about.)

Also, as mentioned in my earlier mail, I think we should merge in  
Sun's changes, to fix the fix for handling of delegated credentials.

-- Luke

From lukeh at padl.com  Mon Aug 31 14:08:35 2009
From: lukeh at padl.com (Luke Howard)
Date: Mon, 31 Aug 2009 20:08:35 +0200
Subject: Delegated creds and SPNEGO
In-Reply-To: <20090827050710.GN1033@Sun.COM>
References: <30369993-D0E0-4CA2-9021-1EDEAE813783@padl.com>
	<B66AADF1-11D8-4667-A1CC-83A86D7CD736@kth.se>
	<20090826181001.GD1033@Sun.COM>
	<7144CBED-795B-48AB-BD95-EA761676E977@kth.se>
	<20090827050710.GN1033@Sun.COM>
Message-ID: <D0897125-B8D5-4CD1-86C6-112E7FB15859@padl.com>



>>
> Our special case does not actually check for the SPNEGO OID.  It's a
> very simple special case (if (have_deleg_cred && actual_mech !=
> initial_context_token_mech) then expect the mech to have returned a
> mechglue cred, not a mech cred).  It could use a tiny tweak for the  
> case
> of composite mechs (instead of actual_mech !=  
> initial_context_token_mech
> it needs to check that initial_context_token_mech is equal to or a
> prefix of actual_mech).

OK, I've implemented this (more or less). Seems to work.

MIT: this means, I've backed out the deleg credentials fix that went  
in 1.7 (this is in the S4U branch). However, I have verified  
delegation still works

-- Luke