From William.Fiveash at Sun.COM  Tue Sep  2 20:25:34 2008
From: William.Fiveash at Sun.COM (Will Fiveash)
Date: Tue, 2 Sep 2008 19:25:34 -0500
Subject: Requesting review of the Master Key Migration project
Message-ID: <20080903002534.GA4717@sun.com>

I've added a page on the MIT Kerberos Consortium wiki for the Master Key
Migration project.  The URL to the page is:
http://k5wiki.kerberos.org/wiki/Projects/Master_Key_Migration

This project will provide the ability to add a new master key (with an
enctype differing from the current master key) to the master key
principal and stash file and then migrate the encryption of existing
principals long term keys to use the new master key. In addition
deletion of master keys will be provided. 

The review period runs Sept 2-16.

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

From hotz at jpl.nasa.gov  Tue Sep  2 21:17:07 2008
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Tue, 2 Sep 2008 18:17:07 -0700
Subject: MD5DES_BETA5_COMPAT
In-Reply-To: <mailman.453.1219334888.5502.krbdev@mit.edu>
References: <mailman.453.1219334888.5502.krbdev@mit.edu>
Message-ID: <D9A46030-A4D7-4271-9D2A-6E1781EBC5C8@jpl.nasa.gov>


On Aug 21, 2008, at 9:08 AM, krbdev-request at mit.edu wrote:

> Date: Wed, 20 Aug 2008 16:20:52 -0400
> From: Ken Raeburn <raeburn at MIT.EDU>
> Subject: Re: MD5DES_BETA5_COMPAT
> To: Tom Yu <tlyu at MIT.EDU>
> Cc: krbdev at mit.edu
> Message-ID: <5987DCFE-2F9F-4912-80B9-2B5B91484C1E at mit.edu>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> On Aug 20, 2008, at 16:03, Tom Yu wrote:
>> There is some backward compatibility code in the MD5DES and MD4DES
>> keyed hash implementation in our crypto library.  It appears to allow
>> validation of keyed MD5 or MD4 checksums where the sender did not
>> include a confounder.
>>
>> The name macros controlling this compatibility code imply that they
>> were for the "Beta 5" release, which was more than 10 years ago.   
>> Does
>> anyone still require this compatibility hack?
>
> Perhaps another good question is, does anyone still care about any
> sort of backwards compatibility with pre-1.0 releases?  I believe at
> least one vendor is, or was within the last year or so, still
> supporting 1.0.x clients for some customers.  But we may still be able
> to draw a line at 1.0, if not later....
>
> Ken

That would be Oracle?  I'm all for encouraging them to upgrade to a  
current Kerberos code base, and wish you luck with that.  After  
spending the time to figure out how to make their K5 support work, I'm  
left wondering if I could ever in good conscience recommend it to  
anyone, since you have to disable non-DES crypto support.

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




From hotz at jpl.nasa.gov  Wed Sep  3 15:47:17 2008
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Wed, 3 Sep 2008 12:47:17 -0700
Subject: Apple Configuration Information?
Message-ID: <248DC8B0-A235-499A-9C51-2700FD2A0191@jpl.nasa.gov>

Generic Unix has the config file as /etc/krb5.conf.

MacOS prefers /Library/Preferences/edu.mit.Kerberos.

Now I find that under some circumstances MacOS will give preference to  
some configuration information somewhere else.  It has something to do  
with Open Directory;  however I can delete everything in /Library/ 
Preferences/DirectoryService (and reboot) and it *still* overrides the  
others.

Where is it?

