From dodavis at redhat.com  Fri May  1 11:13:12 2009
From: dodavis at redhat.com (Don Davis)
Date: Fri, 01 May 2009 11:13:12 -0400
Subject: Des and 3DES PRF: 16 or 8 bytes
In-Reply-To: <tsliqkl5zqa.fsf@mit.edu>
References: <tslab5x7uu2.fsf@mit.edu> <49FA48B3.2020300@redhat.com>
	<tsliqkl5zqa.fsf@mit.edu>
Message-ID: <49FB1188.5080703@redhat.com>


>     Don> i think an 8 byte hash is sufficiently limited nowadays
>     Don> 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. ...
>
> If you are seeing an attack, I'd appreciate a more detailed response
> describing the attack and its assumptions.
>   
hi, sam --

i think the very fact that 8bytes simply & universally _seems_ inadequate,
is sufficient justification. it's like the argument against using MD5, 
10 years
ago -- we knew, and some customers knew, that MD5 would eventually
get cracked wide-open, so it was easier to deprecate MD5 in advance,
than to detailedly analyze the plusses & minusses of continuing to use
MD5 for a few more years. just for example, i doubt that krb's support
of a 64bit 3DES hash would be acceptable for NIST's FIPS 140-2
certification of kerberos.

after all, no-one in the hash-function field recommends any hash-fcn with
such a short output as 64 bits. i can't justify the work necessary to 
formally
support using a 64-bit hash. at the same time, it also seems plain that 
using
3DES as a 128-bit hash fcn isn't such a bad idea, except for performance.
why overwork the question?

- don davis

From jhutz at cmu.edu  Fri May  1 11:51:14 2009
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Fri, 01 May 2009 11:51:14 -0400
Subject: Des and 3DES PRF: 16 or 8 bytes
In-Reply-To: <200904302025.n3UKPuk2024367@mx02.srv.cs.cmu.edu>
References: <200904302025.n3UKPuk2024367@mx02.srv.cs.cmu.edu>
Message-ID: <EB948A78F15F39EE675DE8D1@atlantis.pc.cs.cmu.edu>

--On Thursday, April 30, 2009 04:25:09 PM -0400 Sam Hartman 
<hartmans-ietf at mit.edu> 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.

Hrm.  This goes directly back to the discussion of whether we want to 
truncate to the nearest multiple of the cipher block size, or to the block 
size itself.  I believe we've rather thoroughly had the discussion of the 
relative security merits of the two approaches, but we were rather focused 
on AES.

Now you are bringing up an interoperability issue relating to 3DES, which 
happens to be the only _other_ standardized simplified-profile CBC-mode 
enctype for which "truncate the output of H to the nearest multiple of m" 
does not mean the same thing as "truncate the output of H to c".  Of 
course, AFAIK it is also the only other standardized simplified-profile 
CBC-mode enctype, period.


I believe we have already come to the conclusion that "truncate to the 
nearest multiple of m" is the only reasonable interpretation of what 3961 
says, and so changing AES will involve updating 3961 and/or 3962.  Provided 
that we are satisfied that the 3961 behavior for 3DES is acceptable, or 
that the interop considerations are more important, I see no reason we 
cannot treat 3DES specially at that time, retaining the existing. 
truncate-to-128-bits behavior.


Of course, I don't think I've seen any discussion yet from the working 
group on the question Sam raised...

-- Jeff

From kstemen at likewise.com  Mon May  4 19:45:19 2009
From: kstemen at likewise.com (Kyle Stemen)
Date: Mon, 04 May 2009 16:45:19 -0700
Subject: Concurrency issue between krb5_cc_retrieve_cred and krb5_cc_store_cred
Message-ID: <1241480719.14098.26.camel@kyle-vmserver>

The file descriptor for file based credentials caches is opened in
O_RDONLY or O_RDWR depending on the operation. krb5_cc_store_cred
requires the file to be opened in O_RDWR mode.

The file credential cache has a flag, KRB5_TC_OPENCLOSE, that causes the
credentials cache to be reopened for every element operation. As an
optimization, krb5_cc_retrieve_cred_seq turns off that flag for the
duration of the function:
static krb5_error_code
krb5_cc_retrieve_cred_seq (krb5_context context, krb5_ccache id,
			   krb5_flags whichfields, krb5_creds *mcreds,
			   krb5_creds *creds, int nktypes, krb5_enctype *ktypes)
{
...
     if (oflags & KRB5_TC_OPENCLOSE)
	 (void) krb5_cc_set_flags(context, id, oflags & ~KRB5_TC_OPENCLOSE);
...
     if (oflags & KRB5_TC_OPENCLOSE)
	 krb5_cc_set_flags(context, id, oflags);
}


When krb5_fcc_set_flags turns off KRB5_TC_OPENCLOSE, it opens the file
in read only mode. If krb5_cc_store_cred is called at that point, it
will reuse the existing read only file descriptor. When
krb5_cc_store_cred tries to write, it will get EBADF. That error will
then get translated to  KRB5_FCC_INTERNAL. So krb5_cc_store_cred only
works when KRB5_TC_OPENCLOSE is on (so the file can be opened in read
write mode). 

krb5_cc_retrieve_cred_seq does not lock the cache file for the entire
operation (only for each individual seek and read). This means there is
a race condition between krb5_cc_store_cred and krb5_cc_retrieve_cred.
The attached program illustrates the failure. On my test machine, it
fails on loop 500 or so.

I am using Kerberos 1.6.3, but I don't see anything that would fix this
in the krb5-1-7 branch of your svn.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: krb5_concurrency.c
Type: text/x-csrc
Size: 2423 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090504/13402bc3/krb5_concurrency.bin

From hartmans at MIT.EDU  Tue May  5 09:27:50 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 05 May 2009 09:27:50 -0400
Subject: Concurrency issue between krb5_cc_retrieve_cred and
	krb5_cc_store_cred
In-Reply-To: <1241480719.14098.26.camel@kyle-vmserver> (Kyle Stemen's message
	of "Mon\, 04 May 2009 16\:45\:19 -0700")
References: <1241480719.14098.26.camel@kyle-vmserver>
Message-ID: <tslvdofvfvt.fsf@mit.edu>

Do you have any thoughts on the fix?
Approaches to try for me seem to include:

* Lock, reopen rw, unlock  if we get EBADF
* Clear the openclose flag and try again if we get EBADF
* Lock around the entire sequential operation in retrieve 

One factor to consider is difference between Windows and Unix locking semantics.

From kstemen at likewise.com  Tue May  5 12:21:36 2009
From: kstemen at likewise.com (Kyle Stemen)
Date: Tue, 05 May 2009 09:21:36 -0700
Subject: Concurrency issue between krb5_cc_retrieve_cred and
	krb5_cc_store_cred
In-Reply-To: <tslvdofvfvt.fsf@mit.edu>
References: <1241480719.14098.26.camel@kyle-vmserver> <tslvdofvfvt.fsf@mit.edu>
Message-ID: <4A006790.6090900@likewise.com>

Sam Hartman wrote:
> Do you have any thoughts on the fix?
> Approaches to try for me seem to include:
>
> * Lock, reopen rw, unlock  if we get EBADF
>   

So the contract would be that when KRB5_TC_OPENCLOSE is set, the file is 
left opened read only, until krb5_fcc_store is called. From then on, the 
file is left open in rw mode.

I think this is an acceptable solution, but personally, would prefer if 
a flag was used to track whether the file is in rw mode instead of 
having to catch the write failure.

> * Clear the openclose flag and try again if we get EBADF
> * Lock around the entire sequential operation in retrieve 
>   
I dislike these options because KRB5_TC_OPENCLOSE is exposed in the 
public API. If krb5_fcc_store clears the flag, it would mean the 
function has an unexpected side effect. If you lock around the retrieve, 
krb5_fcc_store will still fail if openclose is set through the public API.

> One factor to consider is difference between Windows and Unix locking semantics.
>   


From kstemen at likewise.com  Tue May  5 13:07:19 2009
From: kstemen at likewise.com (Kyle Stemen)
Date: Tue, 05 May 2009 10:07:19 -0700
Subject: Concurrency issue between krb5_cc_retrieve_cred and
	krb5_cc_store_cred
In-Reply-To: <4A006790.6090900@likewise.com>
References: <1241480719.14098.26.camel@kyle-vmserver>
	<tslvdofvfvt.fsf@mit.edu> <4A006790.6090900@likewise.com>
Message-ID: <4A007247.4010002@likewise.com>

Sorry, I just realized I had it backwards, I meant when 
KRB5_TC_OPENCLOSE is unset.

Kyle Stemen wrote:
> Sam Hartman wrote:
>> Do you have any thoughts on the fix?
>> Approaches to try for me seem to include:
>>
>> * Lock, reopen rw, unlock  if we get EBADF
>>   
>
> So the contract would be that when KRB5_TC_OPENCLOSE is set, the file 
> is left opened read only, until krb5_fcc_store is called. From then 
> on, the file is left open in rw mode.
>
> I think this is an acceptable solution, but personally, would prefer 
> if a flag was used to track whether the file is in rw mode instead of 
> having to catch the write failure.
>
>> * Clear the openclose flag and try again if we get EBADF
>> * Lock around the entire sequential operation in retrieve   
> I dislike these options because KRB5_TC_OPENCLOSE is exposed in the 
> public API. If krb5_fcc_store clears the flag, it would mean the 
> function has an unexpected side effect. If you lock around the 
> retrieve, krb5_fcc_store will still fail if openclose is set through 
> the public API.
>
>> One factor to consider is difference between Windows and Unix locking 
>> semantics.
>>   
>
>


From ghudson at MIT.EDU  Tue May  5 23:33:32 2009
From: ghudson at MIT.EDU (ghudson@MIT.EDU)
Date: Tue, 5 May 2009 23:33:32 -0400 (EDT)
Subject: Sanity check: MAX_PW_HIST
Message-ID: <200905060333.n463XWid020166@outgoing.mit.edu>

Our kadmind's svr_policy.c contains:

  #define MAX_PW_HISTORY 10

