From jason.gerfen at scl.utah.edu  Wed Jul  1 12:49:53 2009
From: jason.gerfen at scl.utah.edu (Jason Gerfen)
Date: Wed, 01 Jul 2009 10:49:53 -0600
Subject: ldap options in krb5.conf and api?
Message-ID: <4A4B93B1.6090403@scl.utah.edu>

I am looking at some of the function calls within the kdb_ldap.c
(krb5_read_startup_information, krb5_ldap_get_db_opt, etc) and would
like to possibly obtain more information on the proper usage and order
of usage of these when linking against the krb5 libs. Thanks.
-- 
Jas

From atjshadow at gmail.com  Tue Jul  7 00:35:04 2009
From: atjshadow at gmail.com (=?GB2312?B?u8ax8w==?=)
Date: Tue, 7 Jul 2009 12:35:04 +0800
Subject: I have a question
Message-ID: <416daba80907062135p2c509446vd44ac5e382ec6b68@mail.gmail.com>

hello:
  I am reading the source code now ,I have a question.
where can I find the data definition?such as krb5_kdc_rep,I want to know
what  contains in it.
I can not understand the meaning of the data.Would you tell me where can i
find the definition?
  thanks

From Glenn.Barry at sun.com  Tue Jul  7 04:19:30 2009
From: Glenn.Barry at sun.com (Glenn Barry)
Date: Tue, 07 Jul 2009 01:19:30 -0700
Subject: PAC API and PAC_LOGON_INFO?
Message-ID: <4A530512.1090406@sun.com>


We've been experimenting with the new PAC API in 1.7 and noticed most
of the API is in krb5.h but the ulType constants are still in pac.c.

For example, we've needed to use PAC_LOGON_INFO like so

         krb5err = krb5_pac_get_buffer(krb5ctx, pac, PAC_LOGON_INFO,
                    &pac_logon_info);

So seems like PAC_LOGON_INFO should also be in krb5.h and be part of
the official krb5 API?

And if so, does the same go for the other ulType constants?

thx...glenn