(I'd be willing to burn a DTS incident on this if you want, but I  
figure they'd have to ask you guys anyway.  One Apple employee is  
bcc'd if anyone cares.)

------------------------------------------------------
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 gregorio at le.infn.it  Mon Sep  8 10:36:05 2008
From: gregorio at le.infn.it (gregorio@le.infn.it)
Date: Mon,  8 Sep 2008 16:36:05 +0200
Subject: Can't link kadm5 library to my program
Message-ID: <20080908163605.gjszvcj7pmrocc8w@webmail.le.infn.it>

Hello everyone.

I'm trying to create a simple program that uses kadm5's APIs to connect the
admin-server and to do some operations.

But, when I use any function of the kadm5's APIs, the linker (ld) isn't able to
link my program with the correct library.

For Example, if I use kadm5_init_with_password(), ld tells me it can't find that
functions in any library. I tried to manually link the libkadm5clnt to the
program, but ld tells me it can't find libkadm5clnt, even if I use the -L flag
to specify the location where to find the lib.

Does anyone know how to solve this?
Thanks from now.


From William.Fiveash at Sun.COM  Mon Sep  8 18:09:26 2008
From: William.Fiveash at Sun.COM (Will Fiveash)
Date: Mon, 8 Sep 2008 17:09:26 -0500
Subject: Requesting review of the Master Key Migration project
In-Reply-To: <20080903002534.GA4717@sun.com>
References: <20080903002534.GA4717@sun.com>
Message-ID: <20080908220926.GA22993@sun.com>

Reminder, this project is under review.  So far there have been no
review comments on the project page.

On Tue, Sep 02, 2008 at 07:25:34PM -0500, Will Fiveash wrote:
> I've added a page on the MIT Kerberos Consortium wiki for the Master Key
> Migration project.  The URL to the page is:
> http://k5wiki.kerberos.org/wiki/Projects/Master_Key_Migration
> 
> This project will provide the ability to add a new master key (with an
> enctype differing from the current master key) to the master key
> principal and stash file and then migrate the encryption of existing
> principals long term keys to use the new master key. In addition
> deletion of master keys will be provided. 
> 
> The review period runs Sept 2-16.
> 
> -- 
> Will Fiveash
> Sun Microsystems Inc.
> http://opensolaris.org/os/project/kerberos/
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

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

From raeburn at MIT.EDU  Mon Sep  8 19:36:54 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Mon, 8 Sep 2008 19:36:54 -0400
Subject: Requesting review of the Master Key Migration project
In-Reply-To: <20080903002534.GA4717@sun.com>
References: <20080903002534.GA4717@sun.com>
Message-ID: <1B2B18F8-602E-4BAF-851C-B04DE62A0D4B@mit.edu>

On Sep 2, 2008, at 20:25, Will Fiveash wrote:
> I've added a page on the MIT Kerberos Consortium wiki for the Master  
> Key
> Migration project.  The URL to the page is:
> http://k5wiki.kerberos.org/wiki/Projects/Master_Key_Migration


Under "use_mkey <KVNO>", it says, "The kadmind should be stopped/ 
disabled prior to running this command and enabled after successful  
completion."

I'm trying to recall... was there a reason why the change can't be  
done while kadmind is running?  Perhaps it doesn't automatically pick  
up the change, but if we can require just restarting kadmind after the  
update, that's a smaller window of unavailability that having to shut  
it off while manually running commands to update the database.

purge_mkeys: What is the user prompted for?  "Are you sure?"  "This is  
the set I'm going to kill, okay?"  "Kill version 3?  Kill version  
4? ..."

Ken

From rahulkohli2001 at yahoo.com  Wed Sep 10 10:05:39 2008
From: rahulkohli2001 at yahoo.com (Rahul Kohli)
Date: Wed, 10 Sep 2008 07:05:39 -0700 (PDT)
Subject: Application to extract Kerberos Cerdentials
Message-ID: <786910.71656.qm@web34505.mail.mud.yahoo.com>

Hi All,
?
I am using Kerberos Client installed on HP-UX with?Active Directory 2003 (KDC Server).?I have verified the setup to be?working fine using Kinit and Klist utilities installed with Kerberos Client.
?
I need to develop a sample C/C++ application that can extract User's kerberos credentials from the browser HTTP request and pass it to Kerberos Client for validation with KDC Server. 
?
Please suggest how can we extract user's kerberos credentials from Browser. Where can I get details of the API's to be used for this purpose.
?
Thanks,
Rahul
?


      

From hotz at jpl.nasa.gov  Wed Sep 10 13:15:40 2008
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Wed, 10 Sep 2008 10:15:40 -0700
Subject: Application to extract Kerberos Cerdential
In-Reply-To: <mailman.737.1221063477.15024.krbdev@mit.edu>
References: <mailman.737.1221063477.15024.krbdev@mit.edu>
Message-ID: <835B1E34-B115-4FA4-8B0B-05AFB808839F@jpl.nasa.gov>


On Sep 10, 2008, at 9:17 AM, krbdev-request at mit.edu wrote:

> Message: 1
> Date: Wed, 10 Sep 2008 07:05:39 -0700 (PDT)
> From: Rahul Kohli <rahulkohli2001 at yahoo.com>
> Subject: Application to extract Kerberos Cerdentials
> To: krbdev at mit.edu
> Message-ID: <786910.71656.qm at web34505.mail.mud.yahoo.com>
> Content-Type: text/plain; charset=iso-8859-1
>
> Hi All,
> ?
> I am using Kerberos Client installed on HP-UX with?Active Directory  
> 2003 (KDC Server).?I have verified the setup to be?working fine  
> using Kinit and Klist utilities installed with Kerberos Client.
> ?
> I need to develop a sample C/C++ application that can extract User's  
> kerberos credentials from the browser HTTP request and pass it to  
> Kerberos Client for validation with KDC Server.
> ?
> Please suggest how can we extract user's kerberos credentials from  
> Browser. Where can I get details of the API's to be used for this  
> purpose.
> ?
> Thanks,
> Rahul
> ?

I think this kind of question belongs on the kerberos at mit.edu list,  
since it's not specific to the MIT implementation.  I've set the reply- 
to header accordingly.

I don't understand the application you're proposing.  Is it possible  
that what you want is really a web server module like mod_auth_kerb?   
I can't imagine why you would want a *browser* to check a user's  
credentials because the user owns the browser and can run whichever  
one he/she wants, including a custom-modified one.

For the normal usage scenarios the "extraction" process happens  
automatically as part of some other task.  If you can tell us what  
you're trying to do, then perhaps we can point you at the right API's.

From rahulkohli2001 at yahoo.com  Wed Sep 10 15:59:01 2008
From: rahulkohli2001 at yahoo.com (Rahul Kohli)
Date: Wed, 10 Sep 2008 12:59:01 -0700 (PDT)
Subject: Application to extract Kerberos Cerdential
In-Reply-To: <835B1E34-B115-4FA4-8B0B-05AFB808839F@jpl.nasa.gov>
Message-ID: <412398.5412.qm@web34503.mail.mud.yahoo.com>

Hi Henry,
?
Thanks for your response.
?
This C application (shared library)?will be used for validating the kerberos credential of a user with KDC on Microsoft AD 2003.
?
Please suggest how we can use/develop a?C application?to validate user's kerberos credentials with KDC located on different system. 
?
Any pointers to this will be of great help.
?
Thanks,
Rahul
?
?


--- On Wed, 9/10/08, Henry B. Hotz <hotz at jpl.nasa.gov> wrote:

From: Henry B. Hotz <hotz at jpl.nasa.gov>
Subject: Re: Application to extract Kerberos Cerdential
To: "krbdev at mit.edu" <krbdev at mit.edu>
Date: Wednesday, September 10, 2008, 10:45 PM

On Sep 10, 2008, at 9:17 AM, krbdev-request at mit.edu wrote:

> Message: 1
> Date: Wed, 10 Sep 2008 07:05:39 -0700 (PDT)
> From: Rahul Kohli <rahulkohli2001 at yahoo.com>
> Subject: Application to extract Kerberos Cerdentials
> To: krbdev at mit.edu
> Message-ID: <786910.71656.qm at web34505.mail.mud.yahoo.com>
> Content-Type: text/plain; charset=iso-8859-1
>
> Hi All,
> ?
> I am using Kerberos Client installed on HP-UX with?Active Directory  
> 2003 (KDC Server).?I have verified the setup to be?working fine  
> using Kinit and Klist utilities installed with Kerberos Client.
> ?
> I need to develop a sample C/C++ application that can extract User's  
> kerberos credentials from the browser HTTP request and pass it to  
> Kerberos Client for validation with KDC Server.
> ?
> Please suggest how can we extract user's kerberos credentials from  
> Browser. Where can I get details of the API's to be used for this  
> purpose.
> ?
> Thanks,
> Rahul
> ?

I think this kind of question belongs on the kerberos at mit.edu list,  
since it's not specific to the MIT implementation.  I've set the reply-

to header accordingly.

I don't understand the application you're proposing.  Is it possible  
that what you want is really a web server module like mod_auth_kerb?   
I can't imagine why you would want a *browser* to check a user's  
credentials because the user owns the browser and can run whichever  
one he/she wants, including a custom-modified one.

For the normal usage scenarios the "extraction" process happens  
automatically as part of some other task.  If you can tell us what  
you're trying to do, then perhaps we can point you at the right API's.
_______________________________________________
krbdev mailing list             krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev



      

From William.Fiveash at Sun.COM  Wed Sep 10 20:31:47 2008
From: William.Fiveash at Sun.COM (Will Fiveash)
Date: Wed, 10 Sep 2008 19:31:47 -0500
Subject: Requesting review of the Master Key Migration project
In-Reply-To: <1B2B18F8-602E-4BAF-851C-B04DE62A0D4B@mit.edu>
References: <20080903002534.GA4717@sun.com>
	<1B2B18F8-602E-4BAF-851C-B04DE62A0D4B@mit.edu>
Message-ID: <20080911003147.GB22993@sun.com>

On Mon, Sep 08, 2008 at 07:36:54PM -0400, Ken Raeburn wrote:
> On Sep 2, 2008, at 20:25, Will Fiveash wrote:
>> I've added a page on the MIT Kerberos Consortium wiki for the Master  
>> Key
>> Migration project.  The URL to the page is:
>> http://k5wiki.kerberos.org/wiki/Projects/Master_Key_Migration
>
>
> Under "use_mkey <KVNO>", it says, "The kadmind should be stopped/ 
> disabled prior to running this command and enabled after successful  
> completion."
>
> I'm trying to recall... was there a reason why the change can't be done 
> while kadmind is running?  Perhaps it doesn't automatically pick up the 
> change, but if we can require just restarting kadmind after the update, 
> that's a smaller window of unavailability that having to shut it off 
> while manually running commands to update the database.

Right, it was for updating the current MKVNO in the kadmind.  I'll
modify that to say the kadmind and krb5kdc (for the same reason, yes?)
should be restarted to pick up the change.

> purge_mkeys: What is the user prompted for?  "Are you sure?"  "This is  
> the set I'm going to kill, okay?"  "Kill version 3?  Kill version 4? ..."

The prompt will be "Delete version 3 master key for the FOO.COM realm?  [y/n]"

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

From Glenn.Barry at sun.com  Thu Sep 11 01:33:59 2008
From: Glenn.Barry at sun.com (Glenn Barry)
Date: Wed, 10 Sep 2008 22:33:59 -0700
Subject: pkinit kinit/krb5.conf naming inconsistencies
Message-ID: <48C8ADC7.8020700@sun.com>


Nico noticed kinit -X attribute and krb5.conf option inconsistencies 
such as:

kinit -X
    X509_user_identity=value

krb5.conf
    pkinit_identity/pkinit_identities

(and likewise for *_anchors)

Is there a good reason for these to be diff?

thx.


From kwc at umich.edu  Sat Sep 13 19:51:09 2008
From: kwc at umich.edu (Kevin Coffman)
Date: Sat, 13 Sep 2008 19:51:09 -0400
Subject: pkinit kinit/krb5.conf naming inconsistencies
In-Reply-To: <48C8ADC7.8020700@sun.com>
References: <48C8ADC7.8020700@sun.com>
Message-ID: <4d569c330809131651s63efe8c9m4a2ae09a16c1fd09@mail.gmail.com>

On Thu, Sep 11, 2008 at 1:33 AM, Glenn Barry <Glenn.Barry at sun.com> wrote:
>
> Nico noticed kinit -X attribute and krb5.conf option inconsistencies
> such as:
>
> kinit -X
>    X509_user_identity=value
>
> krb5.conf
>    pkinit_identity/pkinit_identities
>
> (and likewise for *_anchors)
>
> Is there a good reason for these to be diff?

Hi Glenn,

Yes, as I recall, there was.

We were making an effort to match the options in the config file with
those used by Heimdal where possible.

For the "-X" preauth options, Sam did not want them to be
pkinit-specific since they could possibly be used with other preauth
methods in the future.

K.C.

From Nicolas.Williams at sun.com  Mon Sep 15 10:01:40 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 15 Sep 2008 09:01:40 -0500
Subject: pkinit kinit/krb5.conf naming inconsistencies
In-Reply-To: <4d569c330809131651s63efe8c9m4a2ae09a16c1fd09@mail.gmail.com>
References: <48C8ADC7.8020700@sun.com>
	<4d569c330809131651s63efe8c9m4a2ae09a16c1fd09@mail.gmail.com>
Message-ID: <20080915140140.GX1875@Sun.COM>

On Sat, Sep 13, 2008 at 07:51:09PM -0400, Kevin Coffman wrote:
> On Thu, Sep 11, 2008 at 1:33 AM, Glenn Barry <Glenn.Barry at sun.com> wrote:
> > Is there a good reason for these to be diff?
> 
> Hi Glenn,
> 
> Yes, as I recall, there was.
> 
> We were making an effort to match the options in the config file with
> those used by Heimdal where possible.
> 
> For the "-X" preauth options, Sam did not want them to be
> pkinit-specific since they could possibly be used with other preauth
> methods in the future.

That makes sense, but perhaps the right answer would be to provide
Heimdal-compatible aliases for use in krb5.conf while having the same
canonical parameter names for both, krb5.conf and kinit -x.

It's one thing to be compatible with another implementation's
configuration parameter names.  It's another to make things confusing
for the user.  We can have the former without the latter.  Yes, it's
more code -- how much more depends on whether the parameter value
syntaxes can be compatible even with diff. param. names -- but from a UI
p.o.v. it's quite useful.

Nico
-- 

From kwc at umich.edu  Mon Sep 15 11:23:53 2008
From: kwc at umich.edu (Kevin Coffman)
Date: Mon, 15 Sep 2008 11:23:53 -0400
Subject: pkinit kinit/krb5.conf naming inconsistencies
In-Reply-To: <20080915140140.GX1875@Sun.COM>
References: <48C8ADC7.8020700@sun.com>
	<4d569c330809131651s63efe8c9m4a2ae09a16c1fd09@mail.gmail.com>
	<20080915140140.GX1875@Sun.COM>
Message-ID: <4d569c330809150823t4a16b786ob62c4dca3484f5ba@mail.gmail.com>

On Mon, Sep 15, 2008 at 10:01 AM, Nicolas Williams
<Nicolas.Williams at sun.com> wrote:
> On Sat, Sep 13, 2008 at 07:51:09PM -0400, Kevin Coffman wrote:
>> On Thu, Sep 11, 2008 at 1:33 AM, Glenn Barry <Glenn.Barry at sun.com> wrote:
>> > Is there a good reason for these to be diff?
>>
>> Hi Glenn,
>>
>> Yes, as I recall, there was.
>>
>> We were making an effort to match the options in the config file with
>> those used by Heimdal where possible.
>>
>> For the "-X" preauth options, Sam did not want them to be
>> pkinit-specific since they could possibly be used with other preauth
>> methods in the future.
>
> That makes sense, but perhaps the right answer would be to provide
> Heimdal-compatible aliases for use in krb5.conf while having the same
> canonical parameter names for both, krb5.conf and kinit -x.
>
> It's one thing to be compatible with another implementation's
> configuration parameter names.  It's another to make things confusing
> for the user.  We can have the former without the latter.  Yes, it's
> more code -- how much more depends on whether the parameter value
> syntaxes can be compatible even with diff. param. names -- but from a UI
> p.o.v. it's quite useful.
>
> Nico
> --

I'm not arguing your points, but my opinion is that the "normal" user
is/was going to see a command-line UI difference between Heimdal and
MIT in any case.  The "normal" user will not notice the difference
between MIT command-line and config file because they will never deal
with the config file.

K.C.

From Nicolas.Williams at sun.com  Mon Sep 15 13:38:44 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 15 Sep 2008 12:38:44 -0500
Subject: pkinit kinit/krb5.conf naming inconsistencies
In-Reply-To: <4d569c330809150823t4a16b786ob62c4dca3484f5ba@mail.gmail.com>
References: <48C8ADC7.8020700@sun.com>
	<4d569c330809131651s63efe8c9m4a2ae09a16c1fd09@mail.gmail.com>
	<20080915140140.GX1875@Sun.COM>
	<4d569c330809150823t4a16b786ob62c4dca3484f5ba@mail.gmail.com>
Message-ID: <20080915173844.GA1875@Sun.COM>

On Mon, Sep 15, 2008 at 11:23:53AM -0400, Kevin Coffman wrote:
> I'm not arguing your points, but my opinion is that the "normal" user
> is/was going to see a command-line UI difference between Heimdal and
> MIT in any case.  The "normal" user will not notice the difference
> between MIT command-line and config file because they will never deal
> with the config file.

Huh?  But you just told us that it's the krb5.conf parameters that were
named to be compatible with Heimdal, that Sam wanted the command-line
parameters to be more generic.

I'm confused.

And besides, I care about the sysadmins too.

Nico
-- 

From jhutz at cmu.edu  Mon Sep 15 15:54:06 2008
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Mon, 15 Sep 2008 15:54:06 -0400
Subject: pkinit kinit/krb5.conf naming inconsistencies
In-Reply-To: <200809151424.m8FEOc4q014467@toasties.srv.cs.cmu.edu>
References: <48C8ADC7.8020700@sun.com>
	<4d569c330809131651s63efe8c9m4a2ae09a16c1fd09@mail.gmail.com>
	<200809151424.m8FEOc4q014467@toasties.srv.cs.cmu.edu>
Message-ID: <0AB3F93C6614C448DF99987C@sirius.fac.cs.cmu.edu>

--On Monday, September 15, 2008 09:01:40 AM -0500 Nicolas Williams 
<Nicolas.Williams at sun.com> wrote:

> That makes sense, but perhaps the right answer would be to provide
> Heimdal-compatible aliases for use in krb5.conf while having the same
> canonical parameter names for both, krb5.conf and kinit -x.

Ugh ugh ugh.
If you have two parameters that do the same thing, and both are given, 
which one is used?  Isn't it bad for the answer to be "it depends on which 
implementation you happen to be using", on a system where both exist?

-- Jeff

From Nicolas.Williams at sun.com  Mon Sep 15 16:28:05 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 15 Sep 2008 15:28:05 -0500
Subject: pkinit kinit/krb5.conf naming inconsistencies
In-Reply-To: <0AB3F93C6614C448DF99987C@sirius.fac.cs.cmu.edu>
References: <48C8ADC7.8020700@sun.com>
	<4d569c330809131651s63efe8c9m4a2ae09a16c1fd09@mail.gmail.com>
	<200809151424.m8FEOc4q014467@toasties.srv.cs.cmu.edu>
	<0AB3F93C6614C448DF99987C@sirius.fac.cs.cmu.edu>
Message-ID: <20080915202805.GK1875@Sun.COM>

On Mon, Sep 15, 2008 at 03:54:06PM -0400, Jeffrey Hutzelman wrote:
> >That makes sense, but perhaps the right answer would be to provide
> >Heimdal-compatible aliases for use in krb5.conf while having the same
> >canonical parameter names for both, krb5.conf and kinit -x.
> 
> Ugh ugh ugh.
> If you have two parameters that do the same thing, and both are given, 
> which one is used?  Isn't it bad for the answer to be "it depends on which 
> implementation you happen to be using", on a system where both exist?

I really don't care for Heimdal-compatible configuration parameters.

But I don't mind them.

What I object to is an inconsistent UI (when you consider sysadmins and
users both).  And I agree with your observation, aliases would be bad.

So pick one: x509_* or pkinit_*.

Alternatively: have aliases only for kinit -x param names.

I'm assuming that Heimdal's kinit doesn't have this -x thing, that in
Heimdal if you want to override the system's krb5.conf you should use
the KRB5_CONFIG environment variable.

From Nicolas.Williams at sun.com  Mon Sep 15 17:09:04 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 15 Sep 2008 16:09:04 -0500
Subject: pkinit kinit/krb5.conf naming inconsistencies
In-Reply-To: <20080915202805.GK1875@Sun.COM>
References: <48C8ADC7.8020700@sun.com>
	<4d569c330809131651s63efe8c9m4a2ae09a16c1fd09@mail.gmail.com>
	<200809151424.m8FEOc4q014467@toasties.srv.cs.cmu.edu>
	<0AB3F93C6614C448DF99987C@sirius.fac.cs.cmu.edu>
	<20080915202805.GK1875@Sun.COM>
Message-ID: <20080915210904.GW1875@Sun.COM>

THe more I think about this the more I dislike having this different
parameter prefix.

Moreover, I wonder why only PKINIT-related parameters should be settable
via kinit -x, and not other krb5.conf parameters such as, say,
default_tkt_enctypes (that would complicate the -x option somewhat in
that a config file section would be needed for some parameters).

So, I think that MIT should reconsider this kinit -x option.

Also, Jeff H. mentions (offline) the possibility of doing
PKINIT-over-StartTLS.  That would certainly render the x509_ prefix very
confusing!  IMO it'd be much better to wait until MIT krb5 gets a
StartTLS implementation before adding parameters with such a generic
prefix.

Nico
-- 

From hotz at jpl.nasa.gov  Tue Sep 16 16:45:46 2008
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Tue, 16 Sep 2008 13:45:46 -0700
Subject: pkinit kinit/krb5.conf naming inconsistencies
In-Reply-To: <mailman.697.1221581528.8662.krbdev@mit.edu>
References: <mailman.697.1221581528.8662.krbdev@mit.edu>
Message-ID: <E6D9291A-3AE0-4CC9-B103-A701E2C89ABE@jpl.nasa.gov>


On Sep 16, 2008, at 9:12 AM, krbdev-request at mit.edu wrote:

> I'm assuming that Heimdal's kinit doesn't have this -x thing, that in
> Heimdal if you want to override the system's krb5.conf you should use
> the KRB5_CONFIG environment variable.


I care a lot more about rationalizing the krb5.conf file than the  
command line options.  For reference:

kinit --pk-user=<x509 identity> --x509-anchors=<directory> --pk-use- 
enckey ...

Option aliases are -C and -D respectively.  <x509 identity> is usually  
a FILE:... or PKCS11:... value.  I've never actually used the other two.

There's no generic "override a config file option" option, just a few  
environment variables like KRB5_CONFIG.

------------------------------------------------------
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  Tue Sep 16 16:54:01 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 16 Sep 2008 15:54:01 -0500
Subject: pkinit kinit/krb5.conf naming inconsistencies
In-Reply-To: <E6D9291A-3AE0-4CC9-B103-A701E2C89ABE@jpl.nasa.gov>
References: <mailman.697.1221581528.8662.krbdev@mit.edu>
	<E6D9291A-3AE0-4CC9-B103-A701E2C89ABE@jpl.nasa.gov>
Message-ID: <20080916205401.GM1875@Sun.COM>

On Tue, Sep 16, 2008 at 01:45:46PM -0700, Henry B. Hotz wrote:
> On Sep 16, 2008, at 9:12 AM, krbdev-request at mit.edu wrote:
> >I'm assuming that Heimdal's kinit doesn't have this -x thing, that in
> >Heimdal if you want to override the system's krb5.conf you should use
> >the KRB5_CONFIG environment variable.
> 
> 
> I care a lot more about rationalizing the krb5.conf file than the  
> command line options.  For reference:

Meaning what?  That you don't care about the difference in naming in
kinit -x?

> kinit --pk-user=<x509 identity> --x509-anchors=<directory> --pk-use- 
> enckey ...

Is the above how Heimdal does it?  I don't mind that, but I do mind
kinit -x <param-name-that-doesn't-relate-to-krb5.conf>.

In any case, I suppose that MIT filibusters by silence, thus nothing
will change and I'm just wasting my time.

Nico
-- 

From hotz at jpl.nasa.gov  Wed Sep 17 01:54:51 2008
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Tue, 16 Sep 2008 22:54:51 -0700
Subject: pkinit kinit/krb5.conf naming inconsistencies
In-Reply-To: <20080916205401.GM1875@Sun.COM>
References: <mailman.697.1221581528.8662.krbdev@mit.edu>
	<E6D9291A-3AE0-4CC9-B103-A701E2C89ABE@jpl.nasa.gov>
	<20080916205401.GM1875@Sun.COM>
Message-ID: <12195BB7-30B1-41DC-890A-16FEABAFF348@jpl.nasa.gov>


On Sep 16, 2008, at 1:54 PM, Nicolas Williams wrote:

> On Tue, Sep 16, 2008 at 01:45:46PM -0700, Henry B. Hotz wrote:
>> On Sep 16, 2008, at 9:12 AM, krbdev-request at mit.edu wrote:
>>> I'm assuming that Heimdal's kinit doesn't have this -x thing, that  
>>> in
>>> Heimdal if you want to override the system's krb5.conf you should  
>>> use
>>> the KRB5_CONFIG environment variable.
>>
>>
>> I care a lot more about rationalizing the krb5.conf file than the
>> command line options.  For reference:
>
> Meaning what?  That you don't care about the difference in naming in
> kinit -x?

Actually I don't see a -x option in 1.6.x either.  From context, I'm  
assuming that you follow it with some krb5.conf item you want to  
override?  If so, that would make my distinction meaningless.

>> kinit --pk-user=<x509 identity> --x509-anchors=<directory> --pk-use-
>> enckey ...
>
> Is the above how Heimdal does it?  I don't mind that, but I do mind
> kinit -x <param-name-that-doesn't-relate-to-krb5.conf>.
>
> In any case, I suppose that MIT filibusters by silence, thus nothing
> will change and I'm just wasting my time.

Who has commit rights?

I learned to have a lot of respect for Sam.  He seemed to have good  
reasons for what he was doing (and what he rejected).  OTOH I've  
always felt that MIT isn't as receptive as a normal open source  
project needs to be to keep volunteers interested.

> Nico
> --


From Nicolas.Williams at sun.com  Wed Sep 17 01:59:15 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 17 Sep 2008 00:59:15 -0500
Subject: pkinit kinit/krb5.conf naming inconsistencies
In-Reply-To: <12195BB7-30B1-41DC-890A-16FEABAFF348@jpl.nasa.gov>
References: <mailman.697.1221581528.8662.krbdev@mit.edu>
	<E6D9291A-3AE0-4CC9-B103-A701E2C89ABE@jpl.nasa.gov>
	<20080916205401.GM1875@Sun.COM>
	<12195BB7-30B1-41DC-890A-16FEABAFF348@jpl.nasa.gov>
Message-ID: <20080917055915.GQ1875@Sun.COM>

On Tue, Sep 16, 2008 at 10:54:51PM -0700, Henry B. Hotz wrote:
> On Sep 16, 2008, at 1:54 PM, Nicolas Williams wrote:
> >On Tue, Sep 16, 2008 at 01:45:46PM -0700, Henry B. Hotz wrote:
> >Meaning what?  That you don't care about the difference in naming in
> >kinit -x?
> 
> Actually I don't see a -x option in 1.6.x either.  From context, I'm  
> assuming that you follow it with some krb5.conf item you want to  
> override?  If so, that would make my distinction meaningless.

That's exactly the thing: it's not some krb5.conf item, but something
named annoyingly different from what's used in krb5.conf.

Nico
-- 

From christian.jung at saarstahl.com  Wed Sep 17 03:35:27 2008
From: christian.jung at saarstahl.com (JUNG, Christian)
Date: Wed, 17 Sep 2008 09:35:27 +0200
Subject: Binding kadmind to a specific virtual IP
Message-ID: <24BB5F92CE3E62419C5A6D5B1A1E0F46028E17FD@nts58.saarstahl.de>

Hi,

I've seen a similar posting on the mailing list (see <http://mailman.mit.edu/pipermail/krbdev/2007-November/006327.html>):

On Nov 12, 2007, at 09:08, Shivakeshav Santi wrote:
>     Does kerberos provide an option where one could bind the krb5kdc,
> kadmind,kadmind4 and krb524d to a specific virtual IP. I have a  
> machine (set of machines) which have multiple virtual ips, so can I 
> bind KDC to a single IP . Right now it listens on all IPs.

I'd like to build a HA cluster. We do this the following way:

Let's have two nodes. Every node got its own IP (node 1: 10.0.10.11, node 2: 10.0.10.12). The cluster itself has the IP 10.0.10.10 which is only active on one node (e.g. node 1).

Every service gets his own IP too (e.g. kerberos 10.0.10.13). My problem: If a user makes a password change request via kpasswd, she sends a UDP packet to the kadmind process listening on port 464. kadmind then makes the password change and sends the answer to the client via UDP. 

But the answer of kadmind comes from the first assigned IP of the interface the kernel sends out the packet. Assuming Kerberos is running on node 2 this would be 10.0.10.12 instead of 10.0.10.13.

This is annoying because the clients prints out the message 'kpasswd: Incorrect net address changing password' despite the fact, that the password change was successful.

I'd like to implement a generic way to tell all core services of the MIT Kerberos implementation to which IPs/Ports they should bind. Does anybody has got suggestions for this topic?


bye
Chris

-- 
phone: +49 6898/10-4987
web  : www.saarstahl.de
mail : Hofstattstra?e 106a
       D 66333 Voelklingen


From josephharfouch at iinet.net.au  Wed Sep 17 05:58:58 2008
From: josephharfouch at iinet.net.au (josephharfouch@iinet.net.au)
Date: Wed, 17 Sep 2008 17:58:58 +0800
Subject: MANDATORY-FOR-KDC elements and RFC 4120 
Message-ID: <5670.1221645538@iinet.net.au>

Hi, 

RFC 4120 (1.5.1.  Compatibility with RFC 1510) states that the The
ticket-granting service MUST 
reject such elements.  

I can't find in RFC 4120 what error code should be sent back in this case.  Would
the following error code out of RFC 4120 be a good choice, or there a better
error code that is expected in this case ? 
 KDC_ERR_POLICY                        12  KDC policy rejects request


Thanks


Joseph 


From sbuckley at MIT.EDU  Wed Sep 17 06:27:26 2008
From: sbuckley at MIT.EDU (Stephen C. Buckley)
Date: Wed, 17 Sep 2008 06:27:26 -0400
Subject: pkinit kinit/krb5.conf naming inconsistencies
In-Reply-To: <20080916205401.GM1875@Sun.COM>
References: <mailman.697.1221581528.8662.krbdev@mit.edu>
	<E6D9291A-3AE0-4CC9-B103-A701E2C89ABE@jpl.nasa.gov>
	<20080916205401.GM1875@Sun.COM>
Message-ID: <B1543915-A208-45D8-84B1-AC32B57AC558@mit.edu>


On Sep 16, 2008, at 4:54 PM, Nicolas Williams wrote:
>
> In any case, I suppose that MIT filibusters by silence, thus nothing
> will change and I'm just wasting my time.
>
> Nico

Hi Nico,

Not quite.  We have a process in place where the Kerberos Consortium  
Board sets the priorities for how the MIT staff spends its time.   
This allows us to more strategic, and maybe a little less able to to  
jump into a discussion that suddenly erupts on one of the lists.

Tom, feel free to jump in here, but isn't one of our unprioritized  
objectives to merge the UMich and Apple pkinit code and we could  
potentially fix this problem as part of that the project?

s

From tlyu at MIT.EDU  Wed Sep 17 10:36:12 2008
From: tlyu at MIT.EDU (Tom Yu)
Date: Wed, 17 Sep 2008 10:36:12 -0400
Subject: pkinit kinit/krb5.conf naming inconsistencies
In-Reply-To: <B1543915-A208-45D8-84B1-AC32B57AC558@mit.edu> (Stephen C.
	Buckley's message of "Wed, 17 Sep 2008 06:27:26 -0400")
References: <mailman.697.1221581528.8662.krbdev@mit.edu>
	<E6D9291A-3AE0-4CC9-B103-A701E2C89ABE@jpl.nasa.gov>
	<20080916205401.GM1875@Sun.COM>
	<B1543915-A208-45D8-84B1-AC32B57AC558@mit.edu>
Message-ID: <ldviqsug7qb.fsf@cathode-dark-space.mit.edu>

"Stephen C. Buckley" <sbuckley at MIT.EDU> writes:

> On Sep 16, 2008, at 4:54 PM, Nicolas Williams wrote:
>>
>> In any case, I suppose that MIT filibusters by silence, thus nothing
>> will change and I'm just wasting my time.
>>
>> Nico
>
> Hi Nico,
>
> Not quite.  We have a process in place where the Kerberos Consortium  
> Board sets the priorities for how the MIT staff spends its time.   
> This allows us to more strategic, and maybe a little less able to to  
> jump into a discussion that suddenly erupts on one of the lists.
>
> Tom, feel free to jump in here, but isn't one of our unprioritized  
> objectives to merge the UMich and Apple pkinit code and we could  
> potentially fix this problem as part of that the project?

One of our medium-term goals is to merge the UMich and Apple pkinit
implementations in some way.  Feedback on the pkinit user interfaces
and other aspects of pkinit is welcome and appreciated.

To Nico: Thank you for pointing out the inconsistency in the pkinit
user interface.  I am currently investigating why this is the case.

-- 
Tom Yu
Development Manager
MIT Kerberos Consortium

From Nicolas.Williams at sun.com  Wed Sep 17 11:06:00 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 17 Sep 2008 10:06:00 -0500
Subject: pkinit kinit/krb5.conf naming inconsistencies
In-Reply-To: <ldviqsug7qb.fsf@cathode-dark-space.mit.edu>
References: <mailman.697.1221581528.8662.krbdev@mit.edu>
	<E6D9291A-3AE0-4CC9-B103-A701E2C89ABE@jpl.nasa.gov>
	<20080916205401.GM1875@Sun.COM>
	<B1543915-A208-45D8-84B1-AC32B57AC558@mit.edu>
	<ldviqsug7qb.fsf@cathode-dark-space.mit.edu>
Message-ID: <20080917150600.GT1875@Sun.COM>

On Wed, Sep 17, 2008 at 10:36:12AM -0400, Tom Yu wrote:
> "Stephen C. Buckley" <sbuckley at MIT.EDU> writes:
> > On Sep 16, 2008, at 4:54 PM, Nicolas Williams wrote:
> >> In any case, I suppose that MIT filibusters by silence, thus nothing
> >> will change and I'm just wasting my time.
> >
> > Not quite.  We have a process in place where the Kerberos Consortium  
> > Board sets the priorities for how the MIT staff spends its time.   
> > This allows us to more strategic, and maybe a little less able to to  
> > jump into a discussion that suddenly erupts on one of the lists.
> >
> > Tom, feel free to jump in here, but isn't one of our unprioritized  
> > objectives to merge the UMich and Apple pkinit code and we could  
> > potentially fix this problem as part of that the project?
> 
> One of our medium-term goals is to merge the UMich and Apple pkinit
> implementations in some way.  Feedback on the pkinit user interfaces
> and other aspects of pkinit is welcome and appreciated.
> 
> To Nico: Thank you for pointing out the inconsistency in the pkinit
> user interface.  I am currently investigating why this is the case.

Excellent, I appreciate that.

Thanks,

Nico
-- 

From gregorio at le.infn.it  Wed Sep 17 09:32:03 2008
From: gregorio at le.infn.it (gregorio@le.infn.it)
Date: Wed, 17 Sep 2008 15:32:03 +0200
Subject: GSS API error while connecting to the admin server
Message-ID: <20080917153203.6plqec2xzn4skg8s@webmail.le.infn.it>

Hello everyone.

I need to connect to the admin server to do some operations, so I started to
write a little program that tries to connect to the server.

Here is the code:

#include <stdio.h>
#include <string.h>
#include <krb5.h>

int main (int argc, const char* argv[]) {
        krb5_context context;
        int err;
        char *svcname = NULL;
        void *handle = NULL;
        long retval;

        err = kadm5_init_krb5_context(&context);
        printf("init context: %d\n", err);

        printf("trying init...\n");

        retval = kadm5_init_with_password("admin/admin", "password",
"service_name",  "REALM", 0x12345600|0x01, 0x12345700|0x01, &handle);
        printf("result: %d\n\n", retval);

        return 0;
}


When I execute it, I have this result for the kadm5_init_with_password function:

result: 43787566

and I find these in the kadmind log file:

kadmind[10779](Notice): Authentication attempt failed: 192.84.152.159, GSS-API
error strings are:
kadmind[10779](Notice):     Unspecified GSS failure.  Minor code may provide
more information
kadmind[10779](Notice):     Unknown code krb5 144
kadmind[10779](Notice):    GSS-API error strings complete.

Any suggestion on how to solve this?

Thanks everyone from now!


From William.Fiveash at Sun.COM  Wed Sep 17 20:04:46 2008
From: William.Fiveash at Sun.COM (Will Fiveash)
Date: Wed, 17 Sep 2008 19:04:46 -0500
Subject: thoughts/issues making MIT krb code fit for drop-in to Solaris
Message-ID: <20080918000446.GA5266@sun.com>

One goal Sun has in regards to it's association with the MIT Kerberos
Consortium is to eventually have the Consortium's Kerberos source code
made suitable to use as is in Solaris (drop-in).  This would save Sun
time and effort in that resync'ing the Consortium's source code with the
Solaris Kerberos source code could be avoided.

One approach suggested by Nico Williams is to do this by modifying one
MITKC component at a time to keep each project smaller in scope.  The
following components would be updated in an order like:

 - Raw Kerberos components
                          
    - libkrb5             
    - libkadm5*
    - utilities (kinit, kdestroy, klist, ktutil, kvno)
    - krb5kdc, kadmind, kadmin, kadmin.local, kdb5_util, ...
    - KDB plugins
    - CCAPI              

 - GSS-API Kerberos V mechanism related components
                                                  
    - mech_krb5 (and implied libgss, mech_dh changes)
    - mech_spnego (and implied libgss, mech_dh changes)
    - libgss (and mech_dh changes)                     

 - misc
       
    - RPCSEC_GSS API diffs (which impact libkadm5* and kadmin* somewhat)

So initially (and most importantly) the libkrb5 code would be modified
and once that project is done, other components could be modified as
additional projects. 

To help understand what this entails, the following is a list of various
differences between the MITKC and Solaris mech_krb5/libkrb5 source code.

- Crypto Framework

    Solaris Kerberos uses the native Solaris Encryption Framework
    interfaces for it's crypto needs in both user and kernel space.
    This mainly involves changes to files under src/lib/crypto. Note
    that the _krb5_keyblock has also been modified:

typedef struct _krb5_keyblock {
    krb5_magic magic;
    krb5_enctype enctype;
    unsigned int length;
    krb5_octet *contents;
    krb5_dk_node   *dk_list; /* list of keys derived from this key */
#ifdef _KERNEL
    crypto_mech_type_t     kef_mt;
    crypto_key_t           kef_key;
    crypto_ctx_template_t  key_tmpl;
#else
    CK_OBJECT_HANDLE       hKey; /* PKCS#11 key object handle */
    pid_t	pid; /* fork safety */
#endif /* _KERNEL */
} krb5_keyblock;

    This creates an ABI difference between Solaris and MIT.

- I18N, error tables and messages in general.

    MIT dynamically generates their error tables, Solaris uses a static
    switch statement in various C files based on the MIT error tables.
    For example, in OpenSolaris there is this code in
    usr/src/lib/gss_mechs/mech_krb5/et/chpass_util_strings.c:

const char *
ovku_error_table(long errorno) {

switch (errorno) {
        case 0:
                return (dgettext(TEXT_DOMAIN,
                        "while getting policy info.\n"));
        case 1:
                return (dgettext(TEXT_DOMAIN,
                        "while getting principal info.\n"));
...

    Solaris krb may have some diffs in the message strings. etc...  
    
    Also Solaris calls gettext() to translate various non-error table
    messages.  Anyway, this is an area that we need to research further
    to find a reasonable solution.

- User space and kernel space krb mechs

    Solaris provides a krb mech that is comparable in function to the
    MIT krb mech in user space and in addition Solaris has a krb mech as
    a kernel module.  This provides a subset of the user space krb mech
    function to basically support NFS security needs.  One implication
    of this is that not all library functions used by the user space krb
    mech are available in the kernel.

- Auditing

    There are 74 calls in the Solaris code base to Basic Security Module
    auditing routines.

- rpcsec_gss(3NSL) API differences

    There may be rpcsec_gss(3NSL) API differences too (for kadmin
    support of use of kadmin/changepw instead of kadmin/host.FQDN
    service princs -- the Solaris API comes up short).

- Changes in *.conf files and other parameters?

    - File locations - default krb5.conf, kdc.conf in /etc/krb5
    - Different defaults for some configuration variables

- Some diffs due to KDB LDAP plugin port

    The diffs can be seen by doing
    grep -i 'solaris kerb' *.[ch]
    in these paths in the OpenSolaris source gate
    usr/src/cmd/krb5/ldap_util
    usr/src/lib/krb5/plugins/kdb/ldap

- lint clean mech (Wyllys announced this 01/13/2003)

    To comply with Solaris kernel code policy, the code that comprises
    the kernel krb mech has been made lint clean.  I believe at least
    that part of the code will need to stay lint clean as a pre-req for
    Solaris drop-in purposes.
    
    For code that is only in user space, gcc -wall clean would be
    acceptable unless the Sun Studio lint pointed out something really
    egregious.

- Zero Conf realm lookup changes

    Support of a fall back default realm based on the host's domain name
    if the default realm is not specified in the krb5.conf.

- No reverse DNS lookup in krb5_sname_to_principal()

- Misc bug and performance diffs

    This would take some work to go through our bugtracking DB/code. 

Thoughts as to whether this goal is achievable and on an approach if so?

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

From hotz at jpl.nasa.gov  Thu Sep 18 13:18:52 2008
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Thu, 18 Sep 2008 10:18:52 -0700
Subject: pkinit kinit/krb5.conf naming inconsistencies
In-Reply-To: <mailman.31033.1221665338.6365.krbdev@mit.edu>
References: <mailman.31033.1221665338.6365.krbdev@mit.edu>
Message-ID: <7050BED8-D4F0-48D4-8F2C-A514A1BEE01F@jpl.nasa.gov>

*sigh* I should be more careful about editing distribution lists.

I hope no one at MIT was personally offended by what I said about  
openness.  The comment was meant as a generic observation on  
appearances.  It might even be obsolete.

If I might make a related, strategic suggestion:  If you allocated  
some resources to quick review of unsolicited contributions, you would  
get some genuine PR benefit, and more volunteers contributing.  While  
the improvements mightn't align with official priorities, they would  
be guaranteed to align with the priorities of some real users, without  
the overhead of evaluating priorities.

Of course you may conclude that there isn't a corresponding benefit in  
monetary contributions.  I realize that most open source projects are  
ancillary to other funded efforts.

On Sep 17, 2008, at 8:28 AM, krbdev-request at mit.edu wrote:

> Date: Tue, 16 Sep 2008 22:54:51 -0700
> From: "Henry B. Hotz" <hotz at jpl.nasa.gov>
> Subject: Re: pkinit kinit/krb5.conf naming inconsistencies
> To: Nicolas Williams <Nicolas.Williams at sun.com>
> Cc: "Hotz, Henry B" <henry.b.hotz-100849 at jpl.nasa.gov>,
>        "krbdev at mit.edu" <krbdev at mit.edu>
> Message-ID: <12195BB7-30B1-41DC-890A-16FEABAFF348 at jpl.nasa.gov>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> On Sep 16, 2008, at 1:54 PM, Nicolas Williams wrote:
>
>> On Tue, Sep 16, 2008 at 01:45:46PM -0700, Henry B. Hotz wrote:
>>> On Sep 16, 2008, at 9:12 AM, krbdev-request at mit.edu wrote:
>>>> I'm assuming that Heimdal's kinit doesn't have this -x thing, that
>>>> in
>>>> Heimdal if you want to override the system's krb5.conf you should
>>>> use
>>>> the KRB5_CONFIG environment variable.
>>>
>>>
>>> I care a lot more about rationalizing the krb5.conf file than the
>>> command line options.  For reference:
>>
>> Meaning what?  That you don't care about the difference in naming in
>> kinit -x?
>
> Actually I don't see a -x option in 1.6.x either.  From context, I'm
> assuming that you follow it with some krb5.conf item you want to
> override?  If so, that would make my distinction meaningless.
>
>>> kinit --pk-user=<x509 identity> --x509-anchors=<directory> --pk-use-
>>> enckey ...
>>
>> Is the above how Heimdal does it?  I don't mind that, but I do mind
>> kinit -x <param-name-that-doesn't-relate-to-krb5.conf>.
>>
>> In any case, I suppose that MIT filibusters by silence, thus nothing
>> will change and I'm just wasting my time.
>
> Who has commit rights?
>
> I learned to have a lot of respect for Sam.  He seemed to have good
> reasons for what he was doing (and what he rejected).  OTOH I've
> always felt that MIT isn't as receptive as a normal open source
> project needs to be to keep volunteers interested.
>
>> Nico
>> --

------------------------------------------------------
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  Thu Sep 18 14:19:44 2008
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Thu, 18 Sep 2008 11:19:44 -0700
Subject: Building pkinit plugin in 1.6.4beta
Message-ID: <B454B5FF-BD4D-489A-A9A3-7820576BF4E9@jpl.nasa.gov>

I admit I haven't tried very hard yet, but I haven't been able to  
build the pkinit plugin yet.

As a starting point, could someone tell me the environment in which  
they were able to build it with the included configure?  I'm reminded  
of the recent discussion of how configure scripts were not well CM'ed.
------------------------------------------------------
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 mdw at umich.edu  Thu Sep 18 15:11:35 2008
From: mdw at umich.edu (Marcus Watts)
Date: Thu, 18 Sep 2008 15:11:35 -0400
Subject: pkinit kinit/krb5.conf naming inconsistencies 
In-Reply-To: <7050BED8-D4F0-48D4-8F2C-A514A1BEE01F@jpl.nasa.gov> 
References: <mailman.31033.1221665338.6365.krbdev@mit.edu>
	<7050BED8-D4F0-48D4-8F2C-A514A1BEE01F@jpl.nasa.gov>
Message-ID: <E1KgOud-0003An-NQ@spam.ifs.umich.edu>

"Henry B. Hotz" <hotz at jpl.nasa.gov> wrote:
> Date:    Thu, 18 Sep 2008 10:18:52 PDT
> To:      "krbdev at mit.edu" <krbdev at mit.edu>
> From:    "Henry B. Hotz" <hotz at jpl.nasa.gov>
> Subject: Re: pkinit kinit/krb5.conf naming inconsistencies
...
> If I might make a related, strategic suggestion:  If you allocated  
> some resources to quick review of unsolicited contributions, you would  
...

I'm not sure this is completely related, but I recently posted a number of
"unsolicited contributions" to RT, and I had another one that's been in
RT for over a year now (#5667)--it now predates several recent strategic changes.
I think an even more critical reason than 'good will' to review
contributions there is that it's a cheap way to identify code
problems.

We at umich.edu have run a patched MIT k5 since it was first rolled out,
in 2000.  There is definite interest here in not running those patches,
and that means finding a way for equivalents to those patches to be in
MIT.  Now, a lot of those patches aren't needed anymore; we had a lot of
changes to maintain better continuity with kaserver and K4; we no longer
care about those.  Also it looks like MIT is finally making a significant
effort to support nearly realtime incremental replication which removes
the need for our largest single change.  That still leaves a number of
patches, of varying importance and size, that need to be resolved.

					-Marcus Watts

From ssorce at redhat.com  Thu Sep 18 17:48:41 2008
From: ssorce at redhat.com (Simo Sorce)
Date: Thu, 18 Sep 2008 17:48:41 -0400
Subject: thoughts/issues making MIT krb code fit for drop-in to Solaris
In-Reply-To: <20080918000446.GA5266@sun.com>
References: <20080918000446.GA5266@sun.com>
Message-ID: <1221774521.1796.8.camel@localhost.localdomain>

On Wed, 2008-09-17 at 19:04 -0500, Will Fiveash wrote:
> 
> Thoughts as to whether this goal is achievable and on an approach if
> so?

Would this plan affect other platforms too?
If so, how?

Simo.

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


From William.Fiveash at Sun.COM  Thu Sep 18 18:01:40 2008
From: William.Fiveash at Sun.COM (Will Fiveash)
Date: Thu, 18 Sep 2008 17:01:40 -0500
Subject: thoughts/issues making MIT krb code fit for drop-in to Solaris
In-Reply-To: <1221774521.1796.8.camel@localhost.localdomain>
References: <20080918000446.GA5266@sun.com>
	<1221774521.1796.8.camel@localhost.localdomain>
Message-ID: <20080918220140.GB11802@sun.com>

On Thu, Sep 18, 2008 at 05:48:41PM -0400, Simo Sorce wrote:
> On Wed, 2008-09-17 at 19:04 -0500, Will Fiveash wrote:
> > 
> > Thoughts as to whether this goal is achievable and on an approach if
> > so?
> 
> Would this plan affect other platforms too?
> If so, how?

If there is any impact to binaries it would something that the
Consortium would agree is beneficial to all supported platforms.  For
example, if the Consortium agrees that providing I18N support can be
done reasonably for all platforms then this change would become
universal to the code otherwise the change would be restricted to
Solaris platforms.

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

From ssorce at redhat.com  Thu Sep 18 19:14:56 2008
From: ssorce at redhat.com (Simo Sorce)
Date: Thu, 18 Sep 2008 19:14:56 -0400
Subject: thoughts/issues making MIT krb code fit for drop-in to Solaris
In-Reply-To: <20080918220140.GB11802@sun.com>
References: <20080918000446.GA5266@sun.com>
	<1221774521.1796.8.camel@localhost.localdomain>
	<20080918220140.GB11802@sun.com>
Message-ID: <1221779696.6455.2.camel@localhost.localdomain>

On Thu, 2008-09-18 at 17:01 -0500, Will Fiveash wrote:
> On Thu, Sep 18, 2008 at 05:48:41PM -0400, Simo Sorce wrote:
> > On Wed, 2008-09-17 at 19:04 -0500, Will Fiveash wrote:
> > > 
> > > Thoughts as to whether this goal is achievable and on an approach if
> > > so?
> > 
> > Would this plan affect other platforms too?
> > If so, how?
> 
> If there is any impact to binaries it would something that the
> Consortium would agree is beneficial to all supported platforms.  For
> example, if the Consortium agrees that providing I18N support can be
> done reasonably for all platforms then this change would become
> universal to the code otherwise the change would be restricted to
> Solaris platforms.

Ok, but it seem that some of the feature may break compatibility.
Is there analysis on what may break ?

Simo.

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


From Nicolas.Williams at sun.com  Thu Sep 18 19:28:09 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 18 Sep 2008 18:28:09 -0500
Subject: [kerberos-discuss] thoughts/issues making MIT krb code fit for
	drop-in to Solaris
In-Reply-To: <1221774521.1796.8.camel@localhost.localdomain>
References: <20080918000446.GA5266@sun.com>
	<1221774521.1796.8.camel@localhost.localdomain>
Message-ID: <20080918232809.GA1875@Sun.COM>

On Thu, Sep 18, 2008 at 05:48:41PM -0400, Simo Sorce wrote:
> On Wed, 2008-09-17 at 19:04 -0500, Will Fiveash wrote:
> > 
> > Thoughts as to whether this goal is achievable and on an approach if
> > so?
> 
> Would this plan affect other platforms too?
> If so, how?

No.

The Solaris libkrb5 ABI *is* different from the MIT krb5 ABI when MIT
krb5 is built on Solaris.  But that doesn't mean that we must break MIT
krb5 compatibility.

It would mean having a ./configure option to select which ABI you want.
When building MIT krb5 to provide system components for OpenSolaris
you'd use the Solaris ABI, otherwise you'd use the default ABI.

(The alternative is that we never bother doing this drop-in thing.  Or
that we break the Solaris krb5 ABI and find a very different way to
solve the problems with krb5_keyblock.)

Nico
-- 

From William.Fiveash at Sun.COM  Thu Sep 18 19:41:34 2008
From: William.Fiveash at Sun.COM (Will Fiveash)
Date: Thu, 18 Sep 2008 18:41:34 -0500
Subject: thoughts/issues making MIT krb code fit for drop-in to Solaris
In-Reply-To: <1221779696.6455.2.camel@localhost.localdomain>
References: <20080918000446.GA5266@sun.com>
	<1221774521.1796.8.camel@localhost.localdomain>
	<20080918220140.GB11802@sun.com>
	<1221779696.6455.2.camel@localhost.localdomain>
Message-ID: <20080918234134.GA13243@sun.com>

(please reply so that boath krbdev at mit.edu and
kerberos-discuss at opensolaris.org are included)

On Thu, Sep 18, 2008 at 07:14:56PM -0400, Simo Sorce wrote:
> On Thu, 2008-09-18 at 17:01 -0500, Will Fiveash wrote:
> > On Thu, Sep 18, 2008 at 05:48:41PM -0400, Simo Sorce wrote:
> > > On Wed, 2008-09-17 at 19:04 -0500, Will Fiveash wrote:
> > > > 
> > > > Thoughts as to whether this goal is achievable and on an approach if
> > > > so?
> > > 
> > > Would this plan affect other platforms too?
> > > If so, how?
> > 
> > If there is any impact to binaries it would something that the
> > Consortium would agree is beneficial to all supported platforms.  For
> > example, if the Consortium agrees that providing I18N support can be
> > done reasonably for all platforms then this change would become
> > universal to the code otherwise the change would be restricted to
> > Solaris platforms.
> 
> Ok, but it seem that some of the feature may break compatibility.
> Is there analysis on what may break ?

What do you mean by "compatibility"?

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

From ssorce at redhat.com  Thu Sep 18 20:50:28 2008
From: ssorce at redhat.com (Simo Sorce)
Date: Thu, 18 Sep 2008 20:50:28 -0400
Subject: thoughts/issues making MIT krb code fit for drop-in to Solaris
In-Reply-To: <20080918234134.GA13243@sun.com>
References: <20080918000446.GA5266@sun.com>
	<1221774521.1796.8.camel@localhost.localdomain>
	<20080918220140.GB11802@sun.com>
	<1221779696.6455.2.camel@localhost.localdomain>
	<20080918234134.GA13243@sun.com>
Message-ID: <1221785428.6455.4.camel@localhost.localdomain>

On Thu, 2008-09-18 at 18:41 -0500, Will Fiveash wrote:
> (please reply so that boath krbdev at mit.edu and
> kerberos-discuss at opensolaris.org are included)
> 
> On Thu, Sep 18, 2008 at 07:14:56PM -0400, Simo Sorce wrote:
> > On Thu, 2008-09-18 at 17:01 -0500, Will Fiveash wrote:
> > > On Thu, Sep 18, 2008 at 05:48:41PM -0400, Simo Sorce wrote:
> > > > On Wed, 2008-09-17 at 19:04 -0500, Will Fiveash wrote:
> > > > > 
> > > > > Thoughts as to whether this goal is achievable and on an approach if
> > > > > so?
> > > > 
> > > > Would this plan affect other platforms too?
> > > > If so, how?
> > > 
> > > If there is any impact to binaries it would something that the
> > > Consortium would agree is beneficial to all supported platforms.  For
> > > example, if the Consortium agrees that providing I18N support can be
> > > done reasonably for all platforms then this change would become
> > > universal to the code otherwise the change would be restricted to
> > > Solaris platforms.
> > 
> > Ok, but it seem that some of the feature may break compatibility.
> > Is there analysis on what may break ?
> 
> What do you mean by "compatibility"?

Nicolas gave a good answer.

Simo.

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


From jaltman at secure-endpoints.com  Thu Sep 18 21:47:30 2008
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Thu, 18 Sep 2008 21:47:30 -0400
Subject: [kerberos-discuss] thoughts/issues making MIT krb code fit for
	drop-in to Solaris
In-Reply-To: <20080918232809.GA1875@Sun.COM>
References: <20080918000446.GA5266@sun.com>	<1221774521.1796.8.camel@localhost.localdomain>
	<20080918232809.GA1875@Sun.COM>
Message-ID: <48D304B2.8060600@secure-endpoints.com>

Nicolas Williams wrote:
> The Solaris libkrb5 ABI *is* different from the MIT krb5 ABI when MIT
> krb5 is built on Solaris.  But that doesn't mean that we must break MIT
> krb5 compatibility.
> 
> It would mean having a ./configure option to select which ABI you want.
> When building MIT krb5 to provide system components for OpenSolaris
> you'd use the Solaris ABI, otherwise you'd use the default ABI.
> 
> (The alternative is that we never bother doing this drop-in thing.  Or
> that we break the Solaris krb5 ABI and find a very different way to
> solve the problems with krb5_keyblock.)
> 
> Nico

The long term solution to the KFW problem is to develop an API/ABI
that Microsoft can safely implement as a shim on top of their
internal implementation.  To make that happen all of the key data
and other privates must remain hidden from the application.  Adopting
the Solaris ABI would be a good first step in that direction.

Jeffrey Altman

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

From raeburn at MIT.EDU  Fri Sep 19 00:53:13 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Fri, 19 Sep 2008 00:53:13 -0400
Subject: thoughts/issues making MIT krb code fit for drop-in to Solaris
In-Reply-To: <20080918000446.GA5266@sun.com>
References: <20080918000446.GA5266@sun.com>
Message-ID: <73708652-DDDB-4402-B058-69B5156D121F@mit.edu>

On Sep 17, 2008, at 20:04, Will Fiveash wrote:
> One goal Sun has in regards to it's association with the MIT Kerberos
> Consortium is to eventually have the Consortium's Kerberos source code
> made suitable to use as is in Solaris (drop-in).  This would save Sun
> time and effort in that resync'ing the Consortium's source code with  
> the
> Solaris Kerberos source code could be avoided.


Overall, I think it's a good idea for us to incorporate changes that  
improve the library for everyone, or make it easier to integrate  
without making it harder for us to maintain.  On first read-through,  
here are some of my initial observations:

> One approach suggested by Nico Williams is to do this by modifying one
> MITKC component at a time to keep each project smaller in scope.  The
> following components would be updated in an order like:

Seems reasonable...

> - Crypto Framework
>
>    Solaris Kerberos uses the native Solaris Encryption Framework
>    interfaces for it's crypto needs in both user and kernel space.
>    This mainly involves changes to files under src/lib/crypto. Note
>    that the _krb5_keyblock has also been modified:

I believe our intent from the introduction of krb5_init_keyblock was  
to move towards dynamic allocation of keyblock structures in the  
library, which structures would be extended with additional fields not  
visible to the caller; other code would distinguish the two kinds via  
the magic number field.  Allocating the structure in the caller would  
probably be considered deprecated (but still supported, for backwards  
compatibility).  Additional fields could include key schedules, cached  
derived keys, stuff like that.

We haven't really pushed forward on the idea beyond introducing the  
new allocation function.

> - I18N, error tables and messages in general.
>
>    MIT dynamically generates their error tables, Solaris uses a static
>    switch statement in various C files based on the MIT error tables.
>    For example, in OpenSolaris there is this code in
>    usr/src/lib/gss_mechs/mech_krb5/et/chpass_util_strings.c:

The KfM code already has i18n support in the error table handling, so  
ideally we'd extend the UNIX com_err code in a similar fashion.   
Handling of the domain names is an interesting question -- since  
error_message needs to figure out the right domain name to use, and  
error tables in different libraries may have been installed by  
different packages (it's not widely used, but there are other things  
besides krb5 using com_err), the domain name probably needs to be  
independent of the library and associated just with the error table  
name or values, unless we want to require use of brand new com_err APIs.

>    Also Solaris calls gettext() to translate various non-error table
>    messages.  Anyway, this is an area that we need to research further
>    to find a reasonable solution.

Yeah.  I'm not sure what the best answer's going to be for Windows,  
where (from a couple of things I've read) I think the LoadString  
function is the usual interface, but it wants an integer key, not a  
string, and the domain-name equivalent is a module handle returned  
from another function call.  But otherwise I think gettext, or a  
wrapper around it (to allow for indirection to other mechanisms, or  
filling in no-ops for lame systems or for intentionally disabling it),  
is probably going to be the answer we want.

> - Zero Conf realm lookup changes
>
>    Support of a fall back default realm based on the host's domain  
> name
>    if the default realm is not specified in the krb5.conf.

Yes, we were talking about this the other day.  I think the patch I  
was remembering that Mark sent in does something a bit different  
though.  I still should see about pulling some of that code in though.

> - No reverse DNS lookup in krb5_sname_to_principal()

*sigh*

This will be a behavioral change.  We should also not be doing the DNS  
lookup to canonicalize the name in the first place, but fixing that  
requires other support (having the KDC recognize aliases, etc); that  
will also be a behavioral change.  I think we've been maintaining the  
status quo until we can inflict just one massive change on the end  
sites instead of two.

Ken

From Nicolas.Williams at sun.com  Fri Sep 19 11:06:37 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 19 Sep 2008 10:06:37 -0500
Subject: [kerberos-discuss] thoughts/issues making MIT krb code fit for
	drop-in to Solaris
In-Reply-To: <48D304B2.8060600@secure-endpoints.com>
References: <20080918000446.GA5266@sun.com>
	<1221774521.1796.8.camel@localhost.localdomain>
	<20080918232809.GA1875@Sun.COM>
	<48D304B2.8060600@secure-endpoints.com>
Message-ID: <20080919150637.GB1875@Sun.COM>

On Thu, Sep 18, 2008 at 09:47:30PM -0400, Jeffrey Altman wrote:
> The long term solution to the KFW problem is to develop an API/ABI
> that Microsoft can safely implement as a shim on top of their
> internal implementation.  To make that happen all of the key data
> and other privates must remain hidden from the application.  Adopting
> the Solaris ABI would be a good first step in that direction.

Good to hear.

For the benefit of others...

Keep in mind that the major difference between the two ABIs relates to
krb5_keyblock.

The MIT krb5 API leaves a *lot* to be desired, but if there's any aspect
of it that could be termed 'disastrous' it's the fact that critical
structures are not kept opaque and this has led to developers allocating
instaces of such structures as automatic variables (because they could,
and "everyone knows" that's cheaper than calling a constructor, right?
*sigh*).  Specifically krb5_keyblock.

For those of you who are not aware, Wyllys Ingersoll (at Sun) made two
major changes to krb5_keyblock handling in Solaris.

First he added a derived key cache to krb5_keyblock.  MIT krb5
re-derives keys every time it needs them, which, with key derivation
being a slow operation, slows everything way down, whereas Solaris
derives keys just once.  This is what happens when an API designed with
RFC1510 gets adapted to RFC4120 and RFC3961 -- modern crypto meets
ancient API.  Second, Wyllys retrofitted support for PKCS#11 is
user-land and the Solaris kernel cryptographic API in kernel-land.

The ABI impact is two-fold: krb5_keyblock's size changed (at the time
Solaris did not expose the krb5 API), and now krb5_keyblock must always
be properly initialized or otherwise constructed by the library.

MIT cannot make the same changes without breaking the MIT krb5 ABI.
Keeping a look-aside cache of krb5_keyblock->{derived keys, PKCS#11
sessions, ...}, indexed by krb5_keyblock address would seem like the way
to go.  But because krb5_keyblock instances can be allocated on the
stack the value of a keyblock's keys must always be memcmp()ed at the
very least.

If MIT were to adopt the above look-aside cache approach and the
resulting performance turned out OK then Sun could conceivably adopt
that approach in order to minimize source code differences.

So I suppose we should say that we're willing to consider a scheme that
might not result in a need for a ./configure ABI type selection option.

However, in the short- to medium-term it's quite clear that the only
simple way for Sun to make progress towards having MIT krb5 be a drop-in
replacements in OpenSolaris would be to add such ./configure option.

Nico
-- 

From Nicolas.Williams at sun.com  Fri Sep 19 11:10:16 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 19 Sep 2008 10:10:16 -0500
Subject: [kerberos-discuss] thoughts/issues making MIT krb code fit for
	drop-in to Solaris
In-Reply-To: <73708652-DDDB-4402-B058-69B5156D121F@mit.edu>
References: <20080918000446.GA5266@sun.com>
	<73708652-DDDB-4402-B058-69B5156D121F@mit.edu>
Message-ID: <20080919151016.GC1875@Sun.COM>

On Fri, Sep 19, 2008 at 12:53:13AM -0400, Ken Raeburn wrote:
> On Sep 17, 2008, at 20:04, Will Fiveash wrote:
> > - No reverse DNS lookup in krb5_sname_to_principal()
> 
> *sigh*
> 
> This will be a behavioral change.  We should also not be doing the DNS  
> lookup to canonicalize the name in the first place, but fixing that  
> requires other support (having the KDC recognize aliases, etc); that  
> will also be a behavioral change.  I think we've been maintaining the  
> status quo until we can inflict just one massive change on the end  
> sites instead of two.

I've a plan.  We should discuss this.

For me the krb5_sname_to_principal() issues are extremely annoying, and
I'd be tempted to request that they be given higher priority, except
that it's been so broken for so long that a few years more might not
hurt.  OK, I'm kidding about "years."

Nico
-- 

From lha at kth.se  Fri Sep 19 11:30:21 2008
From: lha at kth.se (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=)
Date: Fri, 19 Sep 2008 17:30:21 +0200
Subject: [kerberos-discuss] thoughts/issues making MIT krb code fit for
	drop-in to Solaris
In-Reply-To: <20080919151016.GC1875@Sun.COM>
References: <20080918000446.GA5266@sun.com>
	<73708652-DDDB-4402-B058-69B5156D121F@mit.edu>
	<20080919151016.GC1875@Sun.COM>
Message-ID: <3917C005-FA40-41DF-828D-026E9139E481@kth.se>


19 sep 2008 kl. 17.10 skrev Nicolas Williams:

> On Fri, Sep 19, 2008 at 12:53:13AM -0400, Ken Raeburn wrote:
>> On Sep 17, 2008, at 20:04, Will Fiveash wrote:
>>> - No reverse DNS lookup in krb5_sname_to_principal()
>>
>> *sigh*
>>
>> This will be a behavioral change.  We should also not be doing the  
>> DNS
>> lookup to canonicalize the name in the first place, but fixing that
>> requires other support (having the KDC recognize aliases, etc); that
>> will also be a behavioral change.  I think we've been maintaining the
>> status quo until we can inflict just one massive change on the end
>> sites instead of two.
>
> I've a plan.  We should discuss this.

We should.

http://www.h5l.org/blog/index.php/2008/09/referrals/


> For me the krb5_sname_to_principal() issues are extremely annoying,  
> and
> I'd be tempted to request that they be given higher priority, except
> that it's been so broken for so long that a few years more might not
> hurt.  OK, I'm kidding about "years."

It must be fixed now, not later.

Love



From hotz at jpl.nasa.gov  Fri Sep 19 11:45:11 2008
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Fri, 19 Sep 2008 08:45:11 -0700
Subject: [kerberos-discuss] thoughts/issues making MIT krb code fit for
	drop-in to Solaris
In-Reply-To: <20080918234134.GA13243@sun.com>
References: <20080918000446.GA5266@sun.com>
	<1221774521.1796.8.camel@localhost.localdomain>
	<20080918220140.GB11802@sun.com>
	<1221779696.6455.2.camel@localhost.localdomain>
	<20080918234134.GA13243@sun.com>
Message-ID: <F8251C98-6D0C-494C-8F5A-4FD8420F27F3@jpl.nasa.gov>

API and source distribution compatibility does not necessarily imply  
ABI compatibility.  I don't see a strong need for ABI compatibility.

On Sep 18, 2008, at 4:41 PM, Will Fiveash wrote:

> (please reply so that boath krbdev at mit.edu and
> kerberos-discuss at opensolaris.org are included)
>
> On Thu, Sep 18, 2008 at 07:14:56PM -0400, Simo Sorce wrote:
>> On Thu, 2008-09-18 at 17:01 -0500, Will Fiveash wrote:
>>> On Thu, Sep 18, 2008 at 05:48:41PM -0400, Simo Sorce wrote:
>>>> On Wed, 2008-09-17 at 19:04 -0500, Will Fiveash wrote:
>>>>>
>>>>> Thoughts as to whether this goal is achievable and on an  
>>>>> approach if
>>>>> so?
>>>>
>>>> Would this plan affect other platforms too?
>>>> If so, how?
>>>
>>> If there is any impact to binaries it would something that the
>>> Consortium would agree is beneficial to all supported platforms.   
>>> For
>>> example, if the Consortium agrees that providing I18N support can be
>>> done reasonably for all platforms then this change would become
>>> universal to the code otherwise the change would be restricted to
>>> Solaris platforms.
>>
>> Ok, but it seem that some of the feature may break compatibility.
>> Is there analysis on what may break ?
>
> What do you mean by "compatibility"?
>
> --
> Will Fiveash
> Sun Microsystems Inc.
> http://opensolaris.org/os/project/kerberos/
> _______________________________________________
> kerberos-discuss mailing list
> kerberos-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/kerberos-discuss


From Nicolas.Williams at sun.com  Fri Sep 19 11:37:09 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 19 Sep 2008 10:37:09 -0500
Subject: [kerberos-discuss] thoughts/issues making MIT krb code fit for
	drop-in to Solaris
In-Reply-To: <3917C005-FA40-41DF-828D-026E9139E481@kth.se>
References: <20080918000446.GA5266@sun.com>
	<73708652-DDDB-4402-B058-69B5156D121F@mit.edu>
	<20080919151016.GC1875@Sun.COM>
	<3917C005-FA40-41DF-828D-026E9139E481@kth.se>
Message-ID: <20080919153709.GH1875@Sun.COM>

On Fri, Sep 19, 2008 at 05:30:21PM +0200, Love H?rnquist ?strand wrote:
> >For me the krb5_sname_to_principal() issues are extremely annoying,
> >and I'd be tempted to request that they be given higher priority,
> >except that it's been so broken for so long that a few years more
> >might not hurt.  OK, I'm kidding about "years."
> 
> It must be fixed now, not later.

That's my preference as well.  My joke about "years" was really just
moaning about how long it's been broken.

From Nicolas.Williams at sun.com  Fri Sep 19 11:57:05 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 19 Sep 2008 10:57:05 -0500
Subject: [kerberos-discuss] thoughts/issues making MIT krb code fit for
	drop-in to Solaris
In-Reply-To: <F8251C98-6D0C-494C-8F5A-4FD8420F27F3@jpl.nasa.gov>
References: <20080918000446.GA5266@sun.com>
	<1221774521.1796.8.camel@localhost.localdomain>
	<20080918220140.GB11802@sun.com>
	<1221779696.6455.2.camel@localhost.localdomain>
	<20080918234134.GA13243@sun.com>
	<F8251C98-6D0C-494C-8F5A-4FD8420F27F3@jpl.nasa.gov>
Message-ID: <20080919155705.GJ1875@Sun.COM>

On Fri, Sep 19, 2008 at 08:45:11AM -0700, Henry B. Hotz wrote:
> API and source distribution compatibility does not necessarily imply  
> ABI compatibility.  I don't see a strong need for ABI compatibility.

So every time MIT makes a new release you rebuild all other krb5/gss
applications that you run?

Seriously??

For Sun ABI compatibility is considered far more important than source
compatibility, and it's what we guarantee (modulo EOF announcements and
our interface stability and release type taxonomies).  From previous
conversations with Sam (and I am aware that he left the Consortium) MIT
cares about the ABI as much as we do.

(I should take this as an opportunity to knock operating systems where
having to rebuild applications from source with every OS release is par
for the course...)

Nico
-- 

From ssorce at redhat.com  Fri Sep 19 12:39:41 2008
From: ssorce at redhat.com (Simo Sorce)
Date: Fri, 19 Sep 2008 12:39:41 -0400
Subject: [kerberos-discuss] thoughts/issues making MIT krb code fit for
	drop-in to Solaris
In-Reply-To: <20080919155705.GJ1875@Sun.COM>
References: <20080918000446.GA5266@sun.com>
	<1221774521.1796.8.camel@localhost.localdomain>
	<20080918220140.GB11802@sun.com>
	<1221779696.6455.2.camel@localhost.localdomain>
	<20080918234134.GA13243@sun.com>
	<F8251C98-6D0C-494C-8F5A-4FD8420F27F3@jpl.nasa.gov>
	<20080919155705.GJ1875@Sun.COM>
Message-ID: <1221842381.6455.12.camel@localhost.localdomain>

On Fri, 2008-09-19 at 10:57 -0500, Nicolas Williams wrote:
> On Fri, Sep 19, 2008 at 08:45:11AM -0700, Henry B. Hotz wrote:
> > API and source distribution compatibility does not necessarily imply  
> > ABI compatibility.  I don't see a strong need for ABI compatibility.
> 
> So every time MIT makes a new release you rebuild all other krb5/gss
> applications that you run?
> 
> Seriously??
> 
> For Sun ABI compatibility is considered far more important than source
> compatibility, and it's what we guarantee (modulo EOF announcements and
> our interface stability and release type taxonomies).  From previous
> conversations with Sam (and I am aware that he left the Consortium) MIT
> cares about the ABI as much as we do.
> 
> (I should take this as an opportunity to knock operating systems where
> having to rebuild applications from source with every OS release is par
> for the course...)

Both API and ABI compatibility are important.
API compatibility is more important for developers.
ABI compatibility is more important for system administrators.

THe important thing is to reach a decent balance and make sure ABI/API
breaks happen on a major release and they are very well advertized in
advance, so that vendors can plan how to address the issue.

Simo.

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


From Nicolas.Williams at sun.com  Fri Sep 19 13:03:03 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 19 Sep 2008 12:03:03 -0500
Subject: ABI vs. API (Re: [kerberos-discuss] thoughts/issues making MIT krb
	code fit for drop-in to Solaris)
In-Reply-To: <1221842381.6455.12.camel@localhost.localdomain>
References: <20080918000446.GA5266@sun.com>
	<1221774521.1796.8.camel@localhost.localdomain>
	<20080918220140.GB11802@sun.com>
	<1221779696.6455.2.camel@localhost.localdomain>
	<20080918234134.GA13243@sun.com>
	<F8251C98-6D0C-494C-8F5A-4FD8420F27F3@jpl.nasa.gov>
	<20080919155705.GJ1875@Sun.COM>
	<1221842381.6455.12.camel@localhost.localdomain>
Message-ID: <20080919170302.GU1875@Sun.COM>

On Fri, Sep 19, 2008 at 12:39:41PM -0400, Simo Sorce wrote:
> Both API and ABI compatibility are important.

Yes.

> API compatibility is more important for developers.

I don't quite agree.  Developers who distribute binaries want their
binaries to run.  They also want their code to remain buildable.  See
below.

> ABI compatibility is more important for system administrators.

And users, and developers.  See above.

Also, in practice ABI compatibility makes API compatibility very likely,
with at most minor source changes needed if the API is changed
incompatibly.  Changing, e.g., a typedef *may* be source-incompatible,
but binary compatible.

Whereas focusing on API compatibility alone often leads to ABI
incompatibilities.  E.g., changing a struct size/layout -> API
compatible (sources rebuild), ABI incompatible (assuming the
struct's size/layout is part of the ABI).

We (Sun) are more cavalier (though far from careless) about API
compatibility than ABI.  Our compatibility guarantee is, after all, a
*binary* compatibility guarantee.  If your vendor/distro maintainer
doesn't do the same for you, forcing you to rebuild everything
periodically, then you're likely to care about source compatibility a
lot more.

> THe important thing is to reach a decent balance and make sure ABI/API
> breaks happen on a major release and they are very well advertized in
> advance, so that vendors can plan how to address the issue.

The MIT krb5 has not had a well-defined API.  Therefore MIT has focused
on ABI compatibility: if something breaks binary compatibility, they'll
fix it.

In fact, though the Consortium appears to be making progress w.r.t. API
documentation, until the API is fully documented then the Consortium has
no choice but to focus on ABI compatibility.

Nico
-- 

From Nicolas.Williams at sun.com  Fri Sep 19 12:05:02 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 19 Sep 2008 11:05:02 -0500
Subject: [kerberos-discuss] thoughts/issues making MIT krb code fit for
	drop-in to Solaris
In-Reply-To: <20080919151016.GC1875@Sun.COM>
References: <20080918000446.GA5266@sun.com>
	<73708652-DDDB-4402-B058-69B5156D121F@mit.edu>
	<20080919151016.GC1875@Sun.COM>
Message-ID: <20080919160502.GL1875@Sun.COM>

On Fri, Sep 19, 2008 at 10:10:16AM -0500, Nicolas Williams wrote:
> On Fri, Sep 19, 2008 at 12:53:13AM -0400, Ken Raeburn wrote:
> > On Sep 17, 2008, at 20:04, Will Fiveash wrote:
> > > - No reverse DNS lookup in krb5_sname_to_principal()
> > 
> > *sigh*
> > 
> > This will be a behavioral change.  We should also not be doing the DNS  
> > lookup to canonicalize the name in the first place, but fixing that  
> > requires other support (having the KDC recognize aliases, etc); that  
> > will also be a behavioral change.  I think we've been maintaining the  
> > status quo until we can inflict just one massive change on the end  
> > sites instead of two.
> 
> I've a plan.  We should discuss this.

I've not read Love's blog entry yet (funny, I've had one of my own saved
but not posted for a while...  perhaps you could say that means I'm part
of the problem :( ), but here's my plan:

I'll take a look.

I haven't yet, but here's my plan:

 - let krb5_sname_to_principal() do no canonicalization (except, if a
   global switch is on, to add the default domain to non-FQDN hostnames)

 - provide an option to do princ name canonicalization during TGS
   exchanges (referrals! but not only)

 - provide a GSS-API req_flag/ret_flag for requesting/indicating
   canonicalization


 - canonicalization, when requested, should be as follows:

    - try the given name first (if referral results -> follow it)

    - for each domainname in the resolver's search list

       - try the given name qualified with that domainname (if referral
         results -> follow it)

 - apps that request canonicalization should prompt the user if the
   resulting name was different than the one given by the user

    - with varying levels of strictness[*] (don't prompt if the
      domainname added was the first one on the search list[**]) and
      with a known_hosts-type file this can be no big deal

[*]  Think OpenSSH's StrictHostKeyChecking option.

[**] Whether this happened should be indicated by the library itself,
     which means one more ret_flag.  The app still gets to decide
     whether to prompt.

Nico
-- 

From hotz at jpl.nasa.gov  Fri Sep 19 15:31:53 2008
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Fri, 19 Sep 2008 12:31:53 -0700
Subject: [kerberos-discuss] thoughts/issues making MIT krb code fit for
	drop-in to Solaris
In-Reply-To: <20080919155705.GJ1875@Sun.COM>
References: <20080918000446.GA5266@sun.com>
	<1221774521.1796.8.camel@localhost.localdomain>
	<20080918220140.GB11802@sun.com>
	<1221779696.6455.2.camel@localhost.localdomain>
	<20080918234134.GA13243@sun.com>
	<F8251C98-6D0C-494C-8F5A-4FD8420F27F3@jpl.nasa.gov>
	<20080919155705.GJ1875@Sun.COM>
Message-ID: <E851C541-BBB0-41EB-B76F-66522C618757@jpl.nasa.gov>


On Sep 19, 2008, at 8:57 AM, Nicolas Williams wrote:

> On Fri, Sep 19, 2008 at 08:45:11AM -0700, Henry B. Hotz wrote:
>> API and source distribution compatibility does not necessarily imply
>> ABI compatibility.  I don't see a strong need for ABI compatibility.
>
> So every time MIT makes a new release you rebuild all other krb5/gss
> applications that you run?
>
> Seriously??

Yes, but not the way you took it.

I meant I don't care if the Sun-supplied library on a Solaris box has  
the same ABI as a corresponding library built directly from the MIT  
distribution (presumably with different configure options).

------------------------------------------------------
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  Fri Sep 19 15:36:04 2008
From: tlyu at MIT.EDU (Tom Yu)
Date: Fri, 19 Sep 2008 15:36:04 -0400
Subject: thoughts/issues making MIT krb code fit for drop-in to Solaris
In-Reply-To: <20080918000446.GA5266@sun.com> (Will Fiveash's message of "Wed,
	17 Sep 2008 19:04:46 -0500")
References: <20080918000446.GA5266@sun.com>
Message-ID: <ldvd4j0udwb.fsf@cathode-dark-space.mit.edu>

Will, thank you for your efforts in assembling this summary.  It is
valuable input toward updating development priorities for the Kerberos
Consortium's development efforts.

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

> One goal Sun has in regards to it's association with the MIT Kerberos
> Consortium is to eventually have the Consortium's Kerberos source code
> made suitable to use as is in Solaris (drop-in).  This would save Sun
> time and effort in that resync'ing the Consortium's source code with the
> Solaris Kerberos source code could be avoided.
>
> One approach suggested by Nico Williams is to do this by modifying one
> MITKC component at a time to keep each project smaller in scope.  The
> following components would be updated in an order like:
>
>  - Raw Kerberos components
>                           
>     - libkrb5             
>     - libkadm5*
>     - utilities (kinit, kdestroy, klist, ktutil, kvno)
>     - krb5kdc, kadmind, kadmin, kadmin.local, kdb5_util, ...
>     - KDB plugins
>     - CCAPI              
>
>  - GSS-API Kerberos V mechanism related components
>                                                   
>     - mech_krb5 (and implied libgss, mech_dh changes)
>     - mech_spnego (and implied libgss, mech_dh changes)
>     - libgss (and mech_dh changes)                     
>
>  - misc
>        
>     - RPCSEC_GSS API diffs (which impact libkadm5* and kadmin* somewhat)
>
> So initially (and most importantly) the libkrb5 code would be modified
> and once that project is done, other components could be modified as
> additional projects. 

I agree with the strategy of pursuing the updates incrementally.

> To help understand what this entails, the following is a list of various
> differences between the MITKC and Solaris mech_krb5/libkrb5 source code.

Are these in priority order?  I suspect that I would choose a
different priority ordering based on information I currently have from
sponsors and other interested parties, but I am open to additional
suggestions.

> - Crypto Framework
>
>     Solaris Kerberos uses the native Solaris Encryption Framework
>     interfaces for it's crypto needs in both user and kernel space.
>     This mainly involves changes to files under src/lib/crypto. Note
>     that the _krb5_keyblock has also been modified:

I think that improvement of the crypto framework abstraction can be
helpful for many reasons.  I suspect that some vendors may want to be
able to more easily use a FIPS 140-2 compliant crypto library.

>     This creates an ABI difference between Solaris and MIT.

We could choose to deprecate the old ABI, or make compatibility glue
to support it.

> - I18N, error tables and messages in general.
>
>     MIT dynamically generates their error tables, Solaris uses a static
>     switch statement in various C files based on the MIT error tables.

Can gettext() be run on the static strings returned by the com_err
library, if we manage to feed the strings from the com_err string
tables to the localization software?

> - User space and kernel space krb mechs
>
>     Solaris provides a krb mech that is comparable in function to the
>     MIT krb mech in user space and in addition Solaris has a krb mech as
>     a kernel module.  This provides a subset of the user space krb mech
>     function to basically support NFS security needs.  One implication
>     of this is that not all library functions used by the user space krb
>     mech are available in the kernel.

There are multiple reasons that we might want to be able to compile
subsets of various GSS or krb5 library functionality. Among those is
the ability to make a lean client-only library, which is useful for
some scenarios, and which we have already done some work on.

> - Auditing
>
>     There are 74 calls in the Solaris code base to Basic Security Module
>     auditing routines.

Are these primarily on the KDC side, or are there application server
things as well?

> - rpcsec_gss(3NSL) API differences
>
>     There may be rpcsec_gss(3NSL) API differences too (for kadmin
>     support of use of kadmin/changepw instead of kadmin/host.FQDN
>     service princs -- the Solaris API comes up short).

This means that we should probably collaborate on evolving the RPCSEC
APIs to converge.

> - Changes in *.conf files and other parameters?
>
>     - File locations - default krb5.conf, kdc.conf in /etc/krb5
>     - Different defaults for some configuration variables

For the file locaitons, are there necessary changes beyond specifying
special options to the configure script?

> - Some diffs due to KDB LDAP plugin port
>
>     The diffs can be seen by doing
>     grep -i 'solaris kerb' *.[ch]
>     in these paths in the OpenSolaris source gate
>     usr/src/cmd/krb5/ldap_util
>     usr/src/lib/krb5/plugins/kdb/ldap
>
> - lint clean mech (Wyllys announced this 01/13/2003)
>
>     To comply with Solaris kernel code policy, the code that comprises
>     the kernel krb mech has been made lint clean.  I believe at least
>     that part of the code will need to stay lint clean as a pre-req for
>     Solaris drop-in purposes.
>     
>     For code that is only in user space, gcc -wall clean would be
>     acceptable unless the Sun Studio lint pointed out something really
>     egregious.

Quite a few of the warnings we get from gcc are from
signed-vs-unsigned comparisons or conversions.  (It's an extra warning
we turn on, but it can catch some subtle bugs.)  At the moment, many
of them look like false positives due to some quirks with the way
krb5_data is defined.  We can probably eliminate many of them by
changing krb5_data in a way that is ABI-compatible on most platforms.

There may be similar high-leverage changes that can eliminate large
numbers of warnings.

> - Zero Conf realm lookup changes
>
>     Support of a fall back default realm based on the host's domain name
>     if the default realm is not specified in the krb5.conf.

This seems like a good idea.  I haven't extensively examined Mark
Phalan's patch (in ticket #6031) yet, but I have glanced at it.

> - No reverse DNS lookup in krb5_sname_to_principal()

I think reducing or eliminating dependencies on DNS rank fairly high
among the desires of Kerberos users.  I think we can go further to
eliminate dependencies on DNS, including:

  * principal alias support
  * improved referrals support

> - Misc bug and performance diffs
>
>     This would take some work to go through our bugtracking DB/code. 
>
> Thoughts as to whether this goal is achievable and on an approach if so?

I think it is a good goal to make MIT krb5 suitable for drop-in use in
Solaris.  I think we can best accomplish this by taking as many of the
Solaris changes as are suitable and making them useful on a
cross-platform basis, and collaborate on making the code converge in
places where we need to resolve significant differences.  This can
also help other vendors of MIT krb5 if we are careful, so that many
people can benefit.

Having a prioritized list of the desired changes would be helpful, and
knowing any relevant time constraints would also be useful.  I expect
to evaluate Sun's suggestions in more detail in the near future,
probably in separate message threads on this mailing list.

-- 
Tom Yu
Development Manager
MIT Kerberos Consortium

From Nicolas.Williams at sun.com  Fri Sep 19 16:35:19 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 19 Sep 2008 15:35:19 -0500
Subject: [kerberos-discuss] thoughts/issues making MIT krb code fit for
	drop-in to Solaris
In-Reply-To: <E851C541-BBB0-41EB-B76F-66522C618757@jpl.nasa.gov>
References: <20080918000446.GA5266@sun.com>
	<1221774521.1796.8.camel@localhost.localdomain>
	<20080918220140.GB11802@sun.com>
	<1221779696.6455.2.camel@localhost.localdomain>
	<20080918234134.GA13243@sun.com>
	<F8251C98-6D0C-494C-8F5A-4FD8420F27F3@jpl.nasa.gov>
	<20080919155705.GJ1875@Sun.COM>
	<E851C541-BBB0-41EB-B76F-66522C618757@jpl.nasa.gov>
Message-ID: <20080919203518.GA1875@Sun.COM>

On Fri, Sep 19, 2008 at 12:31:53PM -0700, Henry B. Hotz wrote:
> On Sep 19, 2008, at 8:57 AM, Nicolas Williams wrote:
> >Seriously??
> 
> Yes, but not the way you took it.
> 
> I meant I don't care if the Sun-supplied library on a Solaris box has  
> the same ABI as a corresponding library built directly from the MIT  
> distribution (presumably with different configure options).

Of course.  Today they wouldn't have the same ABI anyways.

From jhutz at cmu.edu  Fri Sep 19 17:00:07 2008
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Fri, 19 Sep 2008 17:00:07 -0400
Subject: [kerberos-discuss] thoughts/issues making MIT krb code fit
	for	drop-in to Solaris
In-Reply-To: <200809191608.m8JG87D7021184@raisinbran.srv.cs.cmu.edu>
References: <20080918000446.GA5266@sun.com>
	<73708652-DDDB-4402-B058-69B5156D121F@mit.edu>
	<20080919151016.GC1875@Sun.COM>
	<3917C005-FA40-41DF-828D-026E9139E481@kth.se>
	<200809191608.m8JG87D7021184@raisinbran.srv.cs.cmu.edu>
Message-ID: <A26C524208648C320F7BB090@sirius.fac.cs.cmu.edu>

--On Friday, September 19, 2008 10:37:09 AM -0500 Nicolas Williams 
<Nicolas.Williams at sun.com> wrote:

> On Fri, Sep 19, 2008 at 05:30:21PM +0200, Love H?rnquist ?strand wrote:
>> > For me the krb5_sname_to_principal() issues are extremely annoying,
>> > and I'd be tempted to request that they be given higher priority,
>> > except that it's been so broken for so long that a few years more
>> > might not hurt.  OK, I'm kidding about "years."
>>
>> It must be fixed now, not later.
>
> That's my preference as well.

Actually, I'd much rather fix it 10 years ago.
Anybody got a time machine?


From Nicolas.Williams at sun.com  Fri Sep 19 17:00:47 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 19 Sep 2008 16:00:47 -0500
Subject: thoughts/issues making MIT krb code fit for drop-in to Solaris
In-Reply-To: <ldvd4j0udwb.fsf@cathode-dark-space.mit.edu>
References: <20080918000446.GA5266@sun.com>
	<ldvd4j0udwb.fsf@cathode-dark-space.mit.edu>
Message-ID: <20080919210047.GC1875@Sun.COM>

On Fri, Sep 19, 2008 at 03:36:04PM -0400, Tom Yu wrote:
> > - Crypto Framework
> >
> >     Solaris Kerberos uses the native Solaris Encryption Framework
> >     interfaces for it's crypto needs in both user and kernel space.
> >     This mainly involves changes to files under src/lib/crypto. Note
> >     that the _krb5_keyblock has also been modified:
> 
> I think that improvement of the crypto framework abstraction can be
> helpful for many reasons.  I suspect that some vendors may want to be
> able to more easily use a FIPS 140-2 compliant crypto library.

Indeed.  Solaris' krb5 stack uses PKCS#11 in user-land, so if MIT were
to adopt this then others could potentially plug in FIPS 140-2 compliant
PKCS#11 libraries/tokens.

> >     This creates an ABI difference between Solaris and MIT.
> 
> We could choose to deprecate the old ABI, or make compatibility glue
> to support it.

I see three options:

1)  MIT deprecates the old ABI
2)  MIT adds a configure switch to select ABIs
2a) and MIT adds a look-aside buffer as I described before along with
    PKCS#11 support
3)  (2a) and Solaris switches to using MIT krb5 without crypto mods
    (except for kernel-land)

> > - I18N, error tables and messages in general.
> >
> >     MIT dynamically generates their error tables, Solaris uses a static
> >     switch statement in various C files based on the MIT error tables.
> 
> Can gettext() be run on the static strings returned by the com_err
> library, if we manage to feed the strings from the com_err string
> tables to the localization software?

gettext() can be used with non-constant strings expressions, provided
the expression in question ultimately evaluates to string as it appears
in the catalog.

Usually gettext() is used with constant strings because the xgettext(1)
utlity knows to extract those for localization.

For example SunSSH uses GNU xgettext() to extract constant strings from
calls to functions like 'debug()', 'debug2()', 'error()', 'fatal()',
etc...  And those functions, in turn, pass their first argument to
gettext() (i.e., gettext() in SunSSH gets called with non-constant
string expressions most of the time).

> > - User space and kernel space krb mechs
> >
> >     Solaris provides a krb mech that is comparable in function to the
> >     MIT krb mech in user space and in addition Solaris has a krb mech as
> >     a kernel module.  This provides a subset of the user space krb mech
> >     function to basically support NFS security needs.  One implication
> >     of this is that not all library functions used by the user space krb
> >     mech are available in the kernel.
> 
> There are multiple reasons that we might want to be able to compile
> subsets of various GSS or krb5 library functionality. Among those is
> the ability to make a lean client-only library, which is useful for
> some scenarios, and which we have already done some work on.

Good point.  And moving parts of krb5kdc into libkrb5 to make it easier
to build PKU2U would help (but that's a whole 'nother story).

> > - Auditing
> >
> >     There are 74 calls in the Solaris code base to Basic Security Module
> >     auditing routines.
> 
> Are these primarily on the KDC side, or are there application server
> things as well?

Yes, KDC side.  But Solaris Kerberos auditing needs significant
revamping.  For example, it would be quite useful to include hashes of
the Ticket issued and a hash of the Ticket used in PA-TGS-REQ (and
Tickets in additional-tickets, for u2u) in audit messages -- this could
help track individual sessions across multiple hosts/KDCs/realms.
(pam_krb5/login apps should also audit the hash of the TGT and service
Ticket used during authentication, but that's well outside MIT krb5
right now.)

> > - rpcsec_gss(3NSL) API differences
> >
> >     There may be rpcsec_gss(3NSL) API differences too (for kadmin
> >     support of use of kadmin/changepw instead of kadmin/host.FQDN
> >     service princs -- the Solaris API comes up short).
> 
> This means that we should probably collaborate on evolving the RPCSEC
> APIs to converge.

I agree.  The single most important additions would be:

 - a way to pass a gss_name_t for the targ_name to the RPCSEC_GSS client
   library, rather than just a string as is the case now;

 - a way to pass in a gss_cred_id_t (if there isn't one already -- I
   forget!)

 - client- and server-side functions for obtaining/releasing references
   to an XPRT's GSS-API context handle(s)

> > - Changes in *.conf files and other parameters?
> >
> >     - File locations - default krb5.conf, kdc.conf in /etc/krb5
> >     - Different defaults for some configuration variables
> 
> For the file locaitons, are there necessary changes beyond specifying
> special options to the configure script?

I don't think so.  But wasn't there a plan to fold kdc.conf into
krb5.conf?  What's the status of that?

> > - No reverse DNS lookup in krb5_sname_to_principal()
> 
> I think reducing or eliminating dependencies on DNS rank fairly high
> among the desires of Kerberos users.  I think we can go further to
> eliminate dependencies on DNS, including:
> 
>   * principal alias support
>   * improved referrals support

Yes!  (See other e-mails in this thread.)

> I think it is a good goal to make MIT krb5 suitable for drop-in use in
> Solaris.  I think we can best accomplish this by taking as many of the
> Solaris changes as are suitable and making them useful on a
> cross-platform basis, and collaborate on making the code converge in
> places where we need to resolve significant differences.  This can
> also help other vendors of MIT krb5 if we are careful, so that many
> people can benefit.

I agree.

> Having a prioritized list of the desired changes would be helpful, and
> knowing any relevant time constraints would also be useful.  I expect
> to evaluate Sun's suggestions in more detail in the near future,
> probably in separate message threads on this mailing list.

(I won't comment on priorities since I'm not in the Solaris Kerberos
team.)

Nico
-- 

From Nicolas.Williams at sun.com  Fri Sep 19 17:04:11 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 19 Sep 2008 16:04:11 -0500
Subject: [kerberos-discuss] thoughts/issues making MIT krb code fit for
	drop-in to Solaris
In-Reply-To: <A26C524208648C320F7BB090@sirius.fac.cs.cmu.edu>
References: <20080918000446.GA5266@sun.com>
	<73708652-DDDB-4402-B058-69B5156D121F@mit.edu>
	<20080919151016.GC1875@Sun.COM>
	<3917C005-FA40-41DF-828D-026E9139E481@kth.se>
	<200809191608.m8JG87D7021184@raisinbran.srv.cs.cmu.edu>
	<A26C524208648C320F7BB090@sirius.fac.cs.cmu.edu>
Message-ID: <20080919210411.GD1875@Sun.COM>

On Fri, Sep 19, 2008 at 05:00:07PM -0400, Jeffrey Hutzelman wrote:
> --On Friday, September 19, 2008 10:37:09 AM -0500 Nicolas Williams 
> <Nicolas.Williams at sun.com> wrote:
> 
> >On Fri, Sep 19, 2008 at 05:30:21PM +0200, Love H?rnquist ?strand wrote:
> >>> For me the krb5_sname_to_principal() issues are extremely annoying,
> >>> and I'd be tempted to request that they be given higher priority,
> >>> except that it's been so broken for so long that a few years more
> >>> might not hurt.  OK, I'm kidding about "years."
> >>
> >>It must be fixed now, not later.
> >
> >That's my preference as well.
> 
> Actually, I'd much rather fix it 10 years ago.
> Anybody got a time machine?

A Dilbert calendar strip I saw recently about time machines comes to
mind (it's a box that takes you one hour into the future in only sixty
minutes) :)

From raeburn at MIT.EDU  Fri Sep 19 19:25:52 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Fri, 19 Sep 2008 19:25:52 -0400
Subject: thoughts/issues making MIT krb code fit for drop-in to Solaris
In-Reply-To: <20080919210047.GC1875@Sun.COM>
References: <20080918000446.GA5266@sun.com>
	<ldvd4j0udwb.fsf@cathode-dark-space.mit.edu>
	<20080919210047.GC1875@Sun.COM>
Message-ID: <DEDFB9CA-F9A5-4A96-B062-E7618880CF77@mit.edu>

On Sep 19, 2008, at 17:00, Nicolas Williams wrote:
>> For the file locaitons, are there necessary changes beyond specifying
>> special options to the configure script?
>
> I don't think so.  But wasn't there a plan to fold kdc.conf into
> krb5.conf?  What's the status of that?

In our current code, the KDC will read kdc.conf + krb5.conf, and use  
the combined result for its data, as will other KDC-side programs.  We  
haven't stopped it from reading kdc.conf, and probably won't any time  
soon for compatibility, but you can omit the file and put everything  
into krb5.conf if you want.

Ken

From William.Fiveash at Sun.COM  Fri Sep 19 20:36:18 2008
From: William.Fiveash at Sun.COM (Will Fiveash)
Date: Fri, 19 Sep 2008 19:36:18 -0500
Subject: thoughts/issues making MIT krb code fit for drop-in to Solaris
In-Reply-To: <ldvd4j0udwb.fsf@cathode-dark-space.mit.edu>
References: <20080918000446.GA5266@sun.com>
	<ldvd4j0udwb.fsf@cathode-dark-space.mit.edu>
Message-ID: <20080920003618.GA16745@sun.com>

On Fri, Sep 19, 2008 at 03:36:04PM -0400, Tom Yu wrote:
> Will, thank you for your efforts in assembling this summary.  It is
> valuable input toward updating development priorities for the Kerberos
> Consortium's development efforts.
> 
> Will Fiveash <William.Fiveash at Sun.COM> writes:
> 
> > To help understand what this entails, the following is a list of various
> > differences between the MITKC and Solaris mech_krb5/libkrb5 source code.
> 
> Are these in priority order?  I suspect that I would choose a
> different priority ordering based on information I currently have from
> sponsors and other interested parties, but I am open to additional
> suggestions.

I was thinking about size of changes when ordering the list, not
priority.  Sun will need most if not all of these things taken care of
before libkrb5 can be a Solaris drop-in.  Now I understand that these
items will probably be separate MITKC projects but until they're all
done, Sun will still have to do some amount of resync/merge work to pull
that libkrb5 into Open Solaris.

[comments deleted]

> > Thoughts as to whether this goal is achievable and on an approach if so?
> 
> I think it is a good goal to make MIT krb5 suitable for drop-in use in
> Solaris.  I think we can best accomplish this by taking as many of the
> Solaris changes as are suitable and making them useful on a
> cross-platform basis, and collaborate on making the code converge in
> places where we need to resolve significant differences.  This can
> also help other vendors of MIT krb5 if we are careful, so that many
> people can benefit.
> 
> Having a prioritized list of the desired changes would be helpful, and
> knowing any relevant time constraints would also be useful.  I expect
> to evaluate Sun's suggestions in more detail in the near future,
> probably in separate message threads on this mailing list.

Sounds good.  We should come up with a plan as to how to implement this
along with the other MITKC objectives.

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

From Mark.Phalan at Sun.COM  Mon Sep 22 10:48:40 2008
From: Mark.Phalan at Sun.COM (Mark Phalan)
Date: Mon, 22 Sep 2008 16:48:40 +0200
Subject: pkcs11_errstrings and raw error codes
Message-ID: <1222094920.16093.431.camel@zup>


As part of porting the pkinit plugin to OpenSolaris/Solaris I tried to
improve the error reporting in a number of places. The pkiDebug() macro
prints lots of useful information when debugging but without DEBUG
defined pkinit is less than helpful when things go wrong.

There are a number of places where pkiDebug() uses
pkinit_pkcs11_code_to_text() to convert pkcs11 error strings to a human
readable error message. This function uses a lookup table with error
code / string pairs. The error codes used are simply the raw error
number (eg. 0xa2). Any reason why the standard defined error codes (eg.
CKR_PIN_INVALID) weren't used?

-Mark



From mike.patnode at centrify.com  Tue Sep 23 17:28:42 2008
From: mike.patnode at centrify.com (Mike Patnode)
Date: Tue, 23 Sep 2008 14:28:42 -0700
Subject: telnet & ftp official status
In-Reply-To: <20080919210411.GD1875@Sun.COM>
References: <20080918000446.GA5266@sun.com><73708652-DDDB-4402-B058-69B5156D121F@mit.edu><20080919151016.GC1875@Sun.COM><3917C005-FA40-41DF-828D-026E9139E481@kth.se><200809191608.m8JG87D7021184@raisinbran.srv.cs.cmu.edu><A26C524208648C320F7BB090@sirius.fac.cs.cmu.edu>
	<20080919210411.GD1875@Sun.COM>
Message-ID: <BB7E16A14DE689469A181EC770AFBF4D02045504@exch-one.centrify.com>

I seem to remember seeing some comments here about on-going support for
the telnet & gssftp client/servers.   What the current official line?
Will they continue to be supported as part of the distribution, or are
they being dropped in preference for OpenSSH?

thx
mp


From William.Fiveash at Sun.COM  Tue Sep 23 20:59:55 2008
From: William.Fiveash at Sun.COM (Will Fiveash)
Date: Tue, 23 Sep 2008 19:59:55 -0500
Subject: Update to the design of the Master Key Migration project
Message-ID: <20080924005955.GC22993@sun.com>

Tom Yu requested that I look into modifying the design for the master
key migration/rollover project to facilitate support for service key
rollover.

The idea here is to provide a facility that would, among other things,
allow an admin to specify which service key version the KDC will use
when issuing tickets for that service.  This would allow an admin to use
ktadd to rekey a service principal, store the new keys in a keytab and
distribute the keytab to whatever systems were hosting that service
prior to the KDC using the new service keys when generating tickets for
that service.  Once the keytab distribution was complete, the admin
could then "enable" use of the new service keys thus ensuring no
interruption of service.

Currently the master key migration design defines a new TL-data type, KRB5_TL_MKEY_AUX, would
apply only to the K/M principal. This new TL data contains:

    - The current master key version number that should be used when
      changing database entries. This may not be the latest key and is
      set by the administrator. If this TL-data type is not found in the
      K/M record then the default value for this will be 1 which is the
      default MKVNO.

    - A set of copies of the latest master key, each encrypted by one of
      the other supported mkeys, in {old-mkvno, keydata} tuples. Thus
      the "master key" used in DAL (DB abstraction layer) need only be
      any one of these keys.

    - Trailing stuff is ignored for now, making the structure
      extensible. 

To enable service key rollover I propose removing the current master key
version number in the KRB5_TL_MKEY_AUX and creating a new TL data type,
KRB5_TL_CURKVNO, that could be associated with any principal.  When set
for the K/M principal it would function as described above in the
KRB5_TL_MKEY_AUX definition.  When set for a service principal it would
indicate the key version to be used when the KDC issues service tickets.
And like KRB5_TL_MKEY_AUX, any trailing data would be ignored to make
this data type extensible.  For example Tom mentioned that it might be
good to support the ability to set an activation date/time for keys and
so on.   

At some point in the future, service key rollover could be implemented
using this new TL data type.

Note that I am not planning on modifying the current master key
migration design other than to add support for the KRB5_TL_CURKVNO as it
pertains to the K/M principal.  And I wasn't planning on adding support
for date/time key activation unless that is deemed to be important.

Thoughts?

On Tue, Sep 02, 2008 at 07:25:34PM -0500, Will Fiveash wrote:
> I've added a page on the MIT Kerberos Consortium wiki for the Master Key
> Migration project.  The URL to the page is:
> http://k5wiki.kerberos.org/wiki/Projects/Master_Key_Migration
> 
> This project will provide the ability to add a new master key (with an
> enctype differing from the current master key) to the master key
> principal and stash file and then migrate the encryption of existing
> principals long term keys to use the new master key. In addition
> deletion of master keys will be provided. 
> 
> The review period runs Sept 2-16.
> 
> -- 
> Will Fiveash
> Sun Microsystems Inc.
> http://opensolaris.org/os/project/kerberos/
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

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

From William.Fiveash at Sun.COM  Wed Sep 24 16:43:33 2008
From: William.Fiveash at Sun.COM (Will Fiveash)
Date: Wed, 24 Sep 2008 15:43:33 -0500
Subject: Update to the design of the Master Key Migration project
In-Reply-To: <20080924005955.GC22993@sun.com>
References: <20080924005955.GC22993@sun.com>
Message-ID: <20080924204333.GD22993@sun.com>

On Tue, Sep 23, 2008 at 07:59:55PM -0500, Will Fiveash wrote:
> Tom Yu requested that I look into modifying the design for the master
> key migration/rollover project to facilitate support for service key
> rollover.
> 
> The idea here is to provide a facility that would, among other things,
> allow an admin to specify which service key version the KDC will use
> when issuing tickets for that service.  This would allow an admin to use
> ktadd to rekey a service principal, store the new keys in a keytab and
> distribute the keytab to whatever systems were hosting that service
> prior to the KDC using the new service keys when generating tickets for
> that service.  Once the keytab distribution was complete, the admin
> could then "enable" use of the new service keys thus ensuring no
> interruption of service.
> 
> Currently the master key migration design defines a new TL-data type, KRB5_TL_MKEY_AUX, would
> apply only to the K/M principal. This new TL data contains:
> 
>     - The current master key version number that should be used when
>       changing database entries. This may not be the latest key and is
>       set by the administrator. If this TL-data type is not found in the
>       K/M record then the default value for this will be 1 which is the
>       default MKVNO.
> 
>     - A set of copies of the latest master key, each encrypted by one of
>       the other supported mkeys, in {old-mkvno, keydata} tuples. Thus
>       the "master key" used in DAL (DB abstraction layer) need only be
>       any one of these keys.
> 
>     - Trailing stuff is ignored for now, making the structure
>       extensible. 
> 
> To enable service key rollover I propose removing the current master key
> version number in the KRB5_TL_MKEY_AUX and creating a new TL data type,
> KRB5_TL_CURKVNO, that could be associated with any principal.  When set
> for the K/M principal it would function as described above in the
> KRB5_TL_MKEY_AUX definition.  When set for a service principal it would
> indicate the key version to be used when the KDC issues service tickets.
> And like KRB5_TL_MKEY_AUX, any trailing data would be ignored to make
> this data type extensible.  For example Tom mentioned that it might be
> good to support the ability to set an activation date/time for keys and
> so on.   

I thought about this some more and have a modification to the definition
of the data stored in KRB5_TL_CURKVNO.  It should be an array holding a
variable number of these structs:

struct krb5_curkvno  {
    krb5_kvno curkvno;
    krb5_timestamp start_time;
}

The idea is that a number of these structs could be stored in the
KRB5_TL_CURKVNO.  start_time would hold a timestamp indicating when
curkvno should be used.  The algorithm used to determine which entry to
use would choose the closest start_time to the present time that isn't
in the future when processing the entries.

In some future project a new kadmin command could be introduced along
these lines:

use_key <KVNO> [start date/time]

This command would create a new KRB5_TL_CURKVNO entry.  If the start
date/time isn't provided it would use the current time so the entry
would take effect immediately.  It would also delete obsolete entries
that have been overridden by the more current active entry thus keeping
the growth of KRB5_TL_CURKVNO in check.

Thoughts?

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

From Nicolas.Williams at sun.com  Wed Sep 24 17:15:14 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 24 Sep 2008 16:15:14 -0500
Subject: Update to the design of the Master Key Migration project
In-Reply-To: <20080924204333.GD22993@sun.com>
References: <20080924005955.GC22993@sun.com> <20080924204333.GD22993@sun.com>
Message-ID: <20080924211514.GG9765@Sun.COM>

On Wed, Sep 24, 2008 at 03:43:33PM -0500, Will Fiveash wrote:
> On Tue, Sep 23, 2008 at 07:59:55PM -0500, Will Fiveash wrote:
> > Tom Yu requested that I look into modifying the design for the master
> > key migration/rollover project to facilitate support for service key
> > rollover.

Excellent idea!  (This addresses one long thread we had a while back
about just this topic.)

> I thought about this some more and have a modification to the definition
> of the data stored in KRB5_TL_CURKVNO.  It should be an array holding a
> variable number of these structs:

I like that -- it could be used for any principal, not just K/M or
krbtgt/<realm>@<realm>.

> struct krb5_curkvno  {
>     krb5_kvno curkvno;
>     krb5_timestamp start_time;
> }

Why not also end_time, with 0 -> never?

> The idea is that a number of these structs could be stored in the
> KRB5_TL_CURKVNO.  start_time would hold a timestamp indicating when
> curkvno should be used.  The algorithm used to determine which entry to
> use would choose the closest start_time to the present time that isn't
> in the future when processing the entries.
> 
> In some future project a new kadmin command could be introduced along
> these lines:
> 
> use_key <KVNO> [start date/time]

getprinc should list these for any one principal.
modprinc should allow setting these for any one principal.

Something like:

    kadmin:  getprinc krbtgt/FOO.EXAMPLE
    Principal: krbtgt/FOO.EXAMPLE at FOO.EXAMPLE
    ...
    Number of keys: 5
--->Key version numbers in use: 4
    Key: vno 4, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
    ...
    kadmin:  
    kadmin:  modprinc krbtgt/FOO.EXAMPLE -use_kvno 5 start ... end ...
--->kadmin:  randkey krbtgt/FOO.EXAMPLE
    kadmin:  getprinc krbtgt/FOO.EXAMPLE
    Principal: krbtgt/FOO.EXAMPLE at FOO.EXAMPLE
    ...
    Number of keys: 10
--->Key version numbers in use: 4
    Key: vno 5, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
    ...
    Key: vno 4, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
    ...
--->kadmin:  modprinc krbtgt/FOO.EXAMPLE -use_kvno 5 start now end never
    kadmin:  getprinc krbtgt/FOO.EXAMPLE
    Principal: krbtgt/FOO.EXAMPLE at FOO.EXAMPLE
    ...
    Number of keys: 10
--->Key version numbers in use: 5, 4
    Key: vno 5, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
    ...
    Key: vno 4, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
    ...
--->kadmin:  modprinc krbtgt/FOO.EXAMPLE -use_kvno 4 end now
    kadmin:  getprinc krbtgt/FOO.EXAMPLE
    Principal: krbtgt/FOO.EXAMPLE at FOO.EXAMPLE
    ...
    Number of keys: 10
--->Key version numbers in use: 5
    Key: vno 5, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
    ...
    Key: vno 4, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
    ...
--->kadmin:  delkeys -v 4 krbtgt/FOO.EXAMPLE
    kadmin:  getprinc krbtgt/FOO.EXAMPLE
    Principal: krbtgt/FOO.EXAMPLE at FOO.EXAMPLE
    ...
--->Number of keys: 5
    Key version numbers in use: 5
    Key: vno 5, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
    ...
    kadmin:  exit

Everything that's highlighted is new: 'randkey' and 'delkeys'
sub-commands, kvnos in use output line, and modprinc '-use_kvno' option.

Yes, I realize that 'delkeys' would require a protocol change, so phat
chance of that.  I can live without 'delkeys'.  (Or can the randkey RPCs
be twisted to do a don't-add-keys-just-delete-old-keys RPC?  Do we even
care?)

Nico
-- 

From jhutz at cmu.edu  Wed Sep 24 18:56:50 2008
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Wed, 24 Sep 2008 18:56:50 -0400
Subject: Update to the design of the Master Key Migration project
In-Reply-To: <200809242123.m8OLNZGL025980@raisinbran.srv.cs.cmu.edu>
References: <20080924005955.GC22993@sun.com> <20080924204333.GD22993@sun.com>
	<200809242123.m8OLNZGL025980@raisinbran.srv.cs.cmu.edu>
Message-ID: <9189F5E2145344B960DF6746@sirius.fac.cs.cmu.edu>

--On Wednesday, September 24, 2008 04:15:14 PM -0500 Nicolas Williams 
<Nicolas.Williams at sun.com> wrote:

> On Wed, Sep 24, 2008 at 03:43:33PM -0500, Will Fiveash wrote:
>> On Tue, Sep 23, 2008 at 07:59:55PM -0500, Will Fiveash wrote:
>> > Tom Yu requested that I look into modifying the design for the master
>> > key migration/rollover project to facilitate support for service key
>> > rollover.
>
> Excellent idea!  (This addresses one long thread we had a while back
> about just this topic.)

Yes, agreed.  It also makes it possible to implement functionality in the 
set-passwd draft related to storing new keys separately from taking them 
into use.



>> I thought about this some more and have a modification to the definition
>> of the data stored in KRB5_TL_CURKVNO.  It should be an array holding a
>> variable number of these structs:
>
> I like that -- it could be used for any principal, not just K/M or
> krbtgt/<realm>@<realm>.
>
>> struct krb5_curkvno  {
>>     krb5_kvno curkvno;
>>     krb5_timestamp start_time;
>> }
>
> Why not also end_time, with 0 -> never?

You don't need one.  The usage period for each entry is bounded by the 
start time of the next later entry, and by the principal and key expiration 
times in the KDB entry.  I see no need for an additional place to store 
this data.

BTW, I really hope no one is proposing defining the terms of database 
structures in terms of a C struct.

-- Jeff

From Nicolas.Williams at sun.com  Thu Sep 25 00:56:00 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 24 Sep 2008 23:56:00 -0500
Subject: Update to the design of the Master Key Migration project
In-Reply-To: <9189F5E2145344B960DF6746@sirius.fac.cs.cmu.edu>
References: <20080924005955.GC22993@sun.com> <20080924204333.GD22993@sun.com>
	<200809242123.m8OLNZGL025980@raisinbran.srv.cs.cmu.edu>
	<9189F5E2145344B960DF6746@sirius.fac.cs.cmu.edu>
Message-ID: <20080925045559.GN9765@Sun.COM>

On Wed, Sep 24, 2008 at 06:56:50PM -0400, Jeffrey Hutzelman wrote:
> >Why not also end_time, with 0 -> never?
> 
> You don't need one.  The usage period for each entry is bounded by the 
> start time of the next later entry, and by the principal and key expiration 
> times in the KDB entry.  I see no need for an additional place to store 
> this data.

It's useful for the TGS key -- it allows one to expire old-but-valid
TGTs.

I suppose that's not really necessary.

From since at opendemand.com  Thu Sep 25 01:57:49 2008
From: since at opendemand.com (Stephen Ince)
Date: Thu, 25 Sep 2008 01:57:49 -0400
Subject: krb5_get_in_tkt_with_password with KRB5_REALM_CANT_RESOLVE error
Message-ID: <01c301c91ed3$a4232830$6e00a8c0@desktop2>

I am getting a KRB5_REALM_CANT_RESOLVE error with the 
krb5_get_in_tkt_with_password call.  I am
trying to programmatically get a ticket from KDC server. I am using
kfw 3.3.3 Mit kerberos toolkit.

The userid is matt at FOOBAR.LOCAL.

The host FOOBAR.LOCAL just has an entry in my C:\WINDOWS
\SYSTEM32\DRIVERS\ETC\HOSTS.

69.127.38.76      apache.foobar.local apache
69.127.38.76      kdc.foobar.local kdc
---------------------------------------------------------------

I have tried the following userids.

matt at FOOBAR.LOCAL
matt at kdc.foobar.local
matt at apache.foobar.local
matt at 69.127.38.76

The code is
------------------------------------------------------------------------------
    err = krb5_get_in_tkt_with_password(
       krb5->context,
       kdcFlags, NULL, NULL, NULL, password, krb5->ccache, &krb5-
>credentials, 0);

Is it failing because the kerberos package can't use a host file but
an actual dns entry? Any help would be greatly appreciated.


Steve 


From kenh at cmf.nrl.navy.mil  Thu Sep 25 14:41:58 2008
From: kenh at cmf.nrl.navy.mil (Ken Hornstein)
Date: Thu, 25 Sep 2008 14:41:58 -0400
Subject: Update to the design of the Master Key Migration project 
In-Reply-To: <20080924211514.GG9765@Sun.COM> 
Message-ID: <200809251841.m8PIfwhB006860@hedwig.cmf.nrl.navy.mil>

>Everything that's highlighted is new: 'randkey' and 'delkeys'
>sub-commands, kvnos in use output line, and modprinc '-use_kvno' option.
>
>Yes, I realize that 'delkeys' would require a protocol change, so phat
>chance of that.  I can live without 'delkeys'.  (Or can the randkey RPCs
>be twisted to do a don't-add-keys-just-delete-old-keys RPC?  Do we even
>care?)

You know, from a practical perspective, "delkeys" would be helpful.
Not only would be useful in this case, but I would _love_ the ability
to delete a particular key (based on the enctype) from a principal.
Sample situation - I generate a new host key based on our default enctypes.
I put that on a host, and I discover that I screwed up and put a key
in the keytab that the host's Kerberos implementation cannot support.
It would be wonderful if could delete that key (or otherwise make it
so the KDC would never issue a service ticket for it) without having
to rekey that host.

--Ken

From raeburn at MIT.EDU  Thu Sep 25 14:49:02 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Thu, 25 Sep 2008 14:49:02 -0400
Subject: krb5_get_in_tkt_with_password with KRB5_REALM_CANT_RESOLVE error
In-Reply-To: <01c301c91ed3$a4232830$6e00a8c0@desktop2>
References: <01c301c91ed3$a4232830$6e00a8c0@desktop2>
Message-ID: <A00D8661-0B1A-4DB9-8319-2D9E7E629E27@mit.edu>

On Sep 25, 2008, at 01:57, Stephen Ince wrote:
> I am getting a KRB5_REALM_CANT_RESOLVE error with the
> krb5_get_in_tkt_with_password call.  I am
> trying to programmatically get a ticket from KDC server. I am using
> kfw 3.3.3 Mit kerberos toolkit.
>
> The userid is matt at FOOBAR.LOCAL.
>
> The host FOOBAR.LOCAL just has an entry in my C:\WINDOWS
> \SYSTEM32\DRIVERS\ETC\HOSTS.
>
> 69.127.38.76      apache.foobar.local apache
> 69.127.38.76      kdc.foobar.local kdc


The realm name and KDC host names are independent.  You would need  
information somewhere that says that kdc.foobar.local is the (or at  
least a) KDC for the realm FOOBAR.LOCAL.  In your Kerberos config file  
(normally /etc/krb5.conf on UNIX, I think it's stored somewhere as  
krb5.ini on Windows) you would have a section that looks like:

[realms]
     FOOBAR.LOCAL = {
         kdc = kdc.foobar.local
         [...possibly other info...]
     }

Or, if you have DNS service set up for foobar.local, you could add a  
SRV record for the name "_kerberos._udp.foobar.local.", pointing to  
port 88 (or whatever you select instead) on the KDC machine.

You may also want:

[domain_realm]
     .foobar.local = FOOBAR.LOCAL

to tell client systems what realm name is used for servers in the  
foobar.local domain.  If you have a machine named "foobar.local" too,  
you'd also add a "foobar.local = FOOBAR.LOCAL" line (without the  
leading dot on the left-hand side, this time).