and two instances of:

  if (entry->pw_history_num < MIN_PW_HISTORY ||
      entry->pw_history_num > MAX_PW_HISTORY)
    return KADM5_BAD_HISTORY;

There's no other use of this constant.  The actual key history is
stored in a circular buffer of dynamic size; we're not taking
advantage of the maximum to allocate a fixed-sized array or anything.

The constant dates back to 1996 when we first merged in the OV kadmin
code; it didn't seem to have any particular reason to exist back then
either.  I think it would be a long shot to find the code's authors
from 13+ years ago and ask why they put that limit there, so before we
get rid of the arbitrary limit, I'll just ask here: does anyone know
of a reason why it should exist?

(For a little more background: this constant limits the maximum value
of the password history size you can set in a policy, which in turn
determines how far back kadmind will check to see if you're reusing an
old password.)

From einav_co at yahoo.com  Sun May 10 14:36:12 2009
From: einav_co at yahoo.com (einav_co)
Date: Sun, 10 May 2009 11:36:12 -0700 (PDT)
Subject: how can i add a client seed to kerberos
Message-ID: <23472750.post@talk.nabble.com>


hi,

how can i add a client seed to kerberos?

thanks,
Einav
-- 
View this message in context: http://www.nabble.com/how-can-i-add-a-client-seed-to-kerberos-tp23472750p23472750.html
Sent from the Kerberos - Dev mailing list archive at Nabble.com.


From hotz at jpl.nasa.gov  Tue May 12 13:57:31 2009
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Tue, 12 May 2009 10:57:31 -0700
Subject: how can i add a client seed to kerberos
In-Reply-To: <mailman.709.1242144823.8123.krbdev@mit.edu>
References: <mailman.709.1242144823.8123.krbdev@mit.edu>
Message-ID: <619793FD-2696-4610-A2D9-B443F71D9766@jpl.nasa.gov>

I have no idea what you mean.

Possibly this question belongs on kerberos at mit.edu, unless it's unique  
to the MIT implementation.

On May 12, 2009, at 9:13 AM, krbdev-request at mit.edu wrote:

> Date: Sun, 10 May 2009 11:36:12 -0700 (PDT)
> From: einav_co <einav_co at yahoo.com>
> Subject: how can i add a client seed to kerberos
> To: krbdev at mit.edu
> Message-ID: <23472750.post at talk.nabble.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> hi,
>
> how can i add a client seed to kerberos?
>
> thanks,
> Einav
> -- 
> View this message in context: http://www.nabble.com/how-can-i-add-a-client-seed-to-kerberos-tp23472750p23472750.html
> Sent from the Kerberos - Dev mailing list archive at Nabble.com.

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




From tlyu at MIT.EDU  Tue May 12 19:39:43 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Tue, 12 May 2009 19:39:43 -0400
Subject: krb5-1.7-beta2 is available
Message-ID: <ldv4ovp7uww.fsf@cathode-dark-space.mit.edu>

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

MIT krb5-1.7-beta2 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 week.  Changes
since krb5-1.7-beta1 are mostly bug fixes, but KDC support for setting
the ok-as-delegate flag is now included.

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 "true", but may default to "false" 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.
  Currently, only the LDAP back end supports aliases.

* 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 and KDC support for GSS_C_DELEG_POLICY_FLAG, which
  allows a GSS application to request credential delegation only if
  permitted by KDC policy.

* 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)

iEYEARECAAYFAkoKCMMACgkQSO8fWy4vZo634gCg+y4JZFdOIc8gR43l4TwrHcwa
XQ0AoISnaBwMaff4xe6OmC0+9c/y8Laa
=D4DS
-----END PGP SIGNATURE-----

From Srinivas.Cheruku at CyberSafe.com  Thu May 14 08:35:53 2009
From: Srinivas.Cheruku at CyberSafe.com (Srinivas Cheruku)
Date: Thu, 14 May 2009 13:35:53 +0100
Subject: fast and patypes in KRB-ERROR
Message-ID: <1A136DCE57F98F4B8BAB5FFC69C8E6DA21E59BDCD7@exchange.cybersafe.local>

Hi,

I noticed that when kinit is used without -T option (e.g. no fast used) and if the user principal requires pre-authentication, I see the following pa-types in KRB-ERROR e-data:

1.       PA-ENC-TIMESTAMP

2.       PA-FX-COOKIE (not sure why this is required ?? anyway, I think MIT uses some dummy cookie)

3.       PA-ETYPE-INFO2

4.       PA-SAM-RESPONSE

5.       PA-FX-FAST

I think it might be good to include PA-ENCRYPTED-CHALLENGE also when user principal requires pre-authentication.

This would means that fast enabled kinit can do the following:

1.       kinit can send a non-fast request to KDC

2.       KDC replies with KRB-ERROR containing the above pa-types along with PA-ENCRYPTED-CHALLENGE (for user principals having pre-auth required set)

3.       kinit can check for PA-FX-FAST and PA-ENCRYPTED-CHALLENGE and send a fast request containing pa-enc-challenge padata.

4.       KDC sends tgt using FAST on successful authentication

I know that MIT kinit doesn't support this behaviour but other vendors can support this.
Any advice or issues you foresee?

Thanks,
Srini




