From hartmans at MIT.EDU  Mon Apr  6 18:31:37 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Mon, 06 Apr 2009 18:31:37 -0400
Subject: Revisiting weak enctypes off by default
Message-ID: <tslmyatpg6u.fsf@mit.edu>



It's my recollection that we were going to revisit the question of
whether to turn weak enctypes off by default for the beta.  Tom
expressed a desire to do so, I expressed support if the appropriate
documentation happened, and I'm not sure what other opinions were expressed.

Obviously, if we don't do that, it's not a huge issue.  I just wanted
to make sure that we didn't let things slip through the cracks and
that if we didn't change the default it was either because we decided
we didn't want to for 1.7 or we didn't have time to get to docs.

--Sam

From tsitkova at MIT.EDU  Mon Apr  6 18:36:21 2009
From: tsitkova at MIT.EDU (Zhanna Tsitkova)
Date: Mon, 6 Apr 2009 18:36:21 -0400
Subject: Fwd: etypes - weak vs medium vs strong
References: <0B0624DE-9BA5-464A-9320-FCC1C92FECF0@mit.edu>
Message-ID: <E5B6C899-92D3-43F1-81A2-BB99DBF53C99@mit.edu>

medium slot is for 3DES

Begin forwarded message:
> From: Sam Hartman <hartmans at MIT.EDU>
> Date: April 6, 2009 6:29:11 PM EDT
> To: Zhanna Tsitkova <tsitkova at mit.edu>
> Cc: krbcore at mit.edu
> Subject: Re: etypes - weak vs medium vs strong
>
> Unless there is some security or other sensitive issue I'm unaware of,
> it would probably be a good idea to move this to krbdev.  We had the
> previous round of discussions of the weak encryption project there
> back in January and some of your ideas are consistent with proposals
> brought up there.
>
> What criteria would you use for medium vs strong.  Weak seems fairly
> easy at least for the current instances: an enctype is weak if it has
> been brute forced.
>
> --Sam
>
Begin forwarded message:

> From: Zhanna Tsitkova <tsitkova at MIT.EDU>
> Date: April 6, 2009 6:15:12 PM EDT
> To: krbcore at mit.edu
> Subject: etypes - weak vs medium vs strong
>
> Hi!
> I was looking @ etypes.c and found that some of the enc types are  
> marked as ETYPE_WEAK ( des-cbc and friends ) while the others are  
> not classified at all. I think it would be a good idea to  
> categorize  them as weak-medium-strong and in the config file allow  
> to indicate just a type, for example
> default_tgs_enctypes = ETYPE_HIGH
>
> I'm coming from OpenSSL approach (http://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS 
> ). In my opinion it make the config file more readable.
>
> OpenSSL classifies them by
> High - AES128-AES256  - key length > 128
> Medium - 3DES - key length == 128 bits    ( currently, our's des3- 
> cbc-raw  is  ETYPE_WEAK)
> Low - DES  - key length < 128
>
> Thanks,
> Zhanna
>
>


From Nicolas.Williams at sun.com  Mon Apr  6 18:56:57 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 6 Apr 2009 17:56:57 -0500
Subject: Fwd: etypes - weak vs medium vs strong
In-Reply-To: <E5B6C899-92D3-43F1-81A2-BB99DBF53C99@mit.edu>
References: <0B0624DE-9BA5-464A-9320-FCC1C92FECF0@mit.edu>
	<E5B6C899-92D3-43F1-81A2-BB99DBF53C99@mit.edu>
Message-ID: <20090406225656.GN1500@Sun.COM>

On Mon, Apr 06, 2009 at 06:36:21PM -0400, Zhanna Tsitkova wrote:
> > From: Zhanna Tsitkova <tsitkova at MIT.EDU>
> > Date: April 6, 2009 6:15:12 PM EDT
> > To: krbcore at mit.edu
> > Subject: etypes - weak vs medium vs strong
> >
> > Hi!
> > I was looking @ etypes.c and found that some of the enc types are  
> > marked as ETYPE_WEAK ( des-cbc and friends ) while the others are  
> > not classified at all. I think it would be a good idea to  
> > categorize  them as weak-medium-strong and in the config file allow  
> > to indicate just a type, for example
> > default_tgs_enctypes = ETYPE_HIGH
> >
> > I'm coming from OpenSSL approach (http://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS 
> > ). In my opinion it make the config file more readable.
> >
> > OpenSSL classifies them by
> > High - AES128-AES256  - key length > 128
> > Medium - 3DES - key length == 128 bits    ( currently, our's des3- 
> > cbc-raw  is  ETYPE_WEAK)
> > Low - DES  - key length < 128

I'm of the opinion that enctypes' relative strength varies over time as
cryptanalysis advances are uneven.

Therefore this sort of thing should be configurable.  Applications and
users should deal in "fast" and "strong" but the actual meanings of
those labels should be configurable.

Nico
-- 

From tsitkova at MIT.EDU  Mon Apr  6 19:06:27 2009
From: tsitkova at MIT.EDU (Zhanna Tsitkova)
Date: Mon, 6 Apr 2009 19:06:27 -0400
Subject: FAST - enable by default?
In-Reply-To: <tsly6udpgme.fsf@mit.edu>
References: <ADBDAE1F-3991-45E7-B223-080368BEC7DB@mit.edu>
	<1239050349.6777.45.camel@ray>
	<6A50F634-C34C-4421-BF57-E453EB5D0419@mit.edu>
	<7039FAB8-18D3-47C0-A313-76CA8A951DFB@mit.edu>
	<tsly6udpgme.fsf@mit.edu>
Message-ID: <5865ACCC-4215-4F45-8F3F-21CF22F58EBE@mit.edu>

Hmm... this brings us to the conversation about code modularity.

Thinking Kerberos Lite Client I'm coming from the opposite direction  
as one should have as small code/functionality footprint on the mobile  
device as possible. It would not be enough to identify just client vs  
server code - because some clients may need "server" functionality  
(U2U scenario)  , but also allow customers pick up the functionality  
they desire for their client-to-be. So, I suggest to restrict the  
functionality of the library during build time with such flags as  
NO_DES, NO_PKINIT, NO_RCACHE etc.




On Apr 6, 2009, at 6:22 PM, Sam Hartman wrote:

>>>>>> "Stephen" == Stephen C Buckley <sbuckley at MIT.EDU> writes:
>
>    Stephen> On Apr 6, 2009, at 5:35 PM, Zhanna Tsitkova wrote:
>
>> adding Sam.
>>>
>
> I'm certainly no expert, but isn't this a krbcore type question?
>
> I would actually think krbdev.
>
> So, there are two aspects to this.  1) compile-time.  Do we enable
> FAST at compile time.  Our policy has typically been to minimize the
> number of compile-time options, preferring to turn everything on and
> to the extent we provide configuration to do so at run-time.  The
> justification here is that many vendors ship our code as binaries as
> part of their operating systems.  When we provide a compile time
> option we provide vendors with a way to confuse their users by making
> functionality unavailable.  At best, the vendors will turn everything
> on.  At worst, they will turn some things off, and then the question
> of what is available on my operating system that ships MIT Kerberos
> 1.6.3 becomes more confusing than it should be.  Marshall was really
> strict about this; I was a bit less so, but certainly agreed with the
> general principle.
>
> Under this principle, FAST should definitely be enabled by default.
>
> Discussions of this principle should probably be on krbdev.

Hmm... this brings us to the code modularity.

Thinking Kerberos Lite Client I'm coming from the opposite direction  
as one should have as small code/functionality footprint on the mobile  
device as possible. It would not be enough - although one of the steps  
- to identify just client vs server code - because some clients may  
need "server" functionality (U2U scenario)  , but also allow customers  
to pick up the functionality they desire for their client-to-be. So, I  
suggest to restrict the functionality of the library during build time  
with such flags as NO_3DES, NO_PKINIT, NO_RCACHE, well... NO_FAST,  etc.

>
>
> 2) Runtime.  I don't see a need to disable FAST at the KDC layer.  We
> have typically not been concerned about KDC performance.  It's my
> understanding that Redhat has been a bit concerned about database
> performance, but I don't think anyone has brought up KDC crypto
> performance.
>
> Everything currently on the trunk requires explicit client
> configuration to enable.  I do have changes for client TGS support
> that would be on by default.  If we were going to ship Larry's
> negotiation stuff, I'd actually think  that was a really good idea.
> However given where things stand it's less clear to me that we want to
> turn on FAST all the time on the client for TGS.
>
> My concern is more about making a change this close to the release
> than about performance.
>


> From: Greg Hudson <ghudson at MIT.EDU>
> Date: April 6, 2009 4:39:09 PM EDT
> To: Zhanna Tsitkova <tsitkova at mit.edu>
> Cc: Tom Yu <tlyu at mit.edu>, "Stephen C. Buckley" <sbuckley at mit.edu>,  
> Thomas Hardjono <hardjono at mit.edu>
> Subject: Re: FAST - enable by default?
>
> The expensive part of FAST is the extra encryptions performed by the
> client and KDC when FAST is used via a ticket-based armor request.  I
> don't believe this will happen serendipitously; as currently  
> implemented
> it requires specific configuration.  Sam would know more about this.
> Actively preventing FAST from being used against a KDC should be as
> simple as removing the plugin, and perhaps simpler.
>
> In cases where FAST is not used, I believe the only performance impact
> is scanning the padata for a FAST request, and that's probably not
> measurable.
>
> On Mon, 2009-04-06 at 12:26 -0400, Zhanna Tsitkova wrote:
>> Hi!
>> FAST introduces the additional performance drawback and it is  
>> possible
>> that not all appl would want it for one or another reason.
>> Don't you think that one should have an option to disable it during
>> build or run time?
>>
>> Thanks,
>> Zhanna
>


From raeburn at MIT.EDU  Mon Apr  6 19:46:03 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Mon, 6 Apr 2009 19:46:03 -0400
Subject: etypes - weak vs medium vs strong
In-Reply-To: <E5B6C899-92D3-43F1-81A2-BB99DBF53C99@mit.edu>
References: <0B0624DE-9BA5-464A-9320-FCC1C92FECF0@mit.edu>
	<E5B6C899-92D3-43F1-81A2-BB99DBF53C99@mit.edu>
Message-ID: <2555B6A2-B64D-4787-BE03-E4B58D8964B1@mit.edu>

On Apr 6, 2009, at 18:36, Zhanna Tsitkova wrote:
>> I was looking @ etypes.c and found that some of the enc types are
>> marked as ETYPE_WEAK ( des-cbc and friends ) while the others are
>> not classified at all. I think it would be a good idea to
>> categorize  them as weak-medium-strong and in the config file allow
>> to indicate just a type, for example
>> default_tgs_enctypes = ETYPE_HIGH

I'd be concerned with backwards compatibility if the definition of  
"ETYPE_HIGH" changes across releases.  The issue exists even with weak  
vs non-weak, but adding more gradations gives more opportunity for  
problems.  I'm not sure that's a big problem though, compared to the  
ability to say, "*this* machine/service/whatever requires use of the  
strongest encryption systems we've got".

>> High - AES128-AES256  - key length > 128
>> Medium - 3DES - key length == 128 bits    ( currently, our's des3-
>> cbc-raw  is  ETYPE_WEAK)
>> Low - DES  - key length < 128

The 3DES we use has a key length of 168 bits, longer than AES128,  
though by some measures the strength is only 112 (twice that of DES).   
Also, note that des3-cbc-raw is not an encryption type you'd use in  
Kerberos -- the "raw" encryption (without integrity protection) was  
stuck in using the same interface as integrity-protection encryption,  
and only the latter should be used in Kerberos.  And it's only there  
for DES and triple-DES, not for AES or RC4.  I think in an API  
redesign, the two types of functionality (encryption with vs without  
integrity protection -- and similarly keyed vs unkeyed hashes) should  
perhaps be made separate interfaces, to remove any possibility of  
misuse.

Triple-DES with a SHA-1 HMAC is not marked as weak.

Ken

From hartmans at MIT.EDU  Mon Apr  6 20:21:21 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Mon, 06 Apr 2009 20:21:21 -0400
Subject: FAST - enable by default?
In-Reply-To: <5865ACCC-4215-4F45-8F3F-21CF22F58EBE@mit.edu> (Zhanna Tsitkova's
	message of "Mon\, 6 Apr 2009 19\:06\:27 -0400")
References: <ADBDAE1F-3991-45E7-B223-080368BEC7DB@mit.edu>
	<1239050349.6777.45.camel@ray>
	<6A50F634-C34C-4421-BF57-E453EB5D0419@mit.edu>
	<7039FAB8-18D3-47C0-A313-76CA8A951DFB@mit.edu>
	<tsly6udpgme.fsf@mit.edu>
	<5865ACCC-4215-4F45-8F3F-21CF22F58EBE@mit.edu>
Message-ID: <tsliqlhpb3y.fsf@mit.edu>

>>>>> "Zhanna" == Zhanna Tsitkova <tsitkova at MIT.EDU> writes:

    Zhanna> Hmm... this brings us to the conversation about code
    Zhanna> modularity.  Thinking Kerberos Lite Client I'm coming from
    Zhanna> the opposite direction as one should have as small
    Zhanna> code/functionality footprint on the mobile device as
    Zhanna> possible. It would not be enough to identify just client
    Zhanna> vs server code - because some clients may need "server"
    Zhanna> functionality (U2U scenario) , but also allow customers
    Zhanna> pick up the functionality they desire for their
    Zhanna> client-to-be.  So, I suggest to restrict the functionality
    Zhanna> of the library during build time with such flags as
    Zhanna> NO_DES, NO_PKINIT, NO_RCACHE etc.


Note that the wider development community has not thought through the
small client design implications and has not been brought into the
mind set necessary for this.

I completely understand the urgency of the 1.7 lite client work.
however this was somewhat of a one-off.

To turn this into a change in design philosophy, I think you're going
to need to have a fairly broad discussion with the community where you
articulate and build consensus around the design goals.  You also
probably want to confirm some basic assumptions, like the assumption
that it is desirable to meet the needs of the general hosted community
and the small client community in one code base, rather than say
maintaining patches targeted for each mobile environment.

I think it is undesirable to start applying this sort of design to new
projects without clearly articulated principles and general agreement to these principles.

You've been thinking about this for a while.  Part of an open source
project is an education/common ground building exercise to build and
refine a shared understanding and to get everyone onto the same page.
That's the same sort of process needed to change long-standing assumptions like the minimize build time options assumption.

There are valid design tradeoffs associated both with the desire to
have small code in limited scope environments and with the desire to
have a uniform code base on hosted platforms.  Unless you build some
common understanding of the goals that this project has agreed to,
you're always going to run into a push/pull where different people
have different ideas about where to draw lines.

--Sam

From tsitkova at MIT.EDU  Mon Apr  6 21:52:27 2009
From: tsitkova at MIT.EDU (Zhanna Tsitkova)
Date: Mon, 6 Apr 2009 21:52:27 -0400
Subject: FAST - enable by default?
In-Reply-To: <tsliqlhpb3y.fsf@mit.edu>
References: <ADBDAE1F-3991-45E7-B223-080368BEC7DB@mit.edu>
	<1239050349.6777.45.camel@ray>
	<6A50F634-C34C-4421-BF57-E453EB5D0419@mit.edu>
	<7039FAB8-18D3-47C0-A313-76CA8A951DFB@mit.edu>
	<tsly6udpgme.fsf@mit.edu>
	<5865ACCC-4215-4F45-8F3F-21CF22F58EBE@mit.edu>
	<tsliqlhpb3y.fsf@mit.edu>
Message-ID: <AC163BE1-C2B8-4306-B78C-8A24B45C62D4@mit.edu>

Well, another approach would be dividing the code into smaller files  
in such way that when constructing  the client one would pick up the  
object files needed to fulfill the functionality requirement.  
Basically, build the whole code, collect needed object files and then  
link them into the library/appl.
Thanks,
Zhanna


On Apr 6, 2009, at 8:21 PM, Sam Hartman wrote:

>>>>>> "Zhanna" == Zhanna Tsitkova <tsitkova at MIT.EDU> writes:
>
>    Zhanna> modularity.  Thinking Kerberos Lite Client I'm coming from
>
>    Zhanna> the opposite direction as one should have as small
>    Zhanna> code/functionality footprint on the mobile device as
>    Zhanna> possible. It would not be enough to identify just client
>    Zhanna> vs server code - because some clients may need "server"
>    Zhanna> functionality (U2U scenario) , but also allow customers
>    Zhanna> pick up the functionality they desire for their
>    Zhanna> client-to-be.  So, I suggest to restrict the functionality
>    Zhanna> of the library during build time with such flags as
>    Zhanna> NO_DES, NO_PKINIT, NO_RCACHE etc.
>
>
> Note that the wider development community has not thought through the
> small client design implications and has not been brought into the
> mind set necessary for this.
>
> I completely understand the urgency of the 1.7 lite client work.
> however this was somewhat of a one-off.
>
> To turn this into a change in design philosophy, I think you're going
> to need to have a fairly broad discussion with the community where you
> articulate and build consensus around the design goals.  You also
> probably want to confirm some basic assumptions, like the assumption
> that it is desirable to meet the needs of the general hosted community
> and the small client community in one code base, rather than say
> maintaining patches targeted for each mobile environment.
>
> I think it is undesirable to start applying this sort of design to new
> projects without clearly articulated principles and general  
> agreement to these principles.
>
> You've been thinking about this for a while.  Part of an open source
> project is an education/common ground building exercise to build and
> refine a shared understanding and to get everyone onto the same page.
> That's the same sort of process needed to change long-standing  
> assumptions like the minimize build time options assumption.
>
> There are valid design tradeoffs associated both with the desire to
> have small code in limited scope environments and with the desire to
> have a uniform code base on hosted platforms.  Unless you build some
> common understanding of the goals that this project has agreed to,
> you're always going to run into a push/pull where different people
> have different ideas about where to draw lines.
>
> --Sam