You could also get rid of the "kdc.foobar.local" host entry if you  
want, and just use "apache.foobar.local" in the configuration data  
described above.  Kerberos doesn't really care about the specific form  
of the KDC hostname, and we don't use any heuristics like assuming  
"kdc."+$realm might be the name of a KDC.

Ken

From Nicolas.Williams at sun.com  Thu Sep 25 14:57:37 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 25 Sep 2008 13:57:37 -0500
Subject: Update to the design of the Master Key Migration project
In-Reply-To: <200809251841.m8PIfwhB006860@hedwig.cmf.nrl.navy.mil>
References: <20080924211514.GG9765@Sun.COM>
	<200809251841.m8PIfwhB006860@hedwig.cmf.nrl.navy.mil>
Message-ID: <20080925185736.GV9765@Sun.COM>

On Thu, Sep 25, 2008 at 02:41:58PM -0400, Ken Hornstein wrote:
> >Everything that's highlighted is new: 'randkey' and 'delkeys'
> >sub-commands, kvnos in use output line, and modprinc '-use_kvno' option.
> >
> >Yes, I realize that 'delkeys' would require a protocol change, so phat
> >chance of that.  I can live without 'delkeys'.  (Or can the randkey RPCs
> >be twisted to do a don't-add-keys-just-delete-old-keys RPC?  Do we even
> >care?)
> 
> You know, from a practical perspective, "delkeys" would be helpful.
> Not only would be useful in this case, but I would _love_ the ability
> to delete a particular key (based on the enctype) from a principal.
> Sample situation - I generate a new host key based on our default enctypes.
> I put that on a host, and I discover that I screwed up and put a key
> in the keytab that the host's Kerberos implementation cannot support.
> It would be wonderful if could delete that key (or otherwise make it
> so the KDC would never issue a service ticket for it) without having
> to rekey that host.