From hartmans-ietf at MIT.EDU  Thu May 14 19:46:11 2009
From: hartmans-ietf at MIT.EDU (Sam Hartman)
Date: Thu, 14 May 2009 19:46:11 -0400
Subject: fast and patypes in KRB-ERROR
In-Reply-To: <1A136DCE57F98F4B8BAB5FFC69C8E6DA21E59BDCD7@exchange.cybersafe.local>
	(Srinivas Cheruku's message of "Thu\,
	14 May 2009 13\:35\:53 +0100")
References: <1A136DCE57F98F4B8BAB5FFC69C8E6DA21E59BDCD7@exchange.cybersafe.local>
Message-ID: <tslskj7w8n0.fsf@mit.edu>


[I think these points need to be considered in a broader context than just the MIT implementation.
I think I've included enough context.]

>>>>> "Srinivas" == Srinivas Cheruku <Srinivas.Cheruku at CyberSafe.com> writes:


    Srinivas> 2.  PA-FX-COOKIE (not sure why this is required ??
    Srinivas> anyway, I think MIT uses some dummy cookie)

Per discussion on the ietf-krb-wg list, a KDC confirming to the
pre-auth framework should include a cookie whenever it wants to
continue a conversation.  This should becomes a must if FAST is being
used.  I *think* that's in the current draft, but it is definitely in
my working copy.  Larry and I had some internal slowness; I'll be
publishing a new version quite shortly.

    Srinivas> I think it might be good to include
    Srinivas> PA-ENCRYPTED-CHALLENGE also when user principal requires
    Srinivas> pre-authentication.

    Srinivas> This would means that fast enabled kinit can do the
    Srinivas> following:

    Srinivas> 1.  kinit can send a non-fast request to KDC

    Srinivas> 2.  KDC replies with KRB-ERROR containing the above
    Srinivas> pa-types along with PA-ENCRYPTED-CHALLENGE (for user
    Srinivas> principals having pre-auth required set)

    Srinivas> 3.  kinit can check for PA-FX-FAST and
    Srinivas> PA-ENCRYPTED-CHALLENGE and send a fast request
    Srinivas> containing pa-enc-challenge padata.

    Srinivas> 4.  KDC sends tgt using FAST on successful
    Srinivas> authentication

    Srinivas> I know that MIT kinit doesn't support this behaviour but
    Srinivas> other vendors can support this.  Any advice or issues
    Srinivas> you foresee?

Probably this is more of an IETF issue than an MIT issue.  My concern
about doing this is that the negotiation of which fast factors are
supported would be unprotected.

Consider a client with the policy: * prefers fast with OTP, but will
fall back to FAST with encrypted challenge.

I think you have a relatively weak password, so it is in my interest
to get you to fall back to encrypted challenge.  I delete OTP from the
initial unprotected error.


From srinivas.cheruku at gmail.com  Fri May 15 00:08:45 2009
From: srinivas.cheruku at gmail.com (Srinivas Cheruku)
Date: Fri, 15 May 2009 09:38:45 +0530
Subject: [Ietf-krb-wg] fast and patypes in KRB-ERROR
In-Reply-To: <tslskj7w8n0.fsf@mit.edu>
References: <1A136DCE57F98F4B8BAB5FFC69C8E6DA21E59BDCD7@exchange.cybersafe.local>
	<tslskj7w8n0.fsf@mit.edu>
Message-ID: <4a0cead6.1c07d00a.192b.469b@mx.google.com>



    Srinivas> 2.  PA-FX-COOKIE (not sure why this is required ??
    Srinivas> anyway, I think MIT uses some dummy cookie)

Per discussion on the ietf-krb-wg list, a KDC confirming to the
pre-auth framework should include a cookie whenever it wants to
continue a conversation.  This should becomes a must if FAST is being
used. 

[Srinivas Cheruku] Yes, I understand that cookie is a must when FAST is used
to continue conversation. But why should it be included in a non-fast
initial request to KDC? Does this mean that FAST enabled KDC sends the
cookie always irrespective of the request uses FAST or not? For me, as the
request doesn't use FAST, there is no need of any cookie. 

 I *think* that's in the current draft, but it is definitely in
my working copy.  Larry and I had some internal slowness; I'll be
publishing a new version quite shortly.

[Srinivas Cheruku] ok

    Srinivas> I think it might be good to include
    Srinivas> PA-ENCRYPTED-CHALLENGE also when user principal requires
    Srinivas> pre-authentication.

    Srinivas> This would means that fast enabled kinit can do the
    Srinivas> following:

    Srinivas> 1.  kinit can send a non-fast request to KDC

    Srinivas> 2.  KDC replies with KRB-ERROR containing the above
    Srinivas> pa-types along with PA-ENCRYPTED-CHALLENGE (for user
    Srinivas> principals having pre-auth required set)

    Srinivas> 3.  kinit can check for PA-FX-FAST and
    Srinivas> PA-ENCRYPTED-CHALLENGE and send a fast request
    Srinivas> containing pa-enc-challenge padata.

    Srinivas> 4.  KDC sends tgt using FAST on successful
    Srinivas> authentication

    Srinivas> I know that MIT kinit doesn't support this behaviour but
    Srinivas> other vendors can support this.  Any advice or issues
    Srinivas> you foresee?

Probably this is more of an IETF issue than an MIT issue.  My concern
about doing this is that the negotiation of which fast factors are
supported would be unprotected.

[Srinivas Cheruku] yes, make sense.

Consider a client with the policy: * prefers fast with OTP, but will
fall back to FAST with encrypted challenge.

[Srinivas Cheruku] The client policy and the pre-auth to be used is not an
issue as KDC can send the respective pre-auth type e.g.
PA-ENCRYPTED-CHALLENGE or PA-OTP-CHALLENGE based on the client policy along
with PA-FX-FAST. But, I agree that the pre-auth negotiation with fast
factors would be unprotected.

I think you have a relatively weak password, so it is in my interest
to get you to fall back to encrypted challenge.  I delete OTP from the
initial unprotected error.

[Srinivas Cheruku] I think you meant if a eavesdropper changes the OTP
pre-auth in unprotected KRB-ERROR with PA-ENCRYPTED-CHALLENGE? If that is
the case, though enc-challenge is received by KDC it would again ask for OTP
fast factor.

Thanks,
Srini


From srinivas.cheruku at gmail.com  Fri May 15 03:01:05 2009
From: srinivas.cheruku at gmail.com (Srinivas Cheruku)
Date: Fri, 15 May 2009 12:31:05 +0530
Subject: [Ietf-krb-wg] fast and patypes in KRB-ERROR
In-Reply-To: <tslskj7w8n0.fsf@mit.edu>
References: <1A136DCE57F98F4B8BAB5FFC69C8E6DA21E59BDCD7@exchange.cybersafe.local>
	<tslskj7w8n0.fsf@mit.edu>
Message-ID: <4a0d133a.1701d00a.65de.ffff9802@mx.google.com>

Sam wrote:...
>Probably this is more of an IETF issue than an MIT issue.  My concern
>about doing this is that the negotiation of which fast factors are
>supported would be unprotected.

[Srinivas Cheruku] I was thinking on this more. 
What affect would it have if the negotiation of fast factors is not
protected? 
When non-fast request is sent to KDC, it returns KRB-ERROR e-data containing
PA-FX-FAST. This is also not protected PA-FX-FAST can also be deleted from
initial unprotected error. If this happens, the client would send non-fast
request containing enc-timestamp instead of generating a fast request. It
depends on the KDC policy to allow non-fast requests or not.

If we take the case of adding PA-ENCRYPTED-CHALLENGE or PA-OTP-CHALLENGE
along with PA-FX-FAST to unprotected error, then if these are deleted in
transit, then client maynot send OTP or ENC-CHALLENGE, but if the KDC is
configured so that the client requires these, then it won't generate the
ticket and would again asks for the same.

So, where do we see a potential risk of sending PA-ENCRYPTED-CHALLENGE or
PA-OTP-CHALLENGE along with PA-FX-FAST in unprotected error. Am I
overlooking something?

Thanks,
Srini




From hartmans at MIT.EDU  Sat May 16 09:01:03 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Sat, 16 May 2009 09:01:03 -0400 (EDT)
Subject: NFS breakage
Message-ID: <20090516130103.4850B426A@carter-zimmerman.suchdamage.org>



There h;as been additional useful traffic on debian bug #528514.
However I'm on personal travel this weekend and will not deal until probably tuesday or wednesday next week.

If soemone else got there sooner so we could issue beta3 that would
probably be in all of our best interest.

--Sam

From William.Fiveash at Sun.COM  Fri May 22 16:57:58 2009
From: William.Fiveash at Sun.COM (Will Fiveash)
Date: Fri, 22 May 2009 15:57:58 -0500
Subject: issue with MIT KDC and LDAP DS
Message-ID: <20090522205757.GA2250@sun.com>

I'm looking for input regarding my changing the following behavior of
the krb5kdc and kadmind.  Currently, when a KDC is configured to use the
LDAP KDB plugin and krbr5kdc is started prior to the DS being on-line,
the krb5kdc exits immediately with an error.  I want to change this
behavior so krb5kdc (and kadmind) stays up even when the DS is off-line.
The idea is that LDAP bind errors such as LDAP_SERVER_DOWN and
LDAP_CONNECT_ERROR would be treated as non-fatal in
krb5_ldap_initialize().  krb5kdc would daemonize itself as it normally
does but if there were no DS server connections up would try to bind
with a DS when it receives krb requests.  If it is unable to bind it
would send an error response to the *_REQ requester and wait for the
next request whereupon it would try to bind again.

The kadmind would behave similarly, sending back errors until it was
able to bind to the DS.

Thoughts?

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

From jhutz at cmu.edu  Fri May 22 18:04:51 2009
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Fri, 22 May 2009 18:04:51 -0400
Subject: issue with MIT KDC and LDAP DS
In-Reply-To: <200905222105.n4ML5t6P008160@mx02.srv.cs.cmu.edu>
References: <200905222105.n4ML5t6P008160@mx02.srv.cs.cmu.edu>
Message-ID: <FBE2FAE5329E5F4D20985485@atlantis.pc.cs.cmu.edu>

--On Friday, May 22, 2009 03:57:58 PM -0500 Will Fiveash 
<William.Fiveash at Sun.COM> wrote:

> I'm looking for input regarding my changing the following behavior of
> the krb5kdc and kadmind.  Currently, when a KDC is configured to use the
> LDAP KDB plugin and krbr5kdc is started prior to the DS being on-line,
> the krb5kdc exits immediately with an error.  I want to change this
> behavior so krb5kdc (and kadmind) stays up even when the DS is off-line.
> The idea is that LDAP bind errors such as LDAP_SERVER_DOWN and
> LDAP_CONNECT_ERROR would be treated as non-fatal in
> krb5_ldap_initialize().  krb5kdc would daemonize itself as it normally
> does but if there were no DS server connections up would try to bind
> with a DS when it receives krb requests.  If it is unable to bind it
> would send an error response to the *_REQ requester and wait for the
> next request whereupon it would try to bind again.
>
> The kadmind would behave similarly, sending back errors until it was
> able to bind to the DS.
>
> Thoughts?

This sounds good in general, but I'd make a couple of changes...

- Instead of attempting a bind when the KDC receives a request and
  doesn't currently have a connection, it should periodically try
  in the background, and simply fail immediately if it gets a request
  and there is no connection.  Otherwise, the KDC may take a long
  time to process each request, causing it to take much longer to
  process requests than clients are willing to wait, and falling
  behind (i.e starting to process a request when it is already very
  old).

- Instead of returning an error when there is no connection, the KDC
  should probably just drop the request on the floor.  This doesn't
  sound very friendly, but there is no other way to signal to clients
  that they should try another KDC.

-- Jeff

From ssorce at redhat.com  Fri May 22 18:35:16 2009
From: ssorce at redhat.com (Simo Sorce)
Date: Fri, 22 May 2009 18:35:16 -0400
Subject: issue with MIT KDC and LDAP DS
In-Reply-To: <FBE2FAE5329E5F4D20985485@atlantis.pc.cs.cmu.edu>
References: <200905222105.n4ML5t6P008160@mx02.srv.cs.cmu.edu>
	<FBE2FAE5329E5F4D20985485@atlantis.pc.cs.cmu.edu>
Message-ID: <1243031716.32121.27.camel@localhost.localdomain>

On Fri, 2009-05-22 at 18:04 -0400, Jeffrey Hutzelman wrote:
> --On Friday, May 22, 2009 03:57:58 PM -0500 Will Fiveash 
> <William.Fiveash at Sun.COM> wrote:
> 
> > I'm looking for input regarding my changing the following behavior of
> > the krb5kdc and kadmind.  Currently, when a KDC is configured to use the
> > LDAP KDB plugin and krbr5kdc is started prior to the DS being on-line,
> > the krb5kdc exits immediately with an error.  I want to change this
> > behavior so krb5kdc (and kadmind) stays up even when the DS is off-line.
> > The idea is that LDAP bind errors such as LDAP_SERVER_DOWN and
> > LDAP_CONNECT_ERROR would be treated as non-fatal in
> > krb5_ldap_initialize().  krb5kdc would daemonize itself as it normally
> > does but if there were no DS server connections up would try to bind
> > with a DS when it receives krb requests.  If it is unable to bind it
> > would send an error response to the *_REQ requester and wait for the
> > next request whereupon it would try to bind again.
> >
> > The kadmind would behave similarly, sending back errors until it was
> > able to bind to the DS.
> >
> > Thoughts?
> 
> This sounds good in general, but I'd make a couple of changes...
> 
> - Instead of attempting a bind when the KDC receives a request and
>   doesn't currently have a connection, it should periodically try
>   in the background, and simply fail immediately if it gets a request
>   and there is no connection.  Otherwise, the KDC may take a long
>   time to process each request, causing it to take much longer to
>   process requests than clients are willing to wait, and falling
>   behind (i.e starting to process a request when it is already very
>   old).
> 
> - Instead of returning an error when there is no connection, the KDC
>   should probably just drop the request on the floor.  This doesn't
>   sound very friendly, but there is no other way to signal to clients
>   that they should try another KDC.

Totally agree on both comments, and I'd love to see this implemented.

Simo.

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


From raeburn at MIT.EDU  Fri May 22 19:40:33 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Fri, 22 May 2009 19:40:33 -0400
Subject: issue with MIT KDC and LDAP DS
In-Reply-To: <FBE2FAE5329E5F4D20985485@atlantis.pc.cs.cmu.edu>
References: <200905222105.n4ML5t6P008160@mx02.srv.cs.cmu.edu>
	<FBE2FAE5329E5F4D20985485@atlantis.pc.cs.cmu.edu>
Message-ID: <333DEF6B-522D-4CF3-A465-F517DE8268E4@mit.edu>

On May 22, 2009, at 18:04, Jeffrey Hutzelman wrote:
> - Instead of attempting a bind when the KDC receives a request and
>  doesn't currently have a connection, it should periodically try
>  in the background, and simply fail immediately if it gets a request
>  and there is no connection.  Otherwise, the KDC may take a long
>  time to process each request, causing it to take much longer to
>  process requests than clients are willing to wait, and falling
>  behind (i.e starting to process a request when it is already very
>  old).

Doing things "in background" is a lot more complicated in a single- 
threaded process when the background task is defined entirely inside a  
plugin.  It may be a better way to do it in general, but Will's way is  
probably a lot simpler with the current code base.  And if the DS is  
on the same system, and running, the delay shouldn't be that large,  
and would only affect the very first request(s) received.

Longer term, the KDC does need work to allow more parallelism.  I'm  
not sure the database plugin API is a good place to add calls for  
doing processing of background tasks; I'd rather see it transparent to  
the main KDC code.  Several ideas that have been kicked around involve  
multiple threads or processes, and would allow, say, the LDAP database  
implementation to manage its own parallelism and background tasks  
without requiring hooks in the main KDC code.  If that sort of big  
restructuring project can be done, great!  I'd love to see it happen.

I'd add that it would be nice if a KDC connected to an LDAP server  
could detect that the server went down, too, and automatically try  
reconnecting, without needing to be prodded by Kerberos traffic to  
notice.  I'm not familiar enough with the LDAP APIs to know if that's  
practical.

> - Instead of returning an error when there is no connection, the KDC
>  should probably just drop the request on the floor.  This doesn't
>  sound very friendly, but there is no other way to signal to clients
>  that they should try another KDC.

Shouldn't KDC_ERR_SVC_UNAVAILABLE have that effect?  Sending that can  
let the client know to *immediately* try another KDC, instead of  
timing out.

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


From jhutz at cmu.edu  Fri May 22 19:59:41 2009
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Fri, 22 May 2009 19:59:41 -0400
Subject: issue with MIT KDC and LDAP DS
In-Reply-To: <200905222341.n4MNfQDV011074@mx01.srv.cs.cmu.edu>
References: <200905222105.n4ML5t6P008160@mx02.srv.cs.cmu.edu>
	<FBE2FAE5329E5F4D20985485@atlantis.pc.cs.cmu.edu>
	<200905222341.n4MNfQDV011074@mx01.srv.cs.cmu.edu>
Message-ID: <1A7EC08C0DEC51B7E2CFE275@atlantis.pc.cs.cmu.edu>

--On Friday, May 22, 2009 07:40:33 PM -0400 Ken Raeburn <raeburn at mit.edu> 
wrote:

> On May 22, 2009, at 18:04, Jeffrey Hutzelman wrote:
>> - Instead of attempting a bind when the KDC receives a request and
>>  doesn't currently have a connection, it should periodically try
>>  in the background, and simply fail immediately if it gets a request
>>  and there is no connection.  Otherwise, the KDC may take a long
>>  time to process each request, causing it to take much longer to
>>  process requests than clients are willing to wait, and falling
>>  behind (i.e starting to process a request when it is already very
>>  old).
>
> Doing things "in background" is a lot more complicated in a single-
> threaded process when the background task is defined entirely inside a
> plugin.  It may be a better way to do it in general, but Will's way is
> probably a lot simpler with the current code base.

True.  I don't know enough about the implementation to determine whether 
handling reconnection attempts without blocking request processing would be 
easy or hard, or whether it would require adding or modifying a plugin 
interface that you'd rather not deal with right now.

>> - Instead of returning an error when there is no connection, the KDC
>>  should probably just drop the request on the floor.  This doesn't
>>  sound very friendly, but there is no other way to signal to clients
>>  that they should try another KDC.
>
> Shouldn't KDC_ERR_SVC_UNAVAILABLE have that effect?  Sending that can
> let the client know to *immediately* try another KDC, instead of
> timing out.

Unfortunately, that error wasn't defined in RFC1510, and there are still 
clients deployed which don't behave that way, and which treat _any_ error 
response from a KDC as that realm's final word on the request 
(particularly, any response at all from a KDC is enough to escape 
send_to_kdc).  For example, I don't know if current versions of Heimdal 
handle this correctly, but I know we have clients deployed that do not.

-- Jeff

From raeburn at MIT.EDU  Fri May 22 20:12:38 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Fri, 22 May 2009 20:12:38 -0400
Subject: issue with MIT KDC and LDAP DS
In-Reply-To: <1A7EC08C0DEC51B7E2CFE275@atlantis.pc.cs.cmu.edu>
References: <200905222105.n4ML5t6P008160@mx02.srv.cs.cmu.edu>
	<FBE2FAE5329E5F4D20985485@atlantis.pc.cs.cmu.edu>
	<200905222341.n4MNfQDV011074@mx01.srv.cs.cmu.edu>
	<1A7EC08C0DEC51B7E2CFE275@atlantis.pc.cs.cmu.edu>
Message-ID: <8D723554-3582-473D-937E-18148C4053DD@mit.edu>

On May 22, 2009, at 19:59, Jeffrey Hutzelman wrote:
>>> - Instead of returning an error when there is no connection, the KDC
>>> should probably just drop the request on the floor.  This doesn't
>>> sound very friendly, but there is no other way to signal to clients
>>> that they should try another KDC.
>>
>> Shouldn't KDC_ERR_SVC_UNAVAILABLE have that effect?  Sending that can
>> let the client know to *immediately* try another KDC, instead of
>> timing out.
>
> Unfortunately, that error wasn't defined in RFC1510, and there are  
> still clients deployed which don't behave that way, and which treat  
> _any_ error response from a KDC as that realm's final word on the  
> request (particularly, any response at all from a KDC is enough to  
> escape send_to_kdc).  For example, I don't know if current versions  
> of Heimdal handle this correctly, but I know we have clients  
> deployed that do not.

According to http://kbalertz.com/962994/Windows-Server-domain-controllers-return-incorrect-error-Kerberos-requests-during-shutdown-process.aspx 
  the W2003SP2 KDC can return that error code now; presumably more  
recent versions can too.  So if the clients can't cope with it,  
they're going to have problems with more than just these potential  
future MIT KDCs.

(And, having the KDC return this when the LDAP server is unavailable  
is already an item in our bug database, #5715.)

It is a backwards-incompatible protocol change (if you consider "stop  
sending queries after any response" to be part of the original  
protocol), but it's already deployed, some time ago.

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


From jhutz at cmu.edu  Fri May 22 20:31:55 2009
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Fri, 22 May 2009 20:31:55 -0400
Subject: issue with MIT KDC and LDAP DS
In-Reply-To: <200905230012.n4N0CgHv014918@mx01.srv.cs.cmu.edu>
References: <200905222105.n4ML5t6P008160@mx02.srv.cs.cmu.edu>
	<FBE2FAE5329E5F4D20985485@atlantis.pc.cs.cmu.edu>
	<200905222341.n4MNfQDV011074@mx01.srv.cs.cmu.edu>
	<1A7EC08C0DEC51B7E2CFE275@atlantis.pc.cs.cmu.edu>
	<200905230012.n4N0CgHv014918@mx01.srv.cs.cmu.edu>
Message-ID: <DFA009B0D20DCB7CE73EE7A6@atlantis.pc.cs.cmu.edu>

--On Friday, May 22, 2009 08:12:38 PM -0400 Ken Raeburn <raeburn at MIT.EDU> 
wrote:

> It is a backwards-incompatible protocol change (if you consider "stop
> sending queries after any response" to be part of the original protocol),
> but it's already deployed, some time ago.

I don't, particularly, but the original protocol didn't provide any way to 
signal to a client that it should try another KDC, and dropping the request 
on the floor works.

-- Jeff

From ssorce at redhat.com  Sat May 23 10:12:03 2009
From: ssorce at redhat.com (Simo Sorce)
Date: Sat, 23 May 2009 10:12:03 -0400
Subject: issue with MIT KDC and LDAP DS
In-Reply-To: <DFA009B0D20DCB7CE73EE7A6@atlantis.pc.cs.cmu.edu>
References: <200905222105.n4ML5t6P008160@mx02.srv.cs.cmu.edu>
	<FBE2FAE5329E5F4D20985485@atlantis.pc.cs.cmu.edu>
	<200905222341.n4MNfQDV011074@mx01.srv.cs.cmu.edu>
	<1A7EC08C0DEC51B7E2CFE275@atlantis.pc.cs.cmu.edu>
	<200905230012.n4N0CgHv014918@mx01.srv.cs.cmu.edu>
	<DFA009B0D20DCB7CE73EE7A6@atlantis.pc.cs.cmu.edu>
Message-ID: <1243087923.3555.7.camel@localhost.localdomain>

On Fri, 2009-05-22 at 20:31 -0400, Jeffrey Hutzelman wrote:
> --On Friday, May 22, 2009 08:12:38 PM -0400 Ken Raeburn <raeburn at MIT.EDU> 
> wrote:
> 
> > It is a backwards-incompatible protocol change (if you consider "stop
> > sending queries after any response" to be part of the original protocol),
> > but it's already deployed, some time ago.
> 
> I don't, particularly, but the original protocol didn't provide any way to 
> signal to a client that it should try another KDC, and dropping the request 
> on the floor works.

Maybe an option in kdc.conf can be offered for backwards compatibility
with old clients, if an organization still have such ancient code
around, and let modern clients get a better reply.

Simo.

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


From ssorce at redhat.com  Sat May 23 10:17:42 2009
From: ssorce at redhat.com (Simo Sorce)
Date: Sat, 23 May 2009 10:17:42 -0400
Subject: issue with MIT KDC and LDAP DS
In-Reply-To: <333DEF6B-522D-4CF3-A465-F517DE8268E4@mit.edu>
References: <200905222105.n4ML5t6P008160@mx02.srv.cs.cmu.edu>
	<FBE2FAE5329E5F4D20985485@atlantis.pc.cs.cmu.edu>
	<333DEF6B-522D-4CF3-A465-F517DE8268E4@mit.edu>
Message-ID: <1243088262.3555.13.camel@localhost.localdomain>

On Fri, 2009-05-22 at 19:40 -0400, Ken Raeburn wrote:
> 
> Doing things "in background" is a lot more complicated in a single- 
> threaded process when the background task is defined entirely inside
> a  
> plugin.  It may be a better way to do it in general, but Will's way
> is  
> probably a lot simpler with the current code base.  And if the DS is  
> on the same system, and running, the delay shouldn't be that large,  
> and would only affect the very first request(s) received.

It depends on many factors, but it's probably ok for a first
implementation to just wait for a request.
However the driver could try to spawn a simple, very specialized thread,
just for handling the reconnection. With a big mutex around that code.

[..]
> I'd rather see it transparent to the main KDC code.

That would certainly be a good idea.

>   Several ideas that have been kicked around involve  
> multiple threads or processes, and would allow, say, the LDAP
> database  
> implementation to manage its own parallelism and background tasks  
> without requiring hooks in the main KDC code.  If that sort of big  
> restructuring project can be done, great!  I'd love to see it happen.

What need to happen to have it done ?

> I'd add that it would be nice if a KDC connected to an LDAP server  
> could detect that the server went down, too, and automatically try  
> reconnecting, without needing to be prodded by Kerberos traffic to  
> notice.  I'm not familiar enough with the LDAP APIs to know if
> that's  
> practical.

If you have a main loop you can get the same sort of notification you
get when any socket is close from the other side. (A reconnection thread
could easily do that)

Simo.

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


From raeburn at MIT.EDU  Sat May 23 17:45:21 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Sat, 23 May 2009 17:45:21 -0400
Subject: issue with MIT KDC and LDAP DS
In-Reply-To: <1243088262.3555.13.camel@localhost.localdomain>
References: <200905222105.n4ML5t6P008160@mx02.srv.cs.cmu.edu>
	<FBE2FAE5329E5F4D20985485@atlantis.pc.cs.cmu.edu>
	<333DEF6B-522D-4CF3-A465-F517DE8268E4@mit.edu>
	<1243088262.3555.13.camel@localhost.localdomain>
Message-ID: <2E43D8C8-2B11-4AB7-81F0-D002DF2E9177@mit.edu>

(Apologies for the length of this message... as the saying goes, I  
don't have time to write a shorter one.)

On May 23, 2009, at 10:17, Simo Sorce wrote:
>>  Several ideas that have been kicked around involve
>> multiple threads or processes, and would allow, say, the LDAP
>> database
>> implementation to manage its own parallelism and background tasks
>> without requiring hooks in the main KDC code.  If that sort of big
>> restructuring project can be done, great!  I'd love to see it happen.
>
> What need to happen to have it done ?

Some requirements and design discussions, first. :-)  Several ideas  
have been kicked around, including:
  * multithreaded KDC (e.g., http://mailman.mit.edu/pipermail/krbdev/2005-March/003237.html 
; Novell has donated some code, but changing single-threaded security- 
sensitive code to be multithreaded makes some people nervous)
  * multiprocess KDC split by functionality (e.g., main KDC process  
talks to a database-access process, each made smaller and easier to  
analyze, and independently we can assess whether each can safely be  
made multithreaded or should use async APIs or whatever)
  * multiprocess KDC running several independent instances in parallel  
(relatively simple and quick to code: fork after opening sockets,  
(re)open database connections after forking, let multiple processes  
all grab for any available network traffic detected; this leads to  
contention and wasted cycles, but only when more than one process is  
idle; it also may not balance load well in certain circumstances)
  * change DAL to support issuing query without blocking, getting  
result later via callback
  * make database back ends use async APIs for fetching data
  * break KDC functionality into one or more library modules that can  
be invoked in new ways (e.g., inetd-launched KDC) or integrated into  
another process
  * rewrite KDC as well as library to be friendlier to techniques such  
as Apple's Grand Central and similar technologies, but without being  
platform-dependent (okay, rewriting the KDC like this hasn't actually  
gotten a lot of discussion that I've seen, but I expect it would  
eventually come up)

Some of these changes would be relatively easy to implement by  
themselves, in one shot or in a few steps, but they can interact in  
bad ways, so we should have a plan for where we're going.

So far as I've seen, no one has pulled together a requirements list  
for restructuring the KDC.  I could throw out some mostly obvious  
ideas, but as of when I left the Consortium, I think we'd talked to  
various sponsors and potential sponsors about some ideas but hadn't  
really assessed which were the most crucial, and hadn't talked to  
everyone who might have an interest.  So ideas need to be collected  
and evaluated.  It also would help to better understand the needs of  
the various different target environments where the KDC would be used  
-- normal standalone realm KDCs; Samba and IPA environments;  
eDirectory environments.  Mobile/embedded KDCs?  (Maybe a KDC running  
in one of those little Linux server wall-warts, just configure it and  
plug it in in a locked closet.  On a cell phone or PDA?)  Cable system  
head ends?  Tamper-proof cards in computers deployed in insecure venues?

This list is a bit haphazard, but maybe it can help somebody get  
started.

  * more efficient use of multicore systems under heavy load (not the  
top priority, as we rarely hear that CPU time is an issue)
  * don't block one request because processing an earlier request is  
blocking on some external factor; answer KDC requests out of order
    * DB (LDAP) access is just one example
    * PKCROSS would involve having the KDC wait on additional external  
traffic
    * principal alias processing rules could theoretically do DNSSec  
queries
    * recognize if a request duplicates one we already received but  
not answered, and avoid duplicating work and traffic when possible  
(unimportant now but more important if LDAP/PKCROSS/whatever delays  
increase the likelihood of such events; I think Novell's patch deals  
with this by extending the lookaside cache)
    * theoretically, any plugin hook could block, including preauth  
and authz-data mechanisms
    * network reconfiguration could result in a socket being shut down  
while we're still preparing to send out a response through it, if  
we're not careful
  * Should we cache DB results for performance?  If so, at the KDC  
level or buried in the DB layer and transparent to the KDC main code?
  * minimal or zero CPU use in idle state (e.g., no frequent polling  
at application level to make sure LDAP connection is still up, though  
TCP keepalives may be okay, and one-shot timers such as for shutting  
down extra worker processes are probably okay)
  * fast response to clients when possible
  * survive various DoS attack cases reasonably
    * don't crash; be available shortly after attack stops, if not  
immediately after or even during attack
    * reduce backscatter from forged-source traffic? TCP helps
    * don't chew up resources (memory, process slots) without bound?
  * programmable configuration of some functionality
    * current plugins (make list)
    * extended 1.7 DAL operations and flags (make list), moving  
towards general "infrastructure" interface
      * still support various extensions without requiring one massive  
integrated "database" back end?
    * pluggable logging? e.g., log to database for later intrusion- 
detection analysis; if serious auditing requirements exist, such that  
the KDC is not permitted to issue unlogged credentials, errors in  
logging may also need to be able to force errors up the call chain
    * scriptable extensions (e.g., for describing rules for principal  
alias processing or PKINIT mapping)? easier for sysadmins who are not  
experienced C programmers; can one script define multiple plugin  
functions that share data?
    * notify on startup/shutdown hooks -- advertise via mDNS, DDNS,  
anycast routing, whatever
    * may want a way to feed data into a plugin through external means  
(e.g., updated file with alias mappings, or new DNS zone file to parse  
and derive mappings from); how to get its attention vs requiring it to  
call stat() a lot?
    * what else?
  * code clarity, cleanliness, documentation (no, really),  
maintainability
  * security - probably most important; worth jumping through some  
hoops for making buffer overruns impossible, sandboxing, whatever
  * ease of security analysis - could be helped by breaking code into  
well-separated modules, and not sharing address space; also by using  
privilege separation, internal interfaces well suited for static  
analysis tools, and other security practices
  * don't require DB accessibility at startup, per Will F? (but, if  
db2 database is missing, maybe we want to error out at startup?  maybe  
ldap server unavailability should be a "temp fail" condition and we  
continue?  server available but realm data non-existent would probably  
be hard fail.)
  * support multiple realms in one KDC process, possibly with  
different configurations (e.g., LDAP vs DB2, different port numbers  
advertised); OR, explicitly don't support it any more and reject the  
command-line options
  * flexibility in network setup
    * current code listens on all local addresses (separately or via  
PKTINFO options), reconfiguring itself at run time if needed when  
addresses are added or removed
    * inetd "wait"-type service for UDP or TCP
    * forking for multiprocessing would mess with the auto- 
reconfiguration
    * have had request to specify subset of local IP addresses
    * KDC, kadmin, kpasswd services should all use similar mechanism/ 
code and parallel config file/command line specs (if not the same  
ones), as much as practical (e.g., kadmin is IPv4-only for now in MIT  
code but that may be fixed later so options should allow for that)
    * need we worry about kprop at the same time? probably not
  * programming environment: Is it unreasonable to consider careful  
use of C++ or Python for some pieces of the code, or are we stuck with  
C and the dangers and annoyances that come with it?  (For krb5 library  
code, C++ still seems like a bad idea, but for non-library code like  
the server programs, some of the issues don't apply.)
  * integrate into another server process?
    * would probably want to supply plugins programmatically instead  
of requiring the loading of external shared objects
    * would probably want to control options programmatically rather  
than having to write out a config file
    * embedded KDC might work this way, if not dealing with embedded  
Linux or *BSD, or even then in an effort to reduce process count and  
memory footprint
    * might need to hand main-event-loop control over to other code
    * has security implications that should be well documented, but  
don't automatically make it a bad idea
    * "KDC library" idea probably shouldn't involve a public/stable  
API until we can shake out bugs
  * record/report statistics for monitoring? multiprocess approaches  
make this trickier, coordination needed
  * any hooks desired for intrusion detection?
  * fast and easy restart, in case of problems/bugs or changes in  
configuration options only checked at startup; this implies clean and  
quick shutdown of network so we can rebind the ports right away
  * peak load requirements? e.g., at start of work day or after power  
outage

We've talked a little, and I've talked with Don Davis a little, but I  
don't know in great detail what your requirements (and nice-to-have  
list) look like. Nor am I all that sure about what other environments  
with unusual requirements (resource, performance, security, legal) the  
KDC might get used in.  That data should be gathered.

Once we can evaluate requirements, maybe some of the possible  
approaches can be selected, or ruled out.  E.g., my simple fork-after- 
startup idea doesn't keep the load down as well under light usage,  
doesn't minimize memory use or achieve privilege separation, and  
doesn't allow for detecting that multiple identical requests are being  
processed at once and could be optimized.  So in the long term it's  
probably not the way to go.  But it could be a short path to taking  
advantage of multiple CPU cores, if that's useful now.  And if we move  
to a clean "KDC library" interface, the fork-after-startup bit would  
probably have become just a couple dozen lines of code that would be  
easy to rip out when more efficient multi-process code was available.

Many of these items will probably become minor implementation notes  
once a direction is chosen.  But we need to keep some of them in mind  
so we don't accidentally choose a direction that makes some of them  
very hard.

Tom has also been talking about redesigning the database and its  
interface, for various reasons.  The existing arrangement operates in  
old DBM mode -- here's a key and a blob of data, and the KDC code  
knows how to parse and assemble the data.  That doesn't let anyone run  
independent tools over the database very effectively, nor can we ask  
for only the subset of data we actually need.  The LDAP back end makes  
it a bit easier, because it knows how to store some of the KDC data in  
special fields, but a lot of that is buried in the LDAP back end code  
that just mirrors some of the code elsewhere.  It would be nice to  
take that further, and use, for example, sqlite3 or mysql (or one of  
these under odbc) as a database interface, with multiple tables and  
all that fun stuff, and only retrieve the data we really need, but  
that means having a more clearly defined and stable set of fields.  It  
would also provide an opportunity to change how some things are  
stored, so that for example hardware preauth schemes to use with a  
particular principal aren't flagged by the existence of a secondary  
principal in the database, with no keys and no purpose other than to  
exist as a flag.  And Luke's extension of the DAL to add things that  
are not necessarily Kerberos-database items makes it clear that our  
current plugin hooks are not sufficient for some sites' needs.

It's largely a separate project from changing the KDC startup and  
network handling and parallelism and such, but again, if assumptions  
are made on one side and violated on the other, we could hurt  
ourselves, especially in such areas as forking or multithreading, or  
in this case, not coordinating changes in the DAL interface.

>> I'd add that it would be nice if a KDC connected to an LDAP server
>> could detect that the server went down, too, and automatically try
>> reconnecting, without needing to be prodded by Kerberos traffic to
>> notice.  I'm not familiar enough with the LDAP APIs to know if
>> that's
>> practical.
>
> If you have a main loop you can get the same sort of notification you
> get when any socket is close from the other side. (A reconnection  
> thread
> could easily do that)

I may have overlooked something, but as best I recall in the OpenLDAP  
API there wasn't a good way to get a handle on all the sockets that  
might be in use (maybe you could get one? but at least in theory more  
than one could be in use), and so you really needed to be in OpenLDAP  
library routines to notice, which is kind of at odds with having the  
main loop be in the KDC code.  We could cheat and only look at one  
file descriptor (if I recall correctly and we can get one fd number  
out), and if some other one is also in use and gets disconnected, oh  
well, we don't notice that until we try to use it... but we'd still  
need some sort of event notification callback added to the DAL  
interface.

At the time, I was more interested in asynchronous LDAP queries, where  
one thread could process both LDAP traffic and KDC database lookup  
requests.  I didn't see a way to guarantee that I knew about all the  
file descriptors in use by the LDAP library (so I could select on all  
of those plus one used to signal pending DB requests); you really  
seemed to need to turn control over to the LDAP library.

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


From ghudson at MIT.EDU  Sun May 24 11:25:36 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Sun, 24 May 2009 11:25:36 -0400
Subject: issue with MIT KDC and LDAP DS
In-Reply-To: <1A7EC08C0DEC51B7E2CFE275@atlantis.pc.cs.cmu.edu>
References: <200905222105.n4ML5t6P008160@mx02.srv.cs.cmu.edu>
	<FBE2FAE5329E5F4D20985485@atlantis.pc.cs.cmu.edu>
	<200905222341.n4MNfQDV011074@mx01.srv.cs.cmu.edu>
	<1A7EC08C0DEC51B7E2CFE275@atlantis.pc.cs.cmu.edu>
Message-ID: <1243178736.4146.107.camel@ray>

On Fri, 2009-05-22 at 19:59 -0400, Jeffrey Hutzelman wrote:
> Unfortunately, that error wasn't defined in RFC1510, and there are still 
> clients deployed which don't behave that way, and which treat _any_ error 
> response from a KDC as that realm's final word on the request 
> (particularly, any response at all from a KDC is enough to escape 
> send_to_kdc).  For example, I don't know if current versions of Heimdal 
> handle this correctly, but I know we have clients deployed that do not.

Just a factual note: from inspection of the Heimdal source code, it has
apparently handled KDC_ERR_SVC_UNAVAILABLE since June 2007 on the trunk,
slightly predating the 1.0 release branch.



From hartmans at MIT.EDU  Mon May 25 10:09:26 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Mon, 25 May 2009 10:09:26 -0400
Subject: issue with MIT KDC and LDAP DS
In-Reply-To: <1243178736.4146.107.camel@ray> (Greg Hudson's message of "Sun\,
	24 May 2009 11\:25\:36 -0400")
References: <200905222105.n4ML5t6P008160@mx02.srv.cs.cmu.edu>
	<FBE2FAE5329E5F4D20985485@atlantis.pc.cs.cmu.edu>
	<200905222341.n4MNfQDV011074@mx01.srv.cs.cmu.edu>
	<1A7EC08C0DEC51B7E2CFE275@atlantis.pc.cs.cmu.edu>
	<1243178736.4146.107.camel@ray>
Message-ID: <tslhbz9xoix.fsf@mit.edu>

I think this sounds like a good idea.
I'd like to specifically call for a project write-up though, covering

1) background vs per connection
2) error return vs dropping requests

3) ;How we rate limit attempts to connect to the LDAP server

4) How we turn likely configuration failures such as LDAP is up but we
cannot authenticate into hard initial failures while preserving this
behavior for LDAP is down.

My personal vote on the error vs hard fail is to go with svc_unavail.

From elric at imrryr.org  Tue May 26 16:35:59 2009
From: elric at imrryr.org (Roland Dowdeswell)
Date: Tue, 26 May 2009 16:35:59 -0400
Subject: issue with MIT KDC and LDAP DS 
In-Reply-To: Your message of "Sat, 23 May 2009 17:45:21 EDT."
	<2E43D8C8-2B11-4AB7-81F0-D002DF2E9177@mit.edu> 
Message-ID: <20090526203559.248B03813C@arioch.imrryr.org>

On 1243115121 seconds since the Beginning of the UNIX epoch
Ken Raeburn wrote:
>

>  * multiprocess KDC running several independent instances in parallel  
>(relatively simple and quick to code: fork after opening sockets,  
>(re)open database connections after forking, let multiple processes  
>all grab for any available network traffic detected; this leads to  
>contention and wasted cycles, but only when more than one process is  
>idle; it also may not balance load well in certain circumstances)

I submitted a patch to RT to add an inetd mode to the KDC.  If you
use that mode, then you can trivially write a parent that performs
the bind logic and spawns off a number of children.  This would
have the added benefit of providing a parent process that could
restart kids if they crash.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/

From tlyu at MIT.EDU  Tue May 26 18:40:59 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Tue, 26 May 2009 18:40:59 -0400
Subject: krb5-1.7-beta3 is available
Message-ID: <ldvmy8zbi84.fsf@cathode-dark-space.mit.edu>

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

MIT krb5-1.7-beta3 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 week.  We expect
to release around June 1.  Changes since krb5-1.7-beta2 are:

+6486    t_pac fails on SPARC Solaris
+6488    NFS fails to work with KRB5 1.7
+6489    UCS2 support doesn't handle upper half of BMP
+6490    Windows interop with RC4 TGS-REQ subkeys
+6492    Remove spurious assertion in handle_authdata
+6493    some fixes for 1.7
+6495    Fix test rules for non-gmake make versions
+6496    Fix vector initialization error in KDC preauth code
+6497    kinit/fast usage message
+6498    spnego_mech.c syntax error under _GSS_STATIC_LINK
+6499    use printf format attribute only with gcc
+6500    use correct type for krb5_c_prf_length length arg
+6501    Temporarily disable FAST PKINIT for 1.7 release
+6502    typo in doc/api/krb5.tex
+6503    typo in admin.texinfo

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 "true", but may default to "false" 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.
  Currently, only the LDAP back end supports aliases.

* 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 and KDC support for GSS_C_DELEG_POLICY_FLAG, which
  allows a GSS application to request credential delegation only if
  permitted by KDC policy.

* 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)

