Subject: [Ietf-krb-wg] Request for clarification on RFC 4120

From: "Sabharanjak, Ravi" <[email-masked]>
Date: Fri, 8 Jul 2011 20:22:27 -0400

Hello,

I apologize if this is not the correct forum to ask this.

I am a systems administrator with BlackRock, and I was hoping you could help me by clarifying the required KDC behavior per RFC 4120.

I am running into a problem getting a Java client to authenticate with a server 2008 KDC and need this clarification to resolve this issue.

This is the scenario:
-       Java client supports AES, DES and RC4-HMAC encryption
-       Server 2008 KDC supports RC4-HMAC4 encryption only. It does not support AES. (The operating system code does support AES, but this functionality is only available when there are no older operating systems such as server 2003 acting as domain controllers in the environment)

Question:
If the Java client makes an AS-REQ WITHOUT including pre-authentication information, the KDC needs to reply with KDC_ERR_PREAUTH_REQUIRED. Should it list AES in the PA-ETYPE-INFO2 because section 3.1.3 says:

   When the AS server is to include pre-authentication data in a
   KRB-ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-
   INFO, if the etype field of the client's AS-REQ lists at least one
   "newer" encryption type.

Or should the KDC NOT include AES in the reply because section 3.1.3 also says:

If pre-authentication is
required, but was not present in the request, an error message with
   the code KDC_ERR_PREAUTH_REQUIRED is returned, and a METHOD-DATA
   object will be stored in the e-data field of the KRB-ERROR message to
   specify which pre-authentication mechanisms are acceptable.  Usually
   this will include PA-ETYPE-INFO and/or PA-ETYPE-INFO2 elements as
   described below.

Thank you and in anticipation of your reply,
-Ravi

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE PRIVILEGED.  If this message was misdirected, BlackRock, Inc. and its subsidiaries, ("BlackRock") does not waive any confidentiality or privilege.  If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone.  Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized.  The views and opinions expressed in this e-mail message are the author's own and may not reflect the views and opinions of BlackRock, unless the author is authorized by BlackRock to express such views or opinions on its behalf.  All email sent to or from this address is subject to electronic storage and review by BlackRock.  Although BlackRock operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Fri, 08 Jul 2011 23:33:44 -0400

On Fri, 2011-07-08 at 20:22 -0400, Sabharanjak, Ravi wrote:
> -       Server 2008 KDC supports RC4-HMAC4 encryption only. It does
> not support AES. (The operating system code does support AES, but this
> functionality is only available when there are no older operating
> systems such as server 2003 acting as domain controllers in the
> environment)

> [...]the KDC needs to reply with KDC_ERR_PREAUTH_REQUIRED. Should it
> list AES in the PA-ETYPE-INFO2 because
[...]
> Or should the KDC NOT include AES in the reply because [...]

Section 8.1 of RFC 4120 requires that an implementation support AES-256,
and the text you quote from section 3.1.3 relies on that assumption.  So
when Server 2008 is operating in Server 2003 compatibility mode, it is
not trying to conform to RFC 4120 with respect to enctype support.

---

From: "Sabharanjak, Ravi" <[email-masked]>
Date: Mon, 11 Jul 2011 14:36:26 -0400

I'm a bit confused - Which one of these is the proper behavior?

Server 2008+ with a Java client:
>>AS-REQ from Java client, specifying AES128, des and rc4-hmac
<< KDC_ERR_PREAUTH_REQUIRED from server 2008, with AES in the PA-ETYPE-INFO2.
>>AS-REQ from Java client specifying just AES, and the pre-auth information.
<< KDC_ERR_ETYPE_NOTSUPP from server 2008

Server 2008+ with a vista+ client:
>>AS-REQ from client, specifying AES128, des and rc4-hmac
<< KDC_ERR_PREAUTH_REQUIRED from server 2008, with AES in the PA-ETYPE-INFO2.
>>AS-REQ from client specifying ALL encryption schemes (aes, des and rc4-hmac encryption) and the pre-auth information.
<< TGT from server 2008

Am I wrong in concluding that the reason the acceptable encryption schemes are to be listed in the PA-ETYPE-INFO2 structure is to facilitate a negotiation between the kdc and the client as to which encryption schemes are possible OR should the client just repeat the AS-REQ with all possible encryption schemes and let the server pick - as is the vista+ behavior?