Agreed.  I suppose RPCs can always just be added, so, perhaps delkeys
wouldn't be hard.  Will thinks delkeys is outside the scope of this
project though.

Nico
-- 

From William.Fiveash at Sun.COM  Thu Sep 25 17:23:13 2008
From: William.Fiveash at Sun.COM (Will Fiveash)
Date: Thu, 25 Sep 2008 16:23:13 -0500
Subject: Update to the design of the Master Key Migration project
In-Reply-To: <9189F5E2145344B960DF6746@sirius.fac.cs.cmu.edu>
References: <20080924005955.GC22993@sun.com> <20080924204333.GD22993@sun.com>
	<200809242123.m8OLNZGL025980@raisinbran.srv.cs.cmu.edu>
	<9189F5E2145344B960DF6746@sirius.fac.cs.cmu.edu>
Message-ID: <20080925212312.GF22993@sun.com>

On Wed, Sep 24, 2008 at 06:56:50PM -0400, Jeffrey Hutzelman wrote:
> --On Wednesday, September 24, 2008 04:15:14 PM -0500 Nicolas Williams 
> <Nicolas.Williams at sun.com> wrote:
> 
> > On Wed, Sep 24, 2008 at 03:43:33PM -0500, Will Fiveash wrote:
> 
> >> I thought about this some more and have a modification to the definition
> >> of the data stored in KRB5_TL_CURKVNO.  It should be an array holding a
> >> variable number of these structs:
> >
> > I like that -- it could be used for any principal, not just K/M or
> > krbtgt/<realm>@<realm>.
> >
> >> struct krb5_curkvno  {
> >>     krb5_kvno curkvno;
> >>     krb5_timestamp start_time;
> >> }
> >
> > Why not also end_time, with 0 -> never?
> 
> You don't need one.  The usage period for each entry is bounded by the 
> start time of the next later entry, and by the principal and key expiration 
> times in the KDB entry.  I see no need for an additional place to store 
> this data.

