Request for clarification on RFC 4120

Sabharanjak, Ravi Ravi.Sabharanjak at blackrock.com
Fri Jul 8 20:27:03 EDT 2011


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.





More information about the Kerberos mailing list