Announcement Announcement Module
Collapse
No announcement yet.
Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled

    Hi,

    I have MIT kerberos on debian. I have setup /etc/krb5.conf to include under libdefaults:

    default_tkt_enctypes = aes256-cts aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc arcfour-hmac arcfour-hmac-md5

    default_tgt_enctypes = aes256-cts aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc arcfour-hmac arcfour-hmac-md5

    permitted_enctypes = aes256-cts aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc arcfour-hmac arcfour-hmac-md5

    tomcat on debian runs as:

    "/usr/local/java/bin/java" "-Djava.util.logging.config.file=/usr/local/tomcat/conf/logging.properties" -Djava.util.logging.manager=org.apache.juli.ClassLo aderLogManager -Djava.security.auth.login.config=jaas_kerberoscont ext.conf -Djava.security.krb5.realm=PRIMESYSTEMS.COM -Djava.security.krb5.kdc=pinkydebian.primesystems.c om -Djava.endorsed.dirs="/usr/local/tomcat/endorsed" -classpath "/usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar" -Dcatalina.base="/usr/local/tomcat" -Dcatalina.home="/usr/local/tomcat" -Djava.io.tmpdir="/usr/local/tomcat/temp" org.apache.catalina.startup.Bootstrap start
    root@pinkydebian:/etc/rc0.d#


    Now on win 7 I run mit network idenitity manager and fetch TGT. Then I run firefox to access the webapp. I see HTTP ticket fetched in identity manager. Then in tomcat logs on debian I see it being presented but webapp has error:

    Caused by: KrbException: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled


    As far as I know I have enabled it in krb5.conf. is there any other place I need to enable it ? When I exported the HTTP ticket for webapp I did not specify any encoding type. I used the command in the blog article.


    I tried few combinations of encodings for key as below:

    added under libdefaults in /etc/krb5.conf since I read in some blog that java gss api supports only these few enc.

    default_tgs_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
    default_tkt_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
    permitted_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1

    generated the principal and keys again w/o specifying any encoding

    klist -e -k /http-web.keytab
    Keytab name: WRFILE:/http-web.keytab
    KVNO Principal
    ---- --------------------------------------------------------------------------
    2 HTTP/[email protected] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
    2 HTTP/[email protected] (ArcFour with HMAC/md5)
    2 HTTP/[email protected] (Triple DES cbc mode with HMAC/sha1)
    2 HTTP/[email protected] (DES cbc mode with CRC-32)


    I checked in NIM that TGT and HTTP key returned is des3-cbc-sha1 encoding.

    The webapp gives exception as below:

    15:12:29 DEBUG kerberos.KerberosServiceAuthenticationProvider - Try to validate Kerberos Token
    Found KeyTab
    Entered Krb5Context.acceptSecContext with state=STATE_NEW
    Ordering keys wrt default_tkt_enctypes list
    Using builtin default etypes for default_tkt_enctypes
    default etypes for default_tkt_enctypes: 17 16 23 1 3.

    15:12:29 WARN web.SpnegoAuthenticationProcessingFilter - Negotiate Header was invalid: Negotiate YIICtgYGKwYBBQUCoIICqjCCAqagHzAdBgkqhkiG9xIBAgIGBS sFAQUCBgkqhkiC9xIBAgKiggKBBIICfWCCAnkGCSqGSIb3EgEC AgEAboICaDCCAmSgAwIBBaEDAgEOogcDBQAAAAAAo4IBgGGCAX wwggF4oAMCAQWhEhsQUFJJTUVTWVNURU1TLkNPTaIvMC2gAwIB A6EmMCQbBEhUVFAbHHBpbmt5ZGViaWFuLnByaW1lc3lzdGVtcy 5jb22jggEqMIIBJqADAgEQoQMCAQKiggEYBIIBFEmXKG74+4ks REO+4UcVStFMg7hjqDw4HjYWZY9oxlBDBN1Ivrvm8/UX8EaR+cVLKFerHp0FW0q1hzCwk/EwxPYVo059KJvJ15fqbDvqXduz0KZQBfWg/5DXXrwPPG2vQXP5Qtaa96Y7+YiVBqYlyuPFRSyLDhvN+mxhWcF ajxAp9HbuZZ/4KBRhQspQYFdLbDrQpe7VsWpcuwm1X6QGGmavlRjeNEYMNLd5s G1zGADzFeWKXRvHl0TsmKyervwnc4x5eYFVh24sI2S7NXngxP6 cFZgRFjOobjWEaw2b55wNN+Y1DGBU7cj34D98lK1RDZUgSKO+z tF41jUhYYd1HrzDQtLInnHBLuBAaL8wHHEFjyuvdaSByjCBx6A DAgEQooG/BIG8KhOcoed/yg2+laPOknMC9KUz2DeBDi4gkcxasCHNNLoG+LYMWeS3fxp/SsjFSfTko6Raxu3JxqB1ZxhLZ1W0x5ZzA/eqarvksjidSEAu4UqU6JKlMUtUAvmiQr41uvidNnRH9ELl4H8G Gtkm9uDhptQxnrsPdtD25ENV/dLEbvs8C37nIb1CzOzQU9rTPWYyeKRcD1Z5ZpU0RfPIJnCnhTd MuwNOUkq6o4hwC69LXwM/us3M773tLsDFqPc=
    ......

    caused by: java.security.PrivilegedActionException: GSSException: Failure unspecified at GSS-API level (Mechanism level: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - DES3 CBC mode with SHA1-KD)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:415)
    at org.springframework.security.extensions.kerberos.S unJaasKerberosTicketValidator.validateTicket(SunJa asKerberosTicketValidator.java:67)
    ... 26 more


    I suppose the keytab has correct key encoding available but java gss api is not using it ?

    Regards,

    Miten.
    Last edited by imitenmehta; Dec 16th, 2012, 05:11 AM.

  • #2
    Have you placed the JCE Unlimited Policy fileset into your JDK/JRE? You need Unlimited Strength to do AES256.

    Check Appendix C of this http://docs.oracle.com/javase/6/docs...Spec.html#AppC document, the JRE 6 CryptoSpec.

    Comment


    • #3
      Hi, I think some thing else is wrong so I pass junk value for keytab file name and still there is no error. If I try to upgrade the versions of api the base64 codec package has changed. So I am sticking with M2 and 3.0.7.RELEASE of api for extension and core.

      See this message.

      Miten.

      Comment


      • #4
        We are facing the exact same issue on upgrade to spring security 3.1.1 and upgrading the spego the latest extension. We are also using JDK 7.0.

        Is this a known issue? Were you able to ever get it to work or you simply reverted to using old spring jars , the old extension and JDK 6.0

        Comment

        Working...
        X