From ttierney at ecopy.com  Mon Apr  6 11:42:51 2009
From: ttierney at ecopy.com (Tim Tierney)
Date: Mon, 6 Apr 2009 08:42:51 -0700 (PDT)
Subject: CAC single sign on/authentication in a Client/Server C++
Message-ID: <22911463.post@talk.nabble.com>


Hello,

I'm am trying to develop a Common Access Card client/server solution using
C++ and I'm looking for reference material/documentation.  I'd assume I need
PKInit extensions as well.

My client will be running on XP, server could be on XP or Windows 2003
server, and the KDC server will be Windows 2003.  Users will be required to
login with their CAC/Smart Card (certificate logon).

My client will have a CAC (Common Access Card) Card reader, using a
certificate based logon.  After a successful logon, I would like to pass the
public certificate to my server application running as a Service (Local
System acct).  I would like my server to talk to the KDC to obtain a
Kerberos TGT.  Then I can impersonate or create processes as the CAC/Smart
Card user.

Is this even possible?  

Is there any documentation that someone can point me too that I can use as a
reference?  I have been searching the forum and I didn't find any
information yet.  I'm still looking.

I'm do not need to talk to the card (I've got that code).  It is the
authentication mechanism between the client/server app that I need direction
on.

Any pointers/help would be greatly appreciated.

-Tim

P.S.  If I'm not supposed to post this type of question here please let me
know.
-- 
View this message in context: http://www.nabble.com/CAC-single-sign-on-authentication-in-a-Client-Server-C%2B%2B-tp22911463p22911463.html
Sent from the Kerberos - Dev mailing list archive at Nabble.com.


From deengert at anl.gov  Tue Apr  7 10:18:07 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Tue, 07 Apr 2009 09:18:07 -0500
Subject: CAC single sign on/authentication in a Client/Server C++
In-Reply-To: <22911463.post@talk.nabble.com>
References: <22911463.post@talk.nabble.com>
Message-ID: <49DB609F.4050907@anl.gov>



Tim Tierney wrote:
> Hello,
> 
> I'm am trying to develop a Common Access Card client/server solution using
> C++ and I'm looking for reference material/documentation.  I'd assume I need
> PKInit extensions as well.
> 
> My client will be running on XP, server could be on XP or Windows 2003
> server, and the KDC server will be Windows 2003.  Users will be required to
> login with their CAC/Smart Card (certificate logon).

We are doing something similar with the PIV cards. As I understand CAC
cards are being converted to PIV.

There are a couple of routes:

   For Windows login, you will need a windows CSP that understands CAC/PIV.
   Windows 7 has this built in, for PIV at least.

   ActivCard has middleware to do this on XP and Vista.

   Use an open source CSP, like the CoolKey CSP, but since Microsoft is
   going to support PIV we gave up on using CoolKey.

> 
> My client will have a CAC (Common Access Card) Card reader, using a
> certificate based logon. 

I.E. Windows uses PKINIT, and gets a TGT for the user.

> After a successful logon, I would like to pass the
> public certificate to my server application running as a Service (Local
> System acct).   I would like my server to talk to the KDC to obtain a
> Kerberos TGT.  Then I can impersonate or create processes as the CAC/Smart
> Card user.

After login, Windows and the LSA would already have a TGT for the user, so
it is not clear why you need to get another one. It addition to passing
the certificate you will also need access to the card to sign responses
for PKINIT. (Or TLS.)

> 
> Is this even possible?  
> 
> Is there any documentation that someone can point me too that I can use as a
> reference?  I have been searching the forum and I didn't find any
> information yet.  I'm still looking.

Google for:
ActivCard CAC
CAC PKINIT
CAC pkcs#11
Windows 7 PIV smart card
Windows PKINIT CAC

> 
> I'm do not need to talk to the card (I've got that code).  It is the
> authentication mechanism between the client/server app that I need direction
> on.

Once you login you have Kerberos tickets.

IE can also use the CSP for TLS.  Netscape/FireFox/Thunderbird  can use PKCS#11
to access a card too.

> 
> Any pointers/help would be greatly appreciated.
> 
> -Tim
> 
> P.S.  If I'm not supposed to post this type of question here please let me
> know.

-- 

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

From hartmans at MIT.EDU  Tue Apr  7 10:39:19 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 07 Apr 2009 10:39:19 -0400
Subject: FAST - enable by default?
In-Reply-To: <AC163BE1-C2B8-4306-B78C-8A24B45C62D4@mit.edu> (Zhanna Tsitkova's
	message of "Mon\, 6 Apr 2009 21\:52\:27 -0400")
References: <ADBDAE1F-3991-45E7-B223-080368BEC7DB@mit.edu>
	<1239050349.6777.45.camel@ray>
	<6A50F634-C34C-4421-BF57-E453EB5D0419@mit.edu>
	<7039FAB8-18D3-47C0-A313-76CA8A951DFB@mit.edu>
	<tsly6udpgme.fsf@mit.edu>
	<5865ACCC-4215-4F45-8F3F-21CF22F58EBE@mit.edu>
	<tsliqlhpb3y.fsf@mit.edu>
	<AC163BE1-C2B8-4306-B78C-8A24B45C62D4@mit.edu>
Message-ID: <tslskkko7e0.fsf@mit.edu>

>>>>> "Zhanna" == Zhanna Tsitkova <tsitkova at MIT.EDU> writes:

    Zhanna> Well, another approach would be dividing the code into
    Zhanna> smaller files in such way that when constructing the
    Zhanna> client one would pick up the object files needed to
    Zhanna> fulfill the functionality requirement.  Basically, build
    Zhanna> the whole code, collect needed object files and then link
    Zhanna> them into the library/appl.  Thanks, Zhanna


If we could figure out how to make this work, I think it would be a good approach.

Basically what it would mean is that all you would need to do to trim
Kerberos for some environment is to patch function call tables.  It
would mean that as someone trying to trim Kerberos, you are
responsible for making the system as a whole be consistent.  

It would argue against linked function call tables.  For example,
having one big accessor would not be a good idea because keeping track
of what goes in that would be difficult.  But you could have an
accessor for GSS-API (possibly with a separate one for RC4) or
possibly one for GSS acceptors and one for GSS initiators.

But then the major trimming points would be tables of enctypes, the
export list from the libraries, and possibly a few others.

Even with this approach, there is a lot of work to do to design
current and future code so that you get optimal results when you trim
things.
However it seems like it would be more maintainable than a lot of other approaches.

--Sam

From TTierney at ecopy.com  Tue Apr  7 10:43:19 2009
From: TTierney at ecopy.com (Tim Tierney)
Date: Tue, 7 Apr 2009 10:43:19 -0400
Subject: CAC single sign on/authentication in a Client/Server C++
In-Reply-To: <49DB609F.4050907@anl.gov>
References: <22911463.post@talk.nabble.com> <49DB609F.4050907@anl.gov>
Message-ID: <00216B2F12165648A83C8EBAA1F6C0F3010BA24E@ex01.eCopy.com>

Douglas,

Thank you for you reply.  

Quick overview.  I have ActivIdentiy and a CAC/PKI Domain setup and
users are authenticating on my client (XP) to a Windows 2003 server
using their CAC cards.

In response to "After login, Windows and the LSA would already have a
TGT for the user, so it is not clear why you need to get another one. It
addition to passing the certificate you will also need access to the
card to sign responses for PKINIT. (Or TLS.)"


My apps are C++/COM Windows based and not using IE at all.  My client
app is running on XP and has access to the CAC card/certificate.  I need
to pass information (I assume the public ID certificate) to my Server so
I can impersonate the client's logged on user on the Server.  I was
hoping to get a Kerberos TGT on the server to give me more access.  This
is what I'm lacking info about how to implement.

Currently I've created a SSL connection to get the security access token
of my client user on the server.  I have set up a TCP socket connection
to talk between the client/server so I can go back to the card. 

Thanks again,

-Tim


-----Original Message-----
From: Douglas E. Engert [mailto:deengert at anl.gov] 
Sent: Tuesday, April 07, 2009 10:18
To: Tim Tierney
Cc: krbdev at mit.edu
Subject: Re: CAC single sign on/authentication in a Client/Server C++



Tim Tierney wrote:
> Hello,
> 
> I'm am trying to develop a Common Access Card client/server solution 
> using
> C++ and I'm looking for reference material/documentation.  I'd assume 
> C++ I need
> PKInit extensions as well.
> 
> My client will be running on XP, server could be on XP or Windows 2003

> server, and the KDC server will be Windows 2003.  Users will be 
> required to login with their CAC/Smart Card (certificate logon).

We are doing something similar with the PIV cards. As I understand CAC
cards are being converted to PIV.

There are a couple of routes:

   For Windows login, you will need a windows CSP that understands
CAC/PIV.
   Windows 7 has this built in, for PIV at least.

   ActivCard has middleware to do this on XP and Vista.

   Use an open source CSP, like the CoolKey CSP, but since Microsoft is
   going to support PIV we gave up on using CoolKey.

> 
> My client will have a CAC (Common Access Card) Card reader, using a 
> certificate based logon.

I.E. Windows uses PKINIT, and gets a TGT for the user.

> After a successful logon, I would like to pass the public certificate 
> to my server application running as a Service (Local
> System acct).   I would like my server to talk to the KDC to obtain a
> Kerberos TGT.  Then I can impersonate or create processes as the 
> CAC/Smart Card user.

After login, Windows and the LSA would already have a TGT for the user,
so it is not clear why you need to get another one. It addition to
passing the certificate you will also need access to the card to sign
responses for PKINIT. (Or TLS.)

> 
> Is this even possible?  
> 
> Is there any documentation that someone can point me too that I can 
> use as a reference?  I have been searching the forum and I didn't find

> any information yet.  I'm still looking.

Google for:
ActivCard CAC
CAC PKINIT
CAC pkcs#11
Windows 7 PIV smart card
Windows PKINIT CAC

> 
> I'm do not need to talk to the card (I've got that code).  It is the 
> authentication mechanism between the client/server app that I need 
> direction on.

Once you login you have Kerberos tickets.

IE can also use the CSP for TLS.  Netscape/FireFox/Thunderbird  can use
PKCS#11 to access a card too.

> 
> Any pointers/help would be greatly appreciated.
> 
> -Tim
> 
> P.S.  If I'm not supposed to post this type of question here please 
> let me know.

-- 

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


From tlyu at MIT.EDU  Tue Apr  7 14:10:25 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Tue, 07 Apr 2009 14:10:25 -0400
Subject: MITKRB5-SA-2009-002: ASN.1 decoder frees uninitialized pointer
	[CVE-2009-0846]
Message-ID: <ldvvdpg72su.fsf@cathode-dark-space.mit.edu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

MITKRB5-SA-2009-002

MIT krb5 Security Advisory 2009-002
Original release: 2009-04-07
Last update: 2009-04-07

Topic: ASN.1 decoder frees uninitialized pointer

[CVE-2009-0846]
ASN.1 GeneralizedTime decoder can free uninitialized pointer

CVSSv2 Vector: AV:N/AC:L/Au:N/C:C/I:C/A:C/E:POC/RL:OF/RC:C

CVSSv2 Base Score:      10

Access Vector:          Network
Access Complexity:      Low
Authentication:         None
Confidentiality Impact: Complete
Integrity Impact:       Complete
Availability Impact:    Complete

CVSSv2 Temporal Score:  7.8

Exploitability:         Proof-of-Concept
Remediation Level:      Official Fix
Report Confidence:      Confirmed

SUMMARY
=======

[CVE-2009-0846]

An ASN.1 decoder can free an uninitialized pointer when decoding an
invalid encoding.  This can cause a Kerberos application to crash, or,
under theoretically possible but unlikely circumstances, execute
arbitrary malicious code.  No exploit is known to exist that would
cause arbitrary code execution.

This is an implementation vulnerability in MIT krb5, and is not a
vulnerability in the Kerberos protocol.

IMPACT
======

[CVE-2009-0846] An unauthenticated, remote attacker could cause a
Kerberos application, including the Kerberos administration daemon
(kadmind) or the KDC to crash, and possibly to execute arbitrary code.

Compromise of the KDC or kadmind can compromise the Kerberos key
database and host security on the KDC host.  (The KDC and kadmind
typically run as root.)  We believe this scenario is highly unlikely,
given the details of the vulnerability.

Third-party applications using MIT krb5 may also be vulnerable.

MITIGATING FACTORS
==================

While it is theoretically possible for an attacker to execute
arbitrary code by exploiting this vulnerability, it is believed to be
more difficult than exploiting other sorts of memory management flaws
such as double-free or heap buffer overflow events.  Also, in order to
exploit this vulnerability to remotely execute code, an attacker must
ensure that the uninitialized pointer points to valid address space,
otherwise a null-dereference crash will typically occur.

Some operating systems have hardened malloc implementations that are
not susceptible to this problem.  These operating systems are still
vulnerable to a denial of service if the uninitialized pointer points
to invalid address space.

AFFECTED SOFTWARE
=================

* All MIT krb5 releases

* Third-party software using the krb5 library from MIT krb5 releases

FIXES
=====

* The upcoming krb5-1.7 and krb5-1.6.4 releases will contain fixes for
  this vulnerability.

* Apply the patch

diff --git a/src/lib/krb5/asn.1/asn1_decode.c b/src/lib/krb5/asn.1/asn1_decode.c
index aa4be32..5f7461d 100644
- --- a/src/lib/krb5/asn.1/asn1_decode.c
+++ b/src/lib/krb5/asn.1/asn1_decode.c
@@ -231,6 +231,7 @@ asn1_error_code asn1_decode_generaltime(asn1buf *buf, time_t *val)
 
   if(length != 15) return ASN1_BAD_LENGTH;
   retval = asn1buf_remove_charstring(buf,15,&s);
+  if (retval) return retval;
   /* Time encoding: YYYYMMDDhhmmssZ */
   if(s[14] != 'Z') {
       free(s);
diff --git a/src/tests/asn.1/krb5_decode_test.c b/src/tests/asn.1/krb5_decode_test.c
index 0ff9343..1c427d1 100644
- --- a/src/tests/asn.1/krb5_decode_test.c
+++ b/src/tests/asn.1/krb5_decode_test.c
@@ -485,6 +485,22 @@ int main(argc, argv)
     ktest_destroy_keyblock(&(ref.subkey));
     ref.seq_number = 0;
     decode_run("ap_rep_enc_part","(optionals NULL)","7B 1C 30 1A A0 11 18 0F 31 39 39 34 30 36 31 30 30 36 30 33 31 37 5A A1 05 02 03 01 E2 40",decode_krb5_ap_rep_enc_part,ktest_equal_ap_rep_enc_part,krb5_free_ap_rep_enc_part);
+
+    retval = krb5_data_hex_parse(&code, "7B 06 30 04 A0 11 18 0F 31 39 39 34 30 36 31 30 30 36 30 33 31 37 5A A1 05 02 03 01 E2 40");
+    if (retval) {
+	com_err("krb5_decode_test", retval, "while parsing");
+	exit(1);
+    }
+    retval = decode_krb5_ap_rep_enc_part(&code, &var);
+    if (retval != ASN1_OVERRUN) {
+	printf("ERROR: ");
+    } else {
+	printf("OK: ");
+    }
+    printf("ap_rep_enc_part(optionals NULL + expect ASN1_OVERRUN for inconsistent length of timestamp)\n");
+    krb5_free_data_contents(test_context, &code);
+    krb5_free_ap_rep_enc_part(test_context, var);
+
     ktest_empty_ap_rep_enc_part(&ref);
   }
   
  This patch is also available at

  http://web.mit.edu/kerberos/advisories/2009-002-patch.txt

  A PGP-signed patch is available at

  http://web.mit.edu/kerberos/advisories/2009-002-patch.txt.asc

REFERENCES
==========

This announcement is posted at:

  http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2009-002.txt

This announcement and related security advisories may be found on the
MIT Kerberos security advisory page at:

        http://web.mit.edu/kerberos/advisories/index.html

The main MIT Kerberos web page is at:

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

CVSSv2:

    http://www.first.org/cvss/cvss-guide.html
    http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2

CVE: CVE-2009-0846
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0846

CERT: VU#662091
http://www.kb.cert.org/vuls/id/662091

CONTACT
=======

The MIT Kerberos Team security contact address is
<krbcore-security at mit.edu>.  When sending sensitive information,
please PGP-encrypt it using the following key:

pub   2048R/D9058C24 2009-01-26 [expires: 2010-02-01]
uid     MIT Kerberos Team Security Contact <krbcore-security at mit.edu>

DETAILS
=======

The asn1_decode_generaltime() function, which decodes DER encodings of
the ASN.1 type "GeneralizedTime", can free an uninitialized pointer.
This can cause a Kerberos application to crash, or, under
theoretically possible but unlikely circumstances, execute arbitrary
malicious code.  No exploit is known to exist that would cause
arbitrary code execution.

REVISION HISTORY
================

2009-04-07      original release

Copyright (C) 2009 Massachusetts Institute of Technology
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (SunOS)