Right, that is what I was thinking when I came up with the above.

> BTW, I really hope no one is proposing defining the terms of database 
> structures in terms of a C struct.

Sorry, I was thinking in terms of implementation.  Let me rephrase;
KRB5_TL_CURKVNO will be a set of {curkvno, start_time} tuples where
curkvno is the currently active KVNO and start_time indicates when
curkvno is valid for use.

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

From tlyu at MIT.EDU  Tue Sep 30 12:00:37 2008
From: tlyu at MIT.EDU (Tom Yu)
Date: Tue, 30 Sep 2008 12:00:37 -0400
Subject: telnet & ftp official status
References: <20080918000446.GA5266@sun.com>
	<73708652-DDDB-4402-B058-69B5156D121F@mit.edu>
	<20080919151016.GC1875@Sun.COM>
	<3917C005-FA40-41DF-828D-026E9139E481@kth.se>
	<200809191608.m8JG87D7021184@raisinbran.srv.cs.cmu.edu>
	<A26C524208648C320F7BB090@sirius.fac.cs.cmu.edu>
	<20080919210411.GD1875@Sun.COM>
	<BB7E16A14DE689469A181EC770AFBF4D02045504@exch-one.centrify.com>
Message-ID: <ldvabdphbdm.fsf@cathode-dark-space.mit.edu>