iEYEARECAAYFAkoccBIACgkQSO8fWy4vZo56qgCg9iUucRGy0xU1f/SZ2quzNlHg
nKYAoN74v7/i2fjxYohfVpaW6kKGYkXS
=NbMA
-----END PGP SIGNATURE-----

From raeburn at MIT.EDU  Tue May 26 19:17:19 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Tue, 26 May 2009 19:17:19 -0400
Subject: issue with MIT KDC and LDAP DS
In-Reply-To: <20090522205757.GA2250@sun.com>
References: <20090522205757.GA2250@sun.com>
Message-ID: <8AC57446-E5EB-4671-AB65-C0BF388AC2E2@mit.edu>

BTW, getting back on track with Will's idea:

As originally stated, I think it's a good idea and an improvement over  
the current status, and should be implemented.  Minor points: We might  
want the option for the KDC to be silent instead of returning an  
error.  And, as I mentioned in a paragraph buried in the middle of my  
Saturday ramblings^H^H^H^H^H^H^H^H^Hemail, LDAP server unavailability  
might be a "tempfail" situation, but I think we still want hard  
failures (i.e., KDC errors out) for cases like the DB2 database not  
existing, or the LDAP server being available but the KDB data not  
being there.

Improvements like the "background" reconnection Jeff suggests would  
also be good but can wait for later, and possibly be examined in a  
larger-scale redesign.

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