iQCVAgUBSduVcabDgE/zdoE9AQI+OgQApBBzBcQYG2GfuPIvZhwhJlvaWzSAQpb4
lYgScNNihKVs+xQF8vE5omSXSC/uaRkb5pGd0sa+LAmNCCjwNGT13f5TB6fAKTwS
MRxmJ6whZGTz+3myihBa/pac14hE0q4XTRw/BgCv4lL1B94/K9FyAFSsAWkkV/Mr
H1P8smh5svk=
=z9B1
-----END PGP SIGNATURE-----
_______________________________________________
kerberos-announce mailing list
kerberos-announce at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos-announce

From tlyu at MIT.EDU  Tue Apr  7 14:10:18 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Tue, 07 Apr 2009 14:10:18 -0400
Subject: MITKRB5-SA-2009-001: multiple vulnerabilities in SPNEGO,
	ASN.1 decoder [CVE-2009-0844 CVE-2009-0845 CVE-2009-0847]
Message-ID: <ldvy6uc72t1.fsf@cathode-dark-space.mit.edu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

MITKRB5-SA-2009-001

MIT krb5 Security Advisory 2009-001
Original release: 2009-04-07
Last update: 2009-04-07

Topic: multiple vulnerabilities in SPNEGO, ASN.1 decoder

[CVE-2009-0844]
SPNEGO implementation can read beyond buffer end

CVSSv2 Vector: AV:N/AC:L/Au:N/C:P/I:N/A:C/E:POC/RL:OF/RC:C

CVSSv2 Base Score:      8.5

Access Vector:          Network
Access Complexity:      Low
Authentication:         None
Confidentiality Impact: Partial
Integrity Impact:       None
Availability Impact:    Complete

CVSSv2 Temporal Score:  6.7

Exploitability:         Proof-of-Concept
Remediation Level:      Official Fix
Report Confidence:      Confirmed

[CVE-2009-0845]
SPNEGO implementation can dereference a null pointer

CVSSv2 Vector: AV:N/AC:L/Au:N/C:N/I:N/A:C/E:POC/RL:OF/RC:C
CVSSv2 Base Score:      7.8
CVSSv2 Temporal Score:  6.1

[CVE-2009-0847]
ASN.1 decoder incorrect length validation

CVSSv2 Vector: AV:N/AC:L/Au:N/C:N/I:N/A:C/E:POC/RL:OF/RC:C
CVSSv2 Base Score:      7.8
CVSSv2 Temporal Score:  6.1

See DETAILS for the expanded CVSSv2 metrics for CVE-2009-0845 and
CVE-2009-0847.

SUMMARY
=======

These are implementation vulnerabilities in MIT krb5, and not
vulnerabilities in the Kerberos protocol.

[CVE-2009-0844]

The MIT krb5 implementation of the SPNEGO GSS-API mechanism can read
beyond the end of a network input buffer.  This can cause a GSS-API
application to crash by reading from invalid address space.  Under
theoretically possible but very unlikely conditions, a small
information leak may occur.  We believe that no successful exploit
exists that could induce an information leak.

[CVE-2009-0845]

The MIT krb5 implementation of the SPNEGO GSS-API mechanism can
dereference a null pointer under error conditions. This can cause a
GSS-API application to crash.  This vulnerability was previously
publicly disclosed.

[CVE-2009-0847]

MIT krb5 can perform an incorrect length check inside an ASN.1
decoder.  This only presents a problem in the PK-INIT code paths.  In
the MIT krb5 KDC or kinit program, this could lead to spurious
malloc() failures or, under some conditions, program crash.  We have
heard reports of the spurious malloc() failures, but nobody has yet
made the publicly made the connection to a security issue.

IMPACT
======

[CVE-2009-0844] An unauthenticated, remote attacker could cause a
GSS-API application, including the Kerberos administration daemon
(kadmind) to crash.  Under extremely unlikely conditions, there may be
a theoretical possibility of a small information disclosure.

[CVE-2009-0845] An unauthenticated, remote attacker could cause a
GSS-API application, including the Kerberos administration daemon
(kadmind) to crash.

[CVE-2009-0847] An unauthenticated, remote attacker could cause a KDC
or kinit program to crash.

AFFECTED SOFTWARE
=================

[CVE-2009-0844 CVE-2009-0845]

* kadmind in MIT releases krb5-1.5 and later

* FTP daemon in MIT releases krb5-1.5 and later

* Third-party software using the GSS-API library from MIT krb5
  releases krb5-1.5 and later

* MIT releases prior to krb5-1.5 did not contain the vulnerable code.

[CVE-2009-0847]

* The kinit program and the KDC from MIT krb5 release krb5-1.6.3.
  Prior releases contained the vulnerable code, but the vulnerability
  was masked due to operations performed by other code.

FIXES
=====

* The upcoming krb5-1.7 and krb5-1.6.4 releases will contain fixes for
  these vulnerabilities.

* Apply the patch, available at

  http://web.mit.edu/kerberos/advisories/2009-001-patch.txt

  A PGP-signed patch is available at

  http://web.mit.edu/kerberos/advisories/2009-001-patch.txt.asc

REFERENCES
==========

This announcement is posted at:

  http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2009-001.txt

This announcement and related security advisories may be found on the
MIT Kerberos security advisory page at:

        http://web.mit.edu/kerberos/advisories/index.html

The main MIT Kerberos web page is at:

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

CVSSv2:

    http://www.first.org/cvss/cvss-guide.html
    http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2

CVE: CVE-2009-0844
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0844

CVE: CVE-2009-0845
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0845

CVE: CVE-2009-0847
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0847

CERT: VU#662091
http://www.kb.cert.org/vuls/id/662091

http://krbdev.mit.edu/rt/Ticket/Display.html?id=6402

ACKNOWLEDGMENTS
===============

CVE-2009-0844 was discovered by Product Security at Apple, Inc.  We
thank Apple and Sun for suggesting improvements to the patches.

CONTACT
=======

The MIT Kerberos Team security contact address is
<krbcore-security at mit.edu>.  When sending sensitive information,
please PGP-encrypt it using the following key:

pub   2048R/D9058C24 2009-01-26 [expires: 2010-02-01]
uid     MIT Kerberos Team Security Contact <krbcore-security at mit.edu>

DETAILS
=======

[CVE-2009-0844]

The get_input_token() function in the SPNEGO implementation can read
beyond the end of a network input buffer.  A length encoding that
decodes to a value exceeding the number of remaining bytes in the
input buffer will cause the function to copy memory past the end of
the input buffer.

[CVE-2009-0845]

CVSSv2 Vector: AV:N/AC:L/Au:N/C:N/I:N/A:C/E:POC/RL:OF/RC:C

CVSSv2 Base Score:      7.8

Access Vector:          Network
Access Complexity:      Low
Authentication:         None
Confidentiality Impact: None
Integrity Impact:       None
Availability Impact:    Complete

CVSSv2 Temporal Score:  6.1

Exploitability:         Proof-of-Concept
Remediation Level:      Official Fix
Report Confidence:      Confirmed

The spnego_gss_accept_sec_context() function in the GSS-API SPNEGO
implementation can dereference a null pointer under error conditions.
Cleanup code in this function can call the helper function
make_spnego_tokenTarg_msg() without first confirming that the value of
the "sc" variable is not null, thus causing a null pointer
dereference.

[CVE-2009-0847]

CVSSv2 Vector: AV:N/AC:L/Au:N/C:N/I:N/A:C/E:POC/RL:OF/RC:C

CVSSv2 Base Score:      7.8

Access Vector:          Network
Access Complexity:      Low
Authentication:         None
Confidentiality Impact: None
Integrity Impact:       None
Availability Impact:    Complete

CVSSv2 Temporal Score:  6.1

Exploitability:         Proof-of-Concept
Remediation Level:      Official Fix
Report Confidence:      Confirmed

The asn1buf_imbed() function incorrectly checks lengths by comparing
pointers after performing pointer arithmetic using an unchecked input
length.  In addition, the functions asn1buf_remove_charstring() and
asn1buf_remove_octetstring() rely on an invariant that is violated
when asn1buf_imbed() incorrectly validates lengths, performing pointer
arithmetic using the invalid length.  Consequently, malloc() receives
a very large number as its argument.  If the malloc() call somehow
succeeds, the copy from the input buffer is likely to cross unmapped
address space, causing a crash.

Prior to the implementation of PK-INIT, the vulnerability was masked
because no ASN.1 decoder used asn1buf_remove_charstring() or
asn1buf_remove_octetstring() immediately following the use of
asn1buf_imbed().  Protocol elements of PK-INIT require this sequence
of calls in the decoder, unmasking the latent vulnerability.

REVISION HISTORY
================

2009-04-07      original release

Copyright (C) 2009 Massachusetts Institute of Technology
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (SunOS)

iQCVAgUBSduVZabDgE/zdoE9AQI9OgP+OymYyzsFHkUcUWjEVtiFPxKCYh6uZvIj
foqgws9Kv4/TZ44SsJJLURCBgBthm/2coWwlaxaFdDgzXxH/KUW5J9UEBy/rraNx
tLh9CFcuP/uG12N9+Hp9BmlO8euu60cMKRlhAKUuOLTLj74RPMYIID6TE4VgE0g8
UKIvMyadl2I=
=OU63
-----END PGP SIGNATURE-----
_______________________________________________
kerberos-announce mailing list
kerberos-announce at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos-announce

From ghudson at MIT.EDU  Tue Apr  7 15:31:50 2009
From: ghudson at MIT.EDU (ghudson@MIT.EDU)
Date: Tue, 7 Apr 2009 15:31:50 -0400 (EDT)
Subject: Exception handling and resource cleanup
Message-ID: <200904071931.n37JVonv009163@outgoing.mit.edu>

We have at least five different patterns for handling exceptions in
Kerberos right now (example snippets at the end):

  1. goto cleanup
  2. if ladders (e.g. plugins/preauth/encrypted_challenge)
  3. Nested if statements (e.g. rule_an_to_ln)
  4. Free everything and return immediately (e.g. krb5_parse_name)
  5. CLEANUP_PUSH/CLEANUP_DONE (used exclusively in mk_safe and friends)

This is not the highest-priority issue facing us, but for the sake of
consistency in new code I would like to resolve:

* How much consistency do we want here, and
* Which style is best if we do want consistency
* Which styles should be ruled out if we don't want consistency

I'm talking specifically about medium-length or long functions here; I
don't think anyone wants to add boilerplate to short functions which
can't fail or can only fail in one place.

Personally, I would like to see consistency around (1) or consistency
around (2).  I can train myself to recognize either style, but
shifting between them is a bit jarring (sort of like shifting between
GNU-style and BSD-style code).  (3) has a certain LISP-like elegance,
but doesn't interact well with our 79-column limit and our long
function names.  (4) is responsible for a lot of memory leaks in our
current code base, duplicates a lot of code, and puts big blocks of
exception-handling code in the middle of the main logic.  I don't
think (5) should be seriously considered because it overuses the
preprocessor and requires the programmer to count the highest number
of resources which might need to be cleaned up.

As for (1) vs. (2): we currently use (1) a lot, but Sam has recently
added a bunch of code using (2) with his FAST work.  The main caveats
are that (1) provokes many people's visceral dislike of goto, and (2)
pushes the main logic of the function one indentation level to the
right (plus another level inside of loops, if the function has them).

Opinions appreciated.  Using a language with garbage collection and
exception handling is not on the table. :)

----------------
Example snippets
----------------

These are intentionally simplified; real-life functions will be a bit
more complicated due to either (a) loops, or (b) return-value
allocations which should be preserved on success but cleaned up on
failure.

1. goto cleanup

  retval = f(...);
  if (retval)
    goto cleanup;
  .
  .
  retval = f(...);
  if (retval)
    goto cleanup;
  .
  .
cleanup:
  free(stuff);
  return retval;

2. if ladders

  retval = f(...);
  if (retval == 0) {
    .
    .
    retval = f(...);
  }
  if (retval == 0) {
    .
    .
    retval = f(...);
  }
  free(stuff);
  return retval;

3. Nested if statements

  retval = f(...);
  if (retval == 0) {
    .
    .
    retval = f(...);
    if (retval == 0) {
      .
      .
    }
    .
    .
    free(stuff);
  }
  return retval;

4. Free everything and return immediately:

  retval = f(...);
  if (retval) {
    free(a);
    free(b);
    return retval;
  }
  .
  .
  retval = f(...);
  if (retval) {
    free(a);
    free(b);
    free(c);
    return retval;
  }
  .
  .
  return 0;

5. CLEANUP_PUSH/CLEANUP_DONE

  {
    CLEANUP_INIT(2); /* 2 is the largest number of cleanups possible */
    .
    .
    CLEANUP_PUSH(stuff, free);
    retval = f(...);
    if (retval) {
      CLEANUP_DONE();
      return retval;
    }
    CLEANUP_PUSH(otherstuff, krb5_free_stuff);
    .
    .
    if (retval) {
      CLEANUP_DONE();
      return retval;
    }
    CLEANUP_DONE();
    return 0;
  }

From hartmans at MIT.EDU  Tue Apr  7 16:15:56 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 07 Apr 2009 16:15:56 -0400
Subject: Exception handling and resource cleanup
In-Reply-To: <200904071931.n37JVonv009163@outgoing.mit.edu> (ghudson@mit.edu's
	message of "Tue\, 7 Apr 2009 15\:31\:50 -0400 \(EDT\)")
References: <200904071931.n37JVonv009163@outgoing.mit.edu>
Message-ID: <tslbpr8kyo3.fsf@mit.edu>

I chose style (2) for FAST because of strong recommendations for that
style from Alexis based on KFM and KLL/KIM.

Before I go into goto vs if-ladder I'd like to distinguish to sub-styles of goto:

goto-many-labels and goto-one-label.  Code like send_tgs.c uses
goto--many-labels.  The idea is that you goto some label based on what
resources need to be cleaned up.

In goto-one-label, such as do_as_req and do_tgs_req.c in the KDC,
there is one cleanup handler at the  bottom of the function.


I would like to recommend against goto-many-labels for the same
reasons that free everything and return is bad.  It doesn't suffer
from the code duplication, but it does make it easy to leak resources
or introduce other memory management errors.

Personally, I don't find the differences between goto-one-label and
iff-ladder all that significant.  I find if-ladder a bit easier to
deal with if the code doesn't have a lot of loops.  I think the
encrypted challenge plugin and most of fast.c are reasonably easy to
follow.  I also think the KFM code I've seen using this style is easy
to follow.

One advantage of if-ladder is that resource cleanup can sometimes be
much closer to resource allocation than with goto-one-label.

However I either don't know how to do if-ladder with loops or it
doesn't work well.  Take a look at prepare_as_error in do_as_req.c.  I
think that code would have been better using goto-one-label.

My personal preference is that we permit either goto-one-label or
if-ladder, although not both within the same function.  If people want
to standardize on one, that would be OK, although that would not be my
preference.

From raeburn at MIT.EDU  Tue Apr  7 20:43:52 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Tue, 7 Apr 2009 20:43:52 -0400
Subject: Exception handling and resource cleanup
In-Reply-To: <tslbpr8kyo3.fsf@mit.edu>
References: <200904071931.n37JVonv009163@outgoing.mit.edu>
	<tslbpr8kyo3.fsf@mit.edu>
Message-ID: <B879486B-BE23-48DA-97C8-B87E4449DB69@mit.edu>

On Apr 7, 2009, at 16:15, Sam Hartman wrote:
> However I either don't know how to do if-ladder with loops or it
> doesn't work well.  Take a look at prepare_as_error in do_as_req.c.  I
> think that code would have been better using goto-one-label.

The first thing I found looking for for loops in kim/lib/mac was that  
the loop condition checks for the error or other exit condition, in  
addition to whatever else.  So instead of "loop up to N times"/"break  
out on error", you write "loop until we get an error or have done it N  
times".  It seems like a logical extension to the "instead of writing  
goto/break, set and test this variable" approach.

If it can give real benefits over goto-one-label, great.  But I  
wouldn't want to use it just because it lets us avoid a certain four- 
letter keyword people have been taught to have a knee-jerk reaction  
to, and it doesn't magically make spaghetti logic impossible.  I  
haven't spent much time reading if-ladder code, and I'm sure it would  
get easier as I get used to it, so I don't want to say too much  
against it (or, what I do say should be weighed accordingly), but so  
far, I find "on error, go down to this cleanup label" easier to follow  
than "on error, skip over this block... skip over this block... skip  
over this block... skip over this block... okay, here's the cleanup  
code".  Multiple cleanup labels for a block, not so much, and I've  
been guilty of writing that way at times, but a single cleanup label  
doesn't seem unreasonable to me.

Ken

From hartmans at MIT.EDU  Wed Apr  8 03:33:03 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 08 Apr 2009 03:33:03 -0400
Subject: Exception handling and resource cleanup
In-Reply-To: <B879486B-BE23-48DA-97C8-B87E4449DB69@mit.edu> (Ken Raeburn's
	message of "Tue\, 7 Apr 2009 20\:43\:52 -0400")
References: <200904071931.n37JVonv009163@outgoing.mit.edu>
	<tslbpr8kyo3.fsf@mit.edu>
	<B879486B-BE23-48DA-97C8-B87E4449DB69@mit.edu>
Message-ID: <tslprfnk3bk.fsf@mit.edu>

I'm quite sure that I'm not in favor of if-ladder because of dislike of goto.

It seemed a bit easierr to write for code without many loops than goto
cleanup, and given a day or so, seemed equally easy to read.  I do not
yet have enough familiarity to explain why I thought it was easier to
write in some cases.