"Mike Patnode" <mike.patnode at centrify.com> writes:

> I seem to remember seeing some comments here about on-going support for
> the telnet & gssftp client/servers.   What the current official line?
> Will they continue to be supported as part of the distribution, or are
> they being dropped in preference for OpenSSH?

The FTP and telnet applications, as well as the BSD "rcmd"
applications, are still present in our main source tree.  Past
discussions have led us to prefer removing them from our main source
code distribution, possibly maintaining them as a separate
distribution, but we do not have a definite timeline for doing so,
partly out of a need to gather more information.  There are also
protocol vulnerabilities in these applications, but some users desire
the simplicity of these applications in preference to OpenSSH.

A few questions we need to consider are:

* Who needs these applications, and why?

* What should be done about the protocol vulnerabilities?

* What advantages are there compared to SSH?

* Should we continue bundling the applications?

We invite comments on the above subjects.

Regarding the eventual removal from our main source distribution, what
I would like to find out is who depends on the continued bundling
these applications in our source tree, and their reasons for requiring
that bundling.  If anyone needs to have these applications bundled in
the MIT Kerberos source code, please let us know.

We need volunteers to maintain the applications if we are to remove
them from the main distribution.  Russ Allbery has expressed a
willingness to do so in the past.  Russ, are you still willing to do
this?  Is anyone else willing to help out?