From raeburn at MIT.EDU  Tue May 26 19:20:29 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Tue, 26 May 2009 19:20:29 -0400
Subject: issue with MIT KDC and LDAP DS 
In-Reply-To: <20090526203559.248B03813C@arioch.imrryr.org>
References: <20090526203559.248B03813C@arioch.imrryr.org>
Message-ID: <0100A839-D2A4-49F5-B236-EFF509ED01FF@MIT.EDU>

On May 26, 2009, at 16:35, Roland Dowdeswell wrote:
> I submitted a patch to RT to add an inetd mode to the KDC.  If you
> use that mode, then you can trivially write a parent that performs
> the bind logic and spawns off a number of children.  This would
> have the added benefit of providing a parent process that could
> restart kids if they crash.

Yes, I knew I'd seen it recently; I'm sorry I didn't remember it was  
yours while I was writing that email and trying (pretty  
unsuccessfully) to get done quickly and go do something else. :-)   
I've looked it over a couple times briefly, and the concept and code  
look good to me, though I haven't tested it myself.  If anyone is  
interested in taking a look at the code, it's ticket 6476.  Note that  
network.c is largely duplicated between the KDC and kadmind in 1.7,  
and the two versions probably should be merged, though it may take a  
little more work to make this functionality apply to RPC services.