--Sam

From johngjesse at hotmail.com  Wed Apr  8 09:38:33 2009
From: johngjesse at hotmail.com (kaffekamelen)
Date: Wed, 8 Apr 2009 06:38:33 -0700 (PDT)
Subject: Do I need keytab for Authentication?
Message-ID: <22950643.post@talk.nabble.com>


Hi all,

I have some problems by getting through to LDAP using jaas/kerberos/GSSAPI.
Kerberos login is successful, but when I try to create an InitialDirContext,
an "AuthenticationNotSupportedException: GSSAPI" is thrown. Funny thing is
that it only occurs when running a websphere+Microsoft AD setup (with ibm's
Krb5LoginModule) - when I use jboss with sun's Krb5LoginModule everything
works!

So, there must be an issue regarding the difference in setup. Do any of you
know about known IBM problems in supporting kerberos and GSSAPI?

I am aware that ibm's Krb5LoginModule may be more restrictive than sun's. If
so, my implementation may be insufficient. Actually, I am running without
keytab file, and I'm wondering if that's a problem.

My implementation consist of a single java ear file deployed on websphere
app server:

1. The only Websphere configuration is that I have added a "MyLoginModule"
entry to wsjaas.properties (MyLoginModule entry points out
com.ibm.security.auth.module.Krb5LoginModule). Don't really know why it
should be wsjaas.properties - I don't have any webservice involved... Is
there a point here?
2. My application accepts username and password i a user dialog.
3. My application sets System properties:
java.security.krb5.conf=<myInstDir>/admin/var/jaas/krb5.conf and
java.security.auth.login.config=<myInstDir>/admin/var/jaas/step-jaas.conf
4. My application creates a LoginContext 8new LoginContext("MyLoginModule",
MyCallbackhandler) - The CallbackHandler provides username and password to
the LoginModule on request. This is why I don't think I need a keytab file
copied to the websphere server...
5. Start a thread using Subject.doAs(loginContext.getSubject(),
myWorkerThread)
6. The worker thread sets environment
LDAP_INITIAL_CONTEXT_FACTORY=com.sun.jndi.ldap.LdapCtxFactory,
LDAP_SERVER_URL=ldap://my.ldap.host:389, AUTH_MECHANISMS=GSSAPI.
7. The worker thread creates new InitialDirContext(env) - and this is where
the "AuthenticationNotSupportedException: GSSAPI" is thrown.

Again - there is no AuthenticationNotSupportedException when using
jboss+sun's Krb5LoginModule, so it seems that I CAN do without a keytab
file. Anyway, the problem here is that websphere is my main target
appserver!!

I hope some of you can give me some advice, because I'm totally stuck in
this case.
-- 
View this message in context: http://www.nabble.com/Do-I-need-keytab-for-Authentication--tp22950643p22950643.html
Sent from the Kerberos - Dev mailing list archive at Nabble.com.


From steve at terapak.com  Wed Apr  8 17:27:53 2009
From: steve at terapak.com (steve@terapak.com)
Date: Wed, 8 Apr 2009 14:27:53 -0700 (PDT)
Subject: cross realm authentication problem
Message-ID: <1239226073.54653366@192.168.1.202>


Ok I am having a problem getting a service ticket from a different realm than my principal use is on.

 

Here is my setup:

 

Using KDC on AD for both realms.  Each domain has a short-cut trust between each other.  Let's call them X & Y.

 

When I get service ticket for the same realm it works fine:  [mailto:service/host at X] service/host at X.

 

For cross realms I am seeing strange behavior at network level.

 

User from realm X asks for service ticket from realm Y:  [mailto:service/host at Y] service/host at Y.

 

First I get back the cross realm TGT as in [mailto:tgt/Y at X] tgt/Y at X.  Everything I have seen this is correct behavior.

 

When I see the TGS-REQ with that TGT I get the following error:

 

KRB5 KRB Error: KDC_ERR_WRONG_REALM

 

There is very little information related to this error but what I did find tells me that is will occur when the TGT is for the wrong realm that you are asking for a ticket from.

 

One thing I thought might wrong is that the TGT is from the X realm but it is for the Y realm but all conversations said this is correct behavior and that I should be able to use that krbtgt to get services from realm Y.

 

I have tried kfw versions 3.2.2 and version 2.6.5 and the behavior is the same.

 

I am quite confused.

 

Steve

From steve at terapak.com  Wed Apr  8 20:46:48 2009
From: steve at terapak.com (steve@terapak.com)
Date: Wed, 8 Apr 2009 17:46:48 -0700 (PDT)
Subject: cross realm authentication problem
In-Reply-To: <03CAA2C09532074C985C6D8D9EBAC89C15702E3C@lwlexch02.olympus.f5net.com>
References: <03CAA2C09532074C985C6D8D9EBAC89C15702E3C@lwlexch02.olympus.f5net.com>
Message-ID: <1239238008.134230335@192.168.1.202>


I just figured it out -- Thanks for the response.

 

I did not setup the realms correctly.  I did not specify a KDC for the REALM.

 

Steve

-----Original Message-----
From: "JC Ferguson" <jc at F5.com>
Sent: Wednesday, April 8, 2009 5:17pm
To: "'steve at terapak.com'" <steve at terapak.com>, "'krbdev at mit.edu'" <krbdev at mit.edu>
Subject: RE: cross realm authentication problem

Couple things:

- do you have a network trace from your client showing this flow you can share?

- does the event log on Windows tell you anything?

- is the shortcut trust bi-directional?



> -----Original Message-----
> From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf
> Of steve at terapak.com
> Sent: Wednesday, April 08, 2009 17:28
> To: krbdev at mit.edu
> Subject: cross realm authentication problem
>
>
> Ok I am having a problem getting a service ticket from a different
> realm than my principal use is on.
>
>
>
> Here is my setup:
>
>
>
> Using KDC on AD for both realms. Each domain has a short-cut trust
> between each other. Let's call them X & Y.
>
>
>
> When I get service ticket for the same realm it works fine:
> [mailto:service/host at X] service/host at X.
>
>
>
> For cross realms I am seeing strange behavior at network level.
>
>
>
> User from realm X asks for service ticket from realm Y:
> [mailto:service/host at Y] service/host at Y.
>
>
>
> First I get back the cross realm TGT as in [mailto:tgt/Y at X] tgt/Y at X.
> Everything I have seen this is correct behavior.
>
>
>
> When I see the TGS-REQ with that TGT I get the following error:
>
>
>
> KRB5 KRB Error: KDC_ERR_WRONG_REALM
>
>
>
> There is very little information related to this error but what I did
> find tells me that is will occur when the TGT is for the wrong realm
> that you are asking for a ticket from.
>
>
>
> One thing I thought might wrong is that the TGT is from the X realm but
> it is for the Y realm but all conversations said this is correct
> behavior and that I should be able to use that krbtgt to get services
> from realm Y.
>
>
>
> I have tried kfw versions 3.2.2 and version 2.6.5 and the behavior is
> the same.
>
>
>
> I am quite confused.
>
>
>
> Steve
> _______________________________________________
> krbdev mailing list krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

From ghudson at MIT.EDU  Thu Apr  9 00:50:55 2009
From: ghudson at MIT.EDU (ghudson@MIT.EDU)
Date: Thu, 9 Apr 2009 00:50:55 -0400 (EDT)
Subject: Glossary wiki page
Message-ID: <200904090450.n394ottb016201@outgoing.mit.edu>

We have sort of a bad habit of not defining acronyms and other terms
anywhere in the Kerberos code base--recent examples include FAST and
PAC.  It's not so bad if you're familiar with RFC 4210 and are
following the IETF krb-wg work, but it can be a bit mystifying
otherwise.  To help address this problem, I've created a glossary page
on k5wiki; it's at:

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

and it's linked from the "learn more about the code" page.  I've
seeded it with all of the acronyms I could think of off the top of my
head.  Please feel free to add others.

From jc at F5.com  Wed Apr  8 20:17:34 2009
From: jc at F5.com (JC Ferguson)
Date: Wed, 8 Apr 2009 20:17:34 -0400
Subject: cross realm authentication problem
In-Reply-To: <1239226073.54653366@192.168.1.202>
References: <1239226073.54653366@192.168.1.202>
Message-ID: <03CAA2C09532074C985C6D8D9EBAC89C15702E3C@lwlexch02.olympus.f5net.com>

Couple things:

- do you have a network trace from your client showing this flow you can share?

- does the event log on Windows tell you anything?

- is the shortcut trust bi-directional?



> -----Original Message-----
> From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf
> Of steve at terapak.com
> Sent: Wednesday, April 08, 2009 17:28
> To: krbdev at mit.edu
> Subject: cross realm authentication problem
>
>
> Ok I am having a problem getting a service ticket from a different
> realm than my principal use is on.
>
>
>
> Here is my setup:
>
>
>
> Using KDC on AD for both realms.  Each domain has a short-cut trust
> between each other.  Let's call them X & Y.
>
>
>
> When I get service ticket for the same realm it works fine:
> [mailto:service/host at X] service/host at X.
>
>
>
> For cross realms I am seeing strange behavior at network level.
>
>
>
> User from realm X asks for service ticket from realm Y:
> [mailto:service/host at Y] service/host at Y.
>
>
>
> First I get back the cross realm TGT as in [mailto:tgt/Y at X] tgt/Y at X.
> Everything I have seen this is correct behavior.
>
>
>
> When I see the TGS-REQ with that TGT I get the following error:
>
>
>
> KRB5 KRB Error: KDC_ERR_WRONG_REALM
>
>
>
> There is very little information related to this error but what I did
> find tells me that is will occur when the TGT is for the wrong realm
> that you are asking for a ticket from.
>
>
>
> One thing I thought might wrong is that the TGT is from the X realm but
> it is for the Y realm but all conversations said this is correct
> behavior and that I should be able to use that krbtgt to get services
> from realm Y.
>
>
>
> I have tried kfw versions 3.2.2 and version 2.6.5 and the behavior is
> the same.
>
>
>
> I am quite confused.
>
>
>
> Steve
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev


From ghudson at MIT.EDU  Thu Apr  9 14:44:27 2009
From: ghudson at MIT.EDU (ghudson@MIT.EDU)
Date: Thu, 9 Apr 2009 14:44:27 -0400 (EDT)
Subject: Revisiting weak enctypes off by default
In-Reply-To: <tslmyatpg6u.fsf@mit.edu>
References: <tslmyatpg6u.fsf@mit.edu>
Message-ID: <200904091844.n39IiR7E004303@outgoing.mit.edu>

I've been asked to take responsibility for this issue.

Sam wrote:
> It's my recollection that we were going to revisit the question of
> whether to turn weak enctypes off by default for the beta.  Tom
> expressed a desire to do so, I expressed support if the appropriate
> documentation happened, and I'm not sure what other opinions were
> expressed.

There were a bunch of other opinions expressed, including concerns
that sites using AFS or old Java applications might have difficulty
with such a default.

After reviewing the situation, I am not sure that changing the
allow_weak_crypto default has a lot of value.  Three reasonably modern
versions of Kerberos (client, server, and KDC) will not use DES with
the current defaults unless the client or server principal only
contains DES keys.  A 1.7 kadmind will not generate DES keys for a new
principal by default (as of r21851).  The risks we might want to
mitigate are:

1. Historical DB entries containing DES keys are subject to
   brute-force attack as long as the KDC will issue tickets for those
   keys.  Turning off allow_weak_crypto on the KDC eliminates that
   risk, but I am not sure that most KDC operators would be happy with
   us unnecessarily surprising them with such a default (since it
   would break any legacy clients or applications which can only use
   DES).

2. Appeasing concerns that a client, server, or KDC might be
   manipulated into using DES via some kind of man-in-the-middle
   attack or bug.  (Even if there is no specific attack or bug which
   would do this, the simple fact that the code exists and is
   available for use is a legitimate concern.)  Turning off
   allow_weak_crypto eliminates most of that risk, but again, I am not
   sure that the use case justifies the default given the possibility
   of breaking legacy applications.

Independent of the 1.7 timeframe, several people in the January
conversation asked for a more granular approach to phasing out DES.  I
think if you want a more granular approach, you can get that by
removing single DES keys from user or service principals as desired.
Unfortunately, I don't see a current kadmin interface for removing
keys without a password or key change, but it would probably be easier
to write code to do that than it would be to add a new set of
profile options.

I did notice that our documentation had out-of-date lists of supported
enctypes (both for protocol communication and for kadmind), which I
have fixed and marked for 1.7 pullup.  I also noticed that
allow_weak_crypto isn't documented, which I will try to fix and mark
for pullup before the end of the week.

From hartmans at MIT.EDU  Thu Apr  9 16:25:24 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Thu, 09 Apr 2009 16:25:24 -0400
Subject: Revisiting weak enctypes off by default
In-Reply-To: <200904091844.n39IiR7E004303@outgoing.mit.edu> (ghudson@mit.edu's
	message of "Thu\, 9 Apr 2009 14\:44\:27 -0400 \(EDT\)")
References: <tslmyatpg6u.fsf@mit.edu>
	<200904091844.n39IiR7E004303@outgoing.mit.edu>
Message-ID: <tslk55tingr.fsf@mit.edu>

>>>>> "ghudson" == ghudson  <ghudson at MIT.EDU> writes:

    ghudson> 2. Appeasing concerns that a client, server, or KDC might
    ghudson> be manipulated into using DES via some kind of
    ghudson> man-in-the-middle attack or bug.  (Even if there is no
    ghudson> specific attack or bug which would do this, the simple
    ghudson> fact that the code exists and is available for use is a
    ghudson> legitimate concern.)  Turning off allow_weak_crypto
    ghudson> eliminates most of that risk, but again, I am not sure
    ghudson> that the use case justifies the default given the
    ghudson> possibility of breaking legacy applications.


I have no problem at all with your conclusions.

For completeness, I'll point out that absent FAST, nothing protectes
the list of enctypes the client sends in the as-req.  So, a
man-in-the-middle can change this list or change the etype-info2
packet in the preauth_required error.  That is sufficient to convince
a client or KDC with DES enabled to use it.

FAST defends against this attack.  While it is definitely not in the
1.7 time frame, Larry does have a proposal for protecting the
negotiation to FAST.

From hotz at jpl.nasa.gov  Thu Apr  9 18:28:16 2009
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Thu, 9 Apr 2009 15:28:16 -0700
Subject: Pre-Auth Plugins in 1.6.2?
Message-ID: <7B439787-485F-41DF-B7F4-3AA0FECB0B1F@jpl.nasa.gov>

Specifically the version in MacOS 10.5.6.

The (client-side) plugins seem to get loaded, but there is e.g. no -X  
option for kinit.  Haven't verified if the pre-auth plugin is actually  
called after it's loaded (but no longer so sure it must be).
------------------------------------------------------
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 steve at terapak.com  Fri Apr 10 11:47:55 2009
From: steve at terapak.com (steve@terapak.com)
Date: Fri, 10 Apr 2009 08:47:55 -0700 (PDT)
Subject: two more questions
Message-ID: <1239378475.333713424@192.168.1.202>


1)  GSSAPI logging.

 

I have built a library using the windows lib included in kfw 3.2.2 using Visual Studio 2005.  I am encountering problems which I would like more detailed information on besides the major and minor error codes.  I am trying to output the logging using the following lines in my krb5.ini.  I know I am using the correct krb5.ini because I am specifying the default keytab file which it is using.  Here is the krb5.ini:

 

[libdefaults]
 dns_lookup_realm = true
  default_keytab_name = krb5.keytab
[logging]
 default = FILE:krb5.log  <-- from everything I have seen all you have to do is include this line but not krb5.log is being produced.
[realms]
 DOMAIN1 = {
  kdc = kdc1
  kdc = kc2
  admin_server = kdc1
 }
 DOMAIN2 = {
  kdc = kdc1
  kdc = kdc2
 }

 

Can you point out any extra steps that are required or direct me to some documentation.  I have really dug through the internet and all the documentation included with the kfw releases.

 

2)  I am receiving an error on gss_init_context on the second call after receiving the context from the server:  KRB5 error code 69.  I was hoping I could get more info on what this means.  I am completely sure that the server side component is working correctly because i have completed a kerberos authentication with it using a Microsoft SSPI client.  This definitely could be a bug in my code and I can post the code on request.

 

Thanks again for the help.

 

Steve

From Shawn.Emery at Sun.COM  Sat Apr 11 02:17:37 2009
From: Shawn.Emery at Sun.COM (Shawn M Emery)
Date: Sat, 11 Apr 2009 00:17:37 -0600
Subject: Principal naming
Message-ID: <49E03601.7090300@sun.com>


Recently there has been some ambiguity on how to handle case sensitivity 
for principal names.  Various principal name components are used either 
in upper or lower case.  For example the following principal names are 
considered valid:

HTTP/host1.example.com at EXAMPLE.COM
HOST/host1.example.com at EXAMPLE.COM
host/host1.example.com at EXAMPLE.COM
host/HOST1.EXAMPLE.COM at EXAMPLE.COM

In order to prevent issues with interoperability, I believe that it 
should be made clear what we can inference from a principal name and 
that the various implementations reflect this.

The other question/issue is that there is no formal syntax to represent 
valid principal names.  Currently there are a number of questionable 
principal names that can added to the database.  For example:

host/@EXAMPLE.COM
host/@
/@
//@
user@

Some principal names can not be used with Kerberos utilities, others may 
be able to by accident.  My opinion is that a formal syntax for 
principals names should exist, but should also allow for future 
extensions.  The syntax can be used to enforce which principal names are 
allowed to be populated in the database and therefore supported by the 
various utilities.

