From matthias at mernst.org  Thu Jul  5 07:34:54 2007
From: matthias at mernst.org (Matthias Ernst)
Date: Thu, 5 Jul 2007 16:34:54 +0200
Subject: [security-dev 00007]: Unicode Characters & RC4-HMAC w/ Kerberos&JGSS
Message-ID: <22ec15240707050734n3d946806of4bd912b9426ed8b@mail.gmail.com>

[Crosspost from http://forum.java.sun.com/thread.jspa?threadID=5192018]

I just stumbled over an issue w/ unicode characters in passwords with
JGSS in our Windows domain.

I extracted my machine account password ($machine.acc) using the
windows LSARetrievePrivateData API via the Win32 Python Extensions.
Result: was a unicode string with one catch: it contained the
character '\ude09', a lower surrogate character with no higher
surrogate in front. I don't know whether this is a Python issue, an
issue with the auto-generated password or what. The password is not a
valid unicode string.

Using this string in JGSS fails pre-authentication because the
UTF-16LE encoder in
sun.security.krb5.internal.crypto.dk.DkCrypto#charToUtf16 doesn't like
the sequence and inserts an "error" sequence FDFF.

If however, I use the following encoding, authentication against our
PDC works fine:

DkCrypto:
static byte[] charToUtf16(char[] chars) {
  ByteBuffer buffer = ByteBuffer.allocate(2 *
chars.length).order(ByteOrder.LITTLE_ENDIAN);
  buffer.asCharBuffer().put(chars);
  return buffer.array();
 }



This is agnostic of surrogates and maybe closer to what the RFC describes:

"Each Windows UNICODE character is encoded in little-endian format of
2 octets each."

Maybe someone who's in this a little deeper than me can judge whether
DkCrypto should be changed.

Thanks
Matthias


From Seema.Malkani at Sun.COM  Thu Jul  5 09:25:23 2007
From: Seema.Malkani at Sun.COM (Seema Malkani)
Date: Thu, 05 Jul 2007 09:25:23 -0700
Subject: [security-dev 00008]: Re: Unicode Characters & RC4-HMAC w/
 Kerberos&JGSS
In-Reply-To: <22ec15240707050734n3d946806of4bd912b9426ed8b@mail.gmail.com>
References: <22ec15240707050734n3d946806of4bd912b9426ed8b@mail.gmail.com>
Message-ID: <468D1B73.1070303@sun.com>

Matthias,

Non-ASCII usernames/passwords are not supported by Kerberos. This is a 
known Kerberos limitation.

Kerberos V is not internationalized. Applications are expected to 
provide ASCII characters with Kerberos. There is an ongoing effort at 
IETF to address this.

Seema

Matthias Ernst wrote:
> [Crosspost from http://forum.java.sun.com/thread.jspa?threadID=5192018]
>
> I just stumbled over an issue w/ unicode characters in passwords with
> JGSS in our Windows domain.
>
> I extracted my machine account password ($machine.acc) using the
> windows LSARetrievePrivateData API via the Win32 Python Extensions.
> Result: was a unicode string with one catch: it contained the
> character '\ude09', a lower surrogate character with no higher
> surrogate in front. I don't know whether this is a Python issue, an
> issue with the auto-generated password or what. The password is not a
> valid unicode string.
>
> Using this string in JGSS fails pre-authentication because the
> UTF-16LE encoder in
> sun.security.krb5.internal.crypto.dk.DkCrypto#charToUtf16 doesn't like
> the sequence and inserts an "error" sequence FDFF.
>
> If however, I use the following encoding, authentication against our
> PDC works fine:
>
> DkCrypto:
> static byte[] charToUtf16(char[] chars) {
>  ByteBuffer buffer = ByteBuffer.allocate(2 *
> chars.length).order(ByteOrder.LITTLE_ENDIAN);
>  buffer.asCharBuffer().put(chars);
>  return buffer.array();
> }
>
>
>
> This is agnostic of surrogates and maybe closer to what the RFC 
> describes:
>
> "Each Windows UNICODE character is encoded in little-endian format of
> 2 octets each."
>
> Maybe someone who's in this a little deeper than me can judge whether
> DkCrypto should be changed.
>
> Thanks
> Matthias



From casey.s.marshall at gmail.com  Sun Jul  8 12:10:47 2007
From: casey.s.marshall at gmail.com (Casey Marshall)
Date: Sun, 8 Jul 2007 12:10:47 -0700
Subject: [security-dev 00009]:  Enabling free JSSE
Message-ID: <BACE4BD0-2297-4EB9-9184-1E937F0FAEDB@gmail.com>

Hi.

I'm just posting this note that I've implemented some missing bits  
needed by the JSSE provider in OpenJDK, and now IcedTea (which is  
using a combination of GNU Classpath's crypto algorithms and Sun's  
SSL provider) can make SSL connections.

This implements the KeyGenerator algorithms SunTlsPrf, etc. The files  
are here:

http://icedtea.classpath.org/hg/icedtea/file/5465e5a55631/jce/gnu/ 
java/security/icedtea/

I don't know what Sun's plans are for the missing pieces of the  
PKCS11 provider (where these missing algorithms were), but I'll still  
offer my implementation to OpenJDK just the same.

Thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2435 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/security-dev/attachments/20070708/0de45be9/smime.p7s