Thanks,
-Ravi

-----Original Message-----
From: Greg Hudson [mailto:[email-masked]] 
Sent: Friday, July 08, 2011 8:34 PM
To: Sabharanjak, Ravi
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] Request for clarification on RFC 4120

[...]
> Or should the KDC NOT include AES in the reply because [...]

Section 8.1 of RFC 4120 requires that an implementation support AES-256, and the text you quote from section 3.1.3 relies on that assumption.  So when Server 2008 is operating in Server 2003 compatibility mode, it is not trying to conform to RFC 4120 with respect to enctype support.

---

From: Greg Hudson <[email-masked]>
Date: Mon, 11 Jul 2011 14:43:27 -0400

> << KDC_ERR_ETYPE_NOTSUPP from server 2008

I would call this improper behavior; the KDC should not advertise an
enctype which it won't accept.  But it's not particularly meaningful to
cite chapter and verse from RFC 4120 in this case.  From RFC 4120's
perspective, the behavior is improper because the KDC isn't supporting
AES-256, not because the KDC refuses to support an enctype it
advertises.

---

From: Martin Rex <[email-masked]>
Date: Mon, 11 Jul 2011 21:03:25 +0200 (MEST)

Sabharanjak, Ravi wrote:
> Am I wrong in concluding that the reason the acceptable encryption
> schemes are to be listed in the PA-ETYPE-INFO2 structure is to facilitate
> a negotiation between the kdc and the client as to which encryption
> schemes are possible OR should the client just repeat the AS-REQ with
> all possible encryption schemes and let the server pick - as is the
> vista+ behavior?

There seems to be a significant variety of strange behaviour out there.

If I create a keytab with a single keytab entry (etype arcfour-hmac)
for a principal, I can use the quite dated "kinit" from heimdal-0.6.1
(the kerberos software included with SuSE Enterprise Linux 9)
to successfully acquire a TGT from a Windows 2008R2 AD with
   (skey,tkt): arcfour-hmac, aes256-cts-hmac-sha1-96

If I try the same with "kinit -k" from MIT Kerberos 1.9.1, it fails miserably
-- it seems to be looking for aes256-cts skey, instead of looking in the
keytab first which enctypes are possible for the specified principal and
acting accordingly.

-Martin

---

From: Marcus Watts <[email-masked]>
Date: Mon, 11 Jul 2011 15:35:53 -0400

> Date:    Mon, 11 Jul 2011 21:03:25 +0200
> To:      [email-masked] (Sabharanjak Ravi)
> cc:      [email-masked]
> From:    Martin Rex <[email-masked]>
> > >>AS-REQ from client specifying ALL encryption schemes (aes, des and rc4-hmac
>  encryption) and the pre-auth information.
> > << TGT from server 2008
> > 

Does your kdb list encryption types for the principal that aren't in the keytab?

You have some client-side knobs you can twist.  Your ancient heimdal
kinit doesn't know about kinit, so it doesn't tell the kdc it can handle
that keytype.  Your modern mit kinit does - and apparently you get your
bad behavior.  But you can tell your modern mit kinit not to ask for
aes by specifying lines like these:
	default_etypes = des3-hmac-sha1 des-cbc-crc arcfour-hmac
	default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc arcfour-hmac
	default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc arcfour-hmac
in /etc/krb5.conf  You can also vary the order of encryption types
by sorting this list differently.

With Java, this becomes even more important: the default list of encryption
types is ordered very strangely, with weak types first.  If you want the
strong types, you want to specify this list.  To use AES256 you must also
install jce_policy and of course you need java 6.

				-Marcus Watts

---

From: "Sabharanjak, Ravi" <[email-masked]>
Date: Mon, 11 Jul 2011 15:48:23 -0400

Specifying the default_tkt_enctypes, removing aes and specifying rc4-hmac does work for Java. 

However, this seems to negate the negotiation capability built into the Kerberos protocol, and also closes the door on going to AES at a future date for me when the KDC is AES capable after the domain level has been updated - If I have to figure out the exact combination that works between a client and server, why have the negotiation where each side lists their capabilities and signals to the other which one is acceptable!