There are protocol vulnerabilities in these applications, some which
more serious than others.  The telnet protocol extensions supporting
Kerberos have known security issues (lack of integrity protection),
and the code only supports single-DES.  The BSD "rcmd" applications
also have known replay-related protocol vulnerabilities when used for
single-DES, and the revised (more secure) protocol only supports
triple-DES.  The FTP protocol extensions supporting GSS-API also have
a few issues involving channel multiplexing.

The continued presence of these applications in the MIT Kerberos
source tree raises a number of issues.  These applications, by virtue
of being login-related applications, present a multitude of
portability challenges.  Operating system interfaces related to user
login activities appear to have the some of the largest variations of
any operating system interfaces.

Additionally, having the release cycle of these applications tied to
that of the core MIT Kerberos source code is problematic.  Security
vulnerabilities discovered in the applications will require an update
to the krb5 package, due to bundling.  For vendors wishing to track
only the core Kerberos libraries and utilities, this can create
difficulties with their change management processes.

-- 
Tom Yu
Development Manager
MIT Kerberos Consortium

From rra at stanford.edu  Tue Sep 30 17:10:45 2008
From: rra at stanford.edu (Russ Allbery)
Date: Tue, 30 Sep 2008 14:10:45 -0700
Subject: telnet & ftp official status
In-Reply-To: <ldvabdphbdm.fsf@cathode-dark-space.mit.edu> (Tom Yu's message of
	"Tue\, 30 Sep 2008 12\:00\:37 -0400")