From hartmans at MIT.EDU  Tue Jul  7 12:59:15 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 07 Jul 2009 12:59:15 -0400
Subject: PAC API and PAC_LOGON_INFO?
In-Reply-To: <4A530512.1090406@sun.com> (Glenn Barry's message of "Tue\,
	07 Jul 2009 01\:19\:30 -0700")
References: <4A530512.1090406@sun.com>
Message-ID: <tslzlbg1lb0.fsf@mit.edu>

Well, the PAC buffer type constants seem like they are an MS technical specification issue rather than an MIT Kerberos API issue.

I don't object to MIT exposing constants for this in krb5.h, although
I'd recommend a prefix including both KRB5 and MS.  Something like KRB5_MS_PAC.  Actually I can see an argument that MS should not be included.

From Nicolas.Williams at sun.com  Tue Jul  7 13:11:55 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 7 Jul 2009 12:11:55 -0500
Subject: PAC API and PAC_LOGON_INFO?
In-Reply-To: <tslzlbg1lb0.fsf@mit.edu>
References: <4A530512.1090406@sun.com> <tslzlbg1lb0.fsf@mit.edu>
Message-ID: <20090707171154.GK15302@Sun.COM>

On Tue, Jul 07, 2009 at 12:59:15PM -0400, Sam Hartman wrote:
> Well, the PAC buffer type constants seem like they are an MS technical
> specification issue rather than an MIT Kerberos API issue.
> 
> I don't object to MIT exposing constants for this in krb5.h, although
> I'd recommend a prefix including both KRB5 and MS.  Something like
> KRB5_MS_PAC.  Actually I can see an argument that MS should not be
> included.

Perhaps such symbols and constants should be in a separate header so as
to underscore the fact that they come from a different namespace
authority.  The authority needs a name that you can put into the symbol
names, and I don't care what that is, as long as it's sufficiently
mnemonic or descriptive.

Nico
-- 

From dtodd at irobot.com  Tue Jul  7 16:35:00 2009
From: dtodd at irobot.com (Todd, David)
Date: Tue, 07 Jul 2009 16:35:00 -0400
Subject: The joys of ActiveDirectory and Kerberized SSH
In-Reply-To: <ldvvdmdc3f4.fsf@cathode-dark-space.mit.edu>
Message-ID: <C67929B4.335F7%dtodd@irobot.com>

On 6/30/09 8:27 , "Tom Yu" <tlyu at MIT.EDU> wrote:


> 
> Are you sure this isn't "host/hq-svn" or "host/" followed by the
> fully-qualified domain name of "hq-svn"?
> 

Yeah, it looks like host/FQDN

> 
> I would like to know more details about the "AD server giving back
> more than one answer" situation.  How did you determine this, and what
> different answers was it giving back?
> 

To be honest, this was a supposition based on discovering that there were
multiple entries for the same Service Principal name, and that getting rid
of the excess entries corrected the problem.

I had to slog through the Windows server logs to discover AD complaining,
and then found the entries with the LDP tool, though I'm guessing it could
have been discovered with ldapsearch or some such.


> 
> Ubuntu 8.04 uses krb5-1.6.3.  The recent krb5-1.7 release has many
> enhancements, which include providing extended error information
> strings in more places, including in the situation you describe.
> There is also a patch queued for the upcoming krb5-1.6.4 maintenance
> release to add that extended error reporting information.

I will value this highly.
> 

> 
> Thanks for letting us know.  We have been working on improving our
> error reporting for some time now, mostly by adding extended error
> information to places where the existing fixed strings provide
> insufficient information.  Having additional reports like yours can
> help us with that effort.

Glad to help. It's a good mechanism, I'd like it to continue to be so.


From ahmar_nauman at hotmail.com  Fri Jul 10 10:38:50 2009
From: ahmar_nauman at hotmail.com (Ahmar Nauman)
Date: Fri, 10 Jul 2009 20:38:50 +0600
Subject: windows 2003 domain controller, mod_auth_kerb in linux, issue with
	kerberos
Message-ID: <COL120-W63ACF8276FA7A8196DB1E4FF270@phx.gbl>


Hi,
 I'm using windows server 2003 as domain controller, 
i've succesfully followed all the necessary steps required for setting up an SSO, generated keytab files which gives me correct info if i type klist -k , integrated mod_auth_kerb and configured machines.
My browser setting are just fine as well, 



My httpd.conf is like
<Location /myURL>
  AuthType Kerberos
  AuthName "Test Kerberos Login"
  KrbVerifyKDC off # it doesn't work if i remove this line
  KrbMethodNegotiate On
  KrbMethodK5Passwd On
  KrbAuthRealms LAB1.DIGIDENT-SOLUTIONS.COM
  Krb5KeyTab /etc/krb5.keytab
  KrbSaveCredentials On
  KrbServiceName HTTP
 require valid-user
</Location>

Now when i tried to test from IE(v 6) it open a login box, if i supply username and password as setup in active directory, it allows me to enter. I dont want to get this login box, so if i change KrbMethodK5Passwd to Off, it simply refuses me to get in by Authorization Required message in browser and in apache logs, i get the following errors,

[Fri Jul 10 20:31:25 2009] [debug] src/mod_auth_kerb.c(1266): [client x.x.x.x] Verifying client data using KRB5 GSS-API
[Fri Jul 10 20:31:25 2009] [debug] src/mod_auth_kerb.c(1282): [client ......] Verification returned code 589824
[Fri Jul 10 20:31:25 2009] [debug] src/mod_auth_kerb.c(1309): [client ......] Warning: received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration.
[Fri Jul 10 20:31:25 2009] [error] [client ......9] gss_accept_sec_context() failed: Invalid token was supplied (No error)

I'm trying to resolve this issue, but nothing work out so far.  
Can anybody please help here??

regards
- Ahmar



_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us

From ghudson at MIT.EDU  Mon Jul 13 16:10:58 2009
From: ghudson at MIT.EDU (ghudson@MIT.EDU)
Date: Mon, 13 Jul 2009 16:10:58 -0400 (EDT)
Subject: krb5-appl status update
Message-ID: <200907132010.n6DKAwKb025184@outgoing.mit.edu>

For background, see:
http://mailman.mit.edu/pipermail/krbdev/2009-June/007721.html

The krb5-appl repository is now open for business.  If you are a krb5
commiter, please commit forward-looking application changes to
krb5-appl instead of krb5.  If they are bugfixes targeted for 1.7,
commit them to krb5 as well.

The new tree has a single unified configure.ac script, and uses a
header file for configuration instead of $(DEFS).  Due to the scope of
that change, there may be some portability regressions.  I am
currently testing the build on Solaris; it works fine on Ubuntu.

The tree is currently still using several un-prototyped libkrb5
interfaces (krb5_read_message, krb5_write_message, krb5_net_read, and
krb5_set_config_files).  We need to prototype these functions and
commit to their maintenance, stop using them in krb5-appl, or cheat
and prototype them in krb5-appl.  I plan to study the situation a bit
more and decide which is best.  The tree builds okay in spite of this
blemish, just with more warnings than usual.

On a related note, krb5-appl is currently relying on some functions in
libkrb5support for portability (e.g. krb5int_strlcpy).  This seems
unlikely to cause a problem since those interfaces are unlikely to
change.

The relevant parts of the dejagnu test suite exist in krb5-appl and
will execute under make check if you have "runtest" in your path.  The
tests pass for me on Ubuntu.  They do assume you have the krb5 daemons
installed (e.g. krb5kdc); it might be worth checking for that at
configure time.

For the moment, the project infrastructure is:

  * The same bug database as krb5 (krb5-appl queue)

  * The same dev mailing list as krb5 (krbdev).  This is subject to
    change if people maintaining krb5-appl don't want the traffic
    volume of the krbdev list.

  * A separate commit list (krb5-appl-commits).  We copied over the
    subscribers of the current krb5 commits list.

There is some information about project maintenance documented at:

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

From Glenn.Barry at sun.com  Tue Jul 14 19:24:38 2009
From: Glenn.Barry at sun.com (Glenn Barry)
Date: Tue, 14 Jul 2009 16:24:38 -0700
Subject: krb5_pac_verify and server key enctype extraction
Message-ID: <4A5D13B6.4090006@sun.com>



For our application to verify the PAC we're using

krb5_error_code KRB5_CALLCONV
krb5_pac_verify
(krb5_context context,
                const krb5_pac pac,
                krb5_timestamp authtime,
                krb5_const_principal principal,
                const krb5_keyblock *server,
                const krb5_keyblock *privsvr);

To get the server arg for krb5_pac_verify() from the local keytab,
we're using

krb5_error_code KRB5_CALLCONV krb5_kt_read_service_key
    (krb5_context,
        krb5_pointer,
        krb5_principal,
        krb5_kvno,
        krb5_enctype,
        krb5_keyblock **);

All looks good except we can't find a public GSS/krb5 API function to
get the enctype from the security context.  gss_inquire_context() and
gss_inquire_sec_context_by_oid() looked promising but don't appear to
have it.

We don't think we can glean the enctype from the PAC signature buffer
itself.

So looks like we need something analogous to
gsskrb5_extract_authz_data_from_sec_context() for tik enctype.

Thoughts?

Thanks...glenn


From lukeh at padl.com  Wed Jul 15 01:38:01 2009
From: lukeh at padl.com (Luke Howard)
Date: Wed, 15 Jul 2009 07:38:01 +0200
Subject: krb5_pac_verify and server key enctype extraction
In-Reply-To: <4A5D13B6.4090006@sun.com>
References: <4A5D13B6.4090006@sun.com>
Message-ID: <05B5918B-EE2B-40F9-B617-6928B4CFDACD@padl.com>

Glenn,

> All looks good except we can't find a public GSS/krb5 API function to
> get the enctype from the security context.  gss_inquire_context() and
> gss_inquire_sec_context_by_oid() looked promising but don't appear to
> have it.
>
> We don't think we can glean the enctype from the PAC signature buffer
> itself.

You can extract the session key with  
gss_inquire_sec_context_by_oid(GSS_C_INQ_SSPI_SESSION_KEY). The  
returned buffer set contains { session key, enctype OID } -- the  
integer enctype is the last element of the OID arc.

Does this help?

cheers,

-- luke

From ghudson at MIT.EDU  Wed Jul 15 11:46:38 2009
From: ghudson at MIT.EDU (ghudson@MIT.EDU)
Date: Wed, 15 Jul 2009 11:46:38 -0400 (EDT)
Subject: Crypto Modularity proj proposal
In-Reply-To: <6DAAB910-3AA0-485C-942A-7193B5DF67CB@mit.edu>
References: <6DAAB910-3AA0-485C-942A-7193B5DF67CB@mit.edu>
Message-ID: <200907151546.n6FFkcJq006136@outgoing.mit.edu>

> A new project proposal is posted on
> http://k5wiki.kerberos.org/wiki/Projects/Crypto_modularity to
> address Crypto Modularity of MIT Kerberos code.

I have shifted this from "early project" to "under review" status and
set a review end date of July 31.

I removed the part about overloading krb5_keyblock.  The remainder of
what's in there is relatively uncontroversial, I think, and
implementation can proceed in parallel with formal review.

We had some discussion about the 1.8 crypto project work yesterday and
decided to split it up into three ordered projects:

  1. Modularity (under review)
  2. Caching of key-derived data for performance
  3. Support for cryptographic modules (external keys)

I will be working on a project proposal for #2.  Following Nico's
idea, my plan is to introduce a new opaque type krb5_key, add crypto
APIs to use it, and use the krb5_key type in the (non-exposed)
gss-krb5 and krb5 security context structures.  Keyblocks in exposed
krb5 structures will be left alone, as it is not necessary to
associate cached information with those keyblocks for performance.

The other reasonable alternative I see is a lookaside table for
keyblocks, and I think it's more likely to result in long-term
maintenance issues than Nico's idea.  (For more background, refer to
http://mailman.mit.edu/pipermail/krbdev/2009-June/007780.html)

For #3, I anticipate we will reuse the krb5_key type and associated
crypto APIs added in #2; however, there will be additional
complications depending on what types of keys we support as external
references.

From Natalie.Li at Sun.COM  Wed Jul 15 12:21:07 2009
From: Natalie.Li at Sun.COM (Natalie Li)
Date: Wed, 15 Jul 2009 09:21:07 -0700
Subject: krb5_pac_verify and server key enctype extraction
In-Reply-To: <05B5918B-EE2B-40F9-B617-6928B4CFDACD@padl.com>
References: <4A5D13B6.4090006@sun.com>
	<05B5918B-EE2B-40F9-B617-6928B4CFDACD@padl.com>
Message-ID: <4A5E01F3.30803@Sun.COM>

Luke Howard wrote:
> Glenn,
>
>> All looks good except we can't find a public GSS/krb5 API function to
>> get the enctype from the security context. gss_inquire_context() and
>> gss_inquire_sec_context_by_oid() looked promising but don't appear to
>> have it.
>>
>> We don't think we can glean the enctype from the PAC signature buffer
>> itself.
>
> You can extract the session key with 
> gss_inquire_sec_context_by_oid(GSS_C_INQ_SSPI_SESSION_KEY). The 
> returned buffer set contains { session key, enctype OID } -- the 
> integer enctype is the last element of the OID arc.
>
> Does this help?
>
> cheers,
>
> -- luke
Just to clarify, we're interested in the enctype associated with the 
server's long-term key that was used to decrypt the krb ticket carried 
in the KRB_AP_REQ, not the session key. Do we have an API to extract 
that information from GSS context?

Thanks,

Natalie

From lukeh at padl.com  Thu Jul 16 02:02:27 2009
From: lukeh at padl.com (Luke Howard)
Date: Thu, 16 Jul 2009 08:02:27 +0200
Subject: krb5_pac_verify and server key enctype extraction
In-Reply-To: <4A5E01F3.30803@Sun.COM>
References: <4A5D13B6.4090006@sun.com>
	<05B5918B-EE2B-40F9-B617-6928B4CFDACD@padl.com>
	<4A5E01F3.30803@Sun.COM>
Message-ID: <38D16C49-7F9C-4463-BA08-3F9139F056CD@padl.com>

>>
> Just to clarify, we're interested in the enctype associated with the  
> server's long-term key that was used to decrypt the krb ticket  
> carried in the KRB_AP_REQ, not the session key. Do we have an API to  
> extract that information from GSS context?

Not that I'm aware of. You can enumerate the keytab, looking for a key  
with a mandatory checksum type that matches that in the PAC.

-- Luke

From hartmans at MIT.EDU  Fri Jul 17 13:30:06 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Fri, 17 Jul 2009 13:30:06 -0400
Subject: krb5_pac_verify and server key enctype extraction
In-Reply-To: <38D16C49-7F9C-4463-BA08-3F9139F056CD@padl.com> (Luke Howard's
	message of "Thu\, 16 Jul 2009 08\:02\:27 +0200")
References: <4A5D13B6.4090006@sun.com>
	<05B5918B-EE2B-40F9-B617-6928B4CFDACD@padl.com>
	<4A5E01F3.30803@Sun.COM>
	<38D16C49-7F9C-4463-BA08-3F9139F056CD@padl.com>
Message-ID: <tslr5wfw735.fsf@mit.edu>

I think we may want an interface to expose a verified PAC for 1.8.
Possibly something at least nominally compatible with the naming work
going on in kitten or that can be extended to that interface.  I'm
definitely not talking about name attributes for each pac subfield,
simply one attribute for the verified pac as a whole, which is not
present if the pac fails to verify.


From jaltman at secure-endpoints.com  Sun Jul 19 11:35:52 2009
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Sun, 19 Jul 2009 11:35:52 -0400
Subject: krb5-appl status update
In-Reply-To: <200907132010.n6DKAwKb025184@outgoing.mit.edu>
References: <200907132010.n6DKAwKb025184@outgoing.mit.edu>
Message-ID: <4A633D58.9050004@secure-endpoints.com>

ghudson at mit.edu wrote:

> The tree is currently still using several un-prototyped libkrb5
> interfaces (krb5_read_message, krb5_write_message, krb5_net_read, and
> krb5_set_config_files).  We need to prototype these functions and
> commit to their maintenance, stop using them in krb5-appl, or cheat
> and prototype them in krb5-appl.  I plan to study the situation a bit
> more and decide which is best.  The tree builds okay in spite of this
> blemish, just with more warnings than usual.
> 
> On a related note, krb5-appl is currently relying on some functions in
> libkrb5support for portability (e.g. krb5int_strlcpy).  This seems
> unlikely to cause a problem since those interfaces are unlikely to
> change.

the krb5_read_message, krb5_write_message, krb5_net_read, ... are helper
functions in the krb5 library that should only be (in my opinion) used
within the krb5 library.  Applications that wish to have access to
similar functionality should define their own similar functions.
These functions and missing portability functions such as strlcpy should
be defined in an apputil library that is statically linked to the
various apps in the krb5-appl tree.

Just my two cents.

Jeffrey Altman


From Natalie.Li at Sun.COM  Mon Jul 20 11:41:49 2009
From: Natalie.Li at Sun.COM (Natalie Li)
Date: Mon, 20 Jul 2009 08:41:49 -0700
Subject: krb5_pac_verify and server key enctype extraction
In-Reply-To: <38D16C49-7F9C-4463-BA08-3F9139F056CD@padl.com>
References: <4A5D13B6.4090006@sun.com>
	<05B5918B-EE2B-40F9-B617-6928B4CFDACD@padl.com>
	<4A5E01F3.30803@Sun.COM>
	<38D16C49-7F9C-4463-BA08-3F9139F056CD@padl.com>
Message-ID: <4A64903D.1040402@Sun.COM>

Luke Howard wrote:
>>>
>> Just to clarify, we're interested in the enctype associated with the 
>> server's long-term key that was used to decrypt the krb ticket 
>> carried in the KRB_AP_REQ, not the session key. Do we have an API to 
>> extract that information from GSS context?
>
> Not that I'm aware of. You can enumerate the keytab, looking for a key 
> with a mandatory checksum type that matches that in the PAC.
>
> -- Luke
Yes, we do something similar to your above suggestion for now. Thanks 
for confirming that there isn't any API for extracting tik enctype.

Thanks,

Natalie


From Natalie.Li at Sun.COM  Mon Jul 20 11:53:58 2009
From: Natalie.Li at Sun.COM (Natalie Li)
Date: Mon, 20 Jul 2009 08:53:58 -0700
Subject: krb5_pac_verify and server key enctype extraction
In-Reply-To: <tslr5wfw735.fsf@mit.edu>
References: <4A5D13B6.4090006@sun.com>
	<05B5918B-EE2B-40F9-B617-6928B4CFDACD@padl.com>
	<4A5E01F3.30803@Sun.COM>
	<38D16C49-7F9C-4463-BA08-3F9139F056CD@padl.com>
	<tslr5wfw735.fsf@mit.edu>
Message-ID: <4A649316.5090402@Sun.COM>

Sam Hartman wrote:
> I think we may want an interface to expose a verified PAC for 1.8.
> Possibly something at least nominally compatible with the naming work
> going on in kitten or that can be extended to that interface.  I'm
> definitely not talking about name attributes for each pac subfield,
> simply one attribute for the verified pac as a whole, which is not
> present if the pac fails to verify.
>
>   
That's a good idea. I believe the acceptor should compute and verify the 
PAC checksum as part of the KRB_AP_REQ handling. The application 
shouldn't have to worry about PAC verification.
Has that be worked on? How can I track that work?

Thanks,

Natalie

From lukeh at padl.com  Mon Jul 20 12:03:19 2009
From: lukeh at padl.com (Luke Howard)
Date: Mon, 20 Jul 2009 18:03:19 +0200
Subject: krb5_pac_verify and server key enctype extraction
In-Reply-To: <4A64903D.1040402@Sun.COM>
References: <4A5D13B6.4090006@sun.com>
	<05B5918B-EE2B-40F9-B617-6928B4CFDACD@padl.com>
	<4A5E01F3.30803@Sun.COM>
	<38D16C49-7F9C-4463-BA08-3F9139F056CD@padl.com>
	<4A64903D.1040402@Sun.COM>
Message-ID: <B862F448-4476-45CC-96B0-334A3C3CAD3F@padl.com>


On 20/07/2009, at 5:41 PM, Natalie Li wrote:

> Luke Howard wrote:
>>>>
>>> Just to clarify, we're interested in the enctype associated with  
>>> the server's long-term key that was used to decrypt the krb ticket  
>>> carried in the KRB_AP_REQ, not the session key. Do we have an API  
>>> to extract that information from GSS context?
>>
>> Not that I'm aware of. You can enumerate the keytab, looking for a  
>> key with a mandatory checksum type that matches that in the PAC.
>>
>> -- Luke
> Yes, we do something similar to your above suggestion for now.  
> Thanks for confirming that there isn't any API for extracting tik  
> enctype.

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

-- Luke

From lukeh at padl.com  Mon Jul 20 12:09:19 2009
From: lukeh at padl.com (Luke Howard)
Date: Mon, 20 Jul 2009 18:09:19 +0200
Subject: krb5_pac_verify and server key enctype extraction
In-Reply-To: <4A649316.5090402@Sun.COM>
References: <4A5D13B6.4090006@sun.com>
	<05B5918B-EE2B-40F9-B617-6928B4CFDACD@padl.com>
	<4A5E01F3.30803@Sun.COM>
	<38D16C49-7F9C-4463-BA08-3F9139F056CD@padl.com>
	<tslr5wfw735.fsf@mit.edu> <4A649316.5090402@Sun.COM>
Message-ID: <8377C9E5-B035-44A3-942D-3B7107939B8E@padl.com>


On 20/07/2009, at 5:53 PM, Natalie Li wrote:

> Sam Hartman wrote:
>> I think we may want an interface to expose a verified PAC for 1.8.
>> Possibly something at least nominally compatible with the naming work
>> going on in kitten or that can be extended to that interface.  I'm
>> definitely not talking about name attributes for each pac subfield,
>> simply one attribute for the verified pac as a whole, which is not
>> present if the pac fails to verify.
>>
>>
> That's a good idea. I believe the acceptor should compute and verify  
> the PAC checksum as part of the KRB_AP_REQ handling. The application  
> shouldn't have to worry about PAC verification.
> Has that be worked on? How can I track that work?

It has not been worked on. I believe Heimdal does this. I did discuss  
it briefly was Sam, and I believe his comment was that one doesn't  
really want to do vendor specific stuff in gss_accept_sec_context().

regards,

-- Luke

From lha at kth.se  Mon Jul 20 12:26:55 2009
From: lha at kth.se (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=)
Date: Mon, 20 Jul 2009 09:26:55 -0700
Subject: krb5_pac_verify and server key enctype extraction
In-Reply-To: <8377C9E5-B035-44A3-942D-3B7107939B8E@padl.com>
References: <4A5D13B6.4090006@sun.com>
	<05B5918B-EE2B-40F9-B617-6928B4CFDACD@padl.com>
	<4A5E01F3.30803@Sun.COM>
	<38D16C49-7F9C-4463-BA08-3F9139F056CD@padl.com>
	<tslr5wfw735.fsf@mit.edu> <4A649316.5090402@Sun.COM>
	<8377C9E5-B035-44A3-942D-3B7107939B8E@padl.com>
Message-ID: <4E299B67-A73B-4A97-AAC2-A90E55432931@kth.se>

>>> I think we may want an interface to expose a verified PAC for 1.8.
>>> Possibly something at least nominally compatible with the naming  
>>> work
>>> going on in kitten or that can be extended to that interface.  I'm
>>> definitely not talking about name attributes for each pac subfield,
>>> simply one attribute for the verified pac as a whole, which is not
>>> present if the pac fails to verify.
>>>
>>>
>> That's a good idea. I believe the acceptor should compute and verify
>> the PAC checksum as part of the KRB_AP_REQ handling. The application
>> shouldn't have to worry about PAC verification.
>> Has that be worked on? How can I track that work?
>
> It has not been worked on. I believe Heimdal does this. I did discuss
> it briefly was Sam, and I believe his comment was that one doesn't
> really want to do vendor specific stuff in gss_accept_sec_context().

If you want to avoid adding interfaces that expose key data/context  
from the gss-api layer you have to checking it in krb5_rd_req/gss_ISC.

This is what Heimdal do.

Love


From ghudson at MIT.EDU  Tue Jul 21 14:09:42 2009
From: ghudson at MIT.EDU (ghudson@MIT.EDU)
Date: Tue, 21 Jul 2009 14:09:42 -0400 (EDT)
Subject: Project review: encryption performance
Message-ID: <200907211809.n6LI9gak019542@outgoing.mit.edu>

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

The review end date is August 3, 2009, which is two weeks from now.
However, implementation work will probably not begin until the
implementation of
http://k5wiki.kerberos.org/wiki/Projects/Crypto_modularity is
complete.

This project proposal covers the extension of keyblocks to contain
additional information when necessary (via a new opaque type named
krb5_key) and the use of this ability to cache derived keys for
improved performance.

From hartmans at MIT.EDU  Mon Jul 20 12:52:26 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Mon, 20 Jul 2009 12:52:26 -0400
Subject: krb5_pac_verify and server key enctype extraction
In-Reply-To: <4E299B67-A73B-4A97-AAC2-A90E55432931@kth.se> ("Love
	=?iso-8859-1?Q?H=F6rnquist_=C5strand=22's?= message of "Mon\,
	20 Jul 2009 09\:26\:55 -0700")
References: <4A5D13B6.4090006@sun.com>
	<05B5918B-EE2B-40F9-B617-6928B4CFDACD@padl.com>
	<4A5E01F3.30803@Sun.COM>
	<38D16C49-7F9C-4463-BA08-3F9139F056CD@padl.com>
	<tslr5wfw735.fsf@mit.edu> <4A649316.5090402@Sun.COM>
	<8377C9E5-B035-44A3-942D-3B7107939B8E@padl.com>
	<4E299B67-A73B-4A97-AAC2-A90E55432931@kth.se>
Message-ID: <tslab2zuwj9.fsf@mit.edu>

>>>>> "Love" == Love H?rnquist ?strand <lha at kth.se> writes:

    Love> If you want to avoid adding interfaces that expose key
    Love> data/context from the gss-api layer you have to checking it
    Love> in krb5_rd_req/gss_ISC.

I disagree.

From lha at kth.se  Tue Jul 21 14:50:29 2009
From: lha at kth.se (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=)
Date: Tue, 21 Jul 2009 11:50:29 -0700
Subject: krb5_pac_verify and server key enctype extraction
In-Reply-To: <tslab2zuwj9.fsf@mit.edu>
References: <4A5D13B6.4090006@sun.com>
	<05B5918B-EE2B-40F9-B617-6928B4CFDACD@padl.com>	<4A5E01F3.30803@Sun.COM>
	<38D16C49-7F9C-4463-BA08-3F9139F056CD@padl.com>	<tslr5wfw735.fsf@mit.edu>
	<4A649316.5090402@Sun.COM>	<8377C9E5-B035-44A3-942D-3B7107939B8E@padl.com>
	<4E299B67-A73B-4A97-AAC2-A90E55432931@kth.se>
	<tslab2zuwj9.fsf@mit.edu>
Message-ID: <31B12955-677F-4EF3-A36A-969F47E01901@kth.se>


20 jul 2009 kl. 09.52 skrev Sam Hartman:

>>>>>> "Love" == Love H?rnquist ?strand <lha at kth.se> writes:
>
>    Love> If you want to avoid adding interfaces that expose key
>    Love> data/context from the gss-api layer you have to checking it
>    Love> in krb5_rd_req/gss_ISC.
>
> I disagree.

You find it acceptable for services like sshd to get hold of the  
system long term keys ?

Love




From Nicolas.Williams at sun.com  Tue Jul 21 14:41:13 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 21 Jul 2009 13:41:13 -0500
Subject: Project review: encryption performance
In-Reply-To: <200907211809.n6LI9gak019542@outgoing.mit.edu>
References: <200907211809.n6LI9gak019542@outgoing.mit.edu>
Message-ID: <20090721184113.GL1020@Sun.COM>

On Tue, Jul 21, 2009 at 02:09:42PM -0400, ghudson at mit.edu wrote:
> Please review:
> http://k5wiki.kerberos.org/wiki/Projects/Encryption_Performance
> 
> The review end date is August 3, 2009, which is two weeks from now.
> However, implementation work will probably not begin until the
> implementation of
> http://k5wiki.kerberos.org/wiki/Projects/Crypto_modularity is
> complete.
> 
> This project proposal covers the extension of keyblocks to contain
> additional information when necessary (via a new opaque type named
> krb5_key) and the use of this ability to cache derived keys for
> improved performance.

 - How will this work:

   "The existing krb5_c versions of the new functions will be
   reimplemented in terms of the krb5_k functions, using an internal
   non-copying keyblock-to-key_st converter."

   ?

   Presumably the crypto plug-in has to be invoked to initialize the
   internal krb5_key.  Can that be generic enough that a "non-copying
   keyblock-to-key_st converter" is feasible?  And why does it matter
   that it be "non-copying"?  Do you expect a key copy operation to be
   slow?  (Key, not key schedule...)

   Which brings me to:

 - The SPI has to be public too, to some degree anyways.  E.g., the
   Solaris Kerberos team might want to wrap Solaris' PKCS#11-based krb5
   crypto into a plug-in for this interface; it'd be good to be able to
   review this project with an eye to ensuring third-party plug-ins are
   feasible.

   Can you include a definition of that SPI in the project page?

 - krb5_k_create_key() should probably know whether the given key can be
   further derived (i.e., if it is a protocol key).

 - For implementation of keyblock-based functions you might want the
   initializer to take a flag saying "don't bother caching derived keys,
   key schedules, or anything else" (since that might mean allocating
   memory you'll free right away).

 - You might want to mention PKCS#11 as a possible crypto provider, not
   just OpenSSL and NSS.

Nico
-- 

From ghudson at MIT.EDU  Tue Jul 21 16:26:23 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Tue, 21 Jul 2009 16:26:23 -0400
Subject: Project review: encryption performance
In-Reply-To: <20090721184113.GL1020@Sun.COM>
References: <200907211809.n6LI9gak019542@outgoing.mit.edu>
	<20090721184113.GL1020@Sun.COM>
Message-ID: <1248207983.10268.339.camel@ray>

On Tue, 2009-07-21 at 13:41 -0500, Nicolas Williams wrote:
>    Presumably the crypto plug-in has to be invoked to initialize the
>    internal krb5_key.  Can that be generic enough that a "non-copying
>    keyblock-to-key_st converter" is feasible?  And why does it matter
>    that it be "non-copying"?  Do you expect a key copy operation to be
>    slow?  (Key, not key schedule...)

It might not be a meaningful performance savings.  I may do some tests
and throw out the non-copying constructor idea.  I just didn't want to
slow down the krb5_c_encrypt type operations by doing unnecessary
allocations and copies.

>  - The SPI has to be public too, to some degree anyways.

I've changed the word "SPI" to "vtable" in my project proposal to avoid
confusion.  The enctype, enc_provider, and hash_provider vtables are for
polymorphism of different algorithms, not different back end
implementations.

>    Can you include a definition of that SPI in the project page?

You mean in the crypto modularity project page?  (Since this has nothing
to do with the encryption performance project.)  I can't speak to
Zhana's plans in that level of detail.  The back-end SPI may be a bit
messy since different libraries implement different bits of
functionality.

Also, just to be clear, the crypto modularity project is about
compile-time back end selection of crypto implementations.  The current
plan does not involve using the plugin layer or doing dynamic loading.
The "SPI" will consist of defining the same function names in different
ways in different source files.  It may not be necessary to have precise
documentation if the proof-of-concept glue layer can act as an example.

The flip side is that we would probably be willing to accept a PKCS#11
back end glue layer (to live alongside the OpenSSL or NSS glue layer we
do ourselves) if one is contributed, so Sun wouldn't have to maintain
the code as a patch against upstream MIT krb5.

>  - krb5_k_create_key() should probably know whether the given key can be
>    further derived (i.e., if it is a protocol key).

krb5_k_create_key is an externally visible API.  From that perspective,
all keys are protocol keys, right?  I mean, you can only use them with
functions like krb5_k_encrypt which accept a key usage.

If there is an implementation reason to keep track of when a key won't
be further derived, we can add an internal constructor which keeps track
of that.

>  - For implementation of keyblock-based functions you might want the
>    initializer to take a flag saying "don't bother caching derived keys,
>    key schedules, or anything else" (since that might mean allocating
>    memory you'll free right away).

Yes, we'll want to disable caching for krb5_c_encrypt and friends.  I've
added a note.

>  - You might want to mention PKCS#11 as a possible crypto provider, not
>    just OpenSSL and NSS.

I assume you again refer to the crypto modularity project.  We will
almost certainly be implementing a proof-of-concept glue layer for
either OpenSSL or NSS as part of that work, so where we mention those
two, it doesn't make sense to add other options.  I added PKCS#11 to the
earlier parenthetical which also mentions Bsafe, although that wasn't
intended to be an exhaustive list.



From Nicolas.Williams at sun.com  Tue Jul 21 17:23:28 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 21 Jul 2009 16:23:28 -0500
Subject: Project review: encryption performance
In-Reply-To: <1248207983.10268.339.camel@ray>
References: <200907211809.n6LI9gak019542@outgoing.mit.edu>
	<20090721184113.GL1020@Sun.COM> <1248207983.10268.339.camel@ray>
Message-ID: <20090721212328.GU1020@Sun.COM>

On Tue, Jul 21, 2009 at 04:26:23PM -0400, Greg Hudson wrote:
> On Tue, 2009-07-21 at 13:41 -0500, Nicolas Williams wrote:
> >    Can you include a definition of that SPI in the project page?
> 
> You mean in the crypto modularity project page?  (Since this has nothing
> to do with the encryption performance project.)  I can't speak to

On some project page.  IMO it belongs in this one.

> Zhana's plans in that level of detail.  The back-end SPI may be a bit
> messy since different libraries implement different bits of
> functionality.
> 
> Also, just to be clear, the crypto modularity project is about
> compile-time back end selection of crypto implementations.  The current
> plan does not involve using the plugin layer or doing dynamic loading.

That's fine, and very good too (there's no need for loadable crypto
modules here).

> The "SPI" will consist of defining the same function names in different
> ways in different source files.  It may not be necessary to have precise
> documentation if the proof-of-concept glue layer can act as an example.

Yes, but back to the internal non-copy constructor you mentioned: I
don't see how to get what you had in mind with PKCS#11, as one way or
another you'll be moving key bytes around.  Perhaps you should not
mention the non-copy constructor, as that makes my concern go away :)

