From ls.niks at gmail.com  Sun Feb  1 13:51:19 2009
From: ls.niks at gmail.com (Nikhil Mishra)
Date: Mon, 2 Feb 2009 00:21:19 +0530
Subject: db_invoke
Message-ID: <35dad1db0902011051k3c41481eh5f09aa7b176c2dcb@mail.gmail.com>

Hi All ,


How is this function working ?

check_allowed_to_delegate_to

calls

code = krb5_db_invoke(context,
                          KRB5_KDB_METHOD_CHECK_ALLOWED_TO_DELEGATE,
                          &req_data,
                          &rep_data);


and in my case dal_handle->lib_handle->vftabl.db_invoke is always NULL .

if (dal_handle->lib_handle->vftabl.db_invoke == NULL) {
        status = KRB5_KDB_DBTYPE_NOSUP;
        goto clean_n_exit;
    }


I dont see any implementation for db_invoke as well .
Do we need to implement db_invoke and If so , why do I see it being called
at multiple places ?

--Nikhil

From lukeh at padl.com  Sun Feb  1 15:32:32 2009
From: lukeh at padl.com (Luke Howard)
Date: Mon, 2 Feb 2009 07:32:32 +1100
Subject: db_invoke
In-Reply-To: <35dad1db0902011051k3c41481eh5f09aa7b176c2dcb@mail.gmail.com>
References: <35dad1db0902011051k3c41481eh5f09aa7b176c2dcb@mail.gmail.com>
Message-ID: <17CEFE4E-AA79-45F5-89A4-F0EC1049E41A@padl.com>

Nikhil,

db_invoke is an extra layer of indirection, I added this initially so  
that interfaces between the KDC and backend could be easily added  
without changing the kdb dispatch table (principally to ease merges  
when this code was proprietary). Whether this approach is still valid  
is open to debate.

There is no implementation in any of the backends shipped with MIT;  
you'll need to implement this yourself.

-- Luke

On 02/02/2009, at 5:51 AM, Nikhil Mishra wrote:

> Hi All ,
>
>
> How is this function working ?
>
> check_allowed_to_delegate_to
>
> calls
>
> code = krb5_db_invoke(context,
>                          KRB5_KDB_METHOD_CHECK_ALLOWED_TO_DELEGATE,
>                          &req_data,
>                          &rep_data);
>
>
> and in my case dal_handle->lib_handle->vftabl.db_invoke is always  
> NULL .
>
> if (dal_handle->lib_handle->vftabl.db_invoke == NULL) {
>        status = KRB5_KDB_DBTYPE_NOSUP;
>        goto clean_n_exit;
>    }
>
>
> I dont see any implementation for db_invoke as well .
> Do we need to implement db_invoke and If so , why do I see it being  
> called
> at multiple places ?
>
> --Nikhil
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>

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


From ls.niks at gmail.com  Mon Feb  2 00:12:56 2009
From: ls.niks at gmail.com (Nikhil Mishra)
Date: Mon, 2 Feb 2009 10:42:56 +0530
Subject: db_invoke
In-Reply-To: <17CEFE4E-AA79-45F5-89A4-F0EC1049E41A@padl.com>
References: <35dad1db0902011051k3c41481eh5f09aa7b176c2dcb@mail.gmail.com>
	<17CEFE4E-AA79-45F5-89A4-F0EC1049E41A@padl.com>
Message-ID: <35dad1db0902012112t5e5adfc8gec828dc6936ae221@mail.gmail.com>

Thanks Luke and I understand the purpose of db_invoke .

But then as I understand, for constrained delegation to work on kdc side,
db_invoke has to be implemented or at least in some form
check_allowed_to_delegate_to should be able to call some db function to
check given service principal is allowed to delegate to given proxy_princ .

Is there any such db function as of now ?

If I understand it correctly from previous email exchanges constrained
delegation should work on kdc side for MIT kerberos ?
Do we need some modifications in calling functions as I dont see it working
with db_invoke ?


--Nikhil

On Mon, Feb 2, 2009 at 2:02 AM, Luke Howard <lukeh at padl.com> wrote:

> Nikhil,
>
> db_invoke is an extra layer of indirection, I added this initially so that
> interfaces between the KDC and backend could be easily added without
> changing the kdb dispatch table (principally to ease merges when this code
> was proprietary). Whether this approach is still valid is open to debate.
>
> There is no implementation in any of the backends shipped with MIT; you'll
> need to implement this yourself.
>
> -- Luke
>
>
> On 02/02/2009, at 5:51 AM, Nikhil Mishra wrote:
>
>  Hi All ,
>>
>>
>> How is this function working ?
>>
>> check_allowed_to_delegate_to
>>
>> calls
>>
>> code = krb5_db_invoke(context,
>>                         KRB5_KDB_METHOD_CHECK_ALLOWED_TO_DELEGATE,
>>                         &req_data,
>>                         &rep_data);
>>
>>
>> and in my case dal_handle->lib_handle->vftabl.db_invoke is always NULL .
>>
>> if (dal_handle->lib_handle->vftabl.db_invoke == NULL) {
>>       status = KRB5_KDB_DBTYPE_NOSUP;
>>       goto clean_n_exit;
>>   }
>>
>>
>> I dont see any implementation for db_invoke as well .
>> Do we need to implement db_invoke and If so , why do I see it being called
>> at multiple places ?
>>
>> --Nikhil
>> _______________________________________________
>> 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  Mon Feb  2 01:30:17 2009
From: lukeh at padl.com (Luke Howard)
Date: Mon, 2 Feb 2009 17:30:17 +1100
Subject: db_invoke
In-Reply-To: <35dad1db0902012112t5e5adfc8gec828dc6936ae221@mail.gmail.com>
References: <35dad1db0902011051k3c41481eh5f09aa7b176c2dcb@mail.gmail.com>
	<17CEFE4E-AA79-45F5-89A4-F0EC1049E41A@padl.com>
	<35dad1db0902012112t5e5adfc8gec828dc6936ae221@mail.gmail.com>
Message-ID: <0C381185-4EBB-4FB7-84E7-0EE4E5FFCD4C@padl.com>

Hi Nikhil,

On 02/02/2009, at 4:12 PM, Nikhil Mishra wrote:

> Thanks Luke and I understand the purpose of db_invoke .
>
> But then as I understand, for constrained delegation to work on kdc  
> side, db_invoke has to be implemented or at least in some form  
> check_allowed_to_delegate_to should be able to call some db function  
> to check given service principal is allowed to delegate to given  
> proxy_princ .
>
> Is there any such db function as of now ?

As I mentioned: there is no implementation in any of the backends  
shipped with MIT; you'll need to implement this yourself.

> If I understand it correctly from previous email exchanges  
> constrained delegation should work on kdc side for MIT kerberos ?

The only db_invoke implementation presently is the (proprietary)  
Novell DSfW backend.

-- Luke

From hartmans at MIT.EDU  Mon Feb  2 10:00:49 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Mon, 02 Feb 2009 10:00:49 -0500
Subject: One cause of krb5 test suite slowness on some systems
In-Reply-To: <DB85D8B5-CBF7-491D-9ED1-6C14AD25AF6F@mit.edu> (Ken Raeburn's
	message of "Fri, 30 Jan 2009 23:50:49 -0500")
References: <200901310222.n0V2MR3v015348@outgoing.mit.edu>
	<1233374485.6528.89.camel@ray>
	<DB85D8B5-CBF7-491D-9ED1-6C14AD25AF6F@mit.edu>
Message-ID: <tsl8woonase.fsf@live.mit.edu>

For the prng issue, it's difficult to fix in prng.c because you don't
typically have a krb5_context (and thus profile) in all the calls to
the prng routines.  (They do take context arguments, but people are
sloppy about supplying them, in part because of the old DES
interfaces).

However, you could fix it in kadmind.  We could have a krb5.conf
setting that tells kadmind not to use /dev/random.


From hotz at jpl.nasa.gov  Mon Feb  2 14:04:36 2009
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Mon, 2 Feb 2009 11:04:36 -0800
Subject: Tangent, was: Review of <<Disable DES1>>
In-Reply-To: <mailman.589.1233335486.23428.krbdev@mit.edu>
References: <mailman.589.1233335486.23428.krbdev@mit.edu>
Message-ID: <10EEEDFA-DC88-4A3D-BB59-9CC4F9A64E31@jpl.nasa.gov>


On Jan 30, 2009, at 9:11 AM, krbdev-request at mit.edu wrote:

>> In addition, improvements in support for key rollover must be  
>> provided.
>> If we are going to force a massive rollover of keys it should be
>> combined with support that permits key rollover to be performed on a
>> regular basis.
>
> Such as with a daemon or with cronjobs?  But this sounds to me like a
> problem for vendors and integrators, not one for MIT, though MIT can
> certainly help.


Do you mean key rollover for:

1) master key
2) krbtgt key
3) service key

?

Each one of those cases can be handled "transparently" with the right  
support.  All are desirable at one time or another.  Each must be done  
differently.  IIUC MIT can do 2 and 3 currently (and Heimdal 1 and 3)  
and you are adding support for 1).

Assuming it's 3) that's being discussed, and the issue is getting  
service principals with DES1 keys, or updating them to remove DES1  
keys, then it's going to be necessary for the distribution to support  
DES1 keys for AFS/NFS for several years as exceptions.  I would hope  
that the "Crappy Java Applications" will have independent pressure to  
move from 1.4.2 to 1.5+ and won't be as big a deal.  I think most  
Telnet uses can be replaced with ssh (preferably with Simon's  
patches).  A no-DES1 compile option is OK but shouldn't be default  
until there are viable AFS/NFS implementations with significant  
deployment.

+1 to all the comments about configuring enctypes on a per-principal  
basis.  Likewise for a global disable-des option, as long as it can  
allow specific exceptions.
------------------------------------------------------
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 hardjono at MIT.EDU  Tue Feb  3 14:11:21 2009
From: hardjono at MIT.EDU (Thomas Hardjono)
Date: Tue, 3 Feb 2009 14:11:21 -0500
Subject: New whitepaper on Kerberos-on-the-Web
Message-ID: <001701c98633$33ba9610$9b2fc230$@edu>

MIT-KC publishes new whitepaper on Kerberos-on-the-Web.

 

One of the major goals of the MIT-KC is to establish Kerberos as a
ubiquitous authentication mechanism on the Internet and also to make
Kerberos appropriate for new environments. One of the key efforts within the
MIT-KC directed at this goal is the Kerberos-on-the-Web (Kerb-Web) project.

 

The Kerberos-on-the-web project seeks initially to investigate the various
aspects of the development and deployment of Kerberos within the Web space.
This includes, among others:

(a) the use of the Kerberos authentication paradigm within the context of
web-authentication and web-services security,

(b) the possible architecture integration and interactions between the
Kerberos infrastructure and web-services security infrastructure,

(c) the possible enhancements of the Kerberos authentication protocol and
Kerberos token in order to address the requirements for Single-Sign-On (SSO)
on the Web and Web Identity Federation, and

(d) the potential re-use of existing Kerberos infrastructure investments in
enterprises and other organizations to support the deployment of
Kerberos-on-the-Web solutions.

 

In order to provide a starting point and context for discussions going
forward regarding Kerberos-on-the-web, the MIT-KC has published a whitepaper
on this topic.  The whitepaper can be found in the following location:

 

http://kerberos.org/software/kerbweb.pdf

 

The MIT-KC would appreciate your inputs and comments regarding this
whitepaper, and also your suggestions and recommendations more broadly
regarding the Kerberos-on-the-Web project.

 

Regards.

 

Thomas Hardjono

 

 

 

 

 

__________________________________________

Thomas Hardjono

MIT Kerberos Consortium

Massachusetts Institute of Technology

77 Massachusetts Ave W92-152

Cambridge, MA 02139

 

email:  hardjono[at]mit.edu

web:    http://www.kerberos.org

mobile: +1 781.729.9559

__________________________________________

 

 

-------------- next part --------------
_______________________________________________
kerberos-announce mailing list
kerberos-announce at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos-announce

From ls.niks at gmail.com  Wed Feb  4 01:43:06 2009
From: ls.niks at gmail.com (Nikhil Mishra)
Date: Wed, 4 Feb 2009 12:13:06 +0530
Subject: db_invoke
In-Reply-To: <0C381185-4EBB-4FB7-84E7-0EE4E5FFCD4C@padl.com>
References: <35dad1db0902011051k3c41481eh5f09aa7b176c2dcb@mail.gmail.com>
	<17CEFE4E-AA79-45F5-89A4-F0EC1049E41A@padl.com>
	<35dad1db0902012112t5e5adfc8gec828dc6936ae221@mail.gmail.com>
	<0C381185-4EBB-4FB7-84E7-0EE4E5FFCD4C@padl.com>
Message-ID: <35dad1db0902032243y4b847bd0j781be6431f423b8c@mail.gmail.com>

I was able to successfully do S4U request against windows KDC using MIT
kerberos as clients .
Now , I am working on providing the API's.

I have following two issues now :

1. The problem is with limitations in existing API to accomodate the
incoming user principal .

We can create a PA_DATA_FOR_USER in here


krb5_error_code krb5_get_cred_via_tkt
        (krb5_context,
                   krb5_creds *,
                   krb5_flags,
                   krb5_address * const *,
                   krb5_creds *,
                   krb5_creds **);


This should be modified to be able to take a client name as well.
Please add commnets/reviews.

2. Since I understand the constrained delegation feature is committed only
in current trunk,
What is the timeline we are looking forward to for next stable release for
MIT kerberos ?


--Nikhil

On Mon, Feb 2, 2009 at 12:00 PM, Luke Howard <lukeh at padl.com> wrote:

> Hi Nikhil,
>
> On 02/02/2009, at 4:12 PM, Nikhil Mishra wrote:
>
>  Thanks Luke and I understand the purpose of db_invoke .
>>
>> But then as I understand, for constrained delegation to work on kdc side,
>> db_invoke has to be implemented or at least in some form
>> check_allowed_to_delegate_to should be able to call some db function to
>> check given service principal is allowed to delegate to given proxy_princ .
>>
>> Is there any such db function as of now ?
>>
>
> As I mentioned: there is no implementation in any of the backends shipped
> with MIT; you'll need to implement this yourself.
>
>  If I understand it correctly from previous email exchanges constrained
>> delegation should work on kdc side for MIT kerberos ?
>>
>
> The only db_invoke implementation presently is the (proprietary) Novell
> DSfW backend.
>
> -- Luke
>

From Mark.Phalan at Sun.COM  Wed Feb  4 04:51:34 2009
From: Mark.Phalan at Sun.COM (Mark Phalan)
Date: Wed, 04 Feb 2009 10:51:34 +0100
Subject: regression due to referral realm
Message-ID: <1233741094.15016.21.camel@zup>


There is a regression in functionality when calling
krb5_get_init_creds*() with a client which has been constructed with
krb5_sname_to_princ() when it returns a principal with a referral realm.

If krb5_get_init_creds*() is passed a client with a referral realm
(empty realm) authentication fails as it cannot construct a valid TGT or
identity which KDC it should authenticate to. If "dns_lookup_kdc" is
set (by default I believe is) then there are going to be some weird DNS
SRV lookups too as it tries to find a KDC for the realm "".