References: <20080918000446.GA5266@sun.com>
	<73708652-DDDB-4402-B058-69B5156D121F@mit.edu>
	<20080919151016.GC1875@Sun.COM>
	<3917C005-FA40-41DF-828D-026E9139E481@kth.se>
	<200809191608.m8JG87D7021184@raisinbran.srv.cs.cmu.edu>
	<A26C524208648C320F7BB090@sirius.fac.cs.cmu.edu>
	<20080919210411.GD1875@Sun.COM>
	<BB7E16A14DE689469A181EC770AFBF4D02045504@exch-one.centrify.com>
	<ldvabdphbdm.fsf@cathode-dark-space.mit.edu>
Message-ID: <8763od9w6i.fsf@windlord.stanford.edu>

Tom Yu <tlyu at mit.edu> writes:

> We need volunteers to maintain the applications if we are to remove them
> from the main distribution.  Russ Allbery has expressed a willingness to
> do so in the past.  Russ, are you still willing to do this?  Is anyone
> else willing to help out?

I'm still willing to help maintain Kerberos rlogin, rsh, and rcp.  I think
they're simpler and easier to maintain than ssh, and they're also
less-well-known and therefore not as much of an attack target.  It may be
that I'll slowly change my mind and eventually switch entirely to using
ssh, particularly given the firewall issues with the rsh protocol, but I
still find them convenient.

However, I have very limited amounts of time to look after them (for
example, I've not managed to do more than read through the patches for PAM
support).  So while I'm willing to help, I'm not sure how much time I'll
realistically have and how much work I'll be able to put into them.

I have no personal interest in Kerberos telnet or ftp.  We never used
Kerberos ftp at Stanford and haven't used Kerberos telnet in years.  I'm
happy to help generally support a build infrastructure including those,
but won't have any time to make code changes in those applications in
particular.

I'm separately strongly interested in making sure ksu continues to be
available and works, although I know it's not part of the apps tree and is
something of a separate issue.

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