> The flip side is that we would probably be willing to accept a PKCS#11
> back end glue layer (to live alongside the OpenSSL or NSS glue layer we
> do ourselves) if one is contributed, so Sun wouldn't have to maintain
> the code as a patch against upstream MIT krb5.

*nod*

Incidentally, NSS itself uses PKCS#11.

> >  - krb5_k_create_key() should probably know whether the given key can be
> >    further derived (i.e., if it is a protocol key).
> 
> krb5_k_create_key is an externally visible API.  From that perspective,
> all keys are protocol keys, right?  I mean, you can only use them with
> functions like krb5_k_encrypt which accept a key usage.

True, but internal uses of it might not deal in protocol keys.

> If there is an implementation reason to keep track of when a key won't
> be further derived, we can add an internal constructor which keeps track
> of that.

Right, that would address my comment.

> >  - For implementation of keyblock-based functions you might want the
> >    initializer to take a flag saying "don't bother caching derived keys,
> >    key schedules, or anything else" (since that might mean allocating
> >    memory you'll free right away).
> 
> Yes, we'll want to disable caching for krb5_c_encrypt and friends.  I've
> added a note.

This probably applies to the internal constructor you mention above.

> >  - You might want to mention PKCS#11 as a possible crypto provider, not
> >    just OpenSSL and NSS.
> 
> I assume you again refer to the crypto modularity project.  We will
> almost certainly be implementing a proof-of-concept glue layer for
> either OpenSSL or NSS as part of that work, so where we mention those
> two, it doesn't make sense to add other options.  I added PKCS#11 to the
> earlier parenthetical which also mentions Bsafe, although that wasn't
> intended to be an exhaustive list.