Ken

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


From srinivas.cheruku at gmail.com  Wed May 27 05:02:09 2009
From: srinivas.cheruku at gmail.com (Srinivas Cheruku)
Date: Wed, 27 May 2009 14:32:09 +0530
Subject: How to use FAST in TGS requests
Message-ID: <4a1d01b2.095c5e0a.4936.1efa@mx.google.com>

Hi,

 

How can I use client code to get service ticket using FAST?

I tried using ftp client as it gets service tickets, but from the network
trace it didn't use FAST.

 

Thanks,
Srini


From ghudson at MIT.EDU  Wed May 27 12:24:17 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Wed, 27 May 2009 12:24:17 -0400
Subject: How to use FAST in TGS requests
In-Reply-To: <4a1d01b2.095c5e0a.4936.1efa@mx.google.com>
References: <4a1d01b2.095c5e0a.4936.1efa@mx.google.com>
Message-ID: <1243441457.4146.309.camel@ray>

On Wed, 2009-05-27 at 14:32 +0530, Srinivas Cheruku wrote:
> How can I use client code to get service ticket using FAST?

My understanding is that we have not implemented FAST for TGS-REQs yet.
(We did implement using a subkey for TGS-REQs as an intermediate step,
which uncovered four different interoperability problems in three
different Kerberos implementations.)