This is easy to reproduce:

1) Populate a keytab with a host/<fqdn> principal
2) Modify krb5.conf so there is no valid domain_realm mapping for the
domain of the host.
3) run kinit -k

The above returns a valid TGT on krb5-1.5.4 but fails with anything
later. The same problem occurs on Solaris in krb5_gss_init_sec_context()
and potentially anywhere a client principal returned from
krb5_sname_to_princ() is used to get initial credentials

It seems to me that mostly this will be hit when doing initial
authentication with a keytab. One way to mitigate that problem would be
to modify krb5_get_init_creds_keytab() to check the client principal to
see if it is using a referral realm. If it is then take the first
matching principal from the keytab and use that principal's realm.
I've got code to do this and can supply a patch.

-M



From Nicolas.Williams at sun.com  Wed Feb  4 11:20:09 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 4 Feb 2009 10:20:09 -0600
Subject: regression due to referral realm
In-Reply-To: <1233741094.15016.21.camel@zup>
References: <1233741094.15016.21.camel@zup>
Message-ID: <20090204162009.GL9992@Sun.COM>

On Wed, Feb 04, 2009 at 10:51:34AM +0100, Mark Phalan wrote:
> It seems to me that mostly this will be hit when doing initial
> authentication with a keytab. One way to mitigate that problem would be
> to modify krb5_get_init_creds_keytab() to check the client principal to
> see if it is using a referral realm. If it is then take the first
> matching principal from the keytab and use that principal's realm.
> I've got code to do this and can supply a patch.

I agree.  This is basically a zero-conf bug affecting apps that a) use
keytabs to acquire initial credentials, and b) use
krb5_sname_to_principal() instead of krb5_parse_name() to get the client
krb5_principal.