Heh.  Thanks,

Nico
-- 

From ghudson at MIT.EDU  Wed Jul 22 11:20:12 2009
From: ghudson at MIT.EDU (ghudson@MIT.EDU)
Date: Wed, 22 Jul 2009 11:20:12 -0400 (EDT)
Subject: Enctype configuration
Message-ID: <200907221520.n6MFKCq0010177@outgoing.mit.edu>

I'm soliciting ideas on enctype configuration changes for 1.8.  Tom
has a skeletal early project page at:

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

The primary deliverable here is the ability to modify the default list
of enctypes without completely replacing it.  So the first question is
what syntax to introduce for that.  OpenSSL has one but it's probably
too complicated for our purposes.  Tom proposed one in the project
page which is probably fine.

A secondary deliverable is making such modifications easier.  We
currently have four basic families of enctypes: des, des3, rc4, and
aes.  For each family we have 1-3 entries on the default enctypes list
and some anciliary enctypes which you wouldn't generally want to use
(e.g. rc4-hmac-exp and des-cbc-raw).  To remove DES from today's
default list in Tom's proposed syntax, you would have to write:

  DEFAULT -des-cbc-crc -des-cbc-md5 -des-cbc-md4

and if you're paranoid about the non-default DES enctypes, you might
decide to write:

  DEFAULT -des-cbc-crc -des-cbc-md5 -des-cbc-md4 -des-cbc-raw -des-hmac-sha1