From hartmans at MIT.EDU  Wed May 27 12:41:26 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 27 May 2009 12:41:26 -0400
Subject: How to use FAST in TGS requests
In-Reply-To: <1243441457.4146.309.camel@ray> (Greg Hudson's message of "Wed\,
	27 May 2009 12\:24\:17 -0400")
References: <4a1d01b2.095c5e0a.4936.1efa@mx.google.com>
	<1243441457.4146.309.camel@ray>
Message-ID: <tslab4ypkg9.fsf@mit.edu>

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

    Greg> On Wed, 2009-05-27 at 14:32 +0530, Srinivas Cheruku wrote:
    >> How can I use client code to get service ticket using FAST?

    Greg> My understanding is that we have not implemented FAST for
    Greg> TGS-REQs yet.  (We did implement using a subkey for TGS-REQs
    Greg> as an intermediate step, which uncovered four different
    Greg> interoperability problems in three different Kerberos
    Greg> implementations.)

I have an implementation of FAST TGS requests that was used during
interop testing.  I believe that the KDC on the trunk supports FAST
TGS correctly; it works against my implementation and against another
vendor's implementation.

I have not checked in the FAST TGS client side changes for two
reasons.  First, as currently written, it breaks interop with non-FAST
KDCs.  Secondly, there was some discussion of when we want to try FAST
with the TGS.  I think it would be fine to experiment with that for
the 1.8 release, but I felt that it was very late in the 1.7 process
to make that decision.

My implementation is not currently public.

--Sam

From William.Fiveash at Sun.COM  Wed May 27 14:19:11 2009
From: William.Fiveash at Sun.COM (Will Fiveash)
Date: Wed, 27 May 2009 13:19:11 -0500
Subject: issue with MIT KDC and LDAP DS
In-Reply-To: <8AC57446-E5EB-4671-AB65-C0BF388AC2E2@mit.edu>
References: <20090522205757.GA2250@sun.com>
	<8AC57446-E5EB-4671-AB65-C0BF388AC2E2@mit.edu>
Message-ID: <20090527181911.GC12597@sun.com>

On Tue, May 26, 2009 at 07:17:19PM -0400, Ken Raeburn wrote:
> BTW, getting back on track with Will's idea:
> 
> As originally stated, I think it's a good idea and an improvement over  
> the current status, and should be implemented.  Minor points: We might  
> want the option for the KDC to be silent instead of returning an  
> error.  And, as I mentioned in a paragraph buried in the middle of my  
> Saturday ramblings^H^H^H^H^H^H^H^H^Hemail, LDAP server unavailability  
> might be a "tempfail" situation, but I think we still want hard  
> failures (i.e., KDC errors out) for cases like the DB2 database not  
> existing, or the LDAP server being available but the KDB data not  
> being there.

A question regarding fundamental krb5kdc behavior; which of the
following do people consider preferable behavior?

1. The krb5kdc exits when it encounters an error accessing the KDB thus
   clients that send it krb requests via UDP then rely on timeouts to
   indicate it should fall back to trying other KDCs.

2. The krb5kdc stays up when it encounters an error accessing the KDB
   and sends clients KDC_ERR_SVC_UNAVAILABLE immediately when receiving
   krb requests.  If the client handles KDC_ERR_SVC_UNAVAILABLE it
   can immediately try other KDCs.

I think consensus on this will influence the fundamental approach to
modifying the KDC daemons to deal with KDB access errors.

And to your point about DAL errors, I was also thinking that the DAL
open function could return fatal and non-fatal errors and the
krb5kdc/kadmind code could be modified to deal with non-fatal errors
(stay up, log the error, have state that indicates initialization is not
complete, etc...).

> Improvements like the "background" reconnection Jeff suggests would  
> also be good but can wait for later, and possibly be examined in a  
> larger-scale redesign.

Agreed.

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

From jhutz at cmu.edu  Wed May 27 16:19:27 2009
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Wed, 27 May 2009 16:19:27 -0400
Subject: issue with MIT KDC and LDAP DS
In-Reply-To: <15511_1243448825_n4RIR5sm029586_20090527181911.GC12597@sun.com>
References: <20090522205757.GA2250@sun.com>
	<8AC57446-E5EB-4671-AB65-C0BF388AC2E2@mit.edu>
	<15511_1243448825_n4RIR5sm029586_20090527181911.GC12597@sun.com>
Message-ID: <F14563DF343AAA5742E34B81@atlantis.pc.cs.cmu.edu>

--On Wednesday, May 27, 2009 01:19:11 PM -0500 Will Fiveash 
<William.Fiveash at Sun.COM> wrote:

> On Tue, May 26, 2009 at 07:17:19PM -0400, Ken Raeburn wrote:
>> BTW, getting back on track with Will's idea:
>>
>> As originally stated, I think it's a good idea and an improvement over
>> the current status, and should be implemented.  Minor points: We might
>> want the option for the KDC to be silent instead of returning an
>> error.  And, as I mentioned in a paragraph buried in the middle of my
>> Saturday ramblings^H^H^H^H^H^H^H^H^Hemail, LDAP server unavailability
>> might be a "tempfail" situation, but I think we still want hard
>> failures (i.e., KDC errors out) for cases like the DB2 database not
>> existing, or the LDAP server being available but the KDB data not
>> being there.
>
> A question regarding fundamental krb5kdc behavior; which of the
> following do people consider preferable behavior?
>
> 1. The krb5kdc exits when it encounters an error accessing the KDB thus
>    clients that send it krb requests via UDP then rely on timeouts to
>    indicate it should fall back to trying other KDCs.
>
> 2. The krb5kdc stays up when it encounters an error accessing the KDB
>    and sends clients KDC_ERR_SVC_UNAVAILABLE immediately when receiving
>    krb requests.  If the client handles KDC_ERR_SVC_UNAVAILABLE it
>    can immediately try other KDCs.
>
> I think consensus on this will influence the fundamental approach to
> modifying the KDC daemons to deal with KDB access errors.

If the KDB is unavailable, but might become available, for example because 
it is stored in some database service that is currently down or 
unreachable, then the KDC should report failures to clients so they can try 
other KDC's.  Similarly if the KDC is temporarily unable to provide service 
for other reasons, such as the master key living on a hardware token that 
is currently unavailable (as a variation on that, my KDC's require someone 
to show up with a hardware token to decrypt the master key, which is then 
kept in memory).  In fact, in general this approach should apply to 
temporary conditions that may appear and disappear after the KDC has 
started.

If the KDC is misconfigured and cannot possibly function correctly without 
the intervention of an administrator, then it should simply fail to start. 
This is consistent with what administrators expect of other services, and 
allows startup scripts to report failure of the KDC to start, instead of 
reporting that it started successfully when in fact it cannot possibly 
provide service.

-- Jeff

From ghudson at MIT.EDU  Wed May 27 16:36:01 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Wed, 27 May 2009 16:36:01 -0400
Subject: svn rev #22393: trunk/src/lib/crypto/aes/
In-Reply-To: <200905272008.n4RK8SkP015763@drugstore.mit.edu>
References: <200905272008.n4RK8SkP015763@drugstore.mit.edu>
Message-ID: <1243456561.4146.341.camel@ray>

On Wed, 2009-05-27 at 16:08 -0400, raeburn at MIT.EDU wrote:
> Don't re-run test programs to recreate output every time 'check' is built.

Uh, why?

make check is a "run the tests" target, not a build target.



From raeburn at MIT.EDU  Wed May 27 17:17:31 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Wed, 27 May 2009 17:17:31 -0400
Subject: svn rev #22393: trunk/src/lib/crypto/aes/
In-Reply-To: <1243456561.4146.341.camel@ray>
References: <200905272008.n4RK8SkP015763@drugstore.mit.edu>
	<1243456561.4146.341.camel@ray>
Message-ID: <34EE5D76-8B27-4440-91A1-6B6CFFF6555D@mit.edu>

On May 27, 2009, at 16:36, Greg Hudson wrote:
> On Wed, 2009-05-27 at 16:08 -0400, raeburn at MIT.EDU wrote:
>> Don't re-run test programs to recreate output every time 'check' is  
>> built.
>
> Uh, why?
>
> make check is a "run the tests" target, not a build target.

For some of them, we run the programs and check that the output file  
content is correct.  If we've created the output file from a previous  
"make check" invocation and haven't updated the program, do we need to  
re-run them?  After some discussion over Jabber, I agree that yes, we  
should do it anyways, and not assume they're deterministic.

I'll revert this change.

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


From srinivas.cheruku at gmail.com  Thu May 28 00:58:13 2009
From: srinivas.cheruku at gmail.com (Srinivas Cheruku)
Date: Thu, 28 May 2009 10:28:13 +0530
Subject: How to use FAST in TGS requests
In-Reply-To: <tslab4ypkg9.fsf@mit.edu>
References: <4a1d01b2.095c5e0a.4936.1efa@mx.google.com>	<1243441457.4146.309.camel@ray>
	<tslab4ypkg9.fsf@mit.edu>
Message-ID: <4a1e19fb.1c365e0a.7b8f.ffffffd2@mx.google.com>



>-----Original Message-----
>From: Sam Hartman [mailto:hartmans at mit.edu]
>Sent: 27 May 2009 22:11
>To: Greg Hudson
>Cc: Srinivas Cheruku; 'krbdev at mit.edu'
>Subject: Re: How to use FAST in TGS requests
>
>>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:
>
>    Greg> On Wed, 2009-05-27 at 14:32 +0530, Srinivas Cheruku wrote:
>    >> How can I use client code to get service ticket using FAST?
>
>    Greg> My understanding is that we have not implemented FAST for
>    Greg> TGS-REQs yet.  (We did implement using a subkey for TGS-REQs
>    Greg> as an intermediate step, which uncovered four different
>    Greg> interoperability problems in three different Kerberos
>    Greg> implementations.)
>
>I have an implementation of FAST TGS requests that was used during
>interop testing.  I believe that the KDC on the trunk supports FAST
>TGS correctly; it works against my implementation and against another
>vendor's implementation.
>
[Srinivas Cheruku] Does your implementation use subkeys in AP-REQ (in
PA-TGS-REQ padata) in TGS-REQ? I saw a thread (by Greg Hudson) where there
were interoperability issues when using subkeys in TGS-REQ and so did you do
anything extra other than adding FAST to TGS code in MIT? I just want to
understand what changes made it work against another vendors implementation.

>I have not checked in the FAST TGS client side changes for two
>reasons.  First, as currently written, it breaks interop with non-FAST
>KDCs. 
[Srinivas Cheruku] The PA-TGS-REQ is in the outer request along with
PA-FX-FAST, so how will it break the interop with non-FAST KDCs? Can you
please explain?

 Secondly, there was some discussion of when we want to try FAST
>with the TGS.  I think it would be fine to experiment with that for
>the 1.8 release, but I felt that it was very late in the 1.7 process
>to make that decision.
[Srinivas Cheruku] ok

Thanks,
Srini


From hartmans at MIT.EDU  Thu May 28 10:55:01 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Thu, 28 May 2009 10:55:01 -0400
Subject: issue with MIT KDC and LDAP DS
In-Reply-To: <F14563DF343AAA5742E34B81@atlantis.pc.cs.cmu.edu> (Jeffrey
	Hutzelman's message of "Wed\, 27 May 2009 16\:19\:27 -0400")
References: <20090522205757.GA2250@sun.com>
	<8AC57446-E5EB-4671-AB65-C0BF388AC2E2@mit.edu>
	<15511_1243448825_n4RIR5sm029586_20090527181911.GC12597@sun.com>
	<F14563DF343AAA5742E34B81@atlantis.pc.cs.cmu.edu>
Message-ID: <tsltz35l1kq.fsf@mit.edu>

I agree with what Jeff said and believe he provides a great write-up
of it.

From William.Fiveash at Sun.COM  Thu May 28 13:01:19 2009
From: William.Fiveash at Sun.COM (Will Fiveash)
Date: Thu, 28 May 2009 12:01:19 -0500
Subject: issue with MIT KDC and LDAP DS
In-Reply-To: <tsltz35l1kq.fsf@mit.edu>
References: <20090522205757.GA2250@sun.com>
	<8AC57446-E5EB-4671-AB65-C0BF388AC2E2@mit.edu>
	<15511_1243448825_n4RIR5sm029586_20090527181911.GC12597@sun.com>
	<F14563DF343AAA5742E34B81@atlantis.pc.cs.cmu.edu>
	<tsltz35l1kq.fsf@mit.edu>
Message-ID: <20090528170119.GA24130@sun.com>

On Thu, May 28, 2009 at 10:55:01AM -0400, Sam Hartman wrote:
> I agree with what Jeff said and believe he provides a great write-up
> of it.

Same here.  I think it's an excellent description of ideal behavior for
krb5kdc and kadmind.  I also agree with your earlier suggestion that
modifying krb5kdc/kadmind to conform to this ideal is a small project
that should have a design written up and reviewed.  Not sure when I can
do it but others should feel free to tackle this if there's an interest.

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

From hartmans at MIT.EDU  Thu May 28 13:41:00 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Thu, 28 May 2009 13:41:00 -0400
Subject: issue with MIT KDC and LDAP DS
In-Reply-To: <20090528170119.GA24130@sun.com> (Will Fiveash's message of "Thu\,
	28 May 2009 12\:01\:19 -0500")
References: <20090522205757.GA2250@sun.com>
	<8AC57446-E5EB-4671-AB65-C0BF388AC2E2@mit.edu>
	<15511_1243448825_n4RIR5sm029586_20090527181911.GC12597@sun.com>
	<F14563DF343AAA5742E34B81@atlantis.pc.cs.cmu.edu>
	<tsltz35l1kq.fsf@mit.edu> <20090528170119.GA24130@sun.com>
Message-ID: <tsl8wkhktw3.fsf@mit.edu>

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

    Will> On Thu, May 28, 2009 at 10:55:01AM -0400, Sam Hartman wrote:
    >> I agree with what Jeff said and believe he provides a great
    >> write-up of it.

    Will> Same here.  I think it's an excellent description of ideal
    Will> behavior for krb5kdc and kadmind.  I also agree with your
    Will> earlier suggestion that modifying krb5kdc/kadmind to conform
    Will> to this ideal is a small project that should have a design
    Will> written up and reviewed.  Not sure when I can do it but
    Will> others should feel free to tackle this if there's an
    Will> interest.

I do want to clarify that I'm not asking for much more than a summary
of this discussion.

From hotz at jpl.nasa.gov  Fri May 29 18:45:49 2009
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Fri, 29 May 2009 15:45:49 -0700
Subject: issue with MIT KDC and LDAP DS
In-Reply-To: <mailman.567.1243527412.20151.krbdev@mit.edu>
References: <mailman.567.1243527412.20151.krbdev@mit.edu>
Message-ID: <68BC6E71-71CA-46AF-82CF-2E4A80EA2F8C@jpl.nasa.gov>


On May 28, 2009, at 9:16 AM, krbdev-request at mit.edu wrote:

> Date: Wed, 27 May 2009 13:19:11 -0500
> From: Will Fiveash <William.Fiveash at Sun.COM>
> Subject: Re: issue with MIT KDC and LDAP DS
> To: Ken Raeburn <raeburn at mit.edu>
> Cc: MIT Kerberos Dev List <krbdev at mit.edu>
> Message-ID: <20090527181911.GC12597 at sun.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, May 26, 2009 at 07:17:19PM -0400, Ken Raeburn wrote:
>> BTW, getting back on track with Will's idea:
>>
>> As originally stated, I think it's a good idea and an improvement  
>> over
>> the current status, and should be implemented.  Minor points: We  
>> might
>> want the option for the KDC to be silent instead of returning an
>> error.  And, as I mentioned in a paragraph buried in the middle of my
>> Saturday ramblings^H^H^H^H^H^H^H^H^Hemail, LDAP server unavailability
>> might be a "tempfail" situation, but I think we still want hard
>> failures (i.e., KDC errors out) for cases like the DB2 database not
>> existing, or the LDAP server being available but the KDB data not
>> being there.
>
> A question regarding fundamental krb5kdc behavior; which of the
> following do people consider preferable behavior?
>
> 1. The krb5kdc exits when it encounters an error accessing the KDB  
> thus
>   clients that send it krb requests via UDP then rely on timeouts to
>   indicate it should fall back to trying other KDCs.
>
> 2. The krb5kdc stays up when it encounters an error accessing the KDB
>   and sends clients KDC_ERR_SVC_UNAVAILABLE immediately when receiving
>   krb requests.  If the client handles KDC_ERR_SVC_UNAVAILABLE it
>   can immediately try other KDCs.

I generally prefer 2), but . . .

I might change my mind if Solaris 10 clients don't support  
KDC_ERR_SVC_UNAVAILABLE properly.  Solaris 9 is finally drifting out  
of usage here.  I expect to have to live with Solaris 10 for a long  
time.

(Way off-topic:  would you rather I put my efforts into getting JPL to  
pay to fix this issue than the other one?  ;-)

Don't know about Windows, but the other client platforms I care about  
are likely to support that error properly soon enough.

> I think consensus on this will influence the fundamental approach to
> modifying the KDC daemons to deal with KDB access errors.
>
> And to your point about DAL errors, I was also thinking that the DAL
> open function could return fatal and non-fatal errors and the
> krb5kdc/kadmind code could be modified to deal with non-fatal errors
> (stay up, log the error, have state that indicates initialization is  
> not
> complete, etc...).
>
>> Improvements like the "background" reconnection Jeff suggests would
>> also be good but can wait for later, and possibly be examined in a
>> larger-scale redesign.
>
> Agreed.
>
> --
> Will Fiveash
> Sun Microsystems Inc.
> http://opensolaris.org/os/project/kerberos/

------------------------------------------------------
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