Such apps can be raw krb5 API apps, GSS-API apps, and even scripts
around kinit (see Mark's note).

Mark's fix involves adding a function that takes a krb5_principal with a
referral realm that then searches a given keytab for a matching entry
(where the match obviously excludes the realm part).  That's likely to
raise some eyebrows, or at least this one:

    Should keytabs be searched front to back or back to front?  They are
    usually appended to...  This is, of course, a long-standing
    question, for me at least.

In any case, the work-around for keytab search order issues is always to
use ktutil to create a keytab with entries in the correct order.

Nico
-- 

From hotz at jpl.nasa.gov  Wed Feb  4 15:15:24 2009
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Wed, 4 Feb 2009 12:15:24 -0800
Subject: regression due to referral realm
In-Reply-To: <mailman.631.1233767642.21443.krbdev@mit.edu>
References: <mailman.631.1233767642.21443.krbdev@mit.edu>
Message-ID: <AAC8386A-BBD5-4383-8755-E67D4F5C622F@jpl.nasa.gov>


On Feb 4, 2009, at 9:14 AM, krbdev-request at mit.edu wrote:

> It seems to me that mostly this will be hit when doing initial
> authentication with a keytab. One way to mitigate that problem would  
> be
> to modify krb5_get_init_creds_keytab() to check the client principal  
> to
> see if it is using a referral realm. If it is then take the first
> matching principal from the keytab and use that principal's realm.
> I've got code to do this and can supply a patch.


Sounds good, modulo whatever you mean by "matching principal".

As a tangental nit, I wish the list of supported enctypes sent by  
krb5_get_init_creds_keytab() was limited to those actually in the  
keytab file (that are also supported by the library in question of  
course).  Since this has been discussed in the past, it's possible you- 
all have taken care of it, and I'm out of date.
------------------------------------------------------
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 Mark.Phalan at Sun.COM  Thu Feb  5 08:59:14 2009
From: Mark.Phalan at Sun.COM (Mark Phalan)
Date: Thu, 05 Feb 2009 14:59:14 +0100
Subject: regression due to referral realm
In-Reply-To: <AAC8386A-BBD5-4383-8755-E67D4F5C622F@jpl.nasa.gov>
References: <mailman.631.1233767642.21443.krbdev@mit.edu>
	<AAC8386A-BBD5-4383-8755-E67D4F5C622F@jpl.nasa.gov>
Message-ID: <1233842354.15016.65.camel@zup>


On Wed, 2009-02-04 at 12:15 -0800, Henry B. Hotz wrote:
> On Feb 4, 2009, at 9:14 AM, krbdev-request at mit.edu wrote:
> 
> > It seems to me that mostly this will be hit when doing initial
> > authentication with a keytab. One way to mitigate that problem would  
> > be
> > to modify krb5_get_init_creds_keytab() to check the client principal  
> > to
> > see if it is using a referral realm. If it is then take the first
> > matching principal from the keytab and use that principal's realm.
> > I've got code to do this and can supply a patch.
> 
> 
> Sounds good, modulo whatever you mean by "matching principal".

A matching principal is one which is identical to one being searched for
apart from its realm. i.e. if searching for

host/foo.bar.com@""

then 

host/foo.bar.com at ACME.COM or host/foo.bar.com at ACME2.COM

are matching principals.

-M



From Nicolas.Williams at sun.com  Thu Feb  5 11:30:29 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 5 Feb 2009 10:30:29 -0600
Subject: regression due to referral realm
In-Reply-To: <AAC8386A-BBD5-4383-8755-E67D4F5C622F@jpl.nasa.gov>
References: <mailman.631.1233767642.21443.krbdev@mit.edu>
	<AAC8386A-BBD5-4383-8755-E67D4F5C622F@jpl.nasa.gov>
Message-ID: <20090205163028.GC9992@Sun.COM>

On Wed, Feb 04, 2009 at 12:15:24PM -0800, Henry B. Hotz wrote:
> As a tangental nit, I wish the list of supported enctypes sent by  
> krb5_get_init_creds_keytab() was limited to those actually in the  
> keytab file (that are also supported by the library in question of  
> course).  Since this has been discussed in the past, it's possible you- 
> all have taken care of it, and I'm out of date.

That's a separate issue, and not necessarily a bug: as long as the
keytab and the KDB entry for that princ ar in sync there's no problem.

Also, IIRC you can affect this via default_*_enctypes.

From hotz at jpl.nasa.gov  Thu Feb  5 12:27:51 2009
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Thu, 5 Feb 2009 09:27:51 -0800
Subject: regression due to referral realm
In-Reply-To: <20090205163028.GC9992@Sun.COM>
References: <mailman.631.1233767642.21443.krbdev@mit.edu>
	<AAC8386A-BBD5-4383-8755-E67D4F5C622F@jpl.nasa.gov>
	<20090205163028.GC9992@Sun.COM>
Message-ID: <7A5F780C-B5D2-4D85-9761-61F3842F0F85@jpl.nasa.gov>


On Feb 5, 2009, at 8:30 AM, Nicolas Williams wrote:

> On Wed, Feb 04, 2009 at 12:15:24PM -0800, Henry B. Hotz wrote:
>> As a tangental nit, I wish the list of supported enctypes sent by
>> krb5_get_init_creds_keytab() was limited to those actually in the
>> keytab file (that are also supported by the library in question of
>> course).  Since this has been discussed in the past, it's possible  
>> you-
>> all have taken care of it, and I'm out of date.
>
> That's a separate issue, and not necessarily a bug: as long as the
> keytab and the KDB entry for that princ ar in sync there's no problem.

I agree, if the keytab is created by direct extraction from the KDB,  
then synchronization is likely.

However, there are a lot of reasons why that might not be true.  You  
may extract with a different code base from your intended app (think  
Java 1.4.2 for instance), or you may need SA's to create keytabs  
directly from passwords.

> Also, IIRC you can affect this via default_*_enctypes.

This solution is too global, usually.
------------------------------------------------------
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 Nicolas.Williams at sun.com  Thu Feb  5 12:27:38 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 5 Feb 2009 11:27:38 -0600
Subject: a word about gettext() and xgettext
Message-ID: <20090205172738.GL9992@Sun.COM>

A note that might be useful.

When adding gettext() calls to extract messages for localization there
is a way to do it with minimal impact if there's an intermediate
function for logging errors (e.g., krb5_set_error_message()):

 - don't put the gettext() call in the code that calls functions like
   krb5_set_error_message() -- put it in those functions

 - use the GNU xgettext(1) with the --keyword[=WORD] and/or
   --flag=word:arg:flag options

   e.g., xgettext --flag=krb5_set_error_message:3:c-format ...

This can keep changes to a minimum.

Solaris Kerberos has gettext() calls all over the place because years
ago the option of using the GNU xgettext didn't exist (either because
GNU xgettext didn't exist/didn't have the necessary features/couldn't be
used in Solaris build processes a decade or so ago).  So it may be too
late for this, but even so, this is a useful trick to know about, and
one that I've used before to keep L10N diffs between OpenSSH and SunSSH
to a minimum (of course, large parts of SunSSH, mostly in the sshd side
of things, do differ from OpenSSH in ways that could not be smoothed
over so well, but that's another story).

Nico
-- 

From Nicolas.Williams at sun.com  Thu Feb  5 12:40:08 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 5 Feb 2009 11:40:08 -0600
Subject: regression due to referral realm
In-Reply-To: <7A5F780C-B5D2-4D85-9761-61F3842F0F85@jpl.nasa.gov>
References: <mailman.631.1233767642.21443.krbdev@mit.edu>
	<AAC8386A-BBD5-4383-8755-E67D4F5C622F@jpl.nasa.gov>
	<20090205163028.GC9992@Sun.COM>
	<7A5F780C-B5D2-4D85-9761-61F3842F0F85@jpl.nasa.gov>
Message-ID: <20090205174007.GO9992@Sun.COM>

Henry,

I think you have a convincing argument for a [fairly simple] RFE.

From hotz at jpl.nasa.gov  Thu Feb  5 13:26:54 2009
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Thu, 5 Feb 2009 10:26:54 -0800
Subject: regression due to referral realm
In-Reply-To: <20090205174007.GO9992@Sun.COM>
References: <mailman.631.1233767642.21443.krbdev@mit.edu>
	<AAC8386A-BBD5-4383-8755-E67D4F5C622F@jpl.nasa.gov>
	<20090205163028.GC9992@Sun.COM>
	<7A5F780C-B5D2-4D85-9761-61F3842F0F85@jpl.nasa.gov>
	<20090205174007.GO9992@Sun.COM>
Message-ID: <385EE5B0-40EB-4B17-8D30-2775EEEF07B6@jpl.nasa.gov>

If this is a competition, then I note that Heimdal respects the API,  
but doesn't actually respect the enctype list if it's put in the init  
options.  If implemented in kinit then it would be showing off  
something that Heimdal doesn't have (yet).

On Feb 5, 2009, at 9:40 AM, Nicolas Williams wrote:

> Henry,
>
> I think you have a convincing argument for a [fairly simple] RFE.

------------------------------------------------------
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 William.Fiveash at Sun.COM  Thu Feb  5 16:31:18 2009
From: William.Fiveash at Sun.COM (Will Fiveash)
Date: Thu, 5 Feb 2009 15:31:18 -0600
Subject: issue trying to do make check on Ubuntu 8.10 desktop
Message-ID: <20090205213118.GA19029@sun.com>

While I can build the latest MITKC krb source in a VirtualBox running
Ubuntu 8.10 desktop I'm seeing errors like the following when running
make check:

Using ../../../../migrate_bugfix/src/lib/rpc/unit-test/config/unix.exp as tool-and-target-specific interface file.
TOP=/home/willf/migrate_bugfix_bld/kadmin
ERROR: didn't get ok back
ERROR: didn't get ok back
ERROR: didn't get ok back
ERROR: didn't get ok back
ERROR: didn't get ok back
ERROR: didn't get ok back
Running pass `tcp' ...
server exited!Running ../../../../migrate_bugfix/src/lib/rpc/unit-test/rpc_test.0/expire.exp ...
ERROR: tcl error sourcing ../../../../migrate_bugfix/src/lib/rpc/unit-test/rpc_test.0/expire.exp.
ERROR: : spawn id exp9 not open
    while executing
"expect -nobrace -i exp9 -re {rpc_test server: Authen.*failed:.*credential.*expired} { pass "expired" } timeout { fail "expired: timeout waiting for ex..."
    invoked from within
"expect {
        -i $server_id
        -re "rpc_test server: Authen.*failed:.*credential.*expired" { pass "expired" }
        timeout { fail "expired: timeout waiting for ..."
    (procedure "expired" line 7)
    invoked from within
"expired"
    (file "../../../../migrate_bugfix/src/lib/rpc/unit-test/rpc_test.0/expire.exp" line 21)
    invoked from within
"source ../../../../migrate_bugfix/src/lib/rpc/unit-test/rpc_test.0/expire.exp"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 source ../../../../migrate_bugfix/src/lib/rpc/unit-test/rpc_test.0/expire.exp"
    invoked from within
"catch "uplevel #0 source $test_file_name""
Running ../../../../migrate_bugfix/src/lib/rpc/unit-test/rpc_test.0/fullrun.exp ...
ERROR: tcl error sourcing ../../../../migrate_bugfix/src/lib/rpc/unit-test/rpc_test.0/fullrun.exp.
ERROR: : spawn id exp9 not open
    while executing
"expect -nobrace -i exp9 -re {rpc_test server: bad verifier[^
]*[
]+} {
                        verbose "Got line from server."
                        incr server_lines
                } default {
                        exp_..."
    invoked from within
and so on...

Any thoughts as to why this is happening?  I'm guessing there's a
compatibility issue between the native expect/Tcl and what the tests
require but that's just a guess.  If someone has successfully run make
check on such a system and could provide the list of installed packages
I'd appreciate that.

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

From ghudson at MIT.EDU  Thu Feb  5 16:48:31 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Thu, 05 Feb 2009 16:48:31 -0500
Subject: issue trying to do make check on Ubuntu 8.10 desktop
In-Reply-To: <20090205213118.GA19029@sun.com>
References: <20090205213118.GA19029@sun.com>
Message-ID: <1233870511.7373.7.camel@ray>

On Thu, 2009-02-05 at 15:31 -0600, Will Fiveash wrote:
> Using ../../../../migrate_bugfix/src/lib/rpc/unit-test/config/unix.exp as tool-and-target-specific interface file.
> TOP=/home/willf/migrate_bugfix_bld/kadmin
> ERROR: didn't get ok back

That looks like what happens when you don't have a portmapper running,
if my memory is correct.  "apt-get install portmap" should be sufficient
to fix that.

(If I'm right, this is documented in doc/build.texinfo.)



From William.Fiveash at Sun.COM  Thu Feb  5 17:41:55 2009
From: William.Fiveash at Sun.COM (Will Fiveash)
Date: Thu, 5 Feb 2009 16:41:55 -0600
Subject: issue trying to do make check on Ubuntu 8.10 desktop
In-Reply-To: <1233870511.7373.7.camel@ray>
References: <20090205213118.GA19029@sun.com> <1233870511.7373.7.camel@ray>
Message-ID: <20090205224155.GB19029@sun.com>

On Thu, Feb 05, 2009 at 04:48:31PM -0500, Greg Hudson wrote:
> On Thu, 2009-02-05 at 15:31 -0600, Will Fiveash wrote:
> > Using ../../../../migrate_bugfix/src/lib/rpc/unit-test/config/unix.exp as tool-and-target-specific interface file.
> > TOP=/home/willf/migrate_bugfix_bld/kadmin
> > ERROR: didn't get ok back
> 
> That looks like what happens when you don't have a portmapper running,
> if my memory is correct.  "apt-get install portmap" should be sufficient
> to fix that.
> 
> (If I'm right, this is documented in doc/build.texinfo.)

You're right, thanks for the tip.

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

From epeisach at MIT.EDU  Thu Feb  5 19:53:50 2009
From: epeisach at MIT.EDU (Ezra Peisach)
Date: Thu, 05 Feb 2009 19:53:50 -0500
Subject: issue trying to do make check on Ubuntu 8.10 desktop
In-Reply-To: <20090205213118.GA19029@sun.com>
References: <20090205213118.GA19029@sun.com>
Message-ID: <498B8A1E.9040305@mit.edu>

The server exited could also be caused by portmap/rpcbind requiring a 
reserved port to register the port. (we are already using a loopback 
interface but I've seen some default configs for rpcbind to require a 
unix domain socket or a reserved port (< 1024 - which requires root)...

I checked in some changes to the source tree to be more graceful for the 
case when portmap is not running or not allowing the server to register....
(hmm - I should make sure the right thing happens when portmap is not 
running at all...)

Ezra


From hartmans at MIT.EDU  Wed Feb  4 13:46:52 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 04 Feb 2009 13:46:52 -0500
Subject: regression due to referral realm
In-Reply-To: <1233741094.15016.21.camel@zup> (Mark Phalan's message of "Wed,
	04 Feb 2009 10:51:34 +0100")
References: <1233741094.15016.21.camel@zup>
Message-ID: <tsl4ozahwf7.fsf@live.mit.edu>

What is the right fix here?  Do we want to substitute in the default
realm, or do we want to substitute in the realm of the local host (I.E. getrealmofhost(gethostname())?


From ls.niks at gmail.com  Mon Feb  9 02:00:05 2009
From: ls.niks at gmail.com (Nikhil Mishra)
Date: Mon, 9 Feb 2009 12:30:05 +0530
Subject: kerberos upcoming release
Message-ID: <35dad1db0902082300s745135a6i694787026167cc5a@mail.gmail.com>

Hi All ,

I have implemented the client side functionality for MS-kerb extensions.
It works for my sample kerberized communication. I am right now working
on the standardizing API's and parameters.


My question is , we use kerberos 1.6.3 in our production environment.
What is the timeline we are looking forward to for kerberos next stable
release which will have MS-kerb extensions ?


--Nikhil

From Natalie.Li at Sun.COM  Sun Feb  8 12:57:12 2009
From: Natalie.Li at Sun.COM (Natalie Li)
Date: Sun, 08 Feb 2009 09:57:12 -0800
Subject: Question on PAC and principal APIs project
Message-ID: <498F1CF8.1030007@sun.com>

Does anyone have a rough idea as to which release this project is 
targeted for?

Thanks,

Natalie

From raeburn at MIT.EDU  Mon Feb  9 12:01:58 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Mon, 9 Feb 2009 12:01:58 -0500
Subject: Question on PAC and principal APIs project
In-Reply-To: <498F1CF8.1030007@sun.com>
References: <498F1CF8.1030007@sun.com>
Message-ID: <2D22ED74-1137-4EB2-B70D-4AA25D628D46@mit.edu>

On Feb 8, 2009, at 12:57, Natalie Li wrote:
> Does anyone have a rough idea as to which release this project is
> targeted for?

The basic support for PAC data and such will be in the 1.7 release --  
there's already an alpha out if you'd like to take a look.  We don't  
currently have support in our shipping database back ends to supply  
PAC data, but if a site or vendor wants to supply a database back end  
that provides that data, the KDC should use it and send it.

Ken

From raeburn at MIT.EDU  Mon Feb  9 13:09:40 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Mon, 9 Feb 2009 13:09:40 -0500
Subject: Question on PAC and principal APIs project
In-Reply-To: <49906BCB.1090500@Sun.COM>
References: <498F1CF8.1030007@sun.com>
	<2D22ED74-1137-4EB2-B70D-4AA25D628D46@mit.edu>
	<49906BCB.1090500@Sun.COM>
Message-ID: <25B96387-4016-4036-9D2F-BCC47805C0E4@MIT.EDU>

On Feb 9, 2009, at 12:45, Natalie Li wrote:
> Ken,
>
> Thanks for the information.  I'll take a look at the alpha version  
> later today.  Would like to confirm the following:
>
> 1) the provided APIs are sufficient for a resource server to extract  
> the PAC from the ticket in KRB_AP_REQ. 2) All the APIs mentioned in  
> the project page (http://k5wiki.kerberos.org/wiki?title=Projects/PAC_and_principal_APIs&redirect=no 
> ) will be in the 1.7 release.

#1: I believe so, but the testing of the new code is being done by the  
developers working on it, not here at MIT.

#2: It looks like that's what's in the alpha release now.  I wouldn't  
expect much change for the final release.

Ken

From Natalie.Li at Sun.COM  Mon Feb  9 12:45:47 2009
From: Natalie.Li at Sun.COM (Natalie Li)
Date: Mon, 09 Feb 2009 09:45:47 -0800
Subject: Question on PAC and principal APIs project
In-Reply-To: <2D22ED74-1137-4EB2-B70D-4AA25D628D46@mit.edu>
References: <498F1CF8.1030007@sun.com>
	<2D22ED74-1137-4EB2-B70D-4AA25D628D46@mit.edu>
Message-ID: <49906BCB.1090500@Sun.COM>

Ken,

Thanks for the information.  I'll take a look at the alpha version later 
today.  Would like to confirm the following:

1) the provided APIs are sufficient for a resource server to extract the 
PAC from the ticket in KRB_AP_REQ. 
2) All the APIs mentioned in the project page 
(http://k5wiki.kerberos.org/wiki?title=Projects/PAC_and_principal_APIs&redirect=no) 
will be in the 1.7 release.

Thanks,

Natalie

Ken Raeburn wrote:
> On Feb 8, 2009, at 12:57, Natalie Li wrote:
>> Does anyone have a rough idea as to which release this project is
>> targeted for?
>
> The basic support for PAC data and such will be in the 1.7 release -- 
> there's already an alpha out if you'd like to take a look.  We don't 
> currently have support in our shipping database back ends to supply 
> PAC data, but if a site or vendor wants to supply a database back end 
> that provides that data, the KDC should use it and send it.
>
> Ken


From Natalie.Li at Sun.COM  Mon Feb  9 13:14:26 2009
From: Natalie.Li at Sun.COM (Natalie Li)
Date: Mon, 09 Feb 2009 10:14:26 -0800
Subject: Question on PAC and principal APIs project
In-Reply-To: <25B96387-4016-4036-9D2F-BCC47805C0E4@MIT.EDU>
References: <498F1CF8.1030007@sun.com>
	<2D22ED74-1137-4EB2-B70D-4AA25D628D46@mit.edu>
	<49906BCB.1090500@Sun.COM>
	<25B96387-4016-4036-9D2F-BCC47805C0E4@MIT.EDU>
Message-ID: <49907282.3070005@Sun.COM>

Thanks Ken!

Ken Raeburn wrote:
> On Feb 9, 2009, at 12:45, Natalie Li wrote:
>> Ken,
>>
>> Thanks for the information.  I'll take a look at the alpha version 
>> later today.  Would like to confirm the following:
>>
>> 1) the provided APIs are sufficient for a resource server to extract 
>> the PAC from the ticket in KRB_AP_REQ. 2) All the APIs mentioned in 
>> the project page 
>> (http://k5wiki.kerberos.org/wiki?title=Projects/PAC_and_principal_APIs&redirect=no) 
>> will be in the 1.7 release.
>
> #1: I believe so, but the testing of the new code is being done by the 
> developers working on it, not here at MIT.
>
> #2: It looks like that's what's in the alpha release now.  I wouldn't 
> expect much change for the final release.
>
> Ken


From William.Fiveash at Sun.COM  Mon Feb  9 23:37:36 2009
From: William.Fiveash at Sun.COM (Will Fiveash)
Date: Mon, 9 Feb 2009 22:37:36 -0600
Subject: MIT e-mail phish attempt
Message-ID: <20090210043735.GA19787@sun.com>

Just got the attached e-mail (which I bzip2ed) that contained:

 Date: Mon, 09 Feb 2009 23:23:12 -0500 (EST)
 From: MIT Support Team <supportteam at MIT.EDU>
 Subject:
 To: undisclosed-recipients: ;

Dear mit.edu User,

Your email account has been used to send numerous Spam mails recently from
a foreign IP. As a result, the mit.edu has received advice to suspend your
account. However, you might not be the one promoting this Spam, as your
email account might have been compromised. To protect your account from
sending spam mails, you are to confirm your true ownership of this account
by providing your original username (*******) and PASSWORD (*******) as a
reply to this message. On receipt of the requested information, the
"mit.edu" web email support shall block your account from Spam.

Failure to do this will violate the mit.edu email terms & conditions. This
will render your account inactive.

Thanks for using mit.edu

The MIT Webmail
Copyright \251 2004-2008 The Massachusetts Institute Of Technology.
=================================================================

Note the Reply-to: is webaceess at ymail.com.  Just letting y'all know.
-- 
Will Fiveash
Sun Microsystems Inc.
http://opensolaris.org/os/project/kerberos/

From tlyu at MIT.EDU  Mon Feb  9 23:51:35 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Mon, 09 Feb 2009 23:51:35 -0500
Subject: MIT e-mail phish attempt
In-Reply-To: <20090210043735.GA19787@sun.com> (Will Fiveash's message of "Mon,
	9 Feb 2009 22:37:36 -0600")
References: <20090210043735.GA19787@sun.com>
Message-ID: <ldvvdrij3mw.fsf@cathode-dark-space.mit.edu>

Will Fiveash <William.Fiveash at Sun.COM> writes:

> From: Will Fiveash <William.Fiveash at Sun.COM>
> Subject: MIT e-mail phish attempt
> To: Tom Yu <tlyu at mit.edu>, Ken Raeburn <raeburn at mit.edu>
> Cc: MIT Kerberos Dev List <krbdev at mit.edu>,        MIT Kerberos List <kerberos at mit.edu>
> Date: Mon, 9 Feb 2009 22:37:36 -0600
> Mail-Followup-To: Tom Yu <tlyu at mit.edu>, Ken Raeburn <raeburn at MIT.EDU>, MIT Kerberos Dev List <krbdev at MIT.EDU>, MIT Kerberos List <kerberos at MIT.EDU>
>
> Just got the attached e-mail (which I bzip2ed) that contained:

[...]

This is an obvious forgery that did not originate at MIT.  Please
ignore it.

From Nicolas.Williams at sun.com  Tue Feb 10 11:17:32 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 10 Feb 2009 10:17:32 -0600
Subject: regression due to referral realm
In-Reply-To: <tsl4ozahwf7.fsf@live.mit.edu>
References: <1233741094.15016.21.camel@zup> <tsl4ozahwf7.fsf@live.mit.edu>
Message-ID: <20090210161732.GO9992@Sun.COM>

On Wed, Feb 04, 2009 at 01:46:52PM -0500, Sam Hartman wrote:
> What is the right fix here?  Do we want to substitute in the default
> realm, or do we want to substitute in the realm of the local host (I.E. getrealmofhost(gethostname())?

What breaks here is krb5_get_init_creds_keytab() when called with a
principal made by krb5_sname_to_principal().  The realm part of that
principal will be the null realm.

Mark's fix is to search the keytab for the first match where the realm
is ignored if the principal we're searching for has a null realm.

I suppose that another fix would be to have keytab entries with a null
realm.

From hartmans at MIT.EDU  Tue Feb 10 13:34:32 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 10 Feb 2009 13:34:32 -0500
Subject: regression due to referral realm
In-Reply-To: <20090210161732.GO9992@Sun.COM> (Nicolas Williams's message of
	"Tue, 10 Feb 2009 10:17:32 -0600")
References: <1233741094.15016.21.camel@zup> <tsl4ozahwf7.fsf@live.mit.edu>
	<20090210161732.GO9992@Sun.COM>
Message-ID: <tslfximb0p3.fsf@live.mit.edu>

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:

    Nicolas> On Wed, Feb 04, 2009 at 01:46:52PM -0500, Sam Hartman
    Nicolas> wrote:
    >> What is the right fix here?  Do we want to substitute in the
    >> default realm, or do we want to substitute in the realm of the
    >> local host (I.E. getrealmofhost(gethostname())?

    Nicolas> What breaks here is krb5_get_init_creds_keytab() when
    Nicolas> called with a principal made by
    Nicolas> krb5_sname_to_principal().  The realm part of that
    Nicolas> principal will be the null realm.

    Nicolas> Mark's fix is to search the keytab for the first match
    Nicolas> where the realm is ignored if the principal we're
    Nicolas> searching for has a null realm.


Hmm.  I would have assumed you wanted to substitute in the default
realm or the realm of the host.  However this fix seems reasonable if
more complicated behavior than the previous code.


From Nicolas.Williams at sun.com  Tue Feb 10 13:40:46 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 10 Feb 2009 12:40:46 -0600
Subject: regression due to referral realm
In-Reply-To: <tslfximb0p3.fsf@live.mit.edu>
References: <1233741094.15016.21.camel@zup> <tsl4ozahwf7.fsf@live.mit.edu>
	<20090210161732.GO9992@Sun.COM> <tslfximb0p3.fsf@live.mit.edu>
Message-ID: <20090210184046.GB9992@Sun.COM>

On Tue, Feb 10, 2009 at 01:34:32PM -0500, Sam Hartman wrote:
> Hmm.  I would have assumed you wanted to substitute in the default
> realm or the realm of the host.  However this fix seems reasonable if
> more complicated behavior than the previous code.

In a zero-conf world there may not be a default realm.  The realm of the
host is a reasonable approach, though it does require searching for it.

I too think Mark's fix is certainly good enough.

Nico
-- 

From tlyu at MIT.EDU  Tue Feb 10 14:06:39 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Tue, 10 Feb 2009 14:06:39 -0500
Subject: regression due to referral realm
In-Reply-To: <20090210184046.GB9992@Sun.COM> (Nicolas Williams's message of
	"Tue, 10 Feb 2009 12:40:46 -0600")
References: <1233741094.15016.21.camel@zup> <tsl4ozahwf7.fsf@live.mit.edu>
	<20090210161732.GO9992@Sun.COM> <tslfximb0p3.fsf@live.mit.edu>
	<20090210184046.GB9992@Sun.COM>
Message-ID: <ldvfxim6ri8.fsf@cathode-dark-space.mit.edu>

Nicolas Williams <Nicolas.Williams at sun.com> writes:

> On Tue, Feb 10, 2009 at 01:34:32PM -0500, Sam Hartman wrote:
>> Hmm.  I would have assumed you wanted to substitute in the default
>> realm or the realm of the host.  However this fix seems reasonable if
>> more complicated behavior than the previous code.
>
> In a zero-conf world there may not be a default realm.  The realm of the
> host is a reasonable approach, though it does require searching for it.

If you have a keytab, you are almost by definition not zero-conf.

From Nicolas.Williams at sun.com  Tue Feb 10 14:12:12 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 10 Feb 2009 13:12:12 -0600
Subject: regression due to referral realm
In-Reply-To: <ldvfxim6ri8.fsf@cathode-dark-space.mit.edu>
References: <1233741094.15016.21.camel@zup> <tsl4ozahwf7.fsf@live.mit.edu>
	<20090210161732.GO9992@Sun.COM> <tslfximb0p3.fsf@live.mit.edu>
	<20090210184046.GB9992@Sun.COM>
	<ldvfxim6ri8.fsf@cathode-dark-space.mit.edu>
Message-ID: <20090210191212.GD9992@Sun.COM>

On Tue, Feb 10, 2009 at 02:06:39PM -0500, Tom Yu wrote:
> Nicolas Williams <Nicolas.Williams at sun.com> writes:
> 
> > On Tue, Feb 10, 2009 at 01:34:32PM -0500, Sam Hartman wrote:
> >> Hmm.  I would have assumed you wanted to substitute in the default
> >> realm or the realm of the host.  However this fix seems reasonable if
> >> more complicated behavior than the previous code.
> >
> > In a zero-conf world there may not be a default realm.  The realm of the
> > host is a reasonable approach, though it does require searching for it.
> 
> If you have a keytab, you are almost by definition not zero-conf.

I don't agree.

You can have a machine account and still not have a suitable notion of
default realm.

In our case this bug caused a regression.  One way to deal with this is
to use the default realm and then change the realm-join code in the CIFS
server to always ensure that default realm is set.  Mark's solution is
more fool-proof and self-contained than that.

Arguably it could cause the system to be a bit more sensitive to keytab
entry order in the very rare case that you have something like this: a)
machine accounts for the same machine name in multiple realms, b) no
default realm, *and* c) you actually care as to which machine name will
be used in krb5_get_init_creds_keytab() cases.  (b) could be made a
non-issue by trying the use of a default realm first, if there is one,
but I don't think (c) will ever be true given (a).  (And, given (a),
it's not necessarily the case that the host's realm can be determined in
a deterministic way either.)

Nico
-- 

From hartmans at MIT.EDU  Tue Feb 10 15:16:30 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 10 Feb 2009 15:16:30 -0500
Subject: regression due to referral realm
In-Reply-To: <20090210191212.GD9992@Sun.COM> (Nicolas Williams's message of
	"Tue, 10 Feb 2009 13:12:12 -0600")
References: <1233741094.15016.21.camel@zup> <tsl4ozahwf7.fsf@live.mit.edu>
	<20090210161732.GO9992@Sun.COM> <tslfximb0p3.fsf@live.mit.edu>
	<20090210184046.GB9992@Sun.COM>
	<ldvfxim6ri8.fsf@cathode-dark-space.mit.edu>
	<20090210191212.GD9992@Sun.COM>
Message-ID: <tslskmm9hep.fsf@live.mit.edu>

I have to agree with Tom here.

From Nicolas.Williams at sun.com  Tue Feb 10 15:25:00 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 10 Feb 2009 14:25:00 -0600
Subject: regression due to referral realm
In-Reply-To: <tslskmm9hep.fsf@live.mit.edu>
References: <1233741094.15016.21.camel@zup> <tsl4ozahwf7.fsf@live.mit.edu>
	<20090210161732.GO9992@Sun.COM> <tslfximb0p3.fsf@live.mit.edu>
	<20090210184046.GB9992@Sun.COM>
	<ldvfxim6ri8.fsf@cathode-dark-space.mit.edu>
	<20090210191212.GD9992@Sun.COM> <tslskmm9hep.fsf@live.mit.edu>
Message-ID: <20090210202459.GH9992@Sun.COM>

On Tue, Feb 10, 2009 at 03:16:30PM -0500, Sam Hartman wrote:
> I have to agree with Tom here.

Meaning what, specifically?  That you think MIT should not accept a
patch that does anything other than replace the null realm name with the
default realm name?

Nico
-- 

From hotz at jpl.nasa.gov  Tue Feb 10 17:08:15 2009
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Tue, 10 Feb 2009 14:08:15 -0800
Subject: regression due to referral realm
In-Reply-To: <mailman.657.1234286018.29984.krbdev@mit.edu>
References: <mailman.657.1234286018.29984.krbdev@mit.edu>
Message-ID: <0F497D0B-D6BE-4C2A-A0E6-C08EE4EA5D32@jpl.nasa.gov>


On Feb 10, 2009, at 9:13 AM, krbdev-request at mit.edu wrote:

> I suppose that another fix would be to have keytab entries with a null
> realm.


Yuck!  |-P
------------------------------------------------------
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 Feb 10 17:13:04 2009
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Tue, 10 Feb 2009 14:13:04 -0800
Subject: Question on PAC and principal APIs project
Message-ID: <BBFC4B99-187C-4E18-BFB2-020B738BB8F1@jpl.nasa.gov>

On Feb 9, 2009, at 12:45, Natalie Li wrote:
> Ken,
>
> Thanks for the information.  I'll take a look at the alpha version
> later today.  Would like to confirm the following:
>
> 1) the provided APIs are sufficient for a resource server to extract
> the PAC from the ticket in KRB_AP_REQ. 2) All the APIs mentioned in
> the project page (http://k5wiki.kerberos.org/wiki?title=Projects/PAC_and_principal_APIs&redirect=no
> ) will be in the 1.7 release.

I gather there is no relationship to the Heimdal/Samba API's for the  
same functions.  (I have not tried the Heimdal ones.)

I'm not saying there needs to be a direct relationship.  Where I get  
the most bent is when things are *almost* the same.  Then you waste a  
lot of time trying to make them the same, and tripping on the  
unanticipated differences.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu




From tlyu at MIT.EDU  Tue Feb 10 17:30:22 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Tue, 10 Feb 2009 17:30:22 -0500
Subject: Question on PAC and principal APIs project
In-Reply-To: <BBFC4B99-187C-4E18-BFB2-020B738BB8F1@jpl.nasa.gov> (Henry B.
	Hotz's message of "Tue, 10 Feb 2009 14:13:04 -0800")
References: <BBFC4B99-187C-4E18-BFB2-020B738BB8F1@jpl.nasa.gov>
Message-ID: <ldvvdri53i9.fsf@cathode-dark-space.mit.edu>

"Henry B. Hotz" <hotz at jpl.nasa.gov> writes:

> On Feb 9, 2009, at 12:45, Natalie Li wrote:
>> Ken,
>>
>> Thanks for the information.  I'll take a look at the alpha version
>> later today.  Would like to confirm the following:
>>
>> 1) the provided APIs are sufficient for a resource server to extract
>> the PAC from the ticket in KRB_AP_REQ. 2) All the APIs mentioned in
>> the project page (http://k5wiki.kerberos.org/wiki?title=Projects/PAC_and_principal_APIs&redirect=no
>> ) will be in the 1.7 release.
>
> I gather there is no relationship to the Heimdal/Samba API's for the  
> same functions.  (I have not tried the Heimdal ones.)

I have not compared these APIs in detail, but our new principal
parsing APIs appear identical to Heimdal.

> I'm not saying there needs to be a direct relationship.  Where I get  
> the most bent is when things are *almost* the same.  Then you waste a  
> lot of time trying to make them the same, and tripping on the  
> unanticipated differences.

If you have specific examples, please let us know about them, so we
can work on them.

From hartmans at MIT.EDU  Tue Feb 10 17:35:29 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 10 Feb 2009 17:35:29 -0500
Subject: regression due to referral realm
In-Reply-To: <20090210202459.GH9992@Sun.COM> (Nicolas Williams's message of
	"Tue, 10 Feb 2009 14:25:00 -0600")
References: <1233741094.15016.21.camel@zup> <tsl4ozahwf7.fsf@live.mit.edu>
	<20090210161732.GO9992@Sun.COM> <tslfximb0p3.fsf@live.mit.edu>
	<20090210184046.GB9992@Sun.COM>
	<ldvfxim6ri8.fsf@cathode-dark-space.mit.edu>
	<20090210191212.GD9992@Sun.COM> <tslskmm9hep.fsf@live.mit.edu>
	<20090210202459.GH9992@Sun.COM>
Message-ID: <tsl4oz19az2.fsf@live.mit.edu>

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:

    Nicolas> On Tue, Feb 10, 2009 at 03:16:30PM -0500, Sam Hartman
    Nicolas> wrote:
    >> I have to agree with Tom here.

    Nicolas> Meaning what, specifically?  That you think MIT should
    Nicolas> not accept a patch that does anything other than replace
    Nicolas> the null realm name with the default realm name?

That MIT should assume that if you have a keytab you have a default
realm name.

I think that the proposed patch may be fine.  I certainly am not objecting to it.

From Nicolas.Williams at sun.com  Tue Feb 10 17:35:16 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 10 Feb 2009 16:35:16 -0600
Subject: regression due to referral realm
In-Reply-To: <tsl4oz19az2.fsf@live.mit.edu>
References: <1233741094.15016.21.camel@zup> <tsl4ozahwf7.fsf@live.mit.edu>
	<20090210161732.GO9992@Sun.COM> <tslfximb0p3.fsf@live.mit.edu>
	<20090210184046.GB9992@Sun.COM>
	<ldvfxim6ri8.fsf@cathode-dark-space.mit.edu>
	<20090210191212.GD9992@Sun.COM> <tslskmm9hep.fsf@live.mit.edu>
	<20090210202459.GH9992@Sun.COM> <tsl4oz19az2.fsf@live.mit.edu>
Message-ID: <20090210223516.GP9992@Sun.COM>

On Tue, Feb 10, 2009 at 05:35:29PM -0500, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
> 
>     Nicolas> On Tue, Feb 10, 2009 at 03:16:30PM -0500, Sam Hartman
>     Nicolas> wrote:
>     >> I have to agree with Tom here.
> 
>     Nicolas> Meaning what, specifically?  That you think MIT should
>     Nicolas> not accept a patch that does anything other than replace
>     Nicolas> the null realm name with the default realm name?
> 
> That MIT should assume that if you have a keytab you have a default
> realm name.
> 
> I think that the proposed patch may be fine.  I certainly am not objecting to it.

OK.  I'll forward this comment to the maintainers of the smbadm join and
kclient commands.

Nico
-- 

From hartmans at MIT.EDU  Tue Feb 10 20:13:48 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 10 Feb 2009 20:13:48 -0500
Subject: Question on PAC and principal APIs project
In-Reply-To: <49907282.3070005@Sun.COM> (Natalie Li's message of "Mon, 09 Feb
	2009 10:14:26 -0800")
References: <498F1CF8.1030007@sun.com>
	<2D22ED74-1137-4EB2-B70D-4AA25D628D46@mit.edu>
	<49906BCB.1090500@Sun.COM>
	<25B96387-4016-4036-9D2F-BCC47805C0E4@MIT.EDU>
	<49907282.3070005@Sun.COM>
Message-ID: <tslzlgt7p2r.fsf@live.mit.edu>

>>>>> "Natalie" == Natalie Li <Natalie.Li at Sun.COM> writes:

    Natalie> Thanks Ken!
    Natalie> Ken Raeburn wrote:

Note that there is also a mechanism to extract authorization data from
a GSS-API context.


From Nicolas.Williams at sun.com  Tue Feb 10 21:24:44 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 10 Feb 2009 20:24:44 -0600
Subject: Question on PAC and principal APIs project
In-Reply-To: <tslzlgt7p2r.fsf@live.mit.edu>
References: <498F1CF8.1030007@sun.com>
	<2D22ED74-1137-4EB2-B70D-4AA25D628D46@mit.edu>
	<49906BCB.1090500@Sun.COM>
	<25B96387-4016-4036-9D2F-BCC47805C0E4@MIT.EDU>
	<49907282.3070005@Sun.COM> <tslzlgt7p2r.fsf@live.mit.edu>
Message-ID: <20090211022444.GT9992@Sun.COM>

On Tue, Feb 10, 2009 at 08:13:48PM -0500, Sam Hartman wrote:
> >>>>> "Natalie" == Natalie Li <Natalie.Li at Sun.COM> writes:
> 
>     Natalie> Thanks Ken!
>     Natalie> Ken Raeburn wrote:
> 
> Note that there is also a mechanism to extract authorization data from
> a GSS-API context.

Indeed.  We'll have to work that in, probably by extracting the PAC and
associating it with the gss_name_t and then adding more functions along
the lines of gsscred_name_to_unix_cred() (at least as an project private
interface in Solaris for Natalie's purposes).

From tlyu at MIT.EDU  Tue Feb 10 22:05:18 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Tue, 10 Feb 2009 22:05:18 -0500
Subject: minimum python version for test suite?
Message-ID: <ldv7i3xbrm9.fsf@cathode-dark-space.mit.edu>

We are considering using Python in some portions of our test suite.
It appears that some operating systems ship with 2.5, but some
slightly older ones ship with 2.3.  Apparently certain desirable
language features are available on 2.5 that are not available on 2.3.

If you are inclined to run our test suite, what versions of Python do
you find to be readily available on their operating systems of choice?
Do you find that installing a version of Python that is newer than the
OS-provided version to be problematic?  What do you consider to be a
reasonable minimum required version of Python for our test suite?

Thanks.

-- 
Tom Yu
Development Team Leader
MIT Kerberos Consortium

From Natalie.Li at Sun.COM  Tue Feb 10 23:20:59 2009
From: Natalie.Li at Sun.COM (Natalie Li)
Date: Tue, 10 Feb 2009 20:20:59 -0800
Subject: Question on PAC and principal APIs project
In-Reply-To: <tslzlgt7p2r.fsf@live.mit.edu>
References: <498F1CF8.1030007@sun.com>
	<2D22ED74-1137-4EB2-B70D-4AA25D628D46@mit.edu>
	<49906BCB.1090500@Sun.COM>
	<25B96387-4016-4036-9D2F-BCC47805C0E4@MIT.EDU>
	<49907282.3070005@Sun.COM> <tslzlgt7p2r.fsf@live.mit.edu>
Message-ID: <4992522B.3020209@sun.com>

Sam Hartman wrote:
> Note that there is also a mechanism to extract authorization data from
> a GSS-API context.
>   
I'm not too familiar with the MIT codebase.   Could you please point me 
to the relevant source code?

Thanks,

Natalie


From Shawn.Emery at Sun.COM  Wed Feb 11 03:25:24 2009
From: Shawn.Emery at Sun.COM (Shawn M Emery)
Date: Wed, 11 Feb 2009 01:25:24 -0700
Subject: regression due to referral realm
In-Reply-To: <20090210223516.GP9992@Sun.COM>
References: <1233741094.15016.21.camel@zup> <tsl4ozahwf7.fsf@live.mit.edu>
	<20090210161732.GO9992@Sun.COM> <tslfximb0p3.fsf@live.mit.edu>
	<20090210184046.GB9992@Sun.COM>
	<ldvfxim6ri8.fsf@cathode-dark-space.mit.edu>
	<20090210191212.GD9992@Sun.COM> <tslskmm9hep.fsf@live.mit.edu>
	<20090210202459.GH9992@Sun.COM> <tsl4oz19az2.fsf@live.mit.edu>
	<20090210223516.GP9992@Sun.COM>
Message-ID: <49928B74.7010300@sun.com>

Nicolas Williams wrote:
> On Tue, Feb 10, 2009 at 05:35:29PM -0500, Sam Hartman wrote:
>   
>>>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
>>>>>>>               
>>     Nicolas> On Tue, Feb 10, 2009 at 03:16:30PM -0500, Sam Hartman
>>     Nicolas> wrote:
>>     >> I have to agree with Tom here.
>>
>>     Nicolas> Meaning what, specifically?  That you think MIT should
>>     Nicolas> not accept a patch that does anything other than replace
>>     Nicolas> the null realm name with the default realm name?
>>
>> That MIT should assume that if you have a keytab you have a default
>> realm name.
>>
>> I think that the proposed patch may be fine.  I certainly am not objecting to it.
>>     
>
> OK.  I'll forward this comment to the maintainers of the smbadm join and
> kclient commands.
>   

kclient populates the default realm so it would not be affected by 
this.  In regards to the solution, I would prefer to search the keytab 
last to first.  When transitioning realms (keeping old service keys), 
the new keys were appended to the keytab from what I remember.  Do you 
recall this as well with "smbadm join", Natalie?

Shawn.
--

From Mark.Phalan at Sun.COM  Wed Feb 11 05:57:07 2009
From: Mark.Phalan at Sun.COM (Mark Phalan)
Date: Wed, 11 Feb 2009 11:57:07 +0100
Subject: regression due to referral realm
In-Reply-To: <tsl4oz19az2.fsf@live.mit.edu>
References: <1233741094.15016.21.camel@zup> <tsl4ozahwf7.fsf@live.mit.edu>
	<20090210161732.GO9992@Sun.COM> <tslfximb0p3.fsf@live.mit.edu>
	<20090210184046.GB9992@Sun.COM>
	<ldvfxim6ri8.fsf@cathode-dark-space.mit.edu>
	<20090210191212.GD9992@Sun.COM> <tslskmm9hep.fsf@live.mit.edu>
	<20090210202459.GH9992@Sun.COM> <tsl4oz19az2.fsf@live.mit.edu>
Message-ID: <1234349827.19333.363.camel@zup>


On Tue, 2009-02-10 at 17:35 -0500, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
> 
>     Nicolas> On Tue, Feb 10, 2009 at 03:16:30PM -0500, Sam Hartman
>     Nicolas> wrote:
>     >> I have to agree with Tom here.
> 
>     Nicolas> Meaning what, specifically?  That you think MIT should
>     Nicolas> not accept a patch that does anything other than replace
>     Nicolas> the null realm name with the default realm name?
> 
> That MIT should assume that if you have a keytab you have a default
> realm name.
> 
> I think that the proposed patch may be fine.  I certainly am not objecting to it.


I've posted the patch here for people to look at:

http://cr.opensolaris.org/~mbp/referral_kt.patch

I could modify it so that it would look for an entry with the default
realm name before falling-back to looking for an entry with any realm if
thats what MIT would like?

-M




From Mark.Phalan at Sun.COM  Wed Feb 11 06:00:51 2009
From: Mark.Phalan at Sun.COM (Mark Phalan)
Date: Wed, 11 Feb 2009 12:00:51 +0100
Subject: regression due to referral realm
In-Reply-To: <49928B74.7010300@sun.com>
References: <1233741094.15016.21.camel@zup> <tsl4ozahwf7.fsf@live.mit.edu>
	<20090210161732.GO9992@Sun.COM> <tslfximb0p3.fsf@live.mit.edu>
	<20090210184046.GB9992@Sun.COM>
	<ldvfxim6ri8.fsf@cathode-dark-space.mit.edu>
	<20090210191212.GD9992@Sun.COM> <tslskmm9hep.fsf@live.mit.edu>
	<20090210202459.GH9992@Sun.COM> <tsl4oz19az2.fsf@live.mit.edu>
	<20090210223516.GP9992@Sun.COM> <49928B74.7010300@sun.com>
Message-ID: <1234350051.19333.372.camel@zup>


On Wed, 2009-02-11 at 01:25 -0700, Shawn M Emery wrote:
> Nicolas Williams wrote:
> > On Tue, Feb 10, 2009 at 05:35:29PM -0500, Sam Hartman wrote:
> >   
> >>>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
> >>>>>>>               
> >>     Nicolas> On Tue, Feb 10, 2009 at 03:16:30PM -0500, Sam Hartman
> >>     Nicolas> wrote:
> >>     >> I have to agree with Tom here.
> >>
> >>     Nicolas> Meaning what, specifically?  That you think MIT should
> >>     Nicolas> not accept a patch that does anything other than replace
> >>     Nicolas> the null realm name with the default realm name?
> >>
> >> That MIT should assume that if you have a keytab you have a default
> >> realm name.
> >>
> >> I think that the proposed patch may be fine.  I certainly am not objecting to it.
> >>     
> >
> > OK.  I'll forward this comment to the maintainers of the smbadm join and
> > kclient commands.
> >   
> 
> kclient populates the default realm so it would not be affected by 
> this.  In regards to the solution, I would prefer to search the keytab 
> last to first.  When transitioning realms (keeping old service keys), 
> the new keys were appended to the keytab from what I remember.

This should be done consistently though throughout MIT Kerberos when
searching a keytab. My understanding is that currently MIT Kerberos
searches first-to-last. Either way my proposed patch just uses
krb5_kt_start_seq_get/krb5_kt_next_entry. Presumably the implementation
of those keytab funcs could be modified to return entries in the reverse
order.

-M


From hartmans at MIT.EDU  Wed Feb 11 08:19:24 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 11 Feb 2009 08:19:24 -0500
Subject: regression due to referral realm
In-Reply-To: <1234349827.19333.363.camel@zup> (Mark Phalan's message of "Wed, 
	11 Feb 2009 11:57:07 +0100")
References: <1233741094.15016.21.camel@zup> <tsl4ozahwf7.fsf@live.mit.edu>
	<20090210161732.GO9992@Sun.COM> <tslfximb0p3.fsf@live.mit.edu>
	<20090210184046.GB9992@Sun.COM>
	<ldvfxim6ri8.fsf@cathode-dark-space.mit.edu>
	<20090210191212.GD9992@Sun.COM> <tslskmm9hep.fsf@live.mit.edu>
	<20090210202459.GH9992@Sun.COM> <tsl4oz19az2.fsf@live.mit.edu>
	<1234349827.19333.363.camel@zup>
Message-ID: <tsl63jh5cwz.fsf@live.mit.edu>

>>>>> "Mark" == Mark Phalan <Mark.Phalan at Sun.COM> writes:

    Mark> On Tue, 2009-02-10 at 17:35 -0500, Sam Hartman wrote:
    >> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com>
    >> writes:
    >> 
    Nicolas> On Tue, Feb 10, 2009 at 03:16:30PM -0500, Sam Hartman
    Nicolas> wrote:
    >> >> I have to agree with Tom here.
    >> 
    Nicolas> Meaning what, specifically?  That you think MIT should
    Nicolas> not accept a patch that does anything other than replace
    Nicolas> the null realm name with the default realm name?
    >>  That MIT should assume that if you have a keytab you have a
    >> default realm name.
    >> 
    >> I think that the proposed patch may be fine.  I certainly am
    >> not objecting to it.


    Mark> I've posted the patch here for people to look at:

Perhaps someone (Will?) could commit?

    Mark> http://cr.opensolaris.org/~mbp/referral_kt.patch

    Mark> I could modify it so that it would look for an entry with
    Mark> the default realm name before falling-back to looking for an
    Mark> entry with any realm if thats what MIT would like?

I'm not asking for that.  I would not object to it.


From hartmans at MIT.EDU  Wed Feb 11 08:24:53 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 11 Feb 2009 08:24:53 -0500
Subject: Question on PAC and principal APIs project
In-Reply-To: <4992522B.3020209@sun.com> (Natalie Li's message of "Tue, 10 Feb
	2009 20:20:59 -0800")
References: <498F1CF8.1030007@sun.com>
	<2D22ED74-1137-4EB2-B70D-4AA25D628D46@mit.edu>
	<49906BCB.1090500@Sun.COM>
	<25B96387-4016-4036-9D2F-BCC47805C0E4@MIT.EDU>
	<49907282.3070005@Sun.COM> <tslzlgt7p2r.fsf@live.mit.edu>
	<4992522B.3020209@sun.com>
Message-ID: <tslwsbx3y3e.fsf@live.mit.edu>

>>>>> "Natalie" == Natalie Li <Natalie.Li at Sun.COM> writes:

    Natalie> Sam Hartman wrote:
    >> Note that there is also a mechanism to extract authorization
    >> data from a GSS-API context.
    >> 
    Natalie> I'm not too familiar with the MIT codebase.  Could you
    Natalie> please point me to the relevant source code?

    Natalie> Thanks,

OM_uint32 KRB5_CALLCONV
gsskrb5_extract_authz_data_from_sec_context(OM_uint32 *minor_status,
                                            const gss_ctx_id_t context_handle,
                                                                                        int ad_type,
                                                                                                                                    gss_buffer_t ad_data);
                                                                                                                                    
(gssapi_krb5.h)
will pull the authorization data out of a context.
You'd need to pull out  ad-if-relevant 
and then use
krb5_error_code KRB5_CALLCONV
krb5_decode_authdata_container(krb5_context context,
    krb5_authdatatype type,
        const krb5_authdata *container,
            krb5_authdata ***authdata);
            
to pull appart the container.
You can then pass the PAC into the APIs described in the project.

Yes, that should be made a bit cleaner.  There should be a utility
function to help.  If you have the time and want to propose such a
utility that would be an excellent contribution to the project, although discussing the interface may take a bit of time.
If you just want to get work done, that's OK too:-)


From Mark.Phalan at Sun.COM  Wed Feb 11 08:35:20 2009
From: Mark.Phalan at Sun.COM (Mark Phalan)
Date: Wed, 11 Feb 2009 14:35:20 +0100
Subject: regression due to referral realm
In-Reply-To: <tsl63jh5cwz.fsf@live.mit.edu>
References: <1233741094.15016.21.camel@zup> <tsl4ozahwf7.fsf@live.mit.edu>
	<20090210161732.GO9992@Sun.COM> <tslfximb0p3.fsf@live.mit.edu>
	<20090210184046.GB9992@Sun.COM>
	<ldvfxim6ri8.fsf@cathode-dark-space.mit.edu>
	<20090210191212.GD9992@Sun.COM> <tslskmm9hep.fsf@live.mit.edu>
	<20090210202459.GH9992@Sun.COM> <tsl4oz19az2.fsf@live.mit.edu>
	<1234349827.19333.363.camel@zup> <tsl63jh5cwz.fsf@live.mit.edu>
Message-ID: <1234359320.19333.405.camel@zup>


On Wed, 2009-02-11 at 08:19 -0500, Sam Hartman wrote:
> >>>>> "Mark" == Mark Phalan <Mark.Phalan at Sun.COM> writes:
> 
>     Mark> On Tue, 2009-02-10 at 17:35 -0500, Sam Hartman wrote:
>     >> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com>
>     >> writes:
>     >> 
>     Nicolas> On Tue, Feb 10, 2009 at 03:16:30PM -0500, Sam Hartman
>     Nicolas> wrote:
>     >> >> I have to agree with Tom here.
>     >> 
>     Nicolas> Meaning what, specifically?  That you think MIT should
>     Nicolas> not accept a patch that does anything other than replace
>     Nicolas> the null realm name with the default realm name?
>     >>  That MIT should assume that if you have a keytab you have a
>     >> default realm name.
>     >> 
>     >> I think that the proposed patch may be fine.  I certainly am
>     >> not objecting to it.
> 
> 
>     Mark> I've posted the patch here for people to look at:
> 
> Perhaps someone (Will?) could commit?

I've only tested the above code with Solaris Kerberos. I'll test it with
the latest MIT trunk and clean up the patch if necessary. I'll talk to
Will about getting it committed.

> 
>     Mark> http://cr.opensolaris.org/~mbp/referral_kt.patch
> 
>     Mark> I could modify it so that it would look for an entry with
>     Mark> the default realm name before falling-back to looking for an
>     Mark> entry with any realm if thats what MIT would like?
> 
> I'm not asking for that.  I would not object to it.

Thanks.

-M


From ssorce at redhat.com  Wed Feb 11 10:39:50 2009
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 11 Feb 2009 10:39:50 -0500
Subject: minimum python version for test suite?
In-Reply-To: <ldv7i3xbrm9.fsf@cathode-dark-space.mit.edu>
References: <ldv7i3xbrm9.fsf@cathode-dark-space.mit.edu>
Message-ID: <1234366790.3787.129.camel@localhost.localdomain>

On Tue, 2009-02-10 at 22:05 -0500, Tom Yu wrote:
> We are considering using Python in some portions of our test suite.
> It appears that some operating systems ship with 2.5, but some
> slightly older ones ship with 2.3.  Apparently certain desirable
> language features are available on 2.5 that are not available on 2.3.
> 
> If you are inclined to run our test suite, what versions of Python do
> you find to be readily available on their operating systems of choice?
> Do you find that installing a version of Python that is newer than the
> OS-provided version to be problematic?  What do you consider to be a
> reasonable minimum required version of Python for our test suite?

I think it depends on what about the tests are related to.
If their main aim is to verify regressions at development time you can
certainly be a little bit more aggressive and shoot for 2.5 (or even
2.6).
If the aim is to have automated test running as part of the build
process to validate the bits then trying to be conservative will help
quite a lot given build systems often rely on what is supported in the
current OS you are building on and adding different software is cause of
concern as it may invalidate other assumptions of the build system.

Simo.

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


From Natalie.Li at Sun.COM  Wed Feb 11 11:18:25 2009
From: Natalie.Li at Sun.COM (Natalie Li)
Date: Wed, 11 Feb 2009 08:18:25 -0800
Subject: regression due to referral realm
In-Reply-To: <49928B74.7010300@sun.com>
References: <1233741094.15016.21.camel@zup> <tsl4ozahwf7.fsf@live.mit.edu>
	<20090210161732.GO9992@Sun.COM> <tslfximb0p3.fsf@live.mit.edu>
	<20090210184046.GB9992@Sun.COM>
	<ldvfxim6ri8.fsf@cathode-dark-space.mit.edu>
	<20090210191212.GD9992@Sun.COM> <tslskmm9hep.fsf@live.mit.edu>
	<20090210202459.GH9992@Sun.COM> <tsl4oz19az2.fsf@live.mit.edu>
	<20090210223516.GP9992@Sun.COM> <49928B74.7010300@sun.com>
Message-ID: <4992FA51.8010701@Sun.COM>

Shawn M Emery wrote:
> Nicolas Williams wrote:
>> On Tue, Feb 10, 2009 at 05:35:29PM -0500, Sam Hartman wrote:
>>   
>>>>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
>>>>>>>>               
>>>     Nicolas> On Tue, Feb 10, 2009 at 03:16:30PM -0500, Sam Hartman
>>>     Nicolas> wrote:
>>>     >> I have to agree with Tom here.
>>>
>>>     Nicolas> Meaning what, specifically?  That you think MIT should
>>>     Nicolas> not accept a patch that does anything other than replace
>>>     Nicolas> the null realm name with the default realm name?
>>>
>>> That MIT should assume that if you have a keytab you have a default
>>> realm name.
>>>
>>> I think that the proposed patch may be fine.  I certainly am not objecting to it.
>>>     
>>
>> OK.  I'll forward this comment to the maintainers of the smbadm join and
>> kclient commands.
>>   
>
> kclient populates the default realm so it would not be affected by 
> this.  In regards to the solution, I would prefer to search the keytab 
> last to first.  When transitioning realms (keeping old service keys), 
> the new keys were appended to the keytab from what I remember.  Do you 
> recall this as well with "smbadm join", Natalie?
>
Yes, I recalled seeing a problem when transitioning from one realm to 
another.  The problem seems to be that a new set of keytab entries with 
different kvno for the same principal names are appended.  So the new 
ones will be last, and the first ones will become  invalid.  Yet, I 
recalled the *INVALID* ones will be selected when one needs it.  It'd be 
better if libkrb5 search to the end of the keytab, always, picking the 
*latest* keytab entry matching whatever is required.

Natalie
> Shawn.
> --


From Nicolas.Williams at sun.com  Wed Feb 11 12:02:54 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 11 Feb 2009 11:02:54 -0600
Subject: regression due to referral realm
In-Reply-To: <tsl4ozahwf7.fsf@live.mit.edu>
References: <1233741094.15016.21.camel@zup> <tsl4ozahwf7.fsf@live.mit.edu>
Message-ID: <20090211170254.GE9992@Sun.COM>

On Wed, Feb 04, 2009 at 01:46:52PM -0500, Sam Hartman wrote:
> What is the right fix here?  Do we want to substitute in the default
> realm, or do we want to substitute in the realm of the local host
> (I.E. getrealmofhost(gethostname())?

Incidentally, I asked Mark why we couldn't use host-2-realm, and the
answer's just too obvious: because we are using the principal in
question as the client principal in an AS-REQ, which means we need a
keytab entry before any referrals/canonicalization could happen, which
means we need to pick a keytab entry without knowing the host's realm.

Nico
-- 

From Natalie.Li at Sun.COM  Wed Feb 11 14:51:48 2009
From: Natalie.Li at Sun.COM (Natalie Li)
Date: Wed, 11 Feb 2009 11:51:48 -0800
Subject: Question on PAC and principal APIs project
In-Reply-To: <tslwsbx3y3e.fsf@live.mit.edu>
References: <498F1CF8.1030007@sun.com>
	<2D22ED74-1137-4EB2-B70D-4AA25D628D46@mit.edu>
	<49906BCB.1090500@Sun.COM>
	<25B96387-4016-4036-9D2F-BCC47805C0E4@MIT.EDU>
	<49907282.3070005@Sun.COM>
	<tslzlgt7p2r.fsf@live.mit.edu> <4992522B.3020209@sun.com>
	<tslwsbx3y3e.fsf@live.mit.edu>
Message-ID: <49932C54.3010802@Sun.COM>

That's very helpful.  Thanks Sam!

Sam Hartman wrote:
>>>>>> "Natalie" == Natalie Li <Natalie.Li at Sun.COM> writes:
>>>>>>             
>
>     Natalie> Sam Hartman wrote:
>     >> Note that there is also a mechanism to extract authorization
>     >> data from a GSS-API context.
>     >> 
>     Natalie> I'm not too familiar with the MIT codebase.  Could you
>     Natalie> please point me to the relevant source code?
>
>     Natalie> Thanks,
>
> OM_uint32 KRB5_CALLCONV
> gsskrb5_extract_authz_data_from_sec_context(OM_uint32 *minor_status,
>                                             const gss_ctx_id_t context_handle,
>                                                                                         int ad_type,
>                                                                                                                                     gss_buffer_t ad_data);
>                                                                                                                                     
> (gssapi_krb5.h)
> will pull the authorization data out of a context.
> You'd need to pull out  ad-if-relevant 
> and then use
> krb5_error_code KRB5_CALLCONV
> krb5_decode_authdata_container(krb5_context context,
>     krb5_authdatatype type,
>         const krb5_authdata *container,
>             krb5_authdata ***authdata);
>             
> to pull appart the container.
> You can then pass the PAC into the APIs described in the project.
>
> Yes, that should be made a bit cleaner.  There should be a utility
> function to help.  If you have the time and want to propose such a
> utility that would be an excellent contribution to the project, although discussing the interface may take a bit of time.
> If you just want to get work done, that's OK too:-)
>
>   


From hartmans at MIT.EDU  Thu Feb 12 16:06:58 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Thu, 12 Feb 2009 16:06:58 -0500
Subject: Unexporting krb5_send_tgs
Message-ID: <tsleiy3xt3h.fsf@live.mit.edu>

Currently, krb5_send_tgs is exported at least on unix, but is defined
in k5-int.h.  I needed to change its interface in order to implement
support for TGS authenticator subkeys (needed by FAST).  Since it is a
private interface, I rename it to krb5int_send_tgs and removed from
the export list.


--Sam

From gmachin at sandia.gov  Fri Feb 13 12:17:44 2009
From: gmachin at sandia.gov (Glenn Machin)
Date: Fri, 13 Feb 2009 10:17:44 -0700
Subject: Does the development team have recommendation on pam_krb5?
Message-ID: <4995AB38.2080506@sandia.gov>

 From what I can tell there are 2 sources for pam_krb5.

It is my understanding that Fedora/RedHat uses 2.2/2.3 version while 
Solaris 10, Ubunto/Debian use 3.X version maintained by Russ Allbery.   
 From what I can tell they are divergent code branches.  

The 3.X version has some features that I don't see in the FC 2.3 
versions such as :
http://www.eyrie.org/~eagle/software/pam-krb5/readme.html
   

   1. PKINIT support
   2. Kerberos principal name mapping:
          * alt_auth_map,only_alt_auth
          * expose_account
          * search_k5login


We have an environment where users are from multiple trusted realms so 
mapping is a necessity and in the future we will be using HSPD 12 PIV 
badges for authentication where PKINIT is important.


So does the MIT development team have a pam_krb5 recommendation?

Does anyone know if the Fedora/RH distribution will have these features 
in the future?


Finally is anyone working on plugin-in for krb5_aname_to_localname()?   
It would be nice to use LDAP  to obtain the mapping information.   The 
information is available in Active Directory through the 
altSecurityIdentities and it looks like the NFS4 work and University of 
Michigan CITI,  idmapd.conf uses the LDAP attribute GSSAuthName.


Thanks,

    Glenn




From rra at stanford.edu  Fri Feb 13 12:55:22 2009
From: rra at stanford.edu (Russ Allbery)
Date: Fri, 13 Feb 2009 09:55:22 -0800
Subject: Does the development team have recommendation on pam_krb5?
In-Reply-To: <4995AB38.2080506@sandia.gov> (Glenn Machin's message of "Fri\,
	13 Feb 2009 10\:17\:44 -0700")
References: <4995AB38.2080506@sandia.gov>
Message-ID: <87k57u2pdh.fsf@windlord.stanford.edu>

I'll refrain from commenting on the general question, since I'm only a
gadfly on the group that you're asking and since my opinion is probably
predictable.  ;)  FWIW, the reason why I started from Debian's at the time
and decided to maintain my own is because search_k5login was a mandatory
feature for us at Stanford and it looked easier to add to and maintain in
the code base Debian was using at the time than the one from Sourceforge
(on which the Red Hat module is based, I believe).

"Glenn Machin" <gmachin at sandia.gov> writes:

> It is my understanding that Fedora/RedHat uses 2.2/2.3 version while
> Solaris 10, Ubunto/Debian use 3.X version maintained by Russ Allbery.
> From what I can tell they are divergent code branches.

Solaris 10 I believe uses yet another separate implementation that Sun
wrote themselves, although I've not looked at it in any detail (in part
because it's covered by a license that's not compatible with mine, and I
don't want to accidentally take code from it).

I don't believe the Fedora / Red Hat PAM module even has a common ancestor
with mine.  I believe it's an entirely separate implementation.

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

From nalin at redhat.com  Fri Feb 13 13:01:05 2009
From: nalin at redhat.com (Nalin Dahyabhai)
Date: Fri, 13 Feb 2009 13:01:05 -0500
Subject: Does the development team have recommendation on pam_krb5?
In-Reply-To: <4995AB38.2080506@sandia.gov>
References: <4995AB38.2080506@sandia.gov>
Message-ID: <20090213180105.GA3178@redhat.com>

On Fri, Feb 13, 2009 at 10:17:44AM -0700, Glenn Machin wrote:
>  From what I can tell there are 2 sources for pam_krb5.
> 
> It is my understanding that Fedora/RedHat uses 2.2/2.3 version while 
> Solaris 10, Ubunto/Debian use 3.X version maintained by Russ Allbery.   
> From what I can tell they are divergent code branches.  

I don't think Russ's is derived from the one we use, which started its
life as a rewrite of the one that preceded it.  Based on its man page, I
doubt Sun's is related to either.

Preauth settings are settable in 2.2.19 and later.  Mapping from user
names to principal names is configurable using regular expressions.

Cheers,

Nalin

From gmachin at sandia.gov  Fri Feb 13 13:46:50 2009
From: gmachin at sandia.gov (Glenn Machin)
Date: Fri, 13 Feb 2009 11:46:50 -0700
Subject: Does the development team have recommendation on pam_krb5?
In-Reply-To: <20090213180105.GA3178@redhat.com>
References: <4995AB38.2080506@sandia.gov>
 <20090213180105.GA3178@redhat.com>
Message-ID: <4995C01A.308@sandia.gov>

Nalin thanks for the feedback.  I did not know if they had been derived 
from the same initial code base.

> Mapping from user names to principal names is configurable using regular expressions.


The problem with a regular expression is that there must be a 
reproducible pattern for all users.

If I manage 2 realms where jdoe at realma is jdoe at realmb  regular 
expressions works well, but if realmb can assign arbitrary names with no 
pattern the only thing you can use  is a database or directory where the 
user's realmb principal name is defined.

Thats why  utilizing the .k5login information to determine the users 
"Kerberos realm(s)" identity for authentication is important.   In order 
for OpenSSH to use gssapi-with-mic you already have to have that mapping 
information in the .k5login file.  

So if regular expressions won't work I'm really left with the .k5login 
unless we can use a  plugin-in for krb5_aname_to_localname() which can 
use the same directory service that is being used by nsswitch (nss_ldap, 
winbind).   I personally don't like .k5login since its user definable 
and  reminds me of the .rhosts file.

Thanks again......

Glenn





Nalin Dahyabhai wrote:
> On Fri, Feb 13, 2009 at 10:17:44AM -0700, Glenn Machin wrote:
>   
>>  From what I can tell there are 2 sources for pam_krb5.
>>
>> It is my understanding that Fedora/RedHat uses 2.2/2.3 version while 
>> Solaris 10, Ubunto/Debian use 3.X version maintained by Russ Allbery.   
>> From what I can tell they are divergent code branches.  
>>     
>
> I don't think Russ's is derived from the one we use, which started its
> life as a rewrite of the one that preceded it.  Based on its man page, I
> doubt Sun's is related to either.
>
> Preauth settings are settable in 2.2.19 and later.  Mapping from user
> names to principal names is configurable using regular expressions.
>
> Cheers,
>
> Nalin
>
>   



From ls.niks at gmail.com  Tue Feb 17 04:30:48 2009
From: ls.niks at gmail.com (Nikhil Mishra)
Date: Tue, 17 Feb 2009 15:00:48 +0530
Subject: KRB5KRB_AP_ERR_BAD_INTEGRITY from krb5_arcfour_decrypt
Message-ID: <35dad1db0902170130j523d8d0fo3650aa0c3abf2ee8@mail.gmail.com>

Hi All ,

This is my setup .

windows XP client
windows 2003 server AD and KDC .
Linux FC with MIT kerberos 1.6.3

I generate keytab for  SPN using this command  :


ktpass -princ cifs/cifsserver2 at WXYZ.COM -mapuser cifsserver2 -pass rohati123
/ptype KRB
5_NT_SRV_INST -setpass -setupn -out cifs.keytab

The user is actually a computer name and not an actual user in domain ( I
dont know If it effects but Just in case )

I want to route my traffic through a linux box and I am trying to decrypt
AP_REQ using this keytab
I looked at kvno and everything else matches so , basically krb_kt_get_entry
passes .

Why would this fail while decrypting the packet in krb5_decrypt_tkt_part
returning  KRB5KRB_AP_ERR_BAD_INTEGRITY?
I have tried debugging it and beyond all reasons I dont find a reason why


Any help would be appreciated !!!

Thanks & Regards

Nikhil

From jaltman at secure-endpoints.com  Tue Feb 17 09:28:13 2009
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Tue, 17 Feb 2009 09:28:13 -0500
Subject: KRB5KRB_AP_ERR_BAD_INTEGRITY from krb5_arcfour_decrypt
In-Reply-To: <35dad1db0902170130j523d8d0fo3650aa0c3abf2ee8@mail.gmail.com>
References: <35dad1db0902170130j523d8d0fo3650aa0c3abf2ee8@mail.gmail.com>
Message-ID: <499AC97D.7030709@secure-endpoints.com>

Nikhil Mishra wrote:
> Hi All ,
> 
> This is my setup .
> 
> windows XP client
> windows 2003 server AD and KDC .
> Linux FC with MIT kerberos 1.6.3
> 
> I generate keytab for  SPN using this command  :
> 
> 
> ktpass -princ cifs/cifsserver2 at WXYZ.COM -mapuser cifsserver2 -pass rohati123
> /ptype KRB
> 5_NT_SRV_INST -setpass -setupn -out cifs.keytab
> 
> The user is actually a computer name and not an actual user in domain ( I
> dont know If it effects but Just in case )
> 
> I want to route my traffic through a linux box and I am trying to decrypt
> AP_REQ using this keytab
> I looked at kvno and everything else matches so , basically krb_kt_get_entry
> passes .
> 
> Why would this fail while decrypting the packet in krb5_decrypt_tkt_part
> returning  KRB5KRB_AP_ERR_BAD_INTEGRITY?
> I have tried debugging it and beyond all reasons I dont find a reason why
> 
> 
> Any help would be appreciated !!!
> 
> Thanks & Regards
> 
> Nikhil

Can you verify the keytab with

  kvno -k cifs.keytab cifs/cifsserver2 at WXYZ.COM

when the default credential cache contains a TGT in the WXYZ.COM realm?

Are you in fact obtaining a ticket whose service name is "cifs/cifsserver2"?

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

From deengert at anl.gov  Tue Feb 17 10:03:12 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Tue, 17 Feb 2009 09:03:12 -0600
Subject: KRB5KRB_AP_ERR_BAD_INTEGRITY from krb5_arcfour_decrypt
In-Reply-To: <35dad1db0902170130j523d8d0fo3650aa0c3abf2ee8@mail.gmail.com>
References: <35dad1db0902170130j523d8d0fo3650aa0c3abf2ee8@mail.gmail.com>
Message-ID: <499AD1B0.3020901@anl.gov>



Nikhil Mishra wrote:
> Hi All ,
> 
> This is my setup .
> 
> windows XP client
> windows 2003 server AD and KDC .
> Linux FC with MIT kerberos 1.6.3
> 
> I generate keytab for  SPN using this command  :
> 
> 
> ktpass -princ cifs/cifsserver2 at WXYZ.COM -mapuser cifsserver2 -pass rohati123
> /ptype KRB
> 5_NT_SRV_INST -setpass -setupn -out cifs.keytab

What version of ktpass? There were some issues with the 2003 version,
Google for ktpass 2003 to see more.

> 
> The user is actually a computer name and not an actual user in domain ( I
> dont know If it effects but Just in case )
> 
> I want to route my traffic through a linux box and I am trying to decrypt
> AP_REQ using this keytab

What do you mean you are trying to route traffic through the linux box?
You mean the AP_REQ is actually from the XP client to the file server server
and you are the man-in-the-middle trying to decrypt it?

But the KDC may be using the actual cifs server key under a different account
with a random password used to generate the key.

You must be careful to change the key in the KDC and on the server to keep them
in sync.



> I looked at kvno and everything else matches so , basically krb_kt_get_entry
> passes .
>




> Why would this fail while decrypting the packet in krb5_decrypt_tkt_part
> returning  KRB5KRB_AP_ERR_BAD_INTEGRITY?
> I have tried debugging it and beyond all reasons I dont find a reason why
> 
> 
> Any help would be appreciated !!!
> 
> Thanks & Regards
> 
> Nikhil
> _______________________________________________
> 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 hotz at jpl.nasa.gov  Tue Feb 17 18:31:42 2009
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Tue, 17 Feb 2009 15:31:42 -0800
Subject: Does the development team have recommendation on pam_krb5?
In-Reply-To: <mailman.527.1234631418.17197.krbdev@mit.edu>
References: <mailman.527.1234631418.17197.krbdev@mit.edu>
Message-ID: <A674FF40-4516-41B6-BE17-D6774C461325@jpl.nasa.gov>

FWIW I've have very good luck with Russ' pam_krb5.  I've had  
difficulty configuring the RedHat one.  The Sun one seems to be good  
but is a bit behind the curve.  (-: At least on Solaris 9! ;-)

I note that if you want to use one with smart cards, then I think  
Russ' pam_krb5 is currently the only option.  OpenSolaris is working  
on it, and will certainly deliver something sometime.

On Feb 14, 2009, at 9:10 AM, krbdev-request at mit.edu wrote:

> Message: 1
> Date: Fri, 13 Feb 2009 10:17:44 -0700
> From: "Glenn Machin" <gmachin at sandia.gov>
> Subject: Does the development team have recommendation on pam_krb5?
> To: "'krbdev at mit.edu'" <krbdev at mit.edu>
> Message-ID: <4995AB38.2080506 at sandia.gov>
> Content-Type: text/plain; charset=iso-8859-1; format=flowed
>
> From what I can tell there are 2 sources for pam_krb5.
>
> It is my understanding that Fedora/RedHat uses 2.2/2.3 version while
> Solaris 10, Ubunto/Debian use 3.X version maintained by Russ Allbery.
> From what I can tell they are divergent code branches.
>
> The 3.X version has some features that I don't see in the FC 2.3
> versions such as :
> http://www.eyrie.org/~eagle/software/pam-krb5/readme.html
>
>
>   1. PKINIT support
>   2. Kerberos principal name mapping:
>          * alt_auth_map,only_alt_auth
>          * expose_account
>          * search_k5login
>
>
> We have an environment where users are from multiple trusted realms so
> mapping is a necessity and in the future we will be using HSPD 12 PIV
> badges for authentication where PKINIT is important.
>
>
> So does the MIT development team have a pam_krb5 recommendation?
>
> Does anyone know if the Fedora/RH distribution will have these  
> features
> in the future?
>
>
> Finally is anyone working on plugin-in for krb5_aname_to_localname()?
> It would be nice to use LDAP  to obtain the mapping information.   The
> information is available in Active Directory through the
> altSecurityIdentities and it looks like the NFS4 work and University  
> of
> Michigan CITI,  idmapd.conf uses the LDAP attribute GSSAuthName.
>
>
> Thanks,
>
>    Glenn

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




From tlyu at MIT.EDU  Thu Feb 19 17:11:29 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Thu, 19 Feb 2009 17:11:29 -0500
Subject: minimum python version for test suite?
In-Reply-To: <1234366790.3787.129.camel@localhost.localdomain> (Simo Sorce's
	message of "Wed, 11 Feb 2009 10:39:50 -0500")
References: <ldv7i3xbrm9.fsf@cathode-dark-space.mit.edu>
	<1234366790.3787.129.camel@localhost.localdomain>
Message-ID: <ldvy6w2axgu.fsf@cathode-dark-space.mit.edu>

Simo Sorce <ssorce at redhat.com> writes:

> On Tue, 2009-02-10 at 22:05 -0500, Tom Yu wrote:
>> We are considering using Python in some portions of our test suite.
>> It appears that some operating systems ship with 2.5, but some
>> slightly older ones ship with 2.3.  Apparently certain desirable
>> language features are available on 2.5 that are not available on 2.3.
>> 
>> If you are inclined to run our test suite, what versions of Python do
>> you find to be readily available on their operating systems of choice?
>> Do you find that installing a version of Python that is newer than the
>> OS-provided version to be problematic?  What do you consider to be a
>> reasonable minimum required version of Python for our test suite?
>
> I think it depends on what about the tests are related to.
> If their main aim is to verify regressions at development time you can
> certainly be a little bit more aggressive and shoot for 2.5 (or even
> 2.6).

The main aim would be using Python in regression tests intended for
developers.

> If the aim is to have automated test running as part of the build
> process to validate the bits then trying to be conservative will help
> quite a lot given build systems often rely on what is supported in the
> current OS you are building on and adding different software is cause of
> concern as it may invalidate other assumptions of the build system.

By "validation", do you mean an acceptance test for a just-built
distribution?  We currently do not have a distinct set of tests meant
as an acceptance test.  Do builders currently use our "make check"
test suite as an acceptance test?

From hotz at jpl.nasa.gov  Fri Feb 20 14:18:40 2009
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Fri, 20 Feb 2009 11:18:40 -0800
Subject: minimum python version for test suite?
In-Reply-To: <mailman.573.1235150283.3158.krbdev@mit.edu>
References: <mailman.573.1235150283.3158.krbdev@mit.edu>
Message-ID: <D67431A6-FE94-4465-9D52-C2254C7A1849@jpl.nasa.gov>


On Feb 20, 2009, at 9:18 AM, krbdev-request at mit.edu wrote:

> Do builders currently use our "make check"
> test suite as an acceptance test?


s/MIT/Heimdal/; yes (where it isn't the checks themselves that are at  
fault).
------------------------------------------------------
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 nikhilm at gs-lab.com  Tue Feb 24 05:39:32 2009
From: nikhilm at gs-lab.com (Nikhil Mishra)
Date: Tue, 24 Feb 2009 16:09:32 +0530
Subject: authentic man in the middle
Message-ID: <49A3CE64.4020804@gs-lab.com>

Hi All,

We have an issue with generating a valid keytab for windows based
services which can be used on unix based machines to decrypt AP-REQ.
I understand this issue is more on windows side but since I am trying
to implement sort of man in the middle on MIT kerberos I think 
someone could lend me some helping hand here.Any related references
might also do some good to me.-

 
Following is our setup :

1. Windows XP cifs client
2. Windows 2003 KDC and domain controller 64 bit
3. Windows XP cifs server 64 bit.
4. Linux FC7 machine with MIT kerberos 1.6.3

We have the admin privileges for all the machines mentioned above.

What we are trying to do ?

1. We request a kerberized traffic from cifs client to cifs server
    which we want to route through linux box.

2. We want to do some processing with the AP-REQ.  Evidently  for
    which we need to authenticate the client in AP_REQ on linux machine.

3. Now to authenticate the client in AP-REQ on linux machine we
    propose to use GSSAPI calls using corresponding service keytab.

The problem :

1. Our understanding is, all windows based services are registered
    under corresponding computer name with their corresponding SPN.

2. This registration occurs whenever the machine joins the domain. So
    basically , whenever the  server is up and running and is in domain
    all its services are registered with windows domain controller and
    are mapped to its computer name.

3. The exchange of long term keys for service between service and KDC
    occurs at the same time.

4. We understand the definition of ktpass is "To generate keytab for
    UNIX based services " but with no other option to generate a keytab,
    we run ktpass for this windows based service which creates a new
    long term service key for the service which  is not communicated back
    to service.
 
    When I use this keytab on linux machine through GSSAPI calls to
    decrypt the AP-REQ , I get KRB5KRB_AP_ERR_BAD_INTEGRITY.
   
    which is obvious since key used by KDC to encrypt the ticket for
    service is different(Its the old key ) than what is in keytab.

Questions :

1. Is there a way to bring KDC and  service in sync in terms of the
    service key being used ? To be more precise , If I change the
    service key for a service at KDC Is there a way to communicate 
    this back to service so that the service starts using this new key
    for all further requests ?

2. We understand ktpass is a tool to generate a keytab for unix based
   services. Do we have any similar tool for windows based services ?

3. Since windows based service SPN's are registered under computer name
    at the time of logon It can be mapped to some other user as well without
    creating a duplicate SPN. Is it possible for a service to run under
    a user account and obtain a service key in windows ?

4. We understand "man in the middle" is not possible with kerberos but 
   when we own all components of traffic ( KDC , server , client , DC 
   with admin privileges ) should't I be allowed to extract a service key
   for the given SPN from KDC without disturbing the existing setup ? 

Any help is deeply appreciated.

Thanks & Regards

Nikhil



From jaltman at secure-endpoints.com  Tue Feb 24 11:55:19 2009
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Tue, 24 Feb 2009 11:55:19 -0500
Subject: authentic man in the middle
In-Reply-To: <49A3CE64.4020804@gs-lab.com>
References: <49A3CE64.4020804@gs-lab.com>
Message-ID: <49A42677.5060601@secure-endpoints.com>

Nikhil:

The problem you are facing is that you do not control the
key management of the Windows Domain.  Windows services
do not use fixed keys.  They use long term passwords that
are assigned to each account and which are then used with
the necessary enc-type and service principal name to compute
the appropriate key on-the-fly.  This permits an account to
have multiple names all of which do not need to be known
at account registration time.  For example, a mobile machine
that obtains a different hostname at each boot and registers
it with dynamic dns which in turn updates the machine's
entry in the active directory.

The passwords are also periodically updated.  Therefore,
even if you were to extract the machine's password from
the registry its lifetime would be limited.  You would
have to do it again whenever the password was replaced.

As a side note, this discussion really has nothing to do
with the development of MIT Kerberos.  Therefore, it is
my opinion that it should be held either on the kerberos at mit.edu
mailing list or one of the Windows Security Groups.

Jeffrey Altman
Secure Endpoints Inc.

Nikhil Mishra wrote:
> Hi All,
> 
> We have an issue with generating a valid keytab for windows based
> services which can be used on unix based machines to decrypt AP-REQ.
> I understand this issue is more on windows side but since I am trying
> to implement sort of man in the middle on MIT kerberos I think 
> someone could lend me some helping hand here.Any related references
> might also do some good to me.-
> 
>  
> Following is our setup :
> 
> 1. Windows XP cifs client
> 2. Windows 2003 KDC and domain controller 64 bit
> 3. Windows XP cifs server 64 bit.
> 4. Linux FC7 machine with MIT kerberos 1.6.3
> 
> We have the admin privileges for all the machines mentioned above.
> 
> What we are trying to do ?
> 
> 1. We request a kerberized traffic from cifs client to cifs server
>     which we want to route through linux box.
> 
> 2. We want to do some processing with the AP-REQ.  Evidently  for
>     which we need to authenticate the client in AP_REQ on linux machine.
> 
> 3. Now to authenticate the client in AP-REQ on linux machine we
>     propose to use GSSAPI calls using corresponding service keytab.
> 
> The problem :
> 
> 1. Our understanding is, all windows based services are registered
>     under corresponding computer name with their corresponding SPN.
> 
> 2. This registration occurs whenever the machine joins the domain. So
>     basically , whenever the  server is up and running and is in domain
>     all its services are registered with windows domain controller and
>     are mapped to its computer name.
> 
> 3. The exchange of long term keys for service between service and KDC
>     occurs at the same time.
> 
> 4. We understand the definition of ktpass is "To generate keytab for
>     UNIX based services " but with no other option to generate a keytab,
>     we run ktpass for this windows based service which creates a new
>     long term service key for the service which  is not communicated back
>     to service.
>  
>     When I use this keytab on linux machine through GSSAPI calls to
>     decrypt the AP-REQ , I get KRB5KRB_AP_ERR_BAD_INTEGRITY.
>    
>     which is obvious since key used by KDC to encrypt the ticket for
>     service is different(Its the old key ) than what is in keytab.
> 
> Questions :
> 
> 1. Is there a way to bring KDC and  service in sync in terms of the
>     service key being used ? To be more precise , If I change the
>     service key for a service at KDC Is there a way to communicate 
>     this back to service so that the service starts using this new key
>     for all further requests ?
> 
> 2. We understand ktpass is a tool to generate a keytab for unix based
>    services. Do we have any similar tool for windows based services ?
> 
> 3. Since windows based service SPN's are registered under computer name
>     at the time of logon It can be mapped to some other user as well without
>     creating a duplicate SPN. Is it possible for a service to run under
>     a user account and obtain a service key in windows ?
> 
> 4. We understand "man in the middle" is not possible with kerberos but 
>    when we own all components of traffic ( KDC , server , client , DC 
>    with admin privileges ) should't I be allowed to extract a service key
>    for the given SPN from KDC without disturbing the existing setup ? 
> 
> Any help is deeply appreciated.
> 
> Thanks & Regards
> 
> Nikhil
> 
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090224/f1b80f95/smime.bin

From nikhilm at gs-lab.com  Tue Feb 24 12:56:00 2009
From: nikhilm at gs-lab.com (Nikhil Mishra)
Date: Tue, 24 Feb 2009 23:26:00 +0530
Subject: tkt->client must be equal to in_cred->client
Message-ID: <49A434B0.5000006@gs-lab.com>

Hi All ,

I have been working on developing client support for MS S4U
extensions in  MIT kerberos .

There are couple of things that I think is worth putting forward and
then I will follow up my questions :

1. I am calling standard krb5_get_credentials() for doing a S4U2self .
    Now , S4U2self  requires three parameters .
        1.  TGT for process
        2.  Delegating SPN viz. service principal of the process .
        3.  Delegating UPN viz. Username/UPN on whose behalf
                this request is done .

  My understanding is in_cred parameter that is being passed to
    krb5_get_credentials should ideally have client as delegating UPN,
server as Delegating SPN .

This will create two problems :

1. To retrieve TGT for the process , we need a client UPN in
    krb5_get_cred_from_kdc_opt() .

    This we can resolve by calling krb5_cc_get_principal() and
    assigning it to client .

2. In krb5_get_cred_via_tkt() there is a strict checking
  
     /* tkt->client must be equal to in_cred->client */
    if (!krb5_principal_compare(context, tkt->client, in_cred->client))
        return KRB5_PRINC_NOMATCH;

    Why are we checking for this equality here ?

I am trying to push S4U feature in existing infrastructure and
that is why the issues .


Thanks & Regards

Nikhil


From nikhilm at gs-lab.com  Tue Feb 24 13:05:52 2009
From: nikhilm at gs-lab.com (Nikhil Mishra)
Date: Tue, 24 Feb 2009 23:35:52 +0530
Subject: authentic man in the middle
In-Reply-To: <49A42677.5060601@secure-endpoints.com>
References: <49A3CE64.4020804@gs-lab.com>
	<49A42677.5060601@secure-endpoints.com>
Message-ID: <49A43700.6040501@gs-lab.com>

Thanks Jeffrey.

I am fine with the limited lifetime part . I completely understand
the solution will be unstable enough to be useful. Nevertheless
I still need a tool to  retrieve long term service keys to  see
what is being said below is true .
 
I will move this discussion to kerberos at mit.edu.
My apologies for the trouble.

Thanks

Nikhil

Jeffrey Altman wrote:
> Nikhil:
>
> The problem you are facing is that you do not control the
> key management of the Windows Domain.  Windows services
> do not use fixed keys.  They use long term passwords that
> are assigned to each account and which are then used with
> the necessary enc-type and service principal name to compute
> the appropriate key on-the-fly.  This permits an account to
> have multiple names all of which do not need to be known
> at account registration time.  For example, a mobile machine
> that obtains a different hostname at each boot and registers
> it with dynamic dns which in turn updates the machine's
> entry in the active directory.
>
> The passwords are also periodically updated.  Therefore,
> even if you were to extract the machine's password from
> the registry its lifetime would be limited.  You would
> have to do it again whenever the password was replaced.
>
> As a side note, this discussion really has nothing to do
> with the development of MIT Kerberos.  Therefore, it is
> my opinion that it should be held either on the kerberos at mit.edu
> mailing list or one of the Windows Security Groups.
>
> Jeffrey Altman
> Secure Endpoints Inc.
>
> Nikhil Mishra wrote:
>   
>> Hi All,
>>
>> We have an issue with generating a valid keytab for windows based
>> services which can be used on unix based machines to decrypt AP-REQ.
>> I understand this issue is more on windows side but since I am trying
>> to implement sort of man in the middle on MIT kerberos I think 
>> someone could lend me some helping hand here.Any related references
>> might also do some good to me.-
>>
>>  
>> Following is our setup :
>>
>> 1. Windows XP cifs client
>> 2. Windows 2003 KDC and domain controller 64 bit
>> 3. Windows XP cifs server 64 bit.
>> 4. Linux FC7 machine with MIT kerberos 1.6.3
>>
>> We have the admin privileges for all the machines mentioned above.
>>
>> What we are trying to do ?
>>
>> 1. We request a kerberized traffic from cifs client to cifs server
>>     which we want to route through linux box.
>>
>> 2. We want to do some processing with the AP-REQ.  Evidently  for
>>     which we need to authenticate the client in AP_REQ on linux machine.
>>
>> 3. Now to authenticate the client in AP-REQ on linux machine we
>>     propose to use GSSAPI calls using corresponding service keytab.
>>
>> The problem :
>>
>> 1. Our understanding is, all windows based services are registered
>>     under corresponding computer name with their corresponding SPN.
>>
>> 2. This registration occurs whenever the machine joins the domain. So
>>     basically , whenever the  server is up and running and is in domain
>>     all its services are registered with windows domain controller and
>>     are mapped to its computer name.
>>
>> 3. The exchange of long term keys for service between service and KDC
>>     occurs at the same time.
>>
>> 4. We understand the definition of ktpass is "To generate keytab for
>>     UNIX based services " but with no other option to generate a keytab,
>>     we run ktpass for this windows based service which creates a new
>>     long term service key for the service which  is not communicated back
>>     to service.
>>  
>>     When I use this keytab on linux machine through GSSAPI calls to
>>     decrypt the AP-REQ , I get KRB5KRB_AP_ERR_BAD_INTEGRITY.
>>    
>>     which is obvious since key used by KDC to encrypt the ticket for
>>     service is different(Its the old key ) than what is in keytab.
>>
>> Questions :
>>
>> 1. Is there a way to bring KDC and  service in sync in terms of the
>>     service key being used ? To be more precise , If I change the
>>     service key for a service at KDC Is there a way to communicate 
>>     this back to service so that the service starts using this new key
>>     for all further requests ?
>>
>> 2. We understand ktpass is a tool to generate a keytab for unix based
>>    services. Do we have any similar tool for windows based services ?
>>
>> 3. Since windows based service SPN's are registered under computer name
>>     at the time of logon It can be mapped to some other user as well without
>>     creating a duplicate SPN. Is it possible for a service to run under
>>     a user account and obtain a service key in windows ?
>>
>> 4. We understand "man in the middle" is not possible with kerberos but 
>>    when we own all components of traffic ( KDC , server , client , DC 
>>    with admin privileges ) should't I be allowed to extract a service key
>>    for the given SPN from KDC without disturbing the existing setup ? 
>>
>> Any help is deeply appreciated.
>>
>> Thanks & Regards
>>
>> Nikhil
>>
>>
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>
>>     


From hartmans at MIT.EDU  Wed Feb 25 09:45:18 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 25 Feb 2009 09:45:18 -0500
Subject: tkt->client must be equal to in_cred->client
In-Reply-To: <49A434B0.5000006@gs-lab.com> (Nikhil Mishra's message of "Tue,
	24 Feb 2009 23:26:00 +0530")
References: <49A434B0.5000006@gs-lab.com>
Message-ID: <tslwsbey3r5.fsf@mit.edu>

>>>>> "Nikhil" == Nikhil Mishra <nikhilm at gs-lab.com> writes:

    Nikhil> Hi All , I have been working on developing client support
    Nikhil> for MS S4U extensions in MIT kerberos .

I'd really recommend you sit down and do a project writeup on
k5wiki.kerberos.org; you should have access there.

I think it would be a lot easier for me to evaluate what you're doing
with a reasonably complete design layed out rather than one chunk at a
time.

For example it is not obvious to me that krb5_get_credentials is the
right place to do this.  Unfortunately, krb5_get_credentials is not a
very extensible API.  the credentials structure is public so it cannot
change.  It may well be that when you think through all the options,
this is the best choice; I expect you've thought through these issues,
but the rest of us have not, and as a result have trouble following
you.

    Nikhil> 2. In krb5_get_cred_via_tkt() there is a strict checking
  
    Nikhil>      /* tkt->client must be equal to in_cred->client */ if
    Nikhil> (!krb5_principal_compare(context, tkt->client,
    Nikhil> in_cred->client)) return KRB5_PRINC_NOMATCH;

    Nikhil>     Why are we checking for this equality here ?


As best I can tell, it's a local sanity check. in_cred->client is the
client identity on whose behalf you're getting a ticket.  In the
Kerberos protocol without SX4U that identity only appears in the
ticket.  So if that check is not present, the API effectively has a
client parameter that is never actually checked.

I think relaxing the check in the SX4U case would be reasonable.

Since krb5_get_cred_via_tkt is an internal API, it might also be
reasonable to move the check into its callers if they are in a better
position to know whether SX4U is happening.

--Sam


From hartmans at MIT.EDU  Thu Feb 26 15:09:37 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Thu, 26 Feb 2009 15:09:37 -0500
Subject: Ticket 6400: krb5_merge_authdata
Message-ID: <tslbpspt0xq.fsf@mit.edu>



I'd like to draw your attention to ticket 6400 which introduces a new
public API: krb5_merge_authdata.

There are a number of cases we've seen in the KDC where you want to
combine two authdata sequences.  This also comes up in the library
because you'd like to get the authdata both from the ticket and
authenticator.

I've introduced this API because I needed something like it to resolve
a GSS-API bug.  I have not removed the similar private API from the
guts of the KDC introduced by Luke's changes.

--Sam


From nikhilm at gs-lab.com  Thu Feb 26 07:21:21 2009
From: nikhilm at gs-lab.com (Nikhil Mishra)
Date: Thu, 26 Feb 2009 17:51:21 +0530
Subject: man in the middle on MIT kerberos  
Message-ID: <49A68941.10304@gs-lab.com>

Hi All ,

I have been trying to do this for a long time but to no rescue
and so I will put it simply now.
 
Is it possible to create a man in the middle in a kerberos environment , If
I own admin privileges in all components of the traffic i.e ( windows
KDC , windows based application , windows based client ) ?

I have a linux box which I want to behave as man in the middle so
basically I want to be able to decrypt AP-REQ from client .

I have tried all kinds of ways but everything boils down to one thing
that is getting an authentic keytab from windows KDC for the application.
There isn't one utility which does this for a windows based service , at
least
all I know of including ktpass .

Is this possible or have I been chasing a wild goose ?


Regards

Nikhil

From paul.moore at centrify.com  Fri Feb 27 14:08:02 2009
From: paul.moore at centrify.com (Paul Moore)
Date: Fri, 27 Feb 2009 11:08:02 -0800
Subject: man in the middle on MIT kerberos  
In-Reply-To: <49A68941.10304@gs-lab.com>
References: <49A68941.10304@gs-lab.com>
Message-ID: <BB7E16A14DE689469A181EC770AFBF4D02C5C052@exch-one.centrify.com>

my question would be - what are you trying to do?
Maybe you need delegation and forwarding rather than man in the middle

you need the target servers password hash
AD knows this - you can get at this data with pwdumpn (n=1,2,3,4,5,6)
(warning - heavy lifting)
The target server knows this too - u can probably attack it in the same
way


-----Original Message-----
From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf
Of Nikhil Mishra
Sent: Thursday, February 26, 2009 4:21 AM
To: krbdev at mit.edu
Subject: man in the middle on MIT kerberos 

Hi All ,

I have been trying to do this for a long time but to no rescue
and so I will put it simply now.
 
Is it possible to create a man in the middle in a kerberos environment ,
If
I own admin privileges in all components of the traffic i.e ( windows
KDC , windows based application , windows based client ) ?

I have a linux box which I want to behave as man in the middle so
basically I want to be able to decrypt AP-REQ from client .

I have tried all kinds of ways but everything boils down to one thing
that is getting an authentic keytab from windows KDC for the
application.
There isn't one utility which does this for a windows based service , at
least
all I know of including ktpass .

Is this possible or have I been chasing a wild goose ?


Regards

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


From hartmans at MIT.EDU  Fri Feb 27 14:07:56 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Fri, 27 Feb 2009 14:07:56 -0500
Subject: man in the middle on MIT kerberos
In-Reply-To: <49A68941.10304@gs-lab.com> (Nikhil Mishra's message of "Thu, 26
	Feb 2009 17:51:21 +0530")
References: <49A68941.10304@gs-lab.com>
Message-ID: <tslhc2fofzn.fsf@mit.edu>

>>>>> "Nikhil" == Nikhil Mishra <nikhilm at gs-lab.com> writes:

    Nikhil> Hi All , I have been trying to do this for a long time but
    Nikhil> to no rescue and so I will put it simply now.
 
    Nikhil> Is it possible to create a man in the middle in a kerberos
    Nikhil> environment , If I own admin privileges in all components
    Nikhil> of the traffic i.e ( windows KDC , windows based
    Nikhil> application , windows based client ) ?

Yes.

I think what you want to do is figure out how to extract (or set
yourselfL) the password for the windows service in AD and then use
ktutil to construct the keytab.  ktpass seems to hurt people more than
it helps.

I don't know enough about AD internals to know how you should extract
the password.  I'll also note that you need to be aware of the concern
that Jeff Altman raised: the password will periodically be updated and
you'll have to deal with that.

--Sam


From Nicolas.Williams at sun.com  Fri Feb 27 14:42:59 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 27 Feb 2009 13:42:59 -0600
Subject: man in the middle on MIT kerberos
In-Reply-To: <49A68941.10304@gs-lab.com>
References: <49A68941.10304@gs-lab.com>
Message-ID: <20090227194258.GC9992@Sun.COM>

On Thu, Feb 26, 2009 at 05:51:21PM +0530, Nikhil Mishra wrote:
> Is it possible to create a man in the middle in a kerberos environment , If
> I own admin privileges in all components of the traffic i.e ( windows
> KDC , windows based application , windows based client ) ?

In any trusted third party protocol, such as Kerberos and PKI, the
trusted third party can generally mount MITM attacks.  In PKI the
trusted third party (the CA) can do it by issuing certs with which it
can impersonate principals to which it has issued certs.  In Kerberos
the trusted third party (the KDC) can decrypt any ticket.  (More or
less; I'm making some simplifying assumptions here.)

From deengert at anl.gov  Fri Feb 27 15:35:22 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Fri, 27 Feb 2009 14:35:22 -0600
Subject: man in the middle on MIT kerberos
In-Reply-To: <49A68941.10304@gs-lab.com>
References: <49A68941.10304@gs-lab.com>
Message-ID: <49A84E8A.4070100@anl.gov>



Nikhil Mishra wrote:
> Hi All ,
> 
> I have been trying to do this for a long time but to no rescue
> and so I will put it simply now.
>  
> Is it possible to create a man in the middle in a kerberos environment , If
> I own admin privileges in all components of the traffic i.e ( windows
> KDC , windows based application , windows based client ) ?
> 
> I have a linux box which I want to behave as man in the middle so
> basically I want to be able to decrypt AP-REQ from client .

You might want start here for W2K:
http://support.microsoft.com/kb/260575
and for W2003:
http://support.microsoft.com/kb/325850


It lets the admin reset the machine password and the password in AD.
It look like you can specify the password which you could then use with
kt_util or maybe ktpass to create a keytab.


> 
> I have tried all kinds of ways but everything boils down to one thing
> that is getting an authentic keytab from windows KDC for the application.
> There isn't one utility which does this for a windows based service , at
> least
> all I know of including ktpass .
> 
> Is this possible or have I been chasing a wild goose ?
> 
> 
> Regards
> 
> Nikhil
> _______________________________________________
> 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 Volker.Lendecke at SerNet.DE  Fri Feb 27 14:27:14 2009
From: Volker.Lendecke at SerNet.DE (Volker Lendecke)
Date: Fri, 27 Feb 2009 20:27:14 +0100
Subject: man in the middle on MIT kerberos
In-Reply-To: <BB7E16A14DE689469A181EC770AFBF4D02C5C052@exch-one.centrify.com>
References: <49A68941.10304@gs-lab.com>
	<BB7E16A14DE689469A181EC770AFBF4D02C5C052@exch-one.centrify.com>
Message-ID: <E1Ld8Gp-00Gt4s-8I@intern.SerNet.DE>

On Fri, Feb 27, 2009 at 11:08:02AM -0800, Paul Moore wrote:
> my question would be - what are you trying to do?
> Maybe you need delegation and forwarding rather than man in the middle
> 
> you need the target servers password hash
> AD knows this - you can get at this data with pwdumpn (n=1,2,3,4,5,6)
> (warning - heavy lifting)
> The target server knows this too - u can probably attack it in the same
> way

Newer Samba "net rpc vampire" tools can extract the server
hashes from AD.

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