We could make this easier through some kind of globbing, or through
syntaxes for adding or disabling enctypes based on algorithmic
components ("exclude anything using DES", "exclude anything using
MD5").  Alternatively, we could formally define the four enctype
families and allow inclusion and exclusion by family.  The presence of
undesirable enctypes like rc4-hmac-exp complicates the issue a bit; if
an configuration option says "include the RC4 family" then we wouldn't
want to add 40-bit RC4 to the list, but if an option says "exclude the
RC4 family" we would definitely want to exclude it.  Of course, these
undesirable enctypes aren't on the default list in the first place, so
perhaps there's no real issue.

If we're going to address the secondary deliverable at all, I would
lean towards using the families option, because it gives the
administrator less rope than globbing or algorithmic component
matching.

Finally, there is a third, ancillary issue, which is the
supported_enctypes variable tells kadmin what key/salt combinations to
create keys for from a user's password.  Because the variable includes
salt types as well as enctypes, it would be complicated to directly
apply any new syntax to this variable.

What I would like to see happen here is for us to stop supporting salt
type configuration.  Ken suggested some time ago that we should just
generate a random explicit salt for every new principal.  If we make
that change, supported_enctypes can become a straight enctype list
using the same syntax as the other three enctype variables.  For
backward compatibility, we would have to accept and ignore :salttype
specifiers after enctypes, of course.  It would take a little extra
time to implement this, but it would also carry side benefits.

From tsitkova at MIT.EDU  Wed Jul 22 12:06:03 2009
From: tsitkova at MIT.EDU (Zhanna Tsitkova)
Date: Wed, 22 Jul 2009 12:06:03 -0400
Subject: Enctype configuration
In-Reply-To: <200907221520.n6MFKCq0010177@outgoing.mit.edu>
References: <200907221520.n6MFKCq0010177@outgoing.mit.edu>
Message-ID: <0C9CBC50-2B5F-4C83-B02D-D41FC76A6C28@mit.edu>


On Jul 22, 2009, at 11:20 AM, ghudson at MIT.EDU wrote:

> I'm soliciting ideas on enctype configuration changes for 1.8.  Tom
> has a skeletal early project page at:
>
>  http://k5wiki.kerberos.org/wiki/Projects/Enctype_config_enhancements
>
> The primary deliverable here is the ability to modify the default list
> of enctypes without completely replacing it.  So the first question is
> what syntax to introduce for that.  OpenSSL has one but it's probably
> too complicated for our purposes.  Tom proposed one in the project
> page which is probably fine.
>
> A secondary deliverable is making such modifications easier.  We
> currently have four basic families of enctypes: des, des3, rc4, and
> aes.  For each family we have 1-3 entries on the default enctypes list
> and some anciliary enctypes which you wouldn't generally want to use
> (e.g. rc4-hmac-exp and des-cbc-raw).  To remove DES from today's
> default list in Tom's proposed syntax, you would have to write:
>
>  DEFAULT -des-cbc-crc -des-cbc-md5 -des-cbc-md4
How is DEFAULT defined? The list of the default enctypes may be  
different between krb releases  and be effected by the security  
advisories.
>
>
> and if you're paranoid about the non-default DES enctypes, you might
> decide to write:
>
>  DEFAULT -des-cbc-crc -des-cbc-md5 -des-cbc-md4 -des-cbc-raw -des- 
> hmac-sha1
>
> We could make this easier through some kind of globbing, or through
> syntaxes for adding or disabling enctypes based on algorithmic
> components ("exclude anything using DES", "exclude anything using
> MD5").  Alternatively, we could formally define the four enctype
> families and allow inclusion and exclusion by family.  The presence of
> undesirable enctypes like rc4-hmac-exp complicates the issue a bit; if
> an configuration option says "include the RC4 family" then we wouldn't
> want to add 40-bit RC4 to the list, but if an option says "exclude the
> RC4 family" we would definitely want to exclude it.  Of course, these
> undesirable enctypes aren't on the default list in the first place, so
> perhaps there's no real issue.
My  suggestion of using "globs" came as a desire to make admin's  
experience more transparent.
For example, admin wants only DES3 and AES crypto without MD5. So one  
indicates: +DES3 +AES -MD5.
in addition, perhaps: +rc4-hmac

> If we're going to address the secondary deliverable at all, I would
> lean towards using the families option, because it gives the
> administrator less rope than globbing or algorithmic component
> matching.
>
> Finally, there is a third, ancillary issue, which is the
> supported_enctypes variable tells kadmin what key/salt combinations to
> create keys for from a user's password.  Because the variable includes
> salt types as well as enctypes, it would be complicated to directly
> apply any new syntax to this variable.
>
> What I would like to see happen here is for us to stop supporting salt
> type configuration.  Ken suggested some time ago that we should just
> generate a random explicit salt for every new principal.  If we make
> that change, supported_enctypes can become a straight enctype list
> using the same syntax as the other three enctype variables.  For
> backward compatibility, we would have to accept and ignore :salttype
> specifiers after enctypes, of course.  It would take a little extra
> time to implement this, but it would also carry side benefits.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev


From ghudson at MIT.EDU  Wed Jul 22 17:07:42 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Wed, 22 Jul 2009 17:07:42 -0400
Subject: Enctype configuration
In-Reply-To: <0C9CBC50-2B5F-4C83-B02D-D41FC76A6C28@mit.edu>
References: <200907221520.n6MFKCq0010177@outgoing.mit.edu>
	<0C9CBC50-2B5F-4C83-B02D-D41FC76A6C28@mit.edu>
Message-ID: <1248296862.10268.386.camel@ray>

On Wed, 2009-07-22 at 12:06 -0400, Zhanna Tsitkova wrote:
> How is DEFAULT defined? The list of the default enctypes may be  
> different between krb releases  and be effected by the security  
> advisories.

Well, yes, that's the point: to be able to modify the default list of
enctypes without replacing it.



From hartmans at MIT.EDU  Thu Jul 23 09:56:31 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Thu, 23 Jul 2009 09:56:31 -0400
Subject: Enctype configuration
In-Reply-To: <200907221520.n6MFKCq0010177@outgoing.mit.edu> (ghudson@mit.edu's
	message of "Wed\, 22 Jul 2009 11\:20\:12 -0400 \(EDT\)")
References: <200907221520.n6MFKCq0010177@outgoing.mit.edu>
Message-ID: <tslfxcnpkog.fsf@mit.edu>

Greg, I've reviewed your mail but not the early project page.
I think your proposal sounds good.
I favor families over globbing  and globbing over algorithms.

My initial reaction to changing supported_enctypes and dropping salt
was negative.  However after examining my reaction I found no
justification other than resistance to change, so that sounds good
too.

--Sam

From hartmans at debian.org  Thu Jul 23 13:21:44 2009
From: hartmans at debian.org (Sam Hartman)
Date: Thu, 23 Jul 2009 13:21:44 -0400 (EDT)
Subject: Proposal: expose two private symbols
Message-ID: <20090723172144.B15284141@carter-zimmerman.suchdamage.org>



I'd like to expose two private symbols:

krb5_kt_free_entry                                                              
krb5_auth_con_set_req_cksumtype                                                 


The first should be exposed as krb5_depricated.  There is some other
symbol that should be used instead (I think free_entry_contents or
some such), but some applications are coded to this interface,
including Samba3.  I see no reason not to expose the symbol.

The second is needed so that Samba3 can properly construct a GSS-API
checksum.  Remember that Samba3 (but I think not Samba4) rolls its own
GSS-API initial context token.  I don't think it is possible for Samba
to do what it needs to do without this symbol.

Any objections, or can I expose them on the trunk and in what Debian ships?

From ghudson at MIT.EDU  Thu Jul 23 15:50:11 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Thu, 23 Jul 2009 15:50:11 -0400
Subject: Enctype configuration -- project review started
In-Reply-To: <200907221520.n6MFKCq0010177@outgoing.mit.edu>
References: <200907221520.n6MFKCq0010177@outgoing.mit.edu>
Message-ID: <1248378611.10268.429.camel@ray>

I've fleshed out
http://k5wiki.kerberos.org/wiki/Projects/Enctype_config_enhancements
and have started a review with an end date of July 30.  I may check in
part or all of an implementation before that date, depending on whether
I run into any snags.



From mdeloera at exacq.com  Fri Jul 24 14:01:18 2009
From: mdeloera at exacq.com (Matthew M. DeLoera)
Date: Fri, 24 Jul 2009 14:01:18 -0400
Subject: How do I use KfW kinit.exe with respect to the Windows credentials
	cache?
In-Reply-To: <4A5D13B6.4090006@sun.com>
References: <4A5D13B6.4090006@sun.com>
Message-ID: <4A69F6EE.6030403@exacq.com>

Good morning/afternoon/etc...

I haven't managed to find any examples of this, and all of my 
experiments have failed:

I've got KfW installed. I can successfully use the accompanying 
kinit.exe, as well as the Network Identity Manager GUI. Either way, I 
can verify my user principal with the included klist.exe. I think 
everything is good as far as KRB5 is concerned. Let's say it's 
"deloera at SNAFU.ORG".

Can I call AcquireCredentialsHandle (SSPI), pass "deloera at SNAFU.ORG" for 
pszPrincipal, and pass NULL for pAuthData? So far, I consistently get 
SEC_E_NO_CREDENTIALS from InitializeSecurityContext. Is the credentials 
cache that I'm viewing with kinit.exe only accessible by the krb5 
libraries and tools? Can't it be referenced in SSPI calls?

I'm trying to mimic Linux/MacOS behavior, where the user must have 
previously run kinit to authenticate. Hence in those platforms, I don't 
have to store passwords.

In the meantime, I can successfully pass NULL for pAuthData to 
successfully reference the default principal (if the user logged into XP 
through the domain/realm). I can also pass a literal 
username/password/domain into the call. But, that requires me to store 
passwords. In case there's a question about it - I'm using the MIT KRB5 
KDC in Linux (Ubuntu 6.06). Everything works consistently in these 2 
scenarios.

So, any suggestions? Is is possible to authenticate in Microsoft with 
kinit.exe on the command-line, then just reference that same cached 
credential from Microsoft's SSPI? Any insight would be appeciated.....

Thanks,
- Matthew


From tlyu at MIT.EDU  Fri Jul 24 15:38:35 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Fri, 24 Jul 2009 15:38:35 -0400
Subject: kfw-3.2.3-alpha1 is available
Message-ID: <ldvd47pooqs.fsf@cathode-dark-space.mit.edu>

There is an alpha release of Kerberos for Windows release 3.2.3
available.  You may download it at:

    http://web.mit.edu/kerberos/dist/testing.html

The main MIT Kerberos page is at:

    http://web.mit.edu/kerberos/

and the MIT Kerberos Consortium page is at:

    http://kerberos.org/

This is an ALPHA release, and is primarily targeted at developers.
There is not yet a complete list of changes since kfw-3.2.2; we will
compile a change list prior to final release.  This release is meant
primarily as a bugfix release and to provide support for AMD64
(a.k.a. x86_64, EM64T, etc.) Windows operating systems.  Most of the
included bugfixes are changes that have pulled up to the krb5-1.6
branch for inclusion in the krb5-1.6.4 release.

The NSIS installer is not built; we expect to remedy this in a
subsequent beta release.  There may be sequencing issues with
installing both 32-bit and 64-bit packages on the same host, i.e.,
installing them in one order will cause problems, while installing
them in the other order succeeds.

AMD64 builds do not support krb4.  This is in accordance with our
earlier decision that building krb4 for AMD64 Windows would count as a
new krb4 implementation, and building krb4 for AMD64 Windows would
thus be against our stated policy of ending active development on
krb4.

-- 
Tom Yu
Development Team Leader
MIT Kerberos Consortium

From ghudson at MIT.EDU  Fri Jul 24 16:22:11 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Fri, 24 Jul 2009 16:22:11 -0400
Subject: Enctype configuration
In-Reply-To: <tslfxcnpkog.fsf@mit.edu>
References: <200907221520.n6MFKCq0010177@outgoing.mit.edu>
	<tslfxcnpkog.fsf@mit.edu>
Message-ID: <1248466931.10268.472.camel@ray>

On Thu, 2009-07-23 at 09:56 -0400, Sam Hartman wrote:
> My initial reaction to changing supported_enctypes and dropping salt
> was negative.  However after examining my reaction I found no
> justification other than resistance to change, so that sounds good
> too.

I found two complications with random explicit salt generation:

1. It breaks our current implementation of password history checking
(unless the principal has rc4-hmac keys, which don't use the salt in
string2key).  I think password history checking could be improved to try
encrypting the new key in the historical salts.

2. As noted in RFC 4120, "it is not possible to generate a user's key
reliably given a pass phrase without contacting the KDC, since it will
not be known whether alternate salt or parameter values are required."
However, you can guess that the salt is the mangled principal, and our
ktutil addent -password command does exactly that.  That guess is wrong
if the admin used any non-NORMAL salt type when creating the principal,
or the principal has been renamed (you can't rename a NORMAL-salted
principal right now, but you could if we processed the patch in RT
#6323)... but in the usual case, the guess is right.  That would cease
to be true if we switched to explicit random salts.

It should be possible to modify ktutil to contact the KDC, assuming that
salt information is present in PREAUTH_REQUIRED errors, which seems to
be true according to a scan of the RFC.

If I can resolve these problems with reasonable effort, I will go ahead
and stick with the plan.  Hopefully this won't turn into one of those
home repair projects where you start out doing something simple and wind
up doing major remodeling.



From jaltman at secure-endpoints.com  Fri Jul 24 16:43:06 2009
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Fri, 24 Jul 2009 16:43:06 -0400
Subject: How do I use KfW kinit.exe with respect to the Windows credentials
	cache?
In-Reply-To: <4A69F6EE.6030403@exacq.com>
References: <4A5D13B6.4090006@sun.com> <4A69F6EE.6030403@exacq.com>
Message-ID: <4A6A1CDA.2060304@secure-endpoints.com>

Matthew M. DeLoera wrote:

> So, any suggestions? Is is possible to authenticate in Microsoft with 
> kinit.exe on the command-line, then just reference that same cached 
> credential from Microsoft's SSPI? Any insight would be appeciated.....

KFW credential caches cannot be used from Microsoft Kerberos SSP
applications.




From raeburn at MIT.EDU  Fri Jul 24 20:38:37 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Fri, 24 Jul 2009 20:38:37 -0400
Subject: Enctype configuration
In-Reply-To: <1248466931.10268.472.camel@ray>
References: <200907221520.n6MFKCq0010177@outgoing.mit.edu>
	<tslfxcnpkog.fsf@mit.edu> <1248466931.10268.472.camel@ray>
Message-ID: <D89D7F7E-96B8-406D-A0B6-87AC8B6C7E4F@mit.edu>

On Jul 24, 2009, at 16:22, Greg Hudson wrote:
> 1. It breaks our current implementation of password history checking
> (unless the principal has rc4-hmac keys, which don't use the salt in
> string2key).  I think password history checking could be improved to  
> try
> encrypting the new key in the historical salts.

Interesting... that aspect had escaped me.  Since using the wrong salt  
means basically no chance of matching the old keys, and AFAIK we  
already support changing salts (just not automatically and randomly),  
I'd say this is an existing bug.


> 2. As noted in RFC 4120, "it is not possible to generate a user's key
> reliably given a pass phrase without contacting the KDC, since it will
> not be known whether alternate salt or parameter values are required."
> However, you can guess that the salt is the mangled principal, and our
> ktutil addent -password command does exactly that.  That guess is  
> wrong
> if the admin used any non-NORMAL salt type when creating the  
> principal,
> or the principal has been renamed (you can't rename a NORMAL-salted
> principal right now, but you could if we processed the patch in RT
> #6323)... but in the usual case, the guess is right.  That would cease
> to be true if we switched to explicit random salts.

Yep.  Other theoretical cases are possible where you'd make the same  
assumption, but this is probably the important one.  In proposing  
randomized salts before, I assumed that service passwords would use  
NORMAL salts instead.

> It should be possible to modify ktutil to contact the KDC, assuming  
> that
> salt information is present in PREAUTH_REQUIRED errors, which seems to
> be true according to a scan of the RFC.

I like this.  Some issues occur to me though:

1) With PREAUTH_REQUIRED, a simple denial-of-service attack is  
possible by forging the KDC reply; ktutil gets the wrong salt, does no  
validation, and stores the wrong key, and the admin happily goes about  
his business.  Getting and decrypting initial credentials would be a  
good start.

2) If canonicalization and referrals are enabled for this validation,  
either ktutil should check that the name didn't actually change, or it  
faces the same issues as I've written up in the past for kinit on the  
IETF list (e.g., careless admin reuses passwords, forged reply alters  
name and salt).  I'm not sure if it actually gets an attacker anything  
in this case beyond a denial of service, but breaking the service's  
keytabs could be bad enough.  If canonicalization is disabled in this  
request, I think just decrypting the AS-REP will be sufficient; the  
admin is not likely to be cooperating with a forger on the wire, so we  
don't need to worry about the Zanarotti attack.  I'm not sure offhand  
what ought to happen if the admin supplies a name that's an alias  
instead of the canonical name; answering that might suggest whether  
canonicalization should be disabled or not.

3) A chicken-and-egg problem for key rollover: Is the new key enabled  
in the database before or after running ktutil?  If it's enabled  
before, there's an obvious window where the service won't work with  
newly-issued credentials.  If it's enabled after, how do you get the  
salt for the new password?

Ken

From epeisach at MIT.EDU  Fri Jul 24 21:53:58 2009
From: epeisach at MIT.EDU (Ezra Peisach)
Date: Fri, 24 Jul 2009 21:53:58 -0400
Subject: TffffrevccaJk deAfyeg
Message-ID: <5F0793DE-F128-41FB-9098-58F32DAC6AF8@mit.edu>



Sent from my iPod

From hartmans at MIT.EDU  Sat Jul 25 06:59:44 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Sat, 25 Jul 2009 06:59:44 -0400
Subject: Enctype configuration
In-Reply-To: <1248466931.10268.472.camel@ray> (Greg Hudson's message of "Fri\,
	24 Jul 2009 16\:22\:11 -0400")
References: <200907221520.n6MFKCq0010177@outgoing.mit.edu>
	<tslfxcnpkog.fsf@mit.edu> <1248466931.10268.472.camel@ray>
Message-ID: <tslk51xkoyn.fsf@mit.edu>

>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:
    Greg> 2. As noted in RFC 4120, "it is not possible to generate a
    Greg> user's key reliably given a pass phrase without contacting
    Greg> the KDC, since it will not be known whether alternate salt
    Greg> or parameter values are required."  However, you can guess
    Greg> that the salt is the mangled principal, and our ktutil
    Greg> addent -password command does exactly that.  That guess is
    Greg> wrong if the admin used any non-NORMAL salt type when
    Greg> creating the principal, or the principal has been renamed
    Greg> (you can't rename a NORMAL-salted principal right now, but
    Greg> you could if we processed the patch in RT #6323)... but in
    Greg> the usual case, the guess is right.  That would cease to be
    Greg> true if we switched to explicit random salts.

    Greg> It should be possible to modify ktutil to contact the KDC,
    Greg> assuming that salt information is present in
    Greg> PREAUTH_REQUIRED errors, which seems to be true according to
    Greg> a scan of the RFC.

Thanks for bringing this up.  Unfortunately there are some interop
cases where random salt will be a problem.  One is creating
cross-realm passwords.  Another is creating machine and service
accounts for Windows.  For this reason, I think it is important to
retain the ability to support normal salt for a principal.

I don't think that needs to be coupled to supported_enctypes in the
config file.

One possibility is to only support it with the -e option of cpw in
kadmin.  Another is to have a principal flag.

From hartmans at MIT.EDU  Sat Jul 25 07:01:33 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Sat, 25 Jul 2009 07:01:33 -0400
Subject: Proposal: expose two private symbols
In-Reply-To: <20090723172144.B15284141@carter-zimmerman.suchdamage.org> (Sam
	Hartman's message of "Thu\, 23 Jul 2009 13\:21\:44 -0400 \(EDT\)")
References: <20090723172144.B15284141@carter-zimmerman.suchdamage.org>
Message-ID: <tslbpn9kovm.fsf@mit.edu>

Seeing no objections I'm going to go forward with this.
If objections emerge, feel free to back out.

From john at betelgeuse.us  Sat Jul 25 10:28:56 2009
From: john at betelgeuse.us (John W. M. Stevens)
Date: Sat, 25 Jul 2009 08:28:56 -0600
Subject: Proper use of krb5_rd_priv ?
Message-ID: <1248532136.30514.8.camel@morningstar.betelgeuse.us>

Hello,

I've been working on a MIT Kerberos based Kerberized messaging library.
Authentication was added first, now I'm working on adding message
encryption.

I've used the krb5_mk_priv and krb5_rd_priv functions, but on the
receiving end, where I attempt to use krb5_rd_priv to decrypt the
message, I get:

Program received signal SIGSEGV, Segmentation fault.
0xb7c13ed2 in krb5_address_compare () from /usr/lib/libkrb5.so.3

This suggests some kind of uninitialized field in the stored addresses,
but I am using the krb5_auth_con_setports, krb5_auth_con_setaddrs
functions to set the local address into the authorization context, as
per a Hemidahl source code example (plus some replay cache setup).

Is there a code example specific to MIT Kerberos that shows proper setup
for and use of the read private function, or can somebody suggest why
the address comparison routine seems to be looking for data I might not
have initialized?

Thanks,
-- 
John W. M. Stevens <john at betelgeuse.us>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090725/41e68bbd/attachment-0001.bin

From hartmans at MIT.EDU  Sat Jul 25 10:54:35 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Sat, 25 Jul 2009 10:54:35 -0400
Subject: Proper use of krb5_rd_priv ?
In-Reply-To: <1248532136.30514.8.camel@morningstar.betelgeuse.us> (John W. M.
	Stevens's message of "Sat\, 25 Jul 2009 08\:28\:56 -0600")
References: <1248532136.30514.8.camel@morningstar.betelgeuse.us>
Message-ID: <tslk51w4xuc.fsf@mit.edu>

Take a look at src/appl/simple/server in the MIT sources.

From ghudson at MIT.EDU  Sat Jul 25 10:53:21 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Sat, 25 Jul 2009 10:53:21 -0400
Subject: Enctype configuration
In-Reply-To: <tslk51xkoyn.fsf@mit.edu>
References: <200907221520.n6MFKCq0010177@outgoing.mit.edu>
	<tslfxcnpkog.fsf@mit.edu> <1248466931.10268.472.camel@ray>
	<tslk51xkoyn.fsf@mit.edu>
Message-ID: <1248533601.10268.486.camel@ray>

On Sat, 2009-07-25 at 06:59 -0400, Sam Hartman wrote:
> Thanks for bringing this up.  Unfortunately there are some interop
> cases where random salt will be a problem.  One is creating
> cross-realm passwords.  Another is creating machine and service
> accounts for Windows.

I thought of the cross-TGT issue last night.  I'm not sure machine and
service accounts for Windows are an issue since rc4-hmac's string-to-key
doesn't use the salt.

At this point, I'm going to carefully replace the drywall I removed and
pretend that I didn't find the nest of bad wiring inside.  I will write
up an early project proposal describing random explicit salts and the
benefits and complications thereof, but I don't think the benefits are
worth the amount of time it would take to resolve the complications at
this point.

For the enctype configuration project, I will just leave the
supported_enctypes variable alone.



From lha at kth.se  Sat Jul 25 14:03:05 2009
From: lha at kth.se (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=)
Date: Sat, 25 Jul 2009 20:03:05 +0200
Subject: Enctype configuration
In-Reply-To: <1248533601.10268.486.camel@ray>
References: <200907221520.n6MFKCq0010177@outgoing.mit.edu>
	<tslfxcnpkog.fsf@mit.edu> <1248466931.10268.472.camel@ray>
	<tslk51xkoyn.fsf@mit.edu> <1248533601.10268.486.camel@ray>
Message-ID: <859B8E51-7683-40A9-8568-D5DD7C65B5A5@kth.se>


25 jul 2009 kl. 16:53 skrev Greg Hudson:

> I thought of the cross-TGT issue last night.  I'm not sure machine and
> service accounts for Windows are an issue since rc4-hmac's string-to- 
> key
> doesn't use the salt.

Whom is not using AES for the cross realm keys ?

Love


From hartmans at MIT.EDU  Sun Jul 26 06:10:30 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Sun, 26 Jul 2009 06:10:30 -0400
Subject: Enctype configuration
In-Reply-To: <859B8E51-7683-40A9-8568-D5DD7C65B5A5@kth.se> ("Love
	=?iso-8859-1?Q?H=F6rnquist_=C5strand=22's?= message of "Sat\,
	25 Jul 2009 20\:03\:05 +0200")
References: <200907221520.n6MFKCq0010177@outgoing.mit.edu>
	<tslfxcnpkog.fsf@mit.edu> <1248466931.10268.472.camel@ray>
	<tslk51xkoyn.fsf@mit.edu> <1248533601.10268.486.camel@ray>
	<859B8E51-7683-40A9-8568-D5DD7C65B5A5@kth.se>
Message-ID: <tslr5w33gbt.fsf@mit.edu>

Starting with Vista, aes is used for machine accounts.

From hotz at jpl.nasa.gov  Mon Jul 27 17:00:38 2009
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Mon, 27 Jul 2009 14:00:38 -0700
Subject: Enctype configuration
In-Reply-To: <mailman.623675.1248532148.7907.krbdev@mit.edu>
References: <mailman.623675.1248532148.7907.krbdev@mit.edu>
Message-ID: <7FCAA762-2609-44FC-8848-E5C302D131D7@jpl.nasa.gov>


On Jul 25, 2009, at 7:29 AM, krbdev-request at mit.edu wrote:

> Date: Sat, 25 Jul 2009 06:59:44 -0400
> From: Sam Hartman <hartmans at MIT.EDU>
> Subject: Re: Enctype configuration
> To: Greg Hudson <ghudson at MIT.EDU>
> Cc: krbdev at mit.edu
> Message-ID: <tslk51xkoyn.fsf at mit.edu>
> Content-Type: text/plain; charset=us-ascii
>
>>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:
>    Greg> 2. As noted in RFC 4120, "it is not possible to generate a
>    Greg> user's key reliably given a pass phrase without contacting
>    Greg> the KDC, since it will not be known whether alternate salt
>    Greg> or parameter values are required."  However, you can guess
>    Greg> that the salt is the mangled principal, and our ktutil
>    Greg> addent -password command does exactly that.  That guess is
>    Greg> wrong if the admin used any non-NORMAL salt type when
>    Greg> creating the principal, or the principal has been renamed
>    Greg> (you can't rename a NORMAL-salted principal right now, but
>    Greg> you could if we processed the patch in RT #6323)... but in
>    Greg> the usual case, the guess is right.  That would cease to be
>    Greg> true if we switched to explicit random salts.
>
>    Greg> It should be possible to modify ktutil to contact the KDC,
>    Greg> assuming that salt information is present in
>    Greg> PREAUTH_REQUIRED errors, which seems to be true according to
>    Greg> a scan of the RFC.
>
> Thanks for bringing this up.  Unfortunately there are some interop
> cases where random salt will be a problem.  One is creating
> cross-realm passwords.  Another is creating machine and service
> accounts for Windows.  For this reason, I think it is important to
> retain the ability to support normal salt for a principal.
>
> I don't think that needs to be coupled to supported_enctypes in the
> config file.
>
> One possibility is to only support it with the -e option of cpw in
> kadmin.  Another is to have a principal flag.


I have occasionally recommended implementing a keytab import  
capability for this purpose.

------------------------------------------------------
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  Mon Jul 27 05:17:56 2009
From: nikhilm at gs-lab.com (Nikhil Mishra)
Date: Mon, 27 Jul 2009 14:47:56 +0530
Subject: KRB5KDC_ERR_ETYPE_NOSUPP in protocol transition
Message-ID: <4A6D70C4.30805@gs-lab.com>

Hi All ,

I made some changes in krb5_get_credentials to work for protocol
transition and constrained delegation .

The issues I have is following :

I am able to fetch an S4U2Self ticket.While I make a S4U2proxy request
It gives me KRB5KDC_ERR_ETYPE_NOSUPP error .

The machine setup is following :

1. Domain controller : Windows server 2003 SP2 with all updates later .
2. MIT kerberos 1.6.5 with changes for protocol transition and 
constrained delegation.
I used setspn utility to create this service principal .

default-tkt-enctypes = rc4-hmac des-cbc-md5 des-hmac-sha1

I have tried other combinations like removing rc4-hmac  , but nothing
works .

I have written small utilities based on MIT kerberos library to make
S4U2Self request on behalf of some other user .



Thanks

Nikhil

From lukeh at padl.com  Tue Jul 28 16:10:01 2009
From: lukeh at padl.com (Luke Howard)
Date: Tue, 28 Jul 2009 22:10:01 +0200
Subject: KRB5KDC_ERR_ETYPE_NOSUPP in protocol transition
In-Reply-To: <4A6D70C4.30805@gs-lab.com>
References: <4A6D70C4.30805@gs-lab.com>
Message-ID: <6A83EB1F-A560-41E5-8B75-EB2A92F8414C@padl.com>


On 27/07/2009, at 11:17 AM, Nikhil Mishra wrote:

> Hi All ,
>
> I made some changes in krb5_get_credentials to work for protocol
> transition and constrained delegation .

Sorry to duplicate the effort: you might want to take a look at the  
users/lhoward/s4u branch in SVN.

That contains my in-progress implementation of S4U2Self and S4U2Proxy.  
Presently only S4U2Self (W2K3 protocol) is tested. (The W2K3 protocol  
has some weaknesses in that the S4U2Self request is not bound to the  
TGS-REQ. This was corrected in W2K8, but I haven't been able to get  
that to work yet.)

As for your immediate problem, I'm not sure, because I haven't tested  
S4U2Proxy yet...

cheers,

-- Luke

From hotz at jpl.nasa.gov  Tue Jul 28 20:33:31 2009
From: hotz at jpl.nasa.gov (Henry B.Hotz)
Date: Tue, 28 Jul 2009 17:33:31 -0700
Subject: How do I use KfW kinit.exe with respect to the Windows
	credentials cache?
In-Reply-To: <mailman.623675.1248532148.7907.krbdev@mit.edu>
References: <mailman.623675.1248532148.7907.krbdev@mit.edu>
Message-ID: <A6CCB94A-EF5A-4C12-89DD-9FA14A3C3A79@jpl.nasa.gov>


On Jul 25, 2009, at 7:29 AM, krbdev-request at mit.edu wrote:

> Message: 4
> Date: Fri, 24 Jul 2009 16:43:06 -0400
> From: Jeffrey Altman <jaltman at secure-endpoints.com>
> Subject: Re: How do I use KfW kinit.exe with respect to the Windows
>        credentials     cache?
> To: "Matthew M. DeLoera" <mdeloera at exacq.com>
> Cc: krbdev at mit.edu
> Message-ID: <4A6A1CDA.2060304 at secure-endpoints.com>
> Content-Type: text/plain; charset=UTF-8
>
> Matthew M. DeLoera wrote:
>
>> So, any suggestions? Is is possible to authenticate in Microsoft with
>> kinit.exe on the command-line, then just reference that same cached
>> credential from Microsoft's SSPI? Any insight would be  
>> appeciated.....
>
> KFW credential caches cannot be used from Microsoft Kerberos SSP
> applications.


I thought there was a registry setting to allow that?
------------------------------------------------------
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 mdeloera at exacq.com  Tue Jul 28 21:12:00 2009
From: mdeloera at exacq.com (Matthew M. DeLoera)
Date: Tue, 28 Jul 2009 21:12:00 -0400
Subject: How do I use KfW kinit.exe with respect to the Windows credentials
	cache?
In-Reply-To: <A6CCB94A-EF5A-4C12-89DD-9FA14A3C3A79@jpl.nasa.gov>
References: <mailman.623675.1248532148.7907.krbdev@mit.edu>
	<A6CCB94A-EF5A-4C12-89DD-9FA14A3C3A79@jpl.nasa.gov>
Message-ID: <4A6FA1E0.1050302@exacq.com>

Thanks for all the responses. Apologies for not promptly responding.

I see that my idea isn't supported.

I think the complication lies in supporting multiple principals. We have 
a security product that implements a list of 
servers/usernames/passwords, and stores them in a locally encrypted 
file. Our client is available for Windows, Linux, and MacOS.

I'm implementing our KRB and LDAP integration. Naturally, the primary 
thought is Active Directory integration. I'm trying to keep things open 
for more generic KRB and LDAP integration.

In Windows, SSPI gives me an easy path to just push the existing 
username/password/realm that we store in a locally-encrypted file. In a 
KRB-enabled environment I'd like to not have to manage passwords, 
because it seems to violate fundamentals. I don't want to integrate 
directly with MIT KRB, in case we're releasing a DEB for Ubuntu where 
heimdal has already been installed. MacOS is nice enough to pop up a GUI 
dialog that interfaces with their keyring facility. Neither Linux nor 
Windows have that functionality right now.

Of course, this deviates from the fundamental idea of only 
authenticating with a single identity. We're trying to support that 
perhaps you log on to your workstation as a non-admin user, but you 
authenticate to our software as an admin user.

I guess it would be nice if there were integration in KfW with the MS 
credential cache, so that a user could install KfW, kinit as 
appropriate, and then SSPI would be able to reference those credentials, 
so that I wouldn't have to maintain passwords. Ideally, some kind of 
keyring functionality. Similar for Linux.

I'm not an expert on these things, and I don't want to violate any 
fundamental understanding that's really in the best interest. Though, if 
not offensive, I'd love to see the MacOS behavior supported in Windows 
and Linux.

So, I guess this is really a discussion thread. For what it's worth.

Peace,
- Matthew DeLoera



>>
>> KFW credential caches cannot be used from Microsoft Kerberos SSP
>> applications.
>
>
> I thought there was a registry setting to allow that?
> ------------------------------------------------------
> 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  Wed Jul 29 00:23:50 2009
From: nikhilm at gs-lab.com (Nikhil Mishra)
Date: Wed, 29 Jul 2009 09:53:50 +0530
Subject: KRB5KDC_ERR_ETYPE_NOSUPP in protocol transition
In-Reply-To: <6A83EB1F-A560-41E5-8B75-EB2A92F8414C@padl.com>
References: <4A6D70C4.30805@gs-lab.com>
	<6A83EB1F-A560-41E5-8B75-EB2A92F8414C@padl.com>
Message-ID: <4A6FCED6.6010109@gs-lab.com>

Thanks Luke. I will take a look at the branch.

I have implemented both S4U2self and S4U2proxy .
I tested it with win2k3 SP2 and limited set of hotfixes .This was
working fine and I was able to fetch corresponding tickets .

After doing an auto upgrade , is when I started getting this error .

I suspect some default parameters being set in windows registry is
causing the issue .

Snippet from my krb5.conf :

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = WXYZ.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 forwardable = yes
# default-tgt-enctypes = rc4-hmac
 default-tkt-enctypes = des-cbc-md5 des-hmac-sha1 des-cbc-crc
# permitted-enctypes = rc4-hmac



Please find the diff attached . This diff is taken on krb 1.6.5.
I will also give it a shot against win2k8.

Thanks

Nikhil

Luke Howard wrote:
>
> On 27/07/2009, at 11:17 AM, Nikhil Mishra wrote:
>
>> Hi All ,
>>
>> I made some changes in krb5_get_credentials to work for protocol
>> transition and constrained delegation .
>
> Sorry to duplicate the effort: you might want to take a look at the
> users/lhoward/s4u branch in SVN.
>
> That contains my in-progress implementation of S4U2Self and S4U2Proxy.
> Presently only S4U2Self (W2K3 protocol) is tested. (The W2K3 protocol
> has some weaknesses in that the S4U2Self request is not bound to the
> TGS-REQ. This was corrected in W2K8, but I haven't been able to get
> that to work yet.)
>
> As for your immediate problem, I'm not sure, because I haven't tested
> S4U2Proxy yet...
>
> cheers,
>
> -- Luke
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kerberos_cd.diff
Type: text/x-patch
Size: 21146 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090729/63eda86a/kerberos_cd-0001.bin

From lukeh at padl.com  Wed Jul 29 08:21:34 2009
From: lukeh at padl.com (Luke Howard)
Date: Wed, 29 Jul 2009 14:21:34 +0200
Subject: KRB5KDC_ERR_ETYPE_NOSUPP in protocol transition
In-Reply-To: <4A6FCED6.6010109@gs-lab.com>
References: <4A6D70C4.30805@gs-lab.com>
	<6A83EB1F-A560-41E5-8B75-EB2A92F8414C@padl.com>
	<4A6FCED6.6010109@gs-lab.com>
Message-ID: <44493101-0B35-4D54-8545-EA70B5F3E7EA@padl.com>


On 29/07/2009, at 6:23 AM, Nikhil Mishra wrote:

> Thanks Luke. I will take a look at the branch.

Again, please accept my apologies for the duplication of effort. I've  
just checked in some changes to get S4U2Proxy to work. You can test  
both S4U2Self and S4U2Proxy using the kvno tool, which now accepts two  
new arguments: -U user and -P.

For example:

# kvno -k krb5.keytab -U delegtest at de.padl.com@DE.PADL.COM -P host/WIN-EQ7E4AA2WR8.DE.PADL.COM at DE.PADL.COM

will use S4U2Self to acquire a ticket from delegtest to the ccache  
principal, and then use S4U2Proxy to acquire a ticket from delegtest  
to host/WIN-EQ7E4AA2WR8.DE.PADL.COM. You need to specify a keytab for  
S4U2Proxy, so that the ticket can be decrypted.

There are also two new exported APIs that can be used from GSS-API  
applications. (I will write this up on the Kerberos projects Wiki  
soon, I promise.) I don't propose to export the krb5 equivalents.

gss_krb5_create_sec_context_for_principal() synthesises an acceptor- 
side security context for an arbitrary principal principal. (There's  
probably a better name for this.) verifier_cred_handle must be both an  
initiator- and acceptor-side credentials handle, because a TGT is  
required to perform S4U2Self.

OM_uint32
gss_krb5_create_sec_context_for_principal(OM_uint32 *minor_status,
	gss_ctx_id_t *context_handle,
	gss_cred_id_t verifier_cred_handle,
	gss_name_t principal,
	OM_uint32 req_flags,
	OM_uint32 time_req,
	gss_name_t *src_name,
	gss_OID *mech_type,
	OM_uint32 *ret_flags,
	OM_uint32 *time_ret,
	gss_cred_id_t *delegated_cred_handle);

gss_krb5_add_sec_context_delegatee() creates or updates a skeleton  
context that can be passed to gss_accept_sec_context(), such that  
delegated_cred_handle will contain credentials for delegating to the  
specified principals.

OM_uint32
gss_krb5_add_sec_context_delegatee(OM_uint32 *minor_status,
	gss_ctx_id_t *context_handle,
	gss_name_t name);

That way, the existing GSS-API delegation model is maintained; the  
only difference is that you don't get a TGT, instead you get a  
credentials handle with a set of service tickets.

As for your specific issue, might be worth either contacting Larry Zhu  
directly or posting on the MS protocol forum (the URL which I don't  
have to hand right now).

-- Luke

From jaltman at secure-endpoints.com  Wed Jul 29 09:10:27 2009
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Wed, 29 Jul 2009 09:10:27 -0400
Subject: How do I use KfW kinit.exe with respect to the Windows	credentials
	cache?
In-Reply-To: <A6CCB94A-EF5A-4C12-89DD-9FA14A3C3A79@jpl.nasa.gov>
References: <mailman.623675.1248532148.7907.krbdev@mit.edu>
	<A6CCB94A-EF5A-4C12-89DD-9FA14A3C3A79@jpl.nasa.gov>
Message-ID: <4A704A43.4080906@secure-endpoints.com>

Henry B.Hotz wrote:

> I thought there was a registry setting to allow that?

There is a registry key that permits third party Kerberos libraries to
export the TGT from the kernel protected LSA cache.  There is no
registry key that provides the reverse.

Beginning with Vista/2008 there is a new API that permits a ticket to be
forwarded to the LSA from third party applications.  However, the
question indicated the platform is XP and the relevant functionality is
not available there.  Even on platforms that do support this
functionality it cannot be used by KfW because MIT's build of the MSLSA:
support was made with the wrong ntsecapi.h header file version and as a
result the support was disabled.

Jeffrey Altman





From jaltman at secure-endpoints.com  Wed Jul 29 09:19:23 2009
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Wed, 29 Jul 2009 09:19:23 -0400
Subject: How do I use KfW kinit.exe with respect to the Windows credentials
	cache?
In-Reply-To: <4A6FA1E0.1050302@exacq.com>
References: <mailman.623675.1248532148.7907.krbdev@mit.edu>	<A6CCB94A-EF5A-4C12-89DD-9FA14A3C3A79@jpl.nasa.gov>
	<4A6FA1E0.1050302@exacq.com>
Message-ID: <4A704C5B.9080503@secure-endpoints.com>

Matthew M. DeLoera wrote:
> Thanks for all the responses. Apologies for not promptly responding.
> 
> I see that my idea isn't supported.
> 
> I think the complication lies in supporting multiple principals. We have 
> a security product that implements a list of 
> servers/usernames/passwords, and stores them in a locally encrypted 
> file. Our client is available for Windows, Linux, and MacOS.

Microsoft has a strong desire to protect all security keys within the
kernel.  As a result they do not want third party credential managers
caching passwords.  Microsoft provides the CredMan API for storing
identities and associated secrets.  The API is much more functional on
Vista and Win7 than on XP.  Of course, its adoption is significantly
limited by the fact that 86% of deployed machines in enterprise
environments are still XP.  (Quoting a recent article on CNET)

> I'm implementing our KRB and LDAP integration. Naturally, the primary 
> thought is Active Directory integration. I'm trying to keep things open 
> for more generic KRB and LDAP integration.
> 
> In Windows, SSPI gives me an easy path to just push the existing 
> username/password/realm that we store in a locally-encrypted file. In a 
> KRB-enabled environment I'd like to not have to manage passwords, 
> because it seems to violate fundamentals. I don't want to integrate 
> directly with MIT KRB, in case we're releasing a DEB for Ubuntu where 
> heimdal has already been installed. MacOS is nice enough to pop up a GUI 
> dialog that interfaces with their keyring facility. Neither Linux nor 
> Windows have that functionality right now.

There is no need to integrate with MIT Kerberos.  If the credentials are
available in the LSA, then MIT Kerberos can make use of them.

> Of course, this deviates from the fundamental idea of only 
> authenticating with a single identity. We're trying to support that 
> perhaps you log on to your workstation as a non-admin user, but you 
> authenticate to our software as an admin user.

Microsoft has one identity per logon session.  If you want to use a
second identity from the same desktop, start a new session using the new
identity.

> I guess it would be nice if there were integration in KfW with the MS 
> credential cache, so that a user could install KfW, kinit as 
> appropriate, and then SSPI would be able to reference those credentials, 
> so that I wouldn't have to maintain passwords. Ideally, some kind of 
> keyring functionality. Similar for Linux.

kinit is not the tool that you want to be using on Windows. It is
specific to the MIT Kerberos libraries.  You want to use Microsoft
provided APIs.

Jeffrey Altman


From lukeh at padl.com  Fri Jul 31 08:01:19 2009
From: lukeh at padl.com (Luke Howard)
Date: Fri, 31 Jul 2009 14:01:19 +0200
Subject: KRB5KDC_ERR_ETYPE_NOSUPP in protocol transition
In-Reply-To: <4A6FCED6.6010109@gs-lab.com>
References: <4A6D70C4.30805@gs-lab.com>
	<6A83EB1F-A560-41E5-8B75-EB2A92F8414C@padl.com>
	<4A6FCED6.6010109@gs-lab.com>
Message-ID: <3B2A5612-4F71-4BA4-AD57-00ADFB964D64@padl.com>

See http://k5wiki.kerberos.org/wiki/Projects/Services4User, too.

-- Luke

From ghudson at MIT.EDU  Fri Jul 31 15:06:03 2009
From: ghudson at MIT.EDU (ghudson@MIT.EDU)
Date: Fri, 31 Jul 2009 15:06:03 -0400 (EDT)
Subject: Integration of k5start/krenew functionality
Message-ID: <200907311906.n6VJ63pH013021@outgoing.mit.edu>

At the request of an OS vendor, we are looking into adding the
functionality of k5start and krenew for the 1.8 release.  I've written
up an early project proposal at:

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

I'm interested in feedback particularly on the interface design
options.  I do not yet have strong opinions about what the interface
should look like, and am willing to spent a little extra time to get
it "right" as opposed to just taking an easy option.
http://www.eyrie.org/~eagle/software/kstart/ has links to the man
pages for k5start and krenew, which may be instructive background.

I'm also interested in any concerns Russ or packagers of the kstart
code might have about the way we do this.

From rra at stanford.edu  Fri Jul 31 15:30:53 2009
From: rra at stanford.edu (Russ Allbery)
Date: Fri, 31 Jul 2009 12:30:53 -0700
Subject: Integration of k5start/krenew functionality
In-Reply-To: <200907311906.n6VJ63pH013021@outgoing.mit.edu> (ghudson@mit.edu's
	message of "Fri\, 31 Jul 2009 15\:06\:03 -0400 \(EDT\)")
References: <200907311906.n6VJ63pH013021@outgoing.mit.edu>
Message-ID: <87iqh8ir9u.fsf@windlord.stanford.edu>

ghudson at mit.edu writes:

> At the request of an OS vendor, we are looking into adding the
> functionality of k5start and krenew for the 1.8 release.

Does that include the AFS token and PAG support?

> I've written up an early project proposal at:
>
>   http://k5wiki.kerberos.org/wiki/Projects/Process_Credential_Management
>
> I'm interested in feedback particularly on the interface design options.
> I do not yet have strong opinions about what the interface should look
> like, and am willing to spent a little extra time to get it "right" as
> opposed to just taking an easy option.
> http://www.eyrie.org/~eagle/software/kstart/ has links to the man pages
> for k5start and krenew, which may be instructive background.

> I'm also interested in any concerns Russ or packagers of the kstart
> code might have about the way we do this.

To note, while the copyrights note that kstart was originally derived from
the kinit code, what it means by that is that the Kerberos v4 k4start was
originally based on the Kerberos v4 kinit code and then k5start was based
on k4start.  You'll find that k5start doesn't have much resemblence to
kinit except insofar as the library API forces similarity.  (Not that this
matters for what you're planning on doing, but I thought I'd clarify.)

My guess is that I would continue to maintain kstart as a separate
package, which may influence how you decide to incorporate the
functionality.  It doesn't change a great deal, but I have found at least
one major new feature to add each year for quite some time.  The next
release, for instance, already has the following significant changes
pending:

    k5start and krenew now catch SIGALRM and immediately refresh the
    ticket cache upon receiving it, even if the ticket isn't expired.

    Add the -i option to krenew, which says to keep running even if there
    is an error renewing the ticket cache.  This is useful if the ticket
    cache renewed by krenew may expire and then later be renewed (such as
    with a manual kinit) and krenew is expected to wake up again and
    process the new ticket cache.

    Re-run aklog even if the ticket is still valid when -H is used in
    combination with -t.  We don't check whether the token is valid, so
    it's safer to always re-run aklog.  We may be setting a token in a new
    PAG using an existing ticket cache.

I have plans to extend the -i option to k5start in the future.  See also
the TODO file in the distribution for other things that should/could be
done.

If you want to integrate the code from kstart, please start from the
current Git repository rather than the last release.

Something else to be aware of if you're looking at incorporating the
current code is that kstart has an extensive test suite that (in the
version in the Git repository) uses C TAP Harness to drive it.  I suspect
you'll want some or all of that test suite for the code in MIT Kerberos,
although as currently written it requires Perl to run.

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

From lukeh at padl.com  Fri Jul 31 19:12:32 2009
From: lukeh at padl.com (Luke Howard)
Date: Sat, 1 Aug 2009 01:12:32 +0200
Subject: Integration of k5start/krenew functionality
In-Reply-To: <87iqh8ir9u.fsf@windlord.stanford.edu>
References: <200907311906.n6VJ63pH013021@outgoing.mit.edu>
	<87iqh8ir9u.fsf@windlord.stanford.edu>
Message-ID: <DAAB8F23-8C19-4EAE-B818-EF8CC97DC272@padl.com>

Also, I wonder if it's worth looking at the kcm I wrote for Heimdal,  
it had (from memory) support for managing host credentials caches.

-- Luke

From raeburn at MIT.EDU  Fri Jul 31 22:24:44 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Fri, 31 Jul 2009 22:24:44 -0400
Subject: Integration of k5start/krenew functionality
In-Reply-To: <200907311906.n6VJ63pH013021@outgoing.mit.edu>
References: <200907311906.n6VJ63pH013021@outgoing.mit.edu>
Message-ID: <2C47D576-AE6E-4D92-8718-484FD881AF9D@mit.edu>

I've wondered before if some of this functionality should be pulled  
into the library or existing programs.  For example, various means  
could be used to express to the library, "if credentials have expired  
or are about to, use this keytab entry to renew them automatically",  
or "after successful TGT acquisition, call this function".

I was going to argue that for the keytab case, at least, we shouldn't  
need a new long-running process to support this fairly simple  
functionality, but the other bits might.  Then I got to thinking about  
the CCAPI and ccache server stuff, where (at least on the Mac) renewal  
and running of additional hooks like token acquisition are handled  
automatically and via a helper process, and how we've had some  
discussions before on the possibility of moving some of the Kerberos  
work out of random processes and into some kind of "Kerberos/GSSAPI  
helper" process.  So, yes, I think maybe this is the right way to go,  
though the UI with these command-line tools is very different from the  
Mac/Windows CCAPI approach in some important respects, and I haven't  
formed an opinion yet whether that's good or bad, or which might be  
better.

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

As for these specific programs -- I think there's a lot of duplicated  
functionality between kinit and k5start, so having one program with a  
few more options may be better... or a helper program to implement the  
other bits, though for some bits that could be as simple as shell code  
running chmod/chown/chgrp on success.  The "wait and see if renewal is  
needed" parts of krenew might reasonably go into program separate from  
kinit, though it's probably okay to merge in too as I wouldn't  
anticipate it could be used in conjunction with anything else besides  
kinit.  Though again, a shell/perl/python script could do some of it  
-- sleep N seconds, run an enhanced "klist -s -H" that'll tell if  
there's a valid TGT with at least X valid lifetime left, run kinit to  
renew, etc.

I guess what I'm suggesting is closest to your option #1, unless the  
process-wrapper bits turn out to be easily scriptable on top of  
existing (possibly slightly enhanced) krb5 programs.  If that's the  
case, maybe we should ship scripts instead of yet more C programs.

Plus maybe that keytab-auto-kinit library enhancement.

Ken