In my mind, today the client and server should negotiate rc4-hmac as that is the highest common denominator between them. Tomorrow, this should automatically shift to AES. Otherwise that is a lot of applications to retest and ini files to update at a later date.

Which is why I am trying to get to the final answer for this: Should the server 2008 KDC reply with a PA-ETYPE-INFO2 in the KDC_ERR_PREAUTH_REQUIRED response that specifies AES128 when it does not support AES128?

-Ravi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marcus Watts
Sent: Monday, July 11, 2011 12:36 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] Request for clarification on RFC 4120

> > schemes are to be listed in the PA-ETYPE-INFO2 structure is to 
> > facilitate a negotiation between the kdc and the client as to which 
> > encryption schemes are possible OR should the client just repeat the 
> > AS-REQ with all possible encryption schemes and let the server pick 
> > - as is the
> > vista+ behavior?
> 
> 
> (the kerberos software included with SuSE Enterprise Linux 9) to 
> successfully acquire a TGT from a Windows 2008R2 AD with
> -- it seems to be looking for aes256-cts skey, instead of looking in 
> the keytab first which enctypes are possible for the specified 
> principal and acting accordingly.
> 
> 
> -Martin
> 

You have some client-side knobs you can twist.  Your ancient heimdal kinit doesn't know about kinit, so it doesn't tell the kdc it can handle that keytype.  Your modern mit kinit does - and apparently you get your bad behavior.  But you can tell your modern mit kinit not to ask for aes by specifying lines like these:
	default_etypes = des3-hmac-sha1 des-cbc-crc arcfour-hmac
	default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc arcfour-hmac
	default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc arcfour-hmac in /etc/krb5.conf  You can also vary the order of encryption types by sorting this list differently.

With Java, this becomes even more important: the default list of encryption types is ordered very strangely, with weak types first.  If you want the strong types, you want to specify this list.  To use AES256 you must also install jce_policy and of course you need java 6.

				-Marcus Watts

---

From: Greg Hudson <[email-masked]>
Date: Mon, 11 Jul 2011 15:48:39 -0400

On Mon, 2011-07-11 at 15:35 -0400, Marcus Watts wrote:
> bad behavior.

(I assume you meant to say "doesn't know about AES" or something like
that.)

It's not about what enctypes the client supports.  Heimdal has code,
which you can find in init_creds_pw.c:krb5_init_creds_set_keytab() in
the current sources, to peer into the keytab and build an etype list for
the AS request.  MIT krb5 does not yet have code to do this.  There's an
open issue (#2131) in our bug database about it.

I don't believe this side issue is relevant to the original question
except that they both have to do with enctypes and AS requests.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Wed, 13 Jul 2011 09:58:46 -0500

> I apologize if this is not the correct forum to ask this.

It is, if this is really a protocol question, and Greg has sent an answer.

If this is more of how to get Java Kerberos to work with W2008 servers
running is 2003 mode, then the [email-masked] list would be a better
choice.  See: http://web.mit.edu/kerberos/mail-lists.html

You could then go into more detail on what version of Java, and what is failing.

-- 

  Douglas E. Engert  <[email-masked]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Douglas E. Engert" <[email-masked]>
Date: Wed, 13 Jul 2011 10:29:52 -0500

>>> AS-REQ from client specifying ALL encryption schemes (aes, des and rc4-hmac encryption) and the pre-auth information.

This sounds like a bug somewhere.

The 2008 KDC can accept a AES encrypted AS-REQ, but must return the TGT with an skey
of RC4, as the TGT may be used with a 2003 DC, later.

The Java is telling the KDC that it only supports AES, rather then it supports

This says it should work as expected:
http://download.oracle.com/javase/6/docs/technotes/guides/security/jgss/jgss-features.html

--

---

From: "Douglas E. Engert" <[email-masked]>
Date: Wed, 13 Jul 2011 10:39:26 -0500

>>> AS-REQ from client specifying ALL encryption schemes (aes, des and rc4-hmac encryption) and the pre-auth information.

This sounds like this bug from March 2010:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6932525

Which is closed, but sounds like
may be fixed in 5.0u29, and 6u25
What version of Java are you using?

--