Shawn.
--

From ghudson at MIT.EDU  Sat Apr 11 13:49:19 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Sat, 11 Apr 2009 13:49:19 -0400
Subject: Principal naming
In-Reply-To: <49E03601.7090300@sun.com>
References: <49E03601.7090300@sun.com>
Message-ID: <1239472159.22340.12.camel@ray>

Can you be more specific about what real interoperability problems are
cropping up from either principal case sensitivity or from "degenerate"
principals like /@, and how you would like those problems to be
resolved?

krb5 1.7 adds some support for protocol features which would allow a KDC
to treat principals as partially or completely case-insensitive.
Clients and servers are not expected to know the KDC's case-handling
policy; this is achieved by allowing clients to request canonicalization
of client principal names when obtaining initial tickets, and by
allowing servers to match server principals in keytabs by key rather
than by name.  There is no back-end support for case-folding in the
shipped DB2 and LDAP back ends, so that piece remains "a simple matter
of programming" for the moment.



From Shawn.Emery at Sun.COM  Sun Apr 12 02:20:25 2009
From: Shawn.Emery at Sun.COM (Shawn M Emery)
Date: Sun, 12 Apr 2009 00:20:25 -0600
Subject: Principal naming
In-Reply-To: <1239472159.22340.12.camel@ray>
References: <49E03601.7090300@sun.com> <1239472159.22340.12.camel@ray>
Message-ID: <49E18829.7040900@sun.com>

Greg Hudson wrote:
> Can you be more specific about what real interoperability problems are
> cropping up from either principal case sensitivity or from "degenerate"
> principals like /@, and how you would like those problems to be
> resolved?
>   

Sorry for not being clear, some implementations can have permutations of 
various principal components in upper or lower case.  During context 
acceptance servers can fail if they can not find key entries in the 
local keytab file unless all permutations of possible service principal 
names are populated in the keytab file.

> krb5 1.7 adds some support for protocol features which would allow a KDC
> to treat principals as partially or completely case-insensitive.
> Clients and servers are not expected to know the KDC's case-handling
> policy; this is achieved by allowing clients to request canonicalization
> of client principal names when obtaining initial tickets, and by
> allowing servers to match server principals in keytabs by key rather
> than by name.  There is no back-end support for case-folding in the
> shipped DB2 and LDAP back ends, so that piece remains "a simple matter
> of programming" for the moment.
>   

Good to know that this is already being looked and can potentially 
thwart some of these issues, as in the past, various utilities have 
skirted around this issue by populating principal names with all 
possible permutation.  I was also trying to find out if there is 
consensus with the various implementors on how case sensitivity and 
principal name syntax is handled, which looks like there is none.

Shawn.
--

From lukeh at padl.com  Sun Apr 12 02:34:11 2009
From: lukeh at padl.com (Luke Howard)
Date: Sun, 12 Apr 2009 16:34:11 +1000
Subject: Principal naming
In-Reply-To: <49E18829.7040900@sun.com>
References: <49E03601.7090300@sun.com> <1239472159.22340.12.camel@ray>
	<49E18829.7040900@sun.com>
Message-ID: <C385F846-FD61-4076-8053-E496FAB426E9@padl.com>

Shawm,

This might be useful:

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

-- Luke

From ghudson at MIT.EDU  Sun Apr 12 12:19:30 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Sun, 12 Apr 2009 12:19:30 -0400
Subject: Principal naming
In-Reply-To: <49E18829.7040900@sun.com>
References: <49E03601.7090300@sun.com> <1239472159.22340.12.camel@ray>
	<49E18829.7040900@sun.com>
Message-ID: <1239553170.22340.22.camel@ray>

On Sun, 2009-04-12 at 00:20 -0600, Shawn M Emery wrote:
> Sorry for not being clear, some implementations can have permutations of 
> various principal components in upper or lower case.
[...]
> I was also trying to find out if there is 
> consensus with the various implementors on how case sensitivity and 
> principal name syntax is handled, which looks like there is none.

MIT krb5's gss_import_name and krb5_sname_to_principal will always use
the lowercase form of a hostname in the second component.

As for the first component, if an application is using the wrong case of
the name it's a bug.  The appropriate name for the host service is
"host", and I believe the appropriate name for the HTTP service is
"HTTP" (looking at
http://meta.cesnet.cz/cms/opencms/en/docs/software/devel/draft-brezak-spnego-http-04.txt) so any other cases of those names are incorrect.



From jhutz at cmu.edu  Sat Apr 11 19:19:39 2009
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Sat, 11 Apr 2009 19:19:39 -0400
Subject: Principal naming
In-Reply-To: <200904110619.n3B6JKfZ025550@mx03.srv.cs.cmu.edu>
References: <200904110619.n3B6JKfZ025550@mx03.srv.cs.cmu.edu>
Message-ID: <C74E9EBED5135161F90F297C@atlantis.pc.cs.cmu.edu>

--On Saturday, April 11, 2009 12:17:37 AM -0600 Shawn M Emery 
<Shawn.Emery at Sun.COM> wrote:

>
> Recently there has been some ambiguity on how to handle case sensitivity
> for principal names.  Various principal name components are used either
> in upper or lower case.  For example the following principal names are
> considered valid:
>
> HTTP/host1.example.com at EXAMPLE.COM
> HOST/host1.example.com at EXAMPLE.COM
> host/host1.example.com at EXAMPLE.COM
> host/HOST1.EXAMPLE.COM at EXAMPLE.COM
>
> In order to prevent issues with interoperability, I believe that it
> should be made clear what we can inference from a principal name and
> that the various implementations reflect this.

You can infer nothing from a principal name.  There are a number of common 
conventions for _constructing_ principal names, some of which are 
documented and/or standardized, but I know of no defined rules for 
_deconstructing_ principal names; a name is just a name.



> The other question/issue is that there is no formal syntax to represent
> valid principal names.  Currently there are a number of questionable
> principal names that can added to the database.  For example:
>
> host/@EXAMPLE.COM
> host/@
> /@
> //@
> user@

Are those principals with empty components, or principals with single 
components containing the characters '/' and/or '@' ?  I suspect you mean 
the former.

Empty realm names do not match any of the syntaxes described in RFC4120, 
and so are forbidden.  IMHO it would be fine for software to reject such 
invalid realm names, though I'm not sure there's any particular reason to 
do so (though there might be in the particular case of an empty realm).

Principal names with empty components _are_ valid, though I think we looked 
into this before when working on draft-ietf-krb-wg-naming; you might want 
to take a look in that document and/or in the krb-wg traffic that led to it.

> Some principal names can not be used with Kerberos utilities, others may
> be able to by accident.  My opinion is that a formal syntax for
> principals names should exist, but should also allow for future
> extensions.  The syntax can be used to enforce which principal names are
> allowed to be populated in the database and therefore supported by the
> various utilities.

The question of what are and are not valid Kerberos principal names is, 
IMHO, a protocol matter.  Please feel free to bring it up on the krb-wg 
mailing list, but you may wish to first examine the -naming document, which 
speaks to some (but not all) of these issues.

-- Jeff

From Shawn.Emery at Sun.COM  Mon Apr 13 01:38:45 2009
From: Shawn.Emery at Sun.COM (Shawn M Emery)
Date: Sun, 12 Apr 2009 23:38:45 -0600
Subject: Principal naming
In-Reply-To: <C74E9EBED5135161F90F297C@atlantis.pc.cs.cmu.edu>
References: <200904110619.n3B6JKfZ025550@mx03.srv.cs.cmu.edu>
	<C74E9EBED5135161F90F297C@atlantis.pc.cs.cmu.edu>
Message-ID: <49E2CFE5.3040806@sun.com>


Thanks to all for the replies.  Comments in-line...

Jeffrey Hutzelman wrote:
> --On Saturday, April 11, 2009 12:17:37 AM -0600 Shawn M Emery 
> <Shawn.Emery at Sun.COM> wrote:
>
>> Recently there has been some ambiguity on how to handle case sensitivity
>> for principal names.  Various principal name components are used either
>> in upper or lower case.  For example the following principal names are
>> considered valid:
>>
>> HTTP/host1.example.com at EXAMPLE.COM
>> HOST/host1.example.com at EXAMPLE.COM
>> host/host1.example.com at EXAMPLE.COM
>> host/HOST1.EXAMPLE.COM at EXAMPLE.COM
>>
>> In order to prevent issues with interoperability, I believe that it
>> should be made clear what we can inference from a principal name and
>> that the various implementations reflect this.
>
> You can infer nothing from a principal name.  There are a number of 
> common conventions for _constructing_ principal names, some of which 
> are documented and/or standardized, but I know of no defined rules for 
> _deconstructing_ principal names; a name is just a name.

Ok, I will check with at least one known implementor that uses upper and 
lower case for service and host components to see if they are actually 
semantically different.  Greg mentioned that the spnego-auth draft 
defines the service component in upper case, but not in lower case.

>> The other question/issue is that there is no formal syntax to represent
>> valid principal names.  Currently there are a number of questionable
>> principal names that can added to the database.  For example:
>>
>> host/@EXAMPLE.COM
>> host/@
>> /@
>> //@
>> user@
>
> Are those principals with empty components, or principals with single 
> components containing the characters '/' and/or '@' ?  I suspect you 
> mean the former.

Yes, the former.

> Empty realm names do not match any of the syntaxes described in 
> RFC4120, and so are forbidden.  IMHO it would be fine for software to 
> reject such invalid realm names, though I'm not sure there's any 
> particular reason to do so (though there might be in the particular 
> case of an empty realm).

Yes, a mechanism could interpret an empty realm (non transitive) with an 
unknown outcome, ergo I believe that there should be some sanity 
checking during creation.

> Principal names with empty components _are_ valid, though I think we 
> looked into this before when working on draft-ietf-krb-wg-naming; you 
> might want to take a look in that document and/or in the krb-wg 
> traffic that led to it.

Thanks for the reminder, I will take a look.  Yes, I wasn't against this 
particular element, as I could see that empty components could be useful 
in wild carding in authorization based on services, host names, domain 
names, etc.

>> Some principal names can not be used with Kerberos utilities, others may
>> be able to by accident.  My opinion is that a formal syntax for
>> principals names should exist, but should also allow for future
>> extensions.  The syntax can be used to enforce which principal names are
>> allowed to be populated in the database and therefore supported by the
>> various utilities.
>
> The question of what are and are not valid Kerberos principal names 
> is, IMHO, a protocol matter.  Please feel free to bring it up on the 
> krb-wg mailing list, but you may wish to first examine the -naming 
> document, which speaks to some (but not all) of these issues.

Ok, thanks.  I will read this and come back with anything that still may 
not be clear.

Shawn.
--

From hartmans at MIT.EDU  Mon Apr 13 05:59:36 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Mon, 13 Apr 2009 05:59:36 -0400
Subject: Principal naming
In-Reply-To: <1239553170.22340.22.camel@ray> (Greg Hudson's message of "Sun\,
	12 Apr 2009 12\:19\:30 -0400")
References: <49E03601.7090300@sun.com> <1239472159.22340.12.camel@ray>
	<49E18829.7040900@sun.com> <1239553170.22340.22.camel@ray>
Message-ID: <tslr5zweuwn.fsf@mit.edu>

>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:

    Greg> On Sun, 2009-04-12 at 00:20 -0600, Shawn M Emery wrote:
    >> Sorry for not being clear, some implementations can have
    >> permutations of various principal components in upper or lower
    >> case.
    Greg> [...]
    >> I was also trying to find out if there is consensus with the
    >> various implementors on how case sensitivity and principal name
    >> syntax is handled, which looks like there is none.

    Greg> MIT krb5's gss_import_name and krb5_sname_to_principal will
    Greg> always use the lowercase form of a hostname in the second
    Greg> component.


Java not so much.

From hartmans at MIT.EDU  Mon Apr 13 10:48:27 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Mon, 13 Apr 2009 10:48:27 -0400 (EDT)
Subject: option letter for kinit fast
Message-ID: <20090413144827.96A68414D@carter-zimmerman.suchdamage.org>



I'd like to add an option to kinit to set the name of the FAST ccache.
If set, the library will look for an armor ticket to use in that cache
and turn on fast.

What option letter should I use?

--Sam

From tsitkova at MIT.EDU  Mon Apr 13 11:08:49 2009
From: tsitkova at MIT.EDU (Zhanna Tsitkova)
Date: Mon, 13 Apr 2009 11:08:49 -0400
Subject: option letter for kinit fast
In-Reply-To: <20090413144827.96A68414D@carter-zimmerman.suchdamage.org>
References: <20090413144827.96A68414D@carter-zimmerman.suchdamage.org>
Message-ID: <CA05440C-C4D5-40FC-889D-B4D49B3484C7@mit.edu>

-A for armor ticket?

On Apr 13, 2009, at 10:48 AM, Sam Hartman wrote:

>
>
> I'd like to add an option to kinit to set the name of the FAST ccache.
> If set, the library will look for an armor ticket to use in that cache
> and turn on fast.
>
> What option letter should I use?
>
> --Sam
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev


From tsitkova at MIT.EDU  Mon Apr 13 11:27:47 2009
From: tsitkova at MIT.EDU (Zhanna Tsitkova)
Date: Mon, 13 Apr 2009 11:27:47 -0400
Subject: option letter for kinit fast
In-Reply-To: <CA05440C-C4D5-40FC-889D-B4D49B3484C7@mit.edu>
References: <20090413144827.96A68414D@carter-zimmerman.suchdamage.org>
	<CA05440C-C4D5-40FC-889D-B4D49B3484C7@mit.edu>
Message-ID: <7AB4A05D-8D05-4D40-8073-D8DFB1FC6C2D@mit.edu>

...except -A  is taken in kinit (was looking @ kvno...). -M?
On Apr 13, 2009, at 11:08 AM, Zhanna Tsitkova wrote:

> -A for armor ticket?
>
> On Apr 13, 2009, at 10:48 AM, Sam Hartman wrote:
>
>>
>>
>> I'd like to add an option to kinit to set the name of the FAST  
>> ccache.
>> If set, the library will look for an armor ticket to use in that  
>> cache
>> and turn on fast.
>>
>> What option letter should I use?
>>
>> --Sam
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev


From ghudson at MIT.EDU  Mon Apr 13 11:30:42 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Mon, 13 Apr 2009 11:30:42 -0400
Subject: option letter for kinit fast
In-Reply-To: <20090413144827.96A68414D@carter-zimmerman.suchdamage.org>
References: <20090413144827.96A68414D@carter-zimmerman.suchdamage.org>
Message-ID: <1239636642.22340.38.camel@ray>

On Mon, 2009-04-13 at 10:48 -0400, Sam Hartman wrote:
> I'd like to add an option to kinit to set the name of the FAST ccache.

This option is specifically for using a pre-existing ccache as a ticket
armor, right?  If, in the future, we are doing anonymous pkinit to
derive the armor ticket, then kinit will presumably create its own
credentials to use for that; if we are doing some future EKE-like armor,
then we won't use a separate credentials cache at all.

Here's the current getopt string in MIT krb5's kinit:

  "r:fpFP54aAVl:s:c:kt:RS:vX:CE"

Zhana's suggestion of 'A' is taken for no-addresses.  'f' and 'F' are
also taken.  It looks like 'T' is available (for "ticket-based armor").



From jhutz at cmu.edu  Mon Apr 13 15:48:40 2009
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Mon, 13 Apr 2009 15:48:40 -0400
Subject: option letter for kinit fast
In-Reply-To: <200904131531.n3DFV5L3018514@mx03.srv.cs.cmu.edu>
References: <20090413144827.96A68414D@carter-zimmerman.suchdamage.org>
	<200904131531.n3DFV5L3018514@mx03.srv.cs.cmu.edu>
Message-ID: <D3D8A71ABD01DB81F2C91BC9@minbar.fac.cs.cmu.edu>

--On Monday, April 13, 2009 11:30:42 AM -0400 Greg Hudson <ghudson at MIT.EDU> 
wrote:

> On Mon, 2009-04-13 at 10:48 -0400, Sam Hartman wrote:
>> I'd like to add an option to kinit to set the name of the FAST ccache.
>
> This option is specifically for using a pre-existing ccache as a ticket
> armor, right?  If, in the future, we are doing anonymous pkinit to
> derive the armor ticket, then kinit will presumably create its own
> credentials to use for that; if we are doing some future EKE-like armor,
> then we won't use a separate credentials cache at all.
>
> Here's the current getopt string in MIT krb5's kinit:
>
>   "r:fpFP54aAVl:s:c:kt:RS:vX:CE"

This is why I like keeping my getopt strings sorted:

45ACEFPRS:VX:ac:fkl:pr:s:t:v

Heimdal also uses at least -9 (--524convert) and -e (--enctypes).
Newer versions may also use others; the one I looked at was pretty old.

-- Jeff

From tlyu at MIT.EDU  Tue Apr 14 00:34:53 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Tue, 14 Apr 2009 00:34:53 -0400
Subject: svn rev #22197: trunk/src/lib/krb5/os/
In-Reply-To: <200904131716.n3DHGZVE018580@drugstore.mit.edu>
	(ghudson@MIT.EDU's message of "Mon, 13 Apr 2009 13:16:35 -0400")
References: <200904131716.n3DHGZVE018580@drugstore.mit.edu>
Message-ID: <ldv63h7am4y.fsf@cathode-dark-space.mit.edu>

ghudson at MIT.EDU writes:

> http://src.mit.edu/fisheye/changelog/krb5/?cs=22197
> Commit By: ghudson
> Log Message:
> In krb5int_dns_init, fix a malloc-returning-null check which could let
> a null result slip past.
>

Can we make things even simpler if we assume realloc(NULL, len) is
always equivalent to malloc(len)?  How safe an assumption is that
these days?

>
>
> Changed Files:
> U   trunk/src/lib/krb5/os/dnsglue.c
> Modified: trunk/src/lib/krb5/os/dnsglue.c
> ===================================================================
> --- trunk/src/lib/krb5/os/dnsglue.c	2009-04-12 15:40:41 UTC (rev 22196)
> +++ trunk/src/lib/krb5/os/dnsglue.c	2009-04-13 17:16:35 UTC (rev 22197)
> @@ -112,7 +112,7 @@
>  	p = (ds->ansp == NULL)
>  	    ? malloc(nextincr) : realloc(ds->ansp, nextincr);
>  
> -	if (p == NULL && ds->ansp != NULL) {
> +	if (p == NULL) {
>  	    ret = -1;
>  	    goto errout;
>  	}
>
> _______________________________________________
> cvs-krb5 mailing list
> cvs-krb5 at mit.edu
> https://mailman.mit.edu/mailman/listinfo/cvs-krb5

From raeburn at MIT.EDU  Tue Apr 14 01:21:50 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Tue, 14 Apr 2009 01:21:50 -0400
Subject: svn rev #22197: trunk/src/lib/krb5/os/
In-Reply-To: <ldv63h7am4y.fsf@cathode-dark-space.mit.edu>
References: <200904131716.n3DHGZVE018580@drugstore.mit.edu>
	<ldv63h7am4y.fsf@cathode-dark-space.mit.edu>
Message-ID: <825C9FA6-3ECA-4782-AD38-9EB5DBA73EA4@mit.edu>

On Apr 14, 2009, at 00:34, Tom Yu wrote:
> Can we make things even simpler if we assume realloc(NULL, len) is
> always equivalent to malloc(len)?  How safe an assumption is that
> these days?

Yes, it should be quite safe.  I've already made some minor  
simplifications in the code base that way.

Ken

From srinivas.cheruku at gmail.com  Tue Apr 14 09:18:43 2009
From: srinivas.cheruku at gmail.com (Srinivas Cheruku)
Date: Tue, 14 Apr 2009 18:48:43 +0530
Subject: option letter for kinit fast
In-Reply-To: <20090413144827.96A68414D@carter-zimmerman.suchdamage.org>
References: <20090413144827.96A68414D@carter-zimmerman.suchdamage.org>
Message-ID: <49e48d39.22ba720a.0536.ffffff5a@mx.google.com>

Sam,

You are looking for specifying FAST cache. Does that mean we can use a
normal request (e.g. no fast) and get a TGT into the FAST cache and use this
as armor TGT?

Thanks,
Srini

-----Original Message-----
From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf Of
Sam Hartman
Sent: 13 April 2009 20:18
To: krbdev at mit.edu
Subject: option letter for kinit fast



I'd like to add an option to kinit to set the name of the FAST ccache.
If set, the library will look for an armor ticket to use in that cache
and turn on fast.

What option letter should I use?

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


From hartmans at MIT.EDU  Tue Apr 14 10:48:54 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 14 Apr 2009 10:48:54 -0400
Subject: oddity: krb5_get_init_creds_opt_set_fast_ccache_name
Message-ID: <tsl63h78f55.fsf@mit.edu>



I noticed that when I created this function I included a krb5_context
argument.  Most of the other gic opts functions don't have one.  I'm
happy with the current state but if anyone else is not, they should
fix before beta1 ships.

From hartmans at MIT.EDU  Tue Apr 14 12:13:58 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 14 Apr 2009 12:13:58 -0400
Subject: Testing FAST
Message-ID: <tslskkb6wmx.fsf@mit.edu>



I think that we want to add regression tests for FAST.

At least initially, I'd like to check the AS path.
I have not enabled the TGS client on the trunk yet, so it would be hard to test.
(I think I'd prefer not to do that in 1.7)

To test FAST, you need to:
* set the requires_preauth flag on some principal
* get a ticket to use as an armor ticket
* run kinit -T armor_ccahe principal

The easiest way to enable preauth is to set 
                default_principal_flags = +preauth
in kdc.conf

Doing so does significant change several aspects of the AS path.  It's
kind of not good that our current tests never seem to test preauth.


FAST is somewhat sensitive to enctype issues.  In particular, FAST
does not currently support DES, although that's relatively easy to
implement.
The code paths that are enctype specific are:
* PRF is used for the session key, long-term key and subsession key enctypes
* The mandatory checksum of the armor key is used at a number of points

It's been a long time since I've messed around inside the dejagnu
tests and I don't currently have either TCL or that code base swapped
in.

From hartmans at MIT.EDU  Tue Apr 14 12:22:12 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 14 Apr 2009 12:22:12 -0400
Subject: Salt for aliases
Message-ID: <tslk55n6w97.fsf@mit.edu>



We had hoped to test salting of aliases and some canonicalization issues at the interop event.

Unfortunately, that testing never happened.

I suspect that if you use aliasing for user name aliases that you
really want to have the KDC return a specific salt string in the
etype_info2 based on the canonical principal name.

This is out of scope of anything I'm currently working on and I would
not count on me for having time to deal.

--Sam

From ghudson at MIT.EDU  Tue Apr 14 19:16:39 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Tue, 14 Apr 2009 19:16:39 -0400
Subject: Salt for aliases
In-Reply-To: <tslk55n6w97.fsf@mit.edu>
References: <tslk55n6w97.fsf@mit.edu>
Message-ID: <1239750999.6635.1.camel@ray>

On Tue, 2009-04-14 at 12:22 -0400, Sam Hartman wrote:
> I suspect that if you use aliasing for user name aliases that you
> really want to have the KDC return a specific salt string in the
> etype_info2 based on the canonical principal name.

I will start looking into this on Thursday if no one else indicates an
intention to do so, and if I'm not handed anything higher-priority in
the meantime.



From ghudson at MIT.EDU  Thu Apr 16 12:48:46 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Thu, 16 Apr 2009 12:48:46 -0400
Subject: Salt for aliases
In-Reply-To: <tslk55n6w97.fsf@mit.edu>
References: <tslk55n6w97.fsf@mit.edu>
Message-ID: <1239900526.6635.12.camel@ray>

On Tue, 2009-04-14 at 12:22 -0400, Sam Hartman wrote:
> I suspect that if you use aliasing for user name aliases that you
> really want to have the KDC return a specific salt string in the
> etype_info2 based on the canonical principal name.

Done and tagged for pullup to 1.7.

Also fixes the salt sent for SALTTYPE_NOREALM keys in the presence of
aliases; previously we were computing the salt based on the requested
name instead of the canonical name.



From tiberian at gmail.com  Fri Apr 17 03:46:13 2009
From: tiberian at gmail.com (mattd)
Date: Fri, 17 Apr 2009 19:46:13 +1200
Subject: KRB5_INT16_MAX
Message-ID: <fb7af90d0904170046n55be0f8ck539244cc6f744319@mail.gmail.com>

KRB5_INT16_MAX is #define'd in include/krb5/krb5.hin as 65535 -
shouldn't this be 32767 instead?

- Matt D.

From epeisach at MIT.EDU  Fri Apr 17 06:33:33 2009
From: epeisach at MIT.EDU (Ezra Peisach)
Date: Fri, 17 Apr 2009 06:33:33 -0400
Subject: KRB5_INT16_MAX
In-Reply-To: <fb7af90d0904170046n55be0f8ck539244cc6f744319@mail.gmail.com>
References: <fb7af90d0904170046n55be0f8ck539244cc6f744319@mail.gmail.com>
Message-ID: <49E85AFD.7080402@mit.edu>

mattd wrote:
> KRB5_INT16_MAX is #define'd in include/krb5/krb5.hin as 65535 -
> shouldn't this be 32767 instead?
>
> - Matt D.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>   
It should be 32767 - based on 0x7f, or stdint.h, etc...

Our usage is:

./include/krb5/krb5.hin:#define KRB5_INT16_MAX 65535
./include/krb5/krb5.hin:#define KRB5_INT16_MIN  (-KRB5_INT16_MAX-1)
./lib/gssapi/krb5/init_sec_context.c:            if (credmsg.length+28 > 
KRB5_INT16_MAX) {

(and KRB5_INT16_MIN is not used....)


So - it should be ok....

Ezra


From ssorce at redhat.com  Fri Apr 17 07:48:00 2009
From: ssorce at redhat.com (Simo Sorce)
Date: Fri, 17 Apr 2009 07:48:00 -0400
Subject: KRB5_INT16_MAX
In-Reply-To: <49E85AFD.7080402@mit.edu>
References: <fb7af90d0904170046n55be0f8ck539244cc6f744319@mail.gmail.com>
	<49E85AFD.7080402@mit.edu>
Message-ID: <1239968880.3696.31.camel@localhost.localdomain>

On Fri, 2009-04-17 at 06:33 -0400, Ezra Peisach wrote:
> Our usage is:
> 
> ./include/krb5/krb5.hin:#define KRB5_INT16_MAX 65535
> ./include/krb5/krb5.hin:#define KRB5_INT16_MIN  (-KRB5_INT16_MAX-1)
> ./lib/gssapi/krb5/init_sec_context.c:            if (credmsg.length+28
> > 
> KRB5_INT16_MAX) {
> 
> (and KRB5_INT16_MIN is not used....)
> 
> 
> So - it should be ok....

Then shouldn't you call it KRB5_UINT16_MAX ?

Simo.

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


From srinivas.cheruku at gmail.com  Mon Apr 20 10:33:28 2009
From: srinivas.cheruku at gmail.com (Srinivas Cheruku)
Date: Mon, 20 Apr 2009 20:03:28 +0530
Subject: krb5-1-7 compilation
Message-ID: <49ec87c3.0a04d00a.62c9.2377@mx.google.com>

Hi,

 

I tried compiling krb5-1-7 got from
svn://anonsvn.mit.edu/krb5/branches/krb5-1-7, but it gives me error while
running configure as below:

 

config.status: creating util/collected-client-lib/Makefile

config.status: error: cannot find input file: include/autoconf.h.in 

-bash-3.00$

 

I just ran autoconf from src directory, before running ./configure. 

Not sure what else I need to run before ./configure

 

I would appreciate very much if anyone can let me know how to configure and
compile the source code. This is required for interoperability testing of
MIT FAST code with ours.

 

Thanks,
Srini

 


From raeburn at MIT.EDU  Mon Apr 20 10:39:16 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Mon, 20 Apr 2009 10:39:16 -0400
Subject: krb5-1-7 compilation
In-Reply-To: <49ec87c3.0a04d00a.62c9.2377@mx.google.com>
References: <49ec87c3.0a04d00a.62c9.2377@mx.google.com>
Message-ID: <5210581C-DE89-4800-8563-94947596BBEB@mit.edu>

On Apr 20, 2009, at 10:33, Srinivas Cheruku wrote:
> config.status: error: cannot find input file: include/autoconf.h.in

> I just ran autoconf from src directory, before running ./configure.

After checking out the tree, you should run util/reconf before running  
configure.  It does some version-number checks and passes the correct  
arguments to autoreconf (which in turn will run both autoconf and  
autoheader, and autoheader creates autoconf.h.in).

Ken

From tlyu at MIT.EDU  Wed Apr 22 17:32:19 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Wed, 22 Apr 2009 17:32:19 -0400
Subject: krb5-1.7-beta1 is available
Message-ID: <ldvk55c1ijg.fsf@cathode-dark-space.mit.edu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

MIT krb5-1.7-beta1 is now available for download from

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

The main MIT Kerberos web page is

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

Please send comments to the krbdev list in the next two weeks.

Major changes in 1.7
- --------------------

* Remove support for version 4 of the Kerberos protocol (krb4).

* New libdefaults configuration variable "allow_weak_crypto".  NOTE:
  Currently defaults to "false", but may default to "true" in a future
  release.  Setting this variable to "false" will have the effect of
  removing weak enctypes (currently defined to be all single-DES
  enctypes) from permitted_enctypes, default_tkt_enctypes, and
  default_tgs_enctypes.

* Client library now follows client principal referrals, for
  compatibility with Windows.

* KDC can issue realm referrals for service principals based on domain
  names.

* Encryption algorithm negotiation (RFC 4537).

* In the replay cache, use a hash over the complete ciphertext to
  avoid false-positive replay indications.

* Microsoft GSS_WrapEX, implemented using the gss_iov API, which is
  similar to the equivalent SSPI functionality.

* DCE RPC, including three-leg GSS context setup and unencapsulated
  GSS tokens.

* NTLM recognition support in GSS-API, to facilitate dropping in an
  NTLM implementation.

* KDC support for principal aliases, if the back end supports them.

* Microsoft set/change password (RFC 3244) protocol in kadmind.

* Incremental propagation support for the KDC database.

* Master key rollover support.

* Flexible Authentication Secure Tunneling (FAST), a preauthentiation
  framework that can protect the AS exchange from dictionary attack.

* Implement client support for GSS_C_DELEG_POLICY_FLAG, which allows a
  GSS application to delegate credentials only if permitted by KDC
  policy.  One minor known bug, which will probably be fixed by final
  release, occurs when this functionality is used with cross-realm
  authentication; see RT ticket #6473.

* Fix CVE-2009-0844, CVE-2009-0845, CVE-2009-0846, CVE-2009-0847 --
  various vulnerabilities in SPNEGO and ASN.1 code.

For a more complete list of changes, please consult

http://krbdev.mit.edu/rt/NoAuth/krb5-1.7/fixed-1.7.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (SunOS)

iEYEARECAAYFAknvjOgACgkQSO8fWy4vZo4KNgCeNcpETJAJhIVr0rctH0s9QM8p
ib8Ani1BPP35ceKV3Ix+zRwo7FV4MY2V
=Uli1
-----END PGP SIGNATURE-----

From hartmans at MIT.EDU  Fri Apr 24 21:41:50 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Fri, 24 Apr 2009 21:41:50 -0400
Subject: krb5-1.7-beta1 is available
In-Reply-To: <ldvk55c1ijg.fsf@cathode-dark-space.mit.edu> (Tom Yu's message of
	"Wed\, 22 Apr 2009 17\:32\:19 -0400")
References: <ldvk55c1ijg.fsf@cathode-dark-space.mit.edu>
Message-ID: <tslzle5jyqp.fsf@mit.edu>

Tom, your major changes claim that allow_weak_crypto defaults to false
.  I thought we decided (and the code seems to agree) that we set it
to true.

--Sam

From tlyu at MIT.EDU  Sat Apr 25 21:58:39 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Sat, 25 Apr 2009 21:58:39 -0400
Subject: krb5-1.7-beta1 is available
In-Reply-To: <tslzle5jyqp.fsf@mit.edu> (Sam Hartman's message of "Fri,
	24 Apr 2009 21:41:50 -0400")
References: <ldvk55c1ijg.fsf@cathode-dark-space.mit.edu>
	<tslzle5jyqp.fsf@mit.edu>
Message-ID: <ldvzle42n1s.fsf@cathode-dark-space.mit.edu>

Sam Hartman <hartmans at MIT.EDU> writes:

> Tom, your major changes claim that allow_weak_crypto defaults to false
> .  I thought we decided (and the code seems to agree) that we set it
> to true.
>
> --Sam

Thanks; I had forgotteon to change this.

From ethan at geographicslab.org  Tue Apr 28 13:55:23 2009
From: ethan at geographicslab.org (Ethan Heilman)
Date: Tue, 28 Apr 2009 13:55:23 -0400
Subject: Kerberos 3DES string-to-key
Message-ID: <46aa15a10904281055i1923e6dx587c0b69db6cd7c2@mail.gmail.com>

Hi,
I'm doing a security project on n-folding within kerberos, and I've I'm
trying to understand the designer's intentions.
I was wondering if any of the developers of kerberos could answer a design
question for me. Kerberos uses an interesting string-to-key method for 3DES.
This key-string-method uses a key expansion algorithm called n-folding to
reduce an arbitrary length string to a fixed length key. This operation
sounds very similar to a cryptographic hash function. In fact in the
documentation provided below, the string-to-key function is claimed to be a
one way function.

Why is n-folding, a key expansion algorithm, used instead of a cryptographic
hash function?
Is there a performance reason I am missing? Are the security requirements
different?

Thanks,
Ethan

For inclusion into RFC 1510
---------------------------
The assigned encryption type designating the use of triple DES is 5.

The assigned checksum type designating the use of encrypting and MD5
checksum with triple DES keys is 9.

Triple DES is implemented using three DES keys.  An Electronic CodeBook
encryption (3-DES ECB) is done by doing a DES ECB encryption of an eight
octet data block with the first DES key, performing a DES ECB decryption
of the resulting data block with the second key and performing a DES ECB
encryption of the result with the third key.

The encryption of a data stream in Cipher Block Chaining mode is
accomplished by eXclusive-ORing each eight-octet data block with the
cipher computed from the previous data block, and then performing a
3-DES ECB encryption.  The first data block is eXclusive-ORed with an
initial vector, which is commonly zero prior to performing the 3-DES
ECB.

The string-to-key algorithm that is used for converting a user's
password into a 3-DES key is a one-way function, evenly distributing the
user's input in the resulting key.  The user's input is appended with
the salt information (typically the realm name), and 168-folded to
produce three DES keys sans parity.  The 168 bits are then expanded to
include odd parity, for use within the DES routines.  If any of the keys
are weak or semi-weak, they are strengthened by eXclusive-ORing the
questionable key with the constant 00000000000000F0.  The three DES keys
are then used to encrypt themselves in 3-DES CBC mode with a zero
initial vector.  This result is once again encrypted using the same keys
and key schedule and an initial vector of the last eight octets.  The
result is then parity adjusted.  If the final result yields weak or
semi-weak keys, they are also strengthened in the same manner as the
input keys.

The n-fold operation used by the string-to-key algorithm
replicates the input bit array X until its length is the least common
multiple of n bits and the length of X.  Before each replication, the
input is circularly rotated to the right by 13 bit positions.  The
successive n-bit chunks of the resulting bit array are then added
together with end-around carry to yield a n-bit result.  The first bit
position in the arrays is treated as the most significant bit.

From raeburn at MIT.EDU  Tue Apr 28 15:28:04 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Tue, 28 Apr 2009 15:28:04 -0400
Subject: Kerberos 3DES string-to-key
In-Reply-To: <46aa15a10904281055i1923e6dx587c0b69db6cd7c2@mail.gmail.com>
References: <46aa15a10904281055i1923e6dx587c0b69db6cd7c2@mail.gmail.com>
Message-ID: <025DCE4C-9F62-4821-AD9D-6511236C79F5@mit.edu>

On Apr 28, 2009, at 13:55, Ethan Heilman wrote:
> I'm doing a security project on n-folding within kerberos, and I've  
> I'm
> trying to understand the designer's intentions.

Great!  It could use more analysis.

> I was wondering if any of the developers of kerberos could answer a  
> design
> question for me.

The 3DES and n-fold stuff was put together many years ago -- I think  
in the early to mid '90s.  I don't know if any of the people behind  
the design of these specific bits are active on the mailing lists  
these days, so we may not be able to address the original intent or  
thought processes.

> Kerberos uses an interesting string-to-key method for 3DES.

"Interesting" is a good word. :-)

> This key-string-method uses a key expansion algorithm called n- 
> folding to
> reduce an arbitrary length string to a fixed length key. This  
> operation
> sounds very similar to a cryptographic hash function. In fact in the
> documentation provided below, the string-to-key function is claimed  
> to be a
> one way function.

> Why is n-folding, a key expansion algorithm, used instead of a  
> cryptographic
> hash function?

First, you should look at RFC 3961, not the text file you found.  That  
text file doesn't describe what we're actually using in Kerberos these  
days.

The pseudocode for DES3string-to-key in RFC 3961 includes:

      s = passwordString + salt
      tmpKey = random-to-key(168-fold(s))
      key = DK (tmpKey, KerberosConstant)

So n-fold scrambles the salt and password together.  The DK function  
basically iteratively encrypts the KerberosConstant (64-fold of the  
string "kerberos") and uses the output blocks concatenated to generate  
the final key.

There are certainly ways in which n-fold could work poorly here.   
Consider a long pass phrase, which when combined with the salt string  
produces a string that's 2*21 or 3*21 bytes (2*168 or 3*168 bits)  
long.  Then 168-fold just chops it into two or three chunks and adds  
them together bitwise.  Given ASCII input, the value range in each  
byte will likely be limited to 32-122 (and usually would exclude some  
of the punctuation characters in that range), so with 2*21 input bytes  
-- two blocks being added together -- each output byte will probably  
be limited to 64-244, about 70% of the possible values or 7.5 bits per  
byte; this from over 8000 possible pairs of ASCII input characters.

If pass+salt isn't a multiple of 21 bytes, then 168-fold gets a little  
more interesting, with multiple rotated copies of the input bit  
string, and individual input bits being added against different sets  
of other input bits.  But how good is this *really* at preserving  
entropy?

The n-fold algorithm came from a paper by Uri Blumenthal and Steve  
Bellovin.  You might also take a look at their paper.

> Is there a performance reason I am missing? Are the security  
> requirements
> different?

The more one works on Kerberos, the more one wishes that modern  
cryptographic algorithms and know-how were available in the mid-80s  
when Kerberos was first being developed. :-)  Performance concerns  
were probably behind a number of decisions (simple key generation  
functions, certain fields not getting encrypted or hashed) that we  
might do differently today if starting from scratch.  These days, when  
designing a new Kerberos cryptosystem, one should probably use "off- 
the-shelf" functions and modes as much as possible, for both security  
and performance reasons.

Ken

-- 
Ken Raeburn / raeburn at mit.edu / no longer at MIT Kerberos Consortium


From ghudson at MIT.EDU  Tue Apr 28 15:37:17 2009
From: ghudson at MIT.EDU (ghudson@MIT.EDU)
Date: Tue, 28 Apr 2009 15:37:17 -0400 (EDT)
Subject: File and line numbers in error messages
Message-ID: <200904281937.n3SJbHgS017383@outgoing.mit.edu>

We had a request from within the MIT krb5 team to optionally include
file and line numbers in error messages.  This is fairly easy to do
with a macro like (relies on a gcc-ism):

#define krb5_set_error_message(ctx, code, fmt, ...) \
  krb5_set_error_message_fl(ctx, code, __FILE__, __LINE__, fmt, ## __VA_ARGS__)

with some appropriate back-end support, producing error messages like:

kinit: get_in_tkt.c: 1503: Client 'blah at ATHENA.MIT.EDU' not found in Kerberos database while getting initial credentials

Obviously, this only helps for code which uses krb5_set_error_message
or krb5int_set_error; code which simply returns an error code will
result in the same cryptic error messages they do today.

We don't want this enabled in production builds; it's not the kind of
error message you want end users to see on a day-to-day basis and it
adds a lot of static strings to the library object files.  So we need
some kind of compile-time flag, either specified through a make-time
option ("make CPPFLAGS=-DBLAH") or a configure-time option
("./configure --enable-blah").

There's a lot of... history in our code base surrounding debug
options, but I don't get the sense that there's any accepted standard
to conform to.  Is there anything I should be aware of before I decide
how this works?

I'm also aware that this feature isn't very useful if no one is really
aware of it, as seems true of a lot of our debugging features.  I'll
probably create a "debugging tips" page in our wiki to help advertise
features like this.

From raeburn at MIT.EDU  Tue Apr 28 16:14:55 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Tue, 28 Apr 2009 16:14:55 -0400
Subject: File and line numbers in error messages
In-Reply-To: <200904281937.n3SJbHgS017383@outgoing.mit.edu>
References: <200904281937.n3SJbHgS017383@outgoing.mit.edu>
Message-ID: <B8EDE3B3-358D-4634-AAD8-B90F0702401B@mit.edu>

On Apr 28, 2009, at 15:37, ghudson at MIT.EDU wrote:
> We had a request from within the MIT krb5 team to optionally include
> file and line numbers in error messages.

Yay!

>  This is fairly easy to do
> with a macro like (relies on a gcc-ism):
>
> #define krb5_set_error_message(ctx, code, fmt, ...) \
>  krb5_set_error_message_fl(ctx, code, __FILE__, __LINE__, fmt, ##  
> __VA_ARGS__)

Even without the gcc bits, if you have C99 support it's doable.  I  
don't know what you'd do for Windows though, where we're stuck with  
VS2003.  I guess you could have it permanently disabled there, along  
with pre-C99 non-GCC platforms.

> kinit: get_in_tkt.c: 1503: Client 'blah at ATHENA.MIT.EDU' not found in  
> Kerberos database while getting initial credentials

It's nitpicky, but I think I'd rather see "(get_in_tkt.c:1503)" added  
at the end.

> We don't want this enabled in production builds; it's not the kind of
> error message you want end users to see on a day-to-day basis and it
> adds a lot of static strings to the library object files.  So we need
> some kind of compile-time flag, either specified through a make-time
> option ("make CPPFLAGS=-DBLAH") or a configure-time option
> ("./configure --enable-blah").

I'd think for many UNIX builds you'd actually want the capability  
compiled in, but turned off by default.  Then when someone reports  
"Waah, my program reports 'generic Kerberos error' using the Kerberos  
packaged with OpenDebHatBuntuKnopp 4.7, what's it mean?" and we don't  
know, we can say, "set KRB5_HELP_ME_OBI_WAN_KENOBI=1 and run it again"  
and get some useful information out without the user having to  
recompile.

But the krb5_set_error_message calls don't happen in enough places.   
Not only do some places still need updating to call it, but many  
places in the code may have nothing else interesting to report, or  
don't even have a context in which to store the information.  It might  
be helpful to have a simple function that can be called within the  
library to indicate, "hey, I'm generating error code X here", where  
one could set a breakpoint and/or cause it to print the file and line  
number when debugging, and which would do nothing normally.  E.g.,  
change "return KRB5_ERR_FOO" to "return mkerr(KRB5_ERR_FOO)" with  
"#define mkerr(CODE) krb5int_mkerr(CODE,__FILE__,__LINE__)" etc; code  
size may suffer a little, but speed isn't very important in the error  
paths.

> I'm also aware that this feature isn't very useful if no one is really
> aware of it, as seems true of a lot of our debugging features.  I'll
> probably create a "debugging tips" page in our wiki to help advertise
> features like this.

Having written more than one bit of debugging code that's fallen into  
this category, I agree, this is a good idea....

Ken


-- 
Ken Raeburn / raeburn at mit.edu / no longer at MIT Kerberos Consortium


From rra at stanford.edu  Tue Apr 28 18:42:27 2009
From: rra at stanford.edu (Russ Allbery)
Date: Tue, 28 Apr 2009 15:42:27 -0700
Subject: File and line numbers in error messages
In-Reply-To: <B8EDE3B3-358D-4634-AAD8-B90F0702401B@mit.edu> (Ken Raeburn's
	message of "Tue\, 28 Apr 2009 16\:14\:55 -0400")
References: <200904281937.n3SJbHgS017383@outgoing.mit.edu>
	<B8EDE3B3-358D-4634-AAD8-B90F0702401B@mit.edu>
Message-ID: <874ow8ieng.fsf@windlord.stanford.edu>

Ken Raeburn <raeburn at MIT.EDU> writes:
> On Apr 28, 2009, at 15:37, ghudson at MIT.EDU wrote:

>> #define krb5_set_error_message(ctx, code, fmt, ...) \
>>  krb5_set_error_message_fl(ctx, code, __FILE__, __LINE__, fmt, ##  
>> __VA_ARGS__)

> Even without the gcc bits, if you have C99 support it's doable.  I
> don't know what you'd do for Windows though, where we're stuck with
> VS2003.  I guess you could have it permanently disabled there, along
> with pre-C99 non-GCC platforms.

You can do it without requiring either C99 or GCC if you're willing to
fall back to using an inline function and provide a version of
krb5_set_error_message that takes a va_list instead of variable
arguments.  But that might be overkill.  (I do that as a standard part
of the error handling library for most of the code I write, if you want
to look at a working and tested implementation.)

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

From raeburn at MIT.EDU  Tue Apr 28 18:55:37 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Tue, 28 Apr 2009 18:55:37 -0400
Subject: File and line numbers in error messages
In-Reply-To: <874ow8ieng.fsf@windlord.stanford.edu>
References: <200904281937.n3SJbHgS017383@outgoing.mit.edu>
	<B8EDE3B3-358D-4634-AAD8-B90F0702401B@mit.edu>
	<874ow8ieng.fsf@windlord.stanford.edu>
Message-ID: <DBDF6892-9C7F-4550-AF2E-9CA4C9E1F04E@mit.edu>

On Apr 28, 2009, at 18:42, Russ Allbery wrote:
> You can do it without requiring either C99 or GCC if you're willing to
> fall back to using an inline function and provide a version of
> krb5_set_error_message that takes a va_list instead of variable
> arguments.  But that might be overkill.  (I do that as a standard part
> of the error handling library for most of the code I write, if you  
> want
> to look at a working and tested implementation.)

If you use __LINE__ in an inline function, you're going to get the  
line number of the inline function.  So how would you get the correct  
line numbers added in each call, without changing every call site?

-- 
Ken Raeburn / raeburn at mit.edu / no longer at MIT Kerberos Consortium


From rra at stanford.edu  Tue Apr 28 19:15:38 2009
From: rra at stanford.edu (Russ Allbery)
Date: Tue, 28 Apr 2009 16:15:38 -0700
Subject: File and line numbers in error messages
In-Reply-To: <DBDF6892-9C7F-4550-AF2E-9CA4C9E1F04E@mit.edu> (Ken Raeburn's
	message of "Tue\, 28 Apr 2009 18\:55\:37 -0400")
References: <200904281937.n3SJbHgS017383@outgoing.mit.edu>
	<B8EDE3B3-358D-4634-AAD8-B90F0702401B@mit.edu>
	<874ow8ieng.fsf@windlord.stanford.edu>
	<DBDF6892-9C7F-4550-AF2E-9CA4C9E1F04E@mit.edu>
Message-ID: <87vdoogyjp.fsf@windlord.stanford.edu>

Ken Raeburn <raeburn at MIT.EDU> writes:
> On Apr 28, 2009, at 18:42, Russ Allbery wrote:

>> You can do it without requiring either C99 or GCC if you're willing
>> to fall back to using an inline function and provide a version of
>> krb5_set_error_message that takes a va_list instead of variable
>> arguments.  But that might be overkill.  (I do that as a standard
>> part of the error handling library for most of the code I write, if
>> you want to look at a working and tested implementation.)

> If you use __LINE__ in an inline function, you're going to get the  
> line number of the inline function.  So how would you get the correct  
> line numbers added in each call, without changing every call site?

Hm, yeah, I thought I had a solution to that, but it looks like I just
suppress the file and line when neither C99 nor GCC are available.

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

From hartmans at MIT.EDU  Wed Apr 29 15:28:15 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 29 Apr 2009 15:28:15 -0400
Subject: File and line numbers in error messages
In-Reply-To: <87vdoogyjp.fsf@windlord.stanford.edu> (Russ Allbery's message of
	"Tue\, 28 Apr 2009 16\:15\:38 -0700")
References: <200904281937.n3SJbHgS017383@outgoing.mit.edu>
	<B8EDE3B3-358D-4634-AAD8-B90F0702401B@mit.edu>
	<874ow8ieng.fsf@windlord.stanford.edu>
	<DBDF6892-9C7F-4550-AF2E-9CA4C9E1F04E@mit.edu>
	<87vdoogyjp.fsf@windlord.stanford.edu>
Message-ID: <tsleivbdzu8.fsf@mit.edu>

The idea of including line numbers in error messages seems like a bad
idea to me.  I don't actually object to it, but grep seems like a
better tool than cluttering up error messages that should be written
for users.  My concern is basically that if an error is likely then it
is more desirable to have the error message be clear than to point to
source code.

However provided that enable-maintainer-mode does not turn on this
behavior, and we don't get more sloppy about writing error messages,
and no one actually ships a build that way, it seems mostly harmless.

Note that krb5_set_error_message is a public API (so it can be used in
plugins) so you don't want to change its calling semantics or turn it
into a macro.  I'd also argue that it would be bad if code built with
this flag had a different ABI in terms of accessor or public exports
than code built without this flag.

--Sam

From ghudson at MIT.EDU  Wed Apr 29 15:56:25 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Wed, 29 Apr 2009 15:56:25 -0400
Subject: File and line numbers in error messages
In-Reply-To: <tsleivbdzu8.fsf@mit.edu>
References: <200904281937.n3SJbHgS017383@outgoing.mit.edu>
	<B8EDE3B3-358D-4634-AAD8-B90F0702401B@mit.edu>
	<874ow8ieng.fsf@windlord.stanford.edu>
	<DBDF6892-9C7F-4550-AF2E-9CA4C9E1F04E@mit.edu>
	<87vdoogyjp.fsf@windlord.stanford.edu>  <tsleivbdzu8.fsf@mit.edu>
Message-ID: <1241034985.6635.44.camel@ray>

On Wed, 2009-04-29 at 15:28 -0400, Sam Hartman wrote:
> Note that krb5_set_error_message is a public API (so it can be used in
> plugins) so you don't want to change its calling semantics or turn it
> into a macro.  I'd also argue that it would be bad if code built with
> this flag had a different ABI in terms of accessor or public exports
> than code built without this flag.

What are the pitfalls here?  If necessary, I can introduce a new
internal interface and use it in the libraries.

I wasn't going to conditionalize the back-end support.



From hartmans at MIT.EDU  Wed Apr 29 16:09:03 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 29 Apr 2009 16:09:03 -0400
Subject: preauth behavior discovered in the BETA
Message-ID: <tslab5zdxy8.fsf@mit.edu>



Looking at beta1 I've discovered a couple of issue I'd really like to see fixed.
I'll write up and commit fixes but wanted to discuss here.

1) As I mentioned before the beta, we currently don't have a PRF for
DES or 3DES.  I think we want to fix that.  The behavior if a client
uses FAST for an enctype the KDC doesn't have a PRF for is not that
good.  You fail to produce an armor key, which fails the request.
That may be the correct thing in the AS case, but it is fairly
annoying in the TGS case.  I'll go implement DES and 3DES PRFs.  3DES
is fairly easy, but I'd really appreciate careful review of the DES
code to make sure it follows the SPEC.

An alternate approach might be to change the error handling in the
FAST TGS path.  I think that would be harder to test and would be
wasted effort in the long run.

Also, our KDC returns KDC_ERR_PREAUTH_FAILED if pre-authentication is
required and an unknown pre-authentication type is used.  I think that
ignoring the unknown pre-authentication type and returning
KDC_ERR_PREAUTH_REQUIRED is better behavior.  That's what Windows
does; that's what the pre-authentication framework says you should do.
Doing so may save a round trip when a 1.8 client talks to a 1.7 KDC
using the negotiation facilities Larry posted to the WG list about
after the interop event.  The 1.7 KDC will not recognize those
facilities and I'm concerned that returning PREAUTH_FAILED may require
the client to do extra work.  In addition, if KDC database updates are
enabled, PREAUTH_FAILED will definitely do the wrong thing.  This is a
simple change.

--Sam

From ghudson at MIT.EDU  Wed Apr 29 16:35:38 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Wed, 29 Apr 2009 16:35:38 -0400
Subject: File and line numbers in error messages
In-Reply-To: <tsleivbdzu8.fsf@mit.edu>
References: <200904281937.n3SJbHgS017383@outgoing.mit.edu>
	<B8EDE3B3-358D-4634-AAD8-B90F0702401B@mit.edu>
	<874ow8ieng.fsf@windlord.stanford.edu>
	<DBDF6892-9C7F-4550-AF2E-9CA4C9E1F04E@mit.edu>
	<87vdoogyjp.fsf@windlord.stanford.edu>  <tsleivbdzu8.fsf@mit.edu>
Message-ID: <1241037338.6635.46.camel@ray>

Ignore my previous answer.

On Wed, 2009-04-29 at 15:28 -0400, Sam Hartman wrote:
> I don't actually object to it, but grep seems like a
> better tool than cluttering up error messages that should be written
> for users.

I sort of lean in this direction myself; I suspect the counterargument
is that you have to guess what to grep for since the error message was
(in the general case) produced from a format string.

> Note that krb5_set_error_message is a public API (so it can be used in
> plugins) so you don't want to change its calling semantics or turn it
> into a macro.  I'd also argue that it would be bad if code built with
> this flag had a different ABI in terms of accessor or public exports
> than code built without this flag.

The idea is to have k5-int.h redefine uses of krb5_set_error_message to
use krb5_set_error_message_fl instead.  The old API will still be there,
unchanged.  Anyone who doesn't use k5-int.h will use the old API.



From ghudson at MIT.EDU  Wed Apr 29 17:37:58 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Wed, 29 Apr 2009 17:37:58 -0400
Subject: File and line numbers in error messages
In-Reply-To: <B8EDE3B3-358D-4634-AAD8-B90F0702401B@mit.edu>
References: <200904281937.n3SJbHgS017383@outgoing.mit.edu>
	<B8EDE3B3-358D-4634-AAD8-B90F0702401B@mit.edu>
Message-ID: <1241041078.6635.52.camel@ray>

On Tue, 2009-04-28 at 16:14 -0400, Ken Raeburn wrote:
> Even without the gcc bits, if you have C99 support it's doable.

Right, by starting the variadic part at the format argument.  Got it.

> It's nitpicky, but I think I'd rather see "(get_in_tkt.c:1503)" added  
> at the end.

Okay, but it's only easy to make it appear at the end of the error message, not the "while brushing my teeth" part that com_err appends.

> I'd think for many UNIX builds you'd actually want the capability  
> compiled in, but turned off by default.

Currently leaning towards no on this, because it still adds static
strings to the library object files.  Using an #ifdef also removes the
need for an autoconf check for variadic macros ("if it hurts for you to
define DEBUG_ERROR_FILE_LINE, don't define it") but for posterity, the
autoconf check is pretty simple:

dnl                                                                             
dnl Test for C99-style variable-argument macro support                          
dnl                                                                             
AC_CACHE_CHECK(if compiler supports C99-style variadic macros,
               krb5_cv_variadic_macros,
[AC_COMPILE_IFELSE([
#define macro(...) return(__VA_ARGS__)                                          
int main() { macro(1); }
], krb5_cv_variadic_macros=yes, krb5_cv_variadic_macros=no)])
if test "$krb5_cv_variadic_macros" = yes; then
  AC_DEFINE(HAVE_VARIADIC_MACROS,1,[Define if compiler supports C99-style variadic macros.])
fi
dnl                                                                             

> Then when someone reports [...]

As Sam pointed out, the onus is on us to make our error messages clear,
not rely on obscure features to support people who get unclear error
messages.

For similar reasons, I don't want to add a mkerr() and litter the code
with it at this time.



From hartmans at MIT.EDU  Wed Apr 29 17:53:35 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 29 Apr 2009 17:53:35 -0400
Subject: File and line numbers in error messages
In-Reply-To: <1241037338.6635.46.camel@ray> (Greg Hudson's message of "Wed\,
	29 Apr 2009 16\:35\:38 -0400")
References: <200904281937.n3SJbHgS017383@outgoing.mit.edu>
	<B8EDE3B3-358D-4634-AAD8-B90F0702401B@mit.edu>
	<874ow8ieng.fsf@windlord.stanford.edu>
	<DBDF6892-9C7F-4550-AF2E-9CA4C9E1F04E@mit.edu>
	<87vdoogyjp.fsf@windlord.stanford.edu> <tsleivbdzu8.fsf@mit.edu>
	<1241037338.6635.46.camel@ray>
Message-ID: <tsl4ow7cejk.fsf@mit.edu>

>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:
    Greg> The idea is to have k5-int.h redefine uses of8
    Greg> krb5_set_error_message to use krb5_set_error_message_fl
    Greg> instead.  The old API will still be there, unchanged.
    Greg> Anyone who doesn't use k5-int.h will use the old API.

OK.  I guess that's the best way to do this.

From jhutz at cmu.edu  Wed Apr 29 17:58:22 2009
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Wed, 29 Apr 2009 17:58:22 -0400
Subject: File and line numbers in error messages
In-Reply-To: <200904292138.n3TLcDOa017237@mx03.srv.cs.cmu.edu>
References: <200904281937.n3SJbHgS017383@outgoing.mit.edu>
	<B8EDE3B3-358D-4634-AAD8-B90F0702401B@mit.edu>
	<200904292138.n3TLcDOa017237@mx03.srv.cs.cmu.edu>
Message-ID: <2248E787F5DD2523EEBC9D3F@minbar.fac.cs.cmu.edu>

--On Wednesday, April 29, 2009 05:37:58 PM -0400 Greg Hudson 
<ghudson at mit.edu> wrote:

> As Sam pointed out, the onus is on us to make our error messages clear,
> not rely on obscure features to support people who get unclear error
> messages.

Clear error messages help the user figure out what is wrong and how to fix 
it.  Unfortunately, they also encourage the user to explain what they think 
is wrong in their own words instead of quoting something you can grep for. 
In addition, even if the user _does_ quote the message, having clear error 
messages also often means producing the same error message in multiple 
places.  That makes it a pain to figure out which code path produced the 
message.  Including the filename and line number can be fairly useful in 
resolving this, and also helps people who are not deeply familiar with the 
source tree to figure out where to start looking.

-- Jeff

From hartmans at MIT.EDU  Wed Apr 29 18:16:54 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 29 Apr 2009 18:16:54 -0400
Subject: File and line numbers in error messages
In-Reply-To: <2248E787F5DD2523EEBC9D3F@minbar.fac.cs.cmu.edu> (Jeffrey
	Hutzelman's message of "Wed\, 29 Apr 2009 17\:58\:22 -0400")
References: <200904281937.n3SJbHgS017383@outgoing.mit.edu>
	<B8EDE3B3-358D-4634-AAD8-B90F0702401B@mit.edu>
	<200904292138.n3TLcDOa017237@mx03.srv.cs.cmu.edu>
	<2248E787F5DD2523EEBC9D3F@minbar.fac.cs.cmu.edu>
Message-ID: <tslzldzayw9.fsf@mit.edu>

I'd object very strongly to a version of this complied in by default
or intended to ship in end-user/OS builds.

--Sam

From jhutz at cmu.edu  Wed Apr 29 18:25:13 2009
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Wed, 29 Apr 2009 18:25:13 -0400
Subject: File and line numbers in error messages
In-Reply-To: <tslzldzayw9.fsf@mit.edu>
References: <200904281937.n3SJbHgS017383@outgoing.mit.edu>
	<B8EDE3B3-358D-4634-AAD8-B90F0702401B@mit.edu>
	<200904292138.n3TLcDOa017237@mx03.srv.cs.cmu.edu>
	<2248E787F5DD2523EEBC9D3F@minbar.fac.cs.cmu.edu>
	<tslzldzayw9.fsf@mit.edu>
Message-ID: <B921B08B12734BD708DA90A2@minbar.fac.cs.cmu.edu>

--On Wednesday, April 29, 2009 06:16:54 PM -0400 Sam Hartman 
<hartmans at mit.edu> wrote:

> I'd object very strongly to a version of this complied in by default
> or intended to ship in end-user/OS builds.

I think I'd object to having it turned on by default.  I certainly would 
not argue in favor of it being compiled in but not turned on.

In my last message, I meant to point out that once you have lots of 
messages which are the same, in the name of making things clear, being able 
to build a version with line numbers is useful for finding the right code 
path.

I do not think line numbers are terribly useful in end-user/OS builds, 
since by the time you get a problem report you will often either not know 
what source was used or not have a copy.

-- Jeff

From hartmans at MIT.EDU  Wed Apr 29 18:37:43 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 29 Apr 2009 18:37:43 -0400
Subject: File and line numbers in error messages
In-Reply-To: <B921B08B12734BD708DA90A2@minbar.fac.cs.cmu.edu> (Jeffrey
	Hutzelman's message of "Wed\, 29 Apr 2009 18\:25\:13 -0400")
References: <200904281937.n3SJbHgS017383@outgoing.mit.edu>
	<B8EDE3B3-358D-4634-AAD8-B90F0702401B@mit.edu>
	<200904292138.n3TLcDOa017237@mx03.srv.cs.cmu.edu>
	<2248E787F5DD2523EEBC9D3F@minbar.fac.cs.cmu.edu>
	<tslzldzayw9.fsf@mit.edu>
	<B921B08B12734BD708DA90A2@minbar.fac.cs.cmu.edu>
Message-ID: <tslvdonaxxk.fsf@mit.edu>

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

    Jeffrey> --On Wednesday, April 29, 2009 06:16:54 PM -0400 Sam
    Jeffrey> Hartman
    Jeffrey> <hartmans at mit.edu> wrote:

> I'd object very strongly to a version of this complied in by default
    >> or intended to ship in end-user/OS builds.

My objection would basically be that presenting line numbers to
end-users is significantly user-hostile in terms of usability.  I
believe we can and should strive to have more usable software and not
to expect end users to get to that level of debugging for user level
errors.

I support line and file numbers for this can't happen/library internal
errors and possibly even for API usage errors.

--Sam

From hartmans at MIT.EDU  Wed Apr 29 19:05:15 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 29 Apr 2009 19:05:15 -0400
Subject: PRF length for 3DES
Message-ID: <tslr5zbawno.fsf@mit.edu>



Hi.  In San Francisco, we discussed the construction of the RFC 3961
PRF.  In that discussion, we concluded that the PRF length for
simplified profile ciphers should be the block size of the cipher.
That means 3DES would have an eight-byte PRF.

I'm going to go implement that, but I want to bring up an interop
concern.  The Racoon2 IPsec daemon ships with KINK support that
assumes the 3DES PRF has 16-bytes of length.  It's my understanding
though that code does not currently call krb5_c_prf.

If we're going to do something different, we need to know quite soon.

-
--Sam

From jhutz at cmu.edu  Wed Apr 29 19:21:31 2009
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Wed, 29 Apr 2009 19:21:31 -0400
Subject: File and line numbers in error messages
In-Reply-To: <tslvdonaxxk.fsf@mit.edu>
References: <200904281937.n3SJbHgS017383@outgoing.mit.edu>
	<B8EDE3B3-358D-4634-AAD8-B90F0702401B@mit.edu>
	<200904292138.n3TLcDOa017237@mx03.srv.cs.cmu.edu>
	<2248E787F5DD2523EEBC9D3F@minbar.fac.cs.cmu.edu>	<tslzldzayw9.fsf@mit.edu>
	<B921B08B12734BD708DA90A2@minbar.fac.cs.cmu.edu>
	<tslvdonaxxk.fsf@mit.edu>
Message-ID: <A1DF35E2788AB3AA1BF3E3EA@atlantis.pc.cs.cmu.edu>

--On Wednesday, April 29, 2009 06:37:43 PM -0400 Sam Hartman 
<hartmans at mit.edu> wrote:

>>>>>> "Jeffrey" == Jeffrey Hutzelman <jhutz at cmu.edu> writes:
>
>     Jeffrey> --On Wednesday, April 29, 2009 06:16:54 PM -0400 Sam
>     Jeffrey> Hartman
>     Jeffrey> <hartmans at mit.edu> wrote:
>
>> I'd object very strongly to a version of this complied in by default
>     >> or intended to ship in end-user/OS builds.
>
> My objection would basically be that presenting line numbers to
> end-users is significantly user-hostile in terms of usability.  I
> believe we can and should strive to have more usable software and not
> to expect end users to get to that level of debugging for user level
> errors.

I agree.

From hartmans-ietf at MIT.EDU  Thu Apr 30 16:25:09 2009
From: hartmans-ietf at MIT.EDU (Sam Hartman)
Date: Thu, 30 Apr 2009 16:25:09 -0400
Subject: Des and 3DES PRF: 16 or 8 bytes
Message-ID: <tslab5x7uu2.fsf@mit.edu>



Folks, it was not clear in the discussion at IETf 74 whether we wanted
to have the RFC 3961 PRF for 3DES change to be an 8-byte output or
not.  Currently if you assume that the text says to truncate to the
nearest multiple of m, then the 3DES PRF should be 16 bytes.

As far as I can tell, no one is shipping DES or 3DES PRF, but I only
checked Heimdal up through 1.2.

My assumption for MIT is that we want to be consistent with RFC 3961
except for AES.

So, that would mean that 

des: cbc-encrypt(md5(prf_input))
3des: cbc-encrypt(sha-1(prf_input) trunc to 128-bits) with
dk(key,"prf")
rc4: hmac-sha1(prf_input) with key
aes: ecb-encrypt(sha-1(prf_input) trunc to 128-bits) with dk(key,
"prf")


Do people agree with that?  If MIT should do something different for
DES or 3DES, now would be the right time to speak up.  We're fairly
committed to our RC4 and AES implementations.

From dodavis at redhat.com  Thu Apr 30 20:56:19 2009
From: dodavis at redhat.com (Don Davis)
Date: Thu, 30 Apr 2009 20:56:19 -0400
Subject: Des and 3DES PRF: 16 or 8 bytes
In-Reply-To: <tslab5x7uu2.fsf@mit.edu>
References: <tslab5x7uu2.fsf@mit.edu>
Message-ID: <49FA48B3.2020300@redhat.com>

hi, sam --

i think an 8 byte hash is sufficiently limited nowadays to justify
using 16 byte as the prf output size.

- don davis, redhat

Sam Hartman wrote:
> Folks, it was not clear in the discussion at IETf 74 whether we wanted
> to have the RFC 3961 PRF for 3DES change to be an 8-byte output or
> not.  Currently if you assume that the text says to truncate to the
> nearest multiple of m, then the 3DES PRF should be 16 bytes.
>
> As far as I can tell, no one is shipping DES or 3DES PRF, but I only
> checked Heimdal up through 1.2.
>
> My assumption for MIT is that we want to be consistent with RFC 3961
> except for AES.
>
> So, that would mean that 
>
> des: cbc-encrypt(md5(prf_input))
> 3des: cbc-encrypt(sha-1(prf_input) trunc to 128-bits) with
> dk(key,"prf")
> rc4: hmac-sha1(prf_input) with key
> aes: ecb-encrypt(sha-1(prf_input) trunc to 128-bits) with dk(key,
> "prf")
>
>
> Do people agree with that?  If MIT should do something different for
> DES or 3DES, now would be the right time to speak up.  We're fairly
> committed to our RC4 and AES implementations.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>   


From hartmans-ietf at MIT.EDU  Thu Apr 30 22:22:21 2009
From: hartmans-ietf at MIT.EDU (Sam Hartman)
Date: Thu, 30 Apr 2009 22:22:21 -0400
Subject: Des and 3DES PRF: 16 or 8 bytes
In-Reply-To: <49FA48B3.2020300@redhat.com> (Don Davis's message of "Thu\,
	30 Apr 2009 20\:56\:19 -0400")
References: <tslab5x7uu2.fsf@mit.edu> <49FA48B3.2020300@redhat.com>
Message-ID: <tsliqkl5zqa.fsf@mit.edu>

>>>>> "Don" == Don Davis <dodavis at redhat.com> writes:

    Don> hi, sam -- i think an 8 byte hash is sufficiently limited
    Don> nowadays to justify using 16 byte as the prf output size.

You and everyone else comes to this conclusion when they examine the
problem for about 30 seconds.

As far as I can tell though, there is not a significant difference in
security properties until you start making 2**32 calls to the PRF with
the same key regardless of whether you use 8 or 16 bytes.  At that
point, I suspect but cannot show that there may be a
distinguishability attack, probably against both the 8 and 16 byte
versions.  I suspect an attack that was useful in breaking the use as
a key derivation function would be harder.

Sorry if I sound a bit frustrated on this one, but I've been seeing
the same argument again and again, and when I ask the person to look
into it, there doesn't seem to be a security justification behind it.


If you are seeing an attack, I'd appreciate a more detailed response
describing the attack and its assumptions.