From Weijun.Wang at Sun.COM  Wed Jan  2 08:52:10 2008
From: Weijun.Wang at Sun.COM (Weijun Max Wang)
Date: Wed, 02 Jan 2008 16:52:10 +0800
Subject: [security-dev 00031]: [Fwd: Re: JAVASEC - Problem running JAAS
	client from tutorial]
Message-ID: <477B50BA.6020903@sun.com>

Hi All

I've tried to disable realm name case check in JDK (equals ->
equalsIgnoreCase), and it works. In fact, I do several experiments to
change the case of principal names, realm names, service names and
hostnames, and MSAD just doesn't care. This is another case of
Microsoft's long term habit of ignoring cases (BASIC language, file
names, user names...).

We already accept BILL and bill and BiLL with the pre-authentication
support in JDK 6. Are we going to embrace this ignorance again?

RFC 4120 3.1.5 says "It also verifies that the sname and srealm in the
response match those in the request (or are otherwise expected values)"
and seems MS has its own way of interpreting "match" and "expected values".

Being strict is not bad here, it just confuses (and then teaches)
careless users.

Thanks
Max

-------- Original Message --------
Subject: Re: JAVASEC - Problem running JAAS client from tutorial
Date: Tue, 01 Jan 2008 09:44:17 +0800
From: Max (Weijun) Wang <Weijun.Wang at Sun.COM>
To: Lea, Isaac <IsaacLea at SierraSystems.com>
CC: java-security at sun.com
References:
<B121C734ED030C429B1513E9FB785984011F117D at svvic2000.sierrasys.com>

>          realm is PRSDev.local
>          sname is krbtgt/PRSDev.local

The realm name should be all CAPITAL for Windows domain. Please use -
Djava.security.krb5.realm=PRSDEV.LOCAL on the command line.

Hope this helps
Max

On Jan 1, 2008, at 4:07 AM, Lea, Isaac wrote:

> I am trying to follow the tutorial for JAAS Authentication located  
> here:
> http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/tutorials/ 
> AcnOnly.html
>
> I am trying to run the sample client JaasAcn.java but am getting a  
> strange error when I try to log on to my Active Directory.
>
> I am using Java version: jre1.6.0_03
>
> I can login to Active Directory fine with the credentials I am  
> providing, just not with this client, so I know the credentials are  
> valid.
>
> Here is the error I get that I don't understand.  Any suggestions  
> would be very helpful, if you provide help for this
>
> The Error message is: [Krb5LoginModule] authentication failed
> Message stream modified (41)
>
> Here is the full output:
>
> C:\Progra~1\Java\jre1.6.0_03\bin\java - 
> Dsun.security.krb5.debug=true - 
> Djava.security.krb5.realm=PRSDev.local - 
> Djava.security.krb5.kdc=192.168.40.72 - 
> Djava.security.auth.login.config=jaas.conf JaasAcn
>
> Debug is  true storeKey false useTicketCache false useKeyTab false  
> doNotPrompt f
> alse ticketCache is null isInitiator true KeyTab is null  
> refreshKrb5Config is fa
> lse principal is null tryFirstPass is false useFirstPass is false  
> storePass is f
> alse clearPass is false
> Kerberos username [ILea]: sra
> Kerberos password for sra:
>                 [Krb5LoginModule] user entered username: sra
>
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 3 1 23 16 17.
> Acquire TGT using AS Exchange
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 3 1 23 16 17.
> >>> KrbAsReq calling createMessage
> >>> KrbAsReq in createMessage
> >>> KrbKdcReq send: kdc=192.168.40.72 UDP:88, timeout=30000, number  
> of retries =
> 3, #bytes=144
> >>> KDCCommunication: kdc=192.168.40.72 UDP:88,  
> timeout=30000,Attempt =1, #bytes
> =144
> >>> KrbKdcReq send: #bytes read=202
> >>> KrbKdcReq send: #bytes read=202
> >>> KDCRep: init() encoding tag is 126 req type is 11
> >>>KRBError:
>          sTime is Mon Dec 31 11:56:40 PST 2007 1199131000000
>          suSec is 884978
>          error code is 25
>          error Message is Additional pre-authentication required
>          realm is PRSDev.local
>          sname is krbtgt/PRSDev.local
>          eData provided.
>          msgType is 30
> >>>Pre-Authentication Data:
>          PA-DATA type = 11
>          PA-ETYPE-INFO etype = 23
> >>>Pre-Authentication Data:
>          PA-DATA type = 2
>          PA-ENC-TIMESTAMP
> >>>Pre-Authentication Data:
>          PA-DATA type = 15
> AcquireTGT: PREAUTH FAILED/REQUIRED, re-send AS-REQ
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 3 1 23 16 17.
> Pre-Authentication: Set preferred etype = 23
> >>>KrbAsReq salt is PRSDev.localsra
> Pre-Authenticaton: find key for etype = 23
> AS-REQ: Add PA_ENC_TIMESTAMP now
> >>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
> >>> KrbAsReq calling createMessage
> >>> KrbAsReq in createMessage
> >>> KrbKdcReq send: kdc=192.168.40.72 UDP:88, timeout=30000, number  
> of retries =
> 3, #bytes=210
> >>> KDCCommunication: kdc=192.168.40.72 UDP:88,  
> timeout=30000,Attempt =1, #bytes
> =210
> >>> KrbKdcReq send: #bytes read=1182
> >>> KrbKdcReq send: #bytes read=1182
> >>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
>                 [Krb5LoginModule] authentication failed
> Message stream modified (41)
> Authentication failed:
>   Message stream modified (41)
>
> Isaac Lea
> Sierra Systems
> 737 Courtney Street
> Victoria, BC V8W 1C3
>
> Tel | 250.385.1535.
> Fax | 250.385.4761
> IsaacLea at SierraSystems.com
> www.SierraSystems.com
>
>
> ----Notice Regarding Confidentiality----
> This email, including any and all attachments, (this "Email") is  
> intended only for the party to whom it is addressed and may contain  
> information that is confidential or privileged. Sierra Systems  
> Group Inc. and its affiliates accept no responsibility for any loss  
> or damage suffered by any person resulting from any unauthorized  
> use of or reliance upon this Email. If you are not the intended  
> recipient, you are hereby notified that any dissemination, copying  
> or other use of this Email is prohibited. Please notify us of the  
> error in communication by return email and destroy all copies of  
> this Email. Thank you.
>



From Weijun.Wang at Sun.COM  Wed Jan  2 09:54:02 2008
From: Weijun.Wang at Sun.COM (Weijun Max Wang)
Date: Wed, 02 Jan 2008 17:54:02 +0800
Subject: [security-dev 00032]: JGSS: Re-construct
	Credentials.acquireTGTFromCache
Message-ID: <477B5F3A.8040100@sun.com>

Hi All

Current sun.security.krb5.Credentials's acquireTGTFromCache method looks
like --

Cred acquireTGTFromCache(princ, fcache) {
  if (fcache not specified) {
    if (Windows) {
      cred = function {
        get default TGT from default file cache;
        if (found && etypeSupported) return it;
        else return one from LSA;
      }
      if (princ specified && princ is not princ in cred)
        return null;
      else
        return cred;
    }
  }
  read cred for princ in fcache
  if (found && etypeSupported) return it;
  else return null;
}

It seems there's a chance on Windows that the default TGT in default
file cache (fcache == null) is not for princ, but maybe there's one for
princ in LSA. It won't get read.

Right? Shall we just move the whole fcache to the beginning and only use
LSA as a fallback?

Thanks
Max



From andrew.fan at sun.com  Wed Jan  2 12:39:40 2008
From: andrew.fan at sun.com (Andrew Fan)
Date: Wed, 02 Jan 2008 20:39:40 +0800
Subject: [security-dev 00033]: Re: JGSS:
	Re-construct	Credentials.acquireTGTFromCache
In-Reply-To: <477B5F3A.8040100@sun.com>
References: <477B5F3A.8040100@sun.com>
Message-ID: <477B860C.8050701@Sun.COM>

Just as the comments, "// The default ticket cache on Windows is not a 
file." So I don't think there are some credentials missed, or won't get 
read.

For the send question, the current CredentialsCache is implemented as a 
file based cache.  It's a good idea that we adjust the CredentialsCache 
to accept LSA on windows platform.  I made a few updates on 
MemoryCredentialsCache, and CredentialsCache  to accept  
MemoryCredentialsCache months ago, I haven't test it completely. I never 
thought about that it could be used to improve the acquireTGTFromCache.

Andrew

Weijun Max Wang wrote:
> Hi All
>
> Current sun.security.krb5.Credentials's acquireTGTFromCache method looks
> like --
>
> Cred acquireTGTFromCache(princ, fcache) {
>   if (fcache not specified) {
>     if (Windows) {
>       cred = function {
>         get default TGT from default file cache;
>         if (found && etypeSupported) return it;
>         else return one from LSA;
>       }
>       if (princ specified && princ is not princ in cred)
>         return null;
>       else
>         return cred;
>     }
>   }
>   read cred for princ in fcache
>   if (found && etypeSupported) return it;
>   else return null;
> }
>
> It seems there's a chance on Windows that the default TGT in default
> file cache (fcache == null) is not for princ, but maybe there's one for
> princ in LSA. It won't get read.
>
> Right? Shall we just move the whole fcache to the beginning and only use
> LSA as a fallback?
>
> Thanks
> Max
>
>   



From Weijun.Wang at Sun.COM  Wed Jan  2 14:13:11 2008
From: Weijun.Wang at Sun.COM (Max (Weijun) Wang)
Date: Wed, 02 Jan 2008 22:13:11 +0800
Subject: [security-dev 00034]: Re: JGSS:	Re-construct
 Credentials.acquireTGTFromCache
In-Reply-To: <477B860C.8050701@Sun.COM>
References: <477B5F3A.8040100@sun.com> <477B860C.8050701@Sun.COM>
Message-ID: <8B352ECC-1F9E-4EDF-B0DD-46D5D570B383@Sun.COM>

Hi Andrew

The current CredentialsCache.getInstance() on Windows should always  
return the file cache, right? Inside the acquireDefaultCreds()  
method, if cache.getDefaultCreds() returns a non-null object which  
has the correct eType, then LSA is never read.

Take this for example:

1. User login Active Directory as A
2. User's JAAS login config includes "principal=A"

Now, acquireTGTFromCache returns the TGT for A in LSA. However, if

3. User run "kinit B" and generate a file cache for user B

acquireTGTFromCache returns NULL, since the TGT for B in fcache is  
first returned and then ignored.

On Jan 2, 2008, at 8:39 PM, Andrew Fan wrote:

> Just as the comments, "// The default ticket cache on Windows is  
> not a file." So I don't think there are some credentials missed, or  
> won't get read.
>
> For the send question, the current CredentialsCache is implemented  
> as a file based cache.  It's a good idea that we adjust the  
> CredentialsCache to accept LSA on windows platform.  I made a few  
> updates on MemoryCredentialsCache, and CredentialsCache  to accept   
> MemoryCredentialsCache months ago, I haven't test it completely. I  
> never thought about that it could be used to improve the  
> acquireTGTFromCache.

Oh, this is cool. The whole ccache picture for Windows may include  
file cache, MIT-style in-memory cache, Windows LSA cache. Does this  
mean there should return 3 kinds of CredentialsCache objects? Is  
something like CredentialsCache.getAllInstances() needed?

Thanks
Max

>
> Andrew
>
> Weijun Max Wang wrote:
>> Hi All
>>
>> Current sun.security.krb5.Credentials's acquireTGTFromCache method  
>> looks
>> like --
>>
>> Cred acquireTGTFromCache(princ, fcache) {
>>   if (fcache not specified) {
>>     if (Windows) {
>>       cred = function {
>>         get default TGT from default file cache;
>>         if (found && etypeSupported) return it;
>>         else return one from LSA;
>>       }
>>       if (princ specified && princ is not princ in cred)
>>         return null;
>>       else
>>         return cred;
>>     }
>>   }
>>   read cred for princ in fcache
>>   if (found && etypeSupported) return it;
>>   else return null;
>> }
>>
>> It seems there's a chance on Windows that the default TGT in default
>> file cache (fcache == null) is not for princ, but maybe there's  
>> one for
>> princ in LSA. It won't get read.
>>
>> Right? Shall we just move the whole fcache to the beginning and  
>> only use
>> LSA as a fallback?
>>
>> Thanks
>> Max
>>
>>
>



From Andrew.Fan at Sun.COM  Wed Jan  2 16:05:16 2008
From: Andrew.Fan at Sun.COM (Andrew Fan)
Date: Thu, 03 Jan 2008 00:05:16 +0800
Subject: [security-dev 00035]: Re: JGSS:	Re-construct
 Credentials.acquireTGTFromCache
In-Reply-To: <8B352ECC-1F9E-4EDF-B0DD-46D5D570B383@Sun.COM>
References: <477B5F3A.8040100@sun.com> <477B860C.8050701@Sun.COM>
	<8B352ECC-1F9E-4EDF-B0DD-46D5D570B383@Sun.COM>
Message-ID: <477BB63C.9050006@Sun.COM>

Max (Weijun) Wang wrote:
> Hi Andrew
>
> The current CredentialsCache.getInstance() on Windows should always 
> return the file cache, right? Inside the acquireDefaultCreds() method, 
> if cache.getDefaultCreds() returns a non-null object which has the 
> correct eType, then LSA is never read.
>
OK, now I understand your question. I wonder if having a default file 
cache, and at the same time the valid LSA cache, should both of them 
should be searched for the credentials? which one should be searched 
firstly? The currently implement only search one cache, and the file 
cache has a higher priority.

Andrew
> Take this for example:
>
> 1. User login Active Directory as A
> 2. User's JAAS login config includes "principal=A"
>
> Now, acquireTGTFromCache returns the TGT for A in LSA. However, if
>
> 3. User run "kinit B" and generate a file cache for user B
>
> acquireTGTFromCache returns NULL, since the TGT for B in fcache is 
> first returned and then ignored.
>
> On Jan 2, 2008, at 8:39 PM, Andrew Fan wrote:
>
>> Just as the comments, "// The default ticket cache on Windows is not 
>> a file." So I don't think there are some credentials missed, or won't 
>> get read.
>>
>> For the send question, the current CredentialsCache is implemented as 
>> a file based cache.  It's a good idea that we adjust the 
>> CredentialsCache to accept LSA on windows platform.  I made a few 
>> updates on MemoryCredentialsCache, and CredentialsCache  to accept  
>> MemoryCredentialsCache months ago, I haven't test it completely. I 
>> never thought about that it could be used to improve the 
>> acquireTGTFromCache.
>
> Oh, this is cool. The whole ccache picture for Windows may include 
> file cache, MIT-style in-memory cache, Windows LSA cache. Does this 
> mean there should return 3 kinds of CredentialsCache objects? Is 
> something like CredentialsCache.getAllInstances() needed?
>
> Thanks
> Max
>
>>
>> Andrew
>>
>> Weijun Max Wang wrote:
>>> Hi All
>>>
>>> Current sun.security.krb5.Credentials's acquireTGTFromCache method 
>>> looks
>>> like --
>>>
>>> Cred acquireTGTFromCache(princ, fcache) {
>>>   if (fcache not specified) {
>>>     if (Windows) {
>>>       cred = function {
>>>         get default TGT from default file cache;
>>>         if (found && etypeSupported) return it;
>>>         else return one from LSA;
>>>       }
>>>       if (princ specified && princ is not princ in cred)
>>>         return null;
>>>       else
>>>         return cred;
>>>     }
>>>   }
>>>   read cred for princ in fcache
>>>   if (found && etypeSupported) return it;
>>>   else return null;
>>> }
>>>
>>> It seems there's a chance on Windows that the default TGT in default
>>> file cache (fcache == null) is not for princ, but maybe there's one for
>>> princ in LSA. It won't get read.
>>>
>>> Right? Shall we just move the whole fcache to the beginning and only 
>>> use
>>> LSA as a fallback?
>>>
>>> Thanks
>>> Max
>>>
>>>
>>
>



From Sean.Mullan at Sun.COM  Wed Jan  2 16:09:50 2008
From: Sean.Mullan at Sun.COM (Sean Mullan)
Date: Wed, 02 Jan 2008 11:09:50 -0500
Subject: [security-dev 00036]: Re: Code review request: 6634644 broken
 fragment, should use @link
In-Reply-To: <BD96F70A-CD58-4D72-8718-B170655ED2FF@Sun.COM>
References: <BD96F70A-CD58-4D72-8718-B170655ED2FF@Sun.COM>
Message-ID: <477BB74E.7090502@sun.com>

Hi Max,

The fix looks fine.

--Sean

Max (Weijun) Wang wrote:
> Hi Sean
> 
> There's a bug on spec inside javax.security.cert.X509Certificate
> 
> -----START BUG REPORT-----
> 6634644 broken fragment, should use @link
> 
> Broken fragment in api doc, following lines in 
> javax/security/cert/X509Certificate.java should be fixed.
> line 366:     * <p>See <a href = "#getIssuerDN">getIssuerDN</a> for 
> <code>Name</code>
>         broken fragment #getIssuerDN
>         should use {@link #getIssuerDN getIssuerDN}
> similar for following:
> line 396:     * the certificate. See <a href = 
> "#getNotBefore">getNotBefore</a>
> line 432:     * <p>See <a href = "#getSigAlgName">getSigAlgName</a> for
> line 445:     * <p>See <a href = "#getSigAlgName">getSigAlgName</a> for
> -----END BUG REPORT-----
> 
> The package is now obsolete. However, since the API is still externally 
> exported, I suggest fixing it. Here's the patch:
> 
> --- a/src/share/classes/javax/security/cert/X509Certificate.java    Wed 
> Dec 19 13:42:51 2007 +0800
> +++ b/src/share/classes/javax/security/cert/X509Certificate.java    Mon 
> Dec 24 18:59:54 2007 +0800
> @@ -363,7 +363,7 @@ public abstract class X509Certificate ex
>       * subject    Name
>       * </pre>
>       *
> -     * <p>See <a href = "#getIssuerDN">getIssuerDN</a> for 
> <code>Name</code>
> +     * <p>See {@link #getIssuerDN() getIssuerDN} for <code>Name</code>
>       * and other relevant definitions.
>       *
>       * @return a Principal whose name is the subject name.
> @@ -393,7 +393,7 @@ public abstract class X509Certificate ex
> 
>      /**
>       * Gets the <code>notAfter</code> date from the validity period of
> -     * the certificate. See <a href = "#getNotBefore">getNotBefore</a>
> +     * the certificate. See {@link #getNotBefore() getNotBefore}
>       * for relevant ASN.1 definitions.
>       *
>       * @return the end date of the validity period.
> @@ -429,7 +429,7 @@ public abstract class X509Certificate ex
>       * For example, the string "1.2.840.10040.4.3" identifies the SHA-1
>       * with DSA signature algorithm, as per the PKIX part I.
>       *
> -     * <p>See <a href = "#getSigAlgName">getSigAlgName</a> for
> +     * <p>See {@link #getSigAlgName() getSigAlgName} for
>       * relevant ASN.1 definitions.
>       *
>       * @return the signature algorithm OID string.
> @@ -442,7 +442,7 @@ public abstract class X509Certificate ex
>       * algorithm parameters are null; the parameters are usually
>       * supplied with the certificate's public key.
>       *
> -     * <p>See <a href = "#getSigAlgName">getSigAlgName</a> for
> +     * <p>See {@link #getSigAlgName() getSigAlgName} for
>       * relevant ASN.1 definitions.
>       *
>       * @return the DER-encoded signature algorithm parameters, or
> 
> Can you take a code review please?
> 
> Thanks
> Max
> 
> ps. I find it ultra inconvenient to ask for a code review while the bug 
> db and code repo is still not in the open, but will give it a try for 
> this tiny bug.



From Sean.Mullan at Sun.COM  Mon Jan  7 21:42:14 2008
From: Sean.Mullan at Sun.COM (Sean Mullan)
Date: Mon, 07 Jan 2008 16:42:14 -0500
Subject: [security-dev 00037]: Re: [Fwd: Re: JAVASEC - Problem running JAAS
 client from tutorial]
In-Reply-To: <477B50BA.6020903@sun.com>
References: <477B50BA.6020903@sun.com>
Message-ID: <47829CB6.9050401@sun.com>

Weijun Max Wang wrote:
> Hi All
> 
> I've tried to disable realm name case check in JDK (equals ->
> equalsIgnoreCase), and it works. In fact, I do several experiments to
> change the case of principal names, realm names, service names and
> hostnames, and MSAD just doesn't care. This is another case of
> Microsoft's long term habit of ignoring cases (BASIC language, file
> names, user names...).

This might work when interoperating with a Microsoft KDC, but what about 
with other KDC implementations where realms are case-sensitive? (i.e. 
"FOO" != "foo")

--Sean


From Bradford.Wetmore at Sun.COM  Wed Jan  9 02:15:55 2008
From: Bradford.Wetmore at Sun.COM (Brad Wetmore)
Date: Tue, 08 Jan 2008 18:15:55 -0800
Subject: [security-dev 00038]:  JCE webrev requested...
Message-ID: <47842E5B.6010204@sun.com>


Valerie,

Here's that PBE memory leak bug which was calling "new SunJCE" for every
PBE key created.

      Fixed 6578538: com.sun.crypto.provider.SunJCE instance leak using
KRB5 and LoginContext

I had the option to either fix by:

      Mac.getInstance(alg)

or

      Mac.getInstance(alg, "SunJCE");

Decided to go with the former, as Hmac1Sha1 should be standard across impls.

I'm attaching the webrev in case external folks want to see, I'll send
you the internal link separately.

This will be backported.

Brad

-------------- next part --------------
A non-text attachment was scrubbed...
Name: webrev.zip
Type: application/x-zip-compressed
Size: 54127 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20080108/7b86ae20/webrev.zip>

From Bradford.Wetmore at Sun.COM  Wed Jan  9 02:43:53 2008
From: Bradford.Wetmore at Sun.COM (Brad Wetmore)
Date: Tue, 08 Jan 2008 18:43:53 -0800
Subject: [security-dev 00039]: Re: JDK 7 build 24 is available at the
	openjdk.java.net website
In-Reply-To: <476E835E.1020308@nefkom.net>
References: <47563FCC.4080907@sun.com> <475D7AB3.8060000@redhat.com>
	<475DDA7F.1080302@sun.com> <47606D05.2040709@nefkom.net>
	<476AE241.1050801@sun.com> <476AF2A7.1000009@nefkom.net>
	<476B1835.6010408@sun.com> <476E835E.1020308@nefkom.net>
Message-ID: <478434E9.9080207@sun.com>

*Moving the discussion to security-dev)

I'm glad Andreas was able to help you resolve your issue while I was on 
vacation.

There is one more minor issue which came out of this discussion.  I 
included the Release.gmk files too early in my crypto Makefiles, and as 
a result, gnumake by itself will fail because the wrong default target 
is made.

6644659:  Error in default target of make/javax/crypto in OpenJDK build

As a workaround, simply specify the desired target, such as:

     % gnumake all

This won't affect the default OpenJDK builds, as they build "all" by 
default.

Thanks, and Happy New Year.

Brad

Arnd-Hendrik Mathias wrote:
> Hi Andreas,
> 
> Andreas Sterbenz wrote:
>> See below output of a rebuild of make/javax/crypto after a previous 
>> build of a fresh clone of the Mercurial jdk repository. If you see 
>> something different, that must be related to your build environment, 
>> e.g. version of make used, out of date binary plugs, etc.
> Since my output looked quite different, it was not really comparable 
> with the correct output you posted. After further examination of the 
> make-/build environment, I found out that the make environment assumes 
> some tools to reside in /usr/bin per default. I found that this can be 
> overwritten by the ALT_USRBIN_PATH variable. However, if tools reside in 
> different directories (/bin /usr/bin ...) setting
> 
> ALT_USRBIN_PATH=                <empty>
> 
> and having the PATH variable set to have all these tools available 
> directly may be the method the most likely to work. In my special case 
> "head" was missing, residing in /bin on my system.
> 


From Yu-Ching.Peng at Sun.COM  Thu Jan 10 22:09:14 2008
From: Yu-Ching.Peng at Sun.COM (Valerie (Yu-Ching) Peng)
Date: Thu, 10 Jan 2008 14:09:14 -0800
Subject: [security-dev 00040]: Re: JCE webrev requested...
In-Reply-To: <47842E5B.6010204@sun.com>
References: <47842E5B.6010204@sun.com>
Message-ID: <4786978A.8000805@sun.com>


The changes look fine although I prefer the later, e.g. explicitly 
specifies SunJCE to be used, slightly since it does not depend on other 
provider(s).
Thanks,
Valerie

Brad Wetmore wrote:
>
> Valerie,
>
> Here's that PBE memory leak bug which was calling "new SunJCE" for every
> PBE key created.
>
>      Fixed 6578538: com.sun.crypto.provider.SunJCE instance leak using
> KRB5 and LoginContext
>
> I had the option to either fix by:
>
>      Mac.getInstance(alg)
>
> or
>
>      Mac.getInstance(alg, "SunJCE");
>
> Decided to go with the former, as Hmac1Sha1 should be standard across 
> impls.
>
> I'm attaching the webrev in case external folks want to see, I'll send
> you the internal link separately.
>
> This will be backported.
>
> Brad



From Bradford.Wetmore at Sun.COM  Fri Jan 11 07:29:24 2008
From: Bradford.Wetmore at Sun.COM (Brad Wetmore)
Date: Thu, 10 Jan 2008 23:29:24 -0800
Subject: [security-dev 00041]: Re: JCE webrev requested...
In-Reply-To: <4786978A.8000805@sun.com>
References: <47842E5B.6010204@sun.com> <4786978A.8000805@sun.com>
Message-ID: <47871AD4.5060808@sun.com>

I could have gone either way.  I'll change to what you suggested.

Thanks for the review.

Brad


Valerie (Yu-Ching) Peng wrote:
> 
> The changes look fine although I prefer the later, e.g. explicitly 
> specifies SunJCE to be used, slightly since it does not depend on other 
> provider(s).
> Thanks,
> Valerie
> 
> Brad Wetmore wrote:
>>
>> Valerie,
>>
>> Here's that PBE memory leak bug which was calling "new SunJCE" for every
>> PBE key created.
>>
>>      Fixed 6578538: com.sun.crypto.provider.SunJCE instance leak using
>> KRB5 and LoginContext
>>
>> I had the option to either fix by:
>>
>>      Mac.getInstance(alg)
>>
>> or
>>
>>      Mac.getInstance(alg, "SunJCE");
>>
>> Decided to go with the former, as Hmac1Sha1 should be standard across 
>> impls.
>>
>> I'm attaching the webrev in case external folks want to see, I'll send
>> you the internal link separately.
>>
>> This will be backported.
>>
>> Brad
> 


From deepak.cute123 at gmail.com  Sun Jan 13 12:37:46 2008
From: deepak.cute123 at gmail.com (deepak sahu)
Date: Sun, 13 Jan 2008 18:07:46 +0530
Subject: [security-dev 00042]: Application of blind signature concept on
	ECDSA and incorporating that into JDK 7
Message-ID: <6fce480801130437o76df35b9k1d88ce8d783fdb7a@mail.gmail.com>

We have fullfledged concept fo how to generate points on EC and are working
on new blind signature concept.
We have also implemented our idea in java.

Any one can guide us in including thi  RFE  into jdk7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20080113/1361a8bd/attachment.htm>

From deepak.cute123 at gmail.com  Sun Jan 13 12:43:28 2008
From: deepak.cute123 at gmail.com (deepak sahu)
Date: Sun, 13 Jan 2008 18:13:28 +0530
Subject: [security-dev 00043]: Application of blind signature concept on
	ECDSA and incorporating that into JDK 7
Message-ID: <6fce480801130443s631c9b0ch23c2983d6a23da88@mail.gmail.com>

We have fullfledged concept fo how to generate points on EC and are working
on new blind signature concept.
We have also implemented our idea in java.

Any one can guide us in including thi  RFE  into jdk7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20080113/c40db59a/attachment.htm>

From Weijun.Wang at Sun.COM  Mon Jan 14 13:55:40 2008
From: Weijun.Wang at Sun.COM (Max (Weijun) Wang)
Date: Mon, 14 Jan 2008 21:55:40 +0800
Subject: [security-dev 00044]:  LSA ticket question
Message-ID: <18EBB015-4D8C-4117-9484-924B5F794717@sun.com>

Hi Andrew

Want to confirm something with you: There are some kinds of Kerberos  
tickets inside the LSA cache that you can never get the encoded form,  
right?

I've seen a ticket in kerbtray.exe that's flagged FORWARDED, but  
never find out how to get its encoded form, therefore cannot use it  
in Java.

Thanks
Max



From deepak.cute123 at gmail.com  Mon Jan 14 13:59:03 2008
From: deepak.cute123 at gmail.com (deepak sahu)
Date: Mon, 14 Jan 2008 09:59:03 -0400
Subject: [security-dev 00045]: Re: LSA ticket question
In-Reply-To: <18EBB015-4D8C-4117-9484-924B5F794717@sun.com>
References: <18EBB015-4D8C-4117-9484-924B5F794717@sun.com>
Message-ID: <6fce480801140559j6e5813e7v57f5df5394f55bae@mail.gmail.com>

hi friends

Do u find ECC implemented completely in jdk6?

if yes,plz help me find it out.i.e ource file

On 1/14/08, Max (Weijun) Wang <Weijun.Wang at sun.com> wrote:
> Hi Andrew
>
> Want to confirm something with you: There are some kinds of Kerberos
> tickets inside the LSA cache that you can never get the encoded form,
> right?
>
> I've seen a ticket in kerbtray.exe that's flagged FORWARDED, but
> never find out how to get its encoded form, therefore cannot use it
> in Java.
>
> Thanks
> Max
>
>


From Weijun.Wang at Sun.COM  Mon Jan 14 14:04:36 2008
From: Weijun.Wang at Sun.COM (Max (Weijun) Wang)
Date: Mon, 14 Jan 2008 22:04:36 +0800
Subject: [security-dev 00046]:  ECC (was Re:  LSA ticket question)
In-Reply-To: <6fce480801140559j6e5813e7v57f5df5394f55bae@mail.gmail.com>
References: <18EBB015-4D8C-4117-9484-924B5F794717@sun.com>
	<6fce480801140559j6e5813e7v57f5df5394f55bae@mail.gmail.com>
Message-ID: <51412B0C-EACE-4069-A60B-56C9C6527DC6@Sun.COM>

Hi Deepak

The ECC has an interface but no Java implementation in Java 6.  
However, you can use ECC through a PKCS11 native provider. Read  
Andreas' blog at
     http://blogs.sun.com/andreas/entry/firefox_2_0_ecc_and
(also read the "here and here" links in the article)

A 100% Java implementation should be available in JDK 7.

Max

On Jan 14, 2008, at 9:59 PM, deepak sahu wrote:

> hi friends
>
> Do u find ECC implemented completely in jdk6?
>
> if yes,plz help me find it out.i.e ource file
>
> On 1/14/08, Max (Weijun) Wang <Weijun.Wang at sun.com> wrote:
>> Hi Andrew
>>
>> Want to confirm something with you: There are some kinds of Kerberos
>> tickets inside the LSA cache that you can never get the encoded form,
>> right?
>>
>> I've seen a ticket in kerbtray.exe that's flagged FORWARDED, but
>> never find out how to get its encoded form, therefore cannot use it
>> in Java.
>>
>> Thanks
>> Max
>>
>>



From Andrew.Fan at Sun.COM  Mon Jan 14 14:07:58 2008
From: Andrew.Fan at Sun.COM (Andrew Fan)
Date: Mon, 14 Jan 2008 22:07:58 +0800
Subject: [security-dev 00047]: Re: LSA ticket question
In-Reply-To: <18EBB015-4D8C-4117-9484-924B5F794717@sun.com>
References: <18EBB015-4D8C-4117-9484-924B5F794717@sun.com>
Message-ID: <478B6CBE.5080407@Sun.COM>

Max (Weijun) Wang wrote:
> Hi Andrew
>
> Want to confirm something with you: There are some kinds of Kerberos 
> tickets inside the LSA cache that you can never get the encoded form, 
> right?
>
I don't have any experience on this issue. But I think even if it is a 
ticket, so it is should encoded in standard format, that's the way the 
ticket exchanged among peers, I will try to look into it tomorrow or the 
day after tomorrow.

Andrew
> I've seen a ticket in kerbtray.exe that's flagged FORWARDED, but never 
> find out how to get its encoded form, therefore cannot use it in Java.
>
> Thanks
> Max
>



From Weijun.Wang at Sun.COM  Mon Jan 14 14:14:25 2008
From: Weijun.Wang at Sun.COM (Max (Weijun) Wang)
Date: Mon, 14 Jan 2008 22:14:25 +0800
Subject: [security-dev 00048]: Re: LSA ticket question
In-Reply-To: <478B6CBE.5080407@Sun.COM>
References: <18EBB015-4D8C-4117-9484-924B5F794717@sun.com>
	<478B6CBE.5080407@Sun.COM>
Message-ID: <EF455F54-EF20-4599-9F28-D0B01F9F72A8@Sun.COM>

I have doubt. I find two kinds of struct for Kerberos ticket:  
KERB_EXTERNAL_TICKET, and KERB_TICEKT_CACHE_INFO. The former include  
an encoded form field, the later only name and flags etc. I can get  
an KERB_TICEKT_CACHE_INFO object for the FORWARDED ticket, but cannot  
find a way to convert it into KERB_EXTERNAL_TICKET.

Max


On Jan 14, 2008, at 10:07 PM, Andrew Fan wrote:

> Max (Weijun) Wang wrote:
>> Hi Andrew
>>
>> Want to confirm something with you: There are some kinds of  
>> Kerberos tickets inside the LSA cache that you can never get the  
>> encoded form, right?
>>
> I don't have any experience on this issue. But I think even if it  
> is a ticket, so it is should encoded in standard format, that's the  
> way the ticket exchanged among peers, I will try to look into it  
> tomorrow or the day after tomorrow.
>
> Andrew
>> I've seen a ticket in kerbtray.exe that's flagged FORWARDED, but  
>> never find out how to get its encoded form, therefore cannot use  
>> it in Java.
>>
>> Thanks
>> Max
>>
>



From jjarrett at tresys.com  Tue Jan 22 21:50:23 2008
From: jjarrett at tresys.com (Jonathan Jarrett)
Date: Tue, 22 Jan 2008 16:50:23 -0500
Subject: [security-dev 00049]:  Guidance on Class loading,
	specifically Bootstrap process...
Message-ID: <1201038623.18283.5.camel@d49jhj91>

I'm trying to understand the start up procedure of the JVM, specifically
how it loads the bootstrap SecurityManager. I keep getting wrapped
around the axle.  Any direction as to where to research would be
appreciated.

Thanks,

Jonathan Jarrett



From Thomas.Hawtin at Sun.COM  Fri Jan 25 13:26:23 2008
From: Thomas.Hawtin at Sun.COM (Thomas Hawtin)
Date: Fri, 25 Jan 2008 13:26:23 +0000
Subject: [security-dev 00050]: Re: Guidance on Class loading,
	specifically Bootstrap process...
In-Reply-To: <1201038623.18283.5.camel@d49jhj91>
References: <1201038623.18283.5.camel@d49jhj91>
Message-ID: <4799E37F.3000004@Sun.COM>

Jonathan Jarrett wrote:
> I'm trying to understand the start up procedure of the JVM, specifically
> how it loads the bootstrap SecurityManager. I keep getting wrapped
> around the axle.  Any direction as to where to research would be
> appreciated.

By bootstrap SecurityManager, do you mean the security manager loaded 
through the use of -Djava.security.manager? That is handled by 
sun.misc.Launcher. That also deals with extension and system class loaders.

Tom Hawtin


From briefkasten at uebber.de  Sat Jan 26 18:12:46 2008
From: briefkasten at uebber.de (Christian Uebber)
Date: Sat, 26 Jan 2008 19:12:46 +0100
Subject: [security-dev 00051]:  DTLS design
In-Reply-To: <474F6A8F.1050906@sun.com>
References: <A59157C1-9468-469F-B040-32F2F41E427B@uebber.de>
	<474F6A8F.1050906@sun.com>
Message-ID: <EFB73321-2D3D-4907-9F1B-A5EAC783639E@uebber.de>

Dear Andreas,

due to some other current business my DTLS efforts were set back for a  
couple of weeks. But I'm happy to be back on the task now. First I'd  
like to discuss some architectural issues. I have put much time into  
working out the best way of integrating DTLS into the current APIs as  
transparently as possible. All solutions have specific trade-offs.

The main class most users would use is going to be TLSDatagramSocket  
extending the well known DatagramSocket. The first design choice would  
be - DTLS differentiates between client and server - if we should keep  
an unified DatagramSocket class without a dedicated  
DatagramServerSocket. I would say yes and I think that's an easy one.  
Users shouldn't be forced to understand different Java networking  
concepts if all what is added is an additional security layer. There  
are also sessions to be managed, but this is also possible in a  
transparent way without a dedicated server class. For security reasons  
a method as acceptHandshakeRequests(boolean b) could be added to  
enable or disable server like behavior.

In any case threads accessing the main I/O methods send(DatagramPacket  
p) and receive() should never be blocked by security layer events, as  
they are needed for bulk transfers from and to anywhere at any time.  
Of course there must be mechanisms (e.g. callbacks) for users wanting  
extended control.

TLS over TCP could attach session information to created sockets in a  
1:1 relationship. As we have just one (TLS)DatagramSocket socket for  
any potential endpoint (1:n) this cannot be done easily in the case of  
UDP. Since Java programmers never had to care about anything else but  
single DatagramPackets in their application space, this shouldn't  
change for anybody who doesn't need to deal with cryptographic  
details. So my proposal would be letting sessions be managed by the  
socket, but exposing control to those who need it.

Trying to accomplish full transparency on the receiving side is quite  
easy. All packets for which there is no established session object and  
which are not handshake requests are silently dropped. Handshake  
requests instead get forwared to a Handshaker class, packets belonging  
to an established session get unwrapped and are then fired through the  
send-method of the attached TLSDatagramSocket.

Transparency on the sending side implies some trade-off decisions in  
cases where the send-method gets packets for destinations without an  
already established session.

Full Transparency:
Session initiation is started, packets for an unestablished target are  
buffered until the session is established and then sent (or dropped if  
establishment failed).
Session initiation is started, packets get dropped (nobody promised  
that UDP would be reliable).
Manual Session Initiation: A method as initiateSession(InetAddress a,  
int port, CallbackHandler c) must be called before any packet can be  
send to a specific endpoint.

Buffers could fill up quite quickly under heavy load in the case of  
1.1. In the case of 1.2 no promises are broken, but it's not really  
good style. An average handshake can take a second and a lot of  
packets can already be lost during this time. The case No. 2 wouldn't  
be usable as a drop-in replacement anymore.

Maybe some aspects could be combined for the best solution. What do  
you think?

But that should be it for today... I'm looking forward to your remarks.


Christian


PS	I've emailed the signed SCA today. It should get registered soon.


Am 30.11.2007 um 02:42 schrieb Andreas Sterbenz:

> Christian Uebber wrote:
>> Is anybody already working on this for Java DatagramSockets? I'd be  
>> interested in doing the work. Integration into and reuse of the  
>> existing JSSE code would also be my preferred way to go.
>
> That sounds like a great idea. We at Sun don't have any current  
> plans to implement DTLS due to a lack of resources, but we could  
> assist by answering questions about JSSE or commenting on your code.  
> There are also some architectural issues about fitting a secure  
> datagram transport into the current Networking APIs that we may want  
> to discuss.
>
> BTW, you may want to look into signing the contributor agreement: http://openjdk.java.net/contribute/
>
> Andreas.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20080126/4d77c776/attachment.htm>

From fw at deneb.enyo.de  Sun Jan 27 10:54:33 2008
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sun, 27 Jan 2008 11:54:33 +0100
Subject: [security-dev 00052]: Re: DTLS design
In-Reply-To: <EFB73321-2D3D-4907-9F1B-A5EAC783639E@uebber.de> (Christian
	Uebber's message of "Sat, 26 Jan 2008 19:12:46 +0100")
References: <A59157C1-9468-469F-B040-32F2F41E427B@uebber.de>
	<474F6A8F.1050906@sun.com>
	<EFB73321-2D3D-4907-9F1B-A5EAC783639E@uebber.de>
Message-ID: <877ihv5yja.fsf@mid.deneb.enyo.de>

* Christian Uebber:

> TLS over TCP could attach session information to created sockets in a
> 1:1 relationship.

There's a separate class for non-TCP (but TCP-like) TLS called
SSLEngine.  Perhaps you can expose a similar class for DTLS?  This way,
your implementation would not be tied to UDP.


From briefkasten at uebber.de  Sun Jan 27 14:29:44 2008
From: briefkasten at uebber.de (Christian Uebber)
Date: Sun, 27 Jan 2008 15:29:44 +0100
Subject: [security-dev 00053]: Re: DTLS design
In-Reply-To: <877ihv5yja.fsf@mid.deneb.enyo.de>
References: <A59157C1-9468-469F-B040-32F2F41E427B@uebber.de>
	<474F6A8F.1050906@sun.com>
	<EFB73321-2D3D-4907-9F1B-A5EAC783639E@uebber.de>
	<877ihv5yja.fsf@mid.deneb.enyo.de>
Message-ID: <C5BEF9D7-4CB1-4825-89F3-78A1B647F912@uebber.de>


Am 27.01.2008 um 11:54 schrieb Florian Weimer:

> * Christian Uebber:
>
>> TLS over TCP could attach session information to created sockets in a
>> 1:1 relationship.
>
> There's a separate class for non-TCP (but TCP-like) TLS called
> SSLEngine.  Perhaps you can expose a similar class for DTLS?  This  
> way,
> your implementation would not be tied to UDP.
>

SSLEngine is very interesting. It would be nice to have the something  
similar or an extended version for packet oriented data. My initial  
plan was finishing the work on the possibly simpler blocking parts and  
then to continue towards the nio-classes. But I may also go for a nio  
centered approach from the beginning and build the TLSDatagramSocket  
on top of that.


From sgodsell at hotmail.com  Mon Jan 28 18:26:05 2008
From: sgodsell at hotmail.com (Sean Godsell)
Date: Mon, 28 Jan 2008 13:26:05 -0500
Subject: [security-dev 00054]:  Addition to the jdk
Message-ID: <BAY123-W10EA5D11555D2449E12EF1C6340@phx.gbl>


Hello openjdk people,

I have a patch that can enhance Java in a number of areas.  The following is a list of enhancements:
    - Overwrite and lock users file paths to a specific base path
    - All temporary files can automatically be created in the base path
    - You can limit the amount of storage being used in a path or file
    - You can limit the # of file and directories being created in path
    - You can make any path read only or read/write
    - You can allow or deny whether libraries can be loaded from a path.
    - You can allow or deny whether native methods can be used from a path.
    - You can have multiple paths to allow users to read or write to with different
       limiting storage and or # or files and directories.
    - You can limit the number of threads and thread priority.
    - You can limit the maximum # of windows being created.
    - You can allow or deny hosts and ports being used.
    - You can allow or deny execution of runtime process.
    - You can limit the amount of socket traffic throughput in bytes per second
    - All items can be controlled in a simple properties file

Now I know a security manager could do a few of the items listed, but with this update you can still use the security manager.  There are a few other things, but in order to get a complete view and the source code go to the following site:
    http://sourceforge.net/projects/javasss/

Sean Godsell


_________________________________________________________________



From briefkasten at uebber.de  Tue Jan 29 00:48:16 2008
From: briefkasten at uebber.de (Christian Uebber)
Date: Tue, 29 Jan 2008 01:48:16 +0100
Subject: [security-dev 00055]:  State of TLS 1.1 implementation
Message-ID: <29F10BCC-BB07-4CC9-9A52-55C791D66F15@uebber.de>

The SunJSSE of CBC mode is insecure against chosen plaintext attacks  
(as all TLS 1.0 implemetations). What's the state of TLS 1.1 support  
for (Open)JDK 7?

TLS 1.1 adds explicit IVs, which is a viable fix for the vulnerability  
and also removes inter-record dependency. The latter is needed by DTLS  
for loss insensitive messaging.


From andrew.fan at sun.com  Tue Jan 29 03:17:19 2008
From: andrew.fan at sun.com (Andrew Fan)
Date: Tue, 29 Jan 2008 11:17:19 +0800
Subject: [security-dev 00056]: Re: State of TLS 1.1 implementation
In-Reply-To: <29F10BCC-BB07-4CC9-9A52-55C791D66F15@uebber.de>
References: <29F10BCC-BB07-4CC9-9A52-55C791D66F15@uebber.de>
Message-ID: <479E9ABF.20407@Sun.COM>

Christian Uebber wrote:
> The SunJSSE of CBC mode is insecure against chosen plaintext attacks 
> (as all TLS 1.0 implemetations). What's the state of TLS 1.1 support 
> for (Open)JDK 7?
>
We plan support TLS1.1 for JDK 7, the implementation is in progress.

Andrew
> TLS 1.1 adds explicit IVs, which is a viable fix for the vulnerability 
> and also removes inter-record dependency. The latter is needed by DTLS 
> for loss insensitive messaging.



From Andreas.Sterbenz at Sun.COM  Tue Jan 29 08:52:38 2008
From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz)
Date: Tue, 29 Jan 2008 00:52:38 -0800
Subject: [security-dev 00057]: Re: DTLS design
In-Reply-To: <EFB73321-2D3D-4907-9F1B-A5EAC783639E@uebber.de>
References: <A59157C1-9468-469F-B040-32F2F41E427B@uebber.de>
	<474F6A8F.1050906@sun.com>
	<EFB73321-2D3D-4907-9F1B-A5EAC783639E@uebber.de>
Message-ID: <479EE956.9030700@sun.com>

Christian,

as you point out, in a datagram world some things are more complicated and 
there are more choices to make than in a socket world. How to handle 
handshaking, buffer data, etc. This is in many ways similar to the issues 
that came up for TLS with non-blocking I/O. There we made the decision to 
decouple the TLS aspects (SSLEngine) from the I/O aspects. That way the 
choices of how to do I/O, how many threads to use and for which tasks, 
etc. are left to the application developer.

A similar approach may be useful here. In fact, you may be able to use the 
existing SSLEngine API and write an implementation that does DTLS instead 
of SSL/TLS. Note that SSLEngine is not tied to java.nio at all. The only 
link to NIO in the API is the use of ByteBuffers as a generic abstraction 
for a memory region.

Of course, having a drop-in replacement for DatagramSocket is still 
useful. That could be implemented on top of the DTLS engine as as simple 
way for applications to use DTLS without the extra flexibility of the engine.

What do you think?

Andreas.


Christian Uebber wrote:
> Dear Andreas,
> 
> due to some other current business my DTLS efforts were set back for a 
> couple of weeks. But I'm happy to be back on the task now. First I'd 
> like to discuss some architectural issues. I have put much time into 
> working out the best way of integrating DTLS into the current APIs as 
> transparently as possible. All solutions have specific trade-offs.
> 
> The main class most users would use is going to 
> be TLSDatagramSocket extending the well known DatagramSocket. The first 
> design choice would be - DTLS differentiates between client and server - 
> if we should keep an unified DatagramSocket class without a dedicated 
> DatagramServerSocket. I would say yes and I think that's an easy one. 
> Users shouldn't be forced to understand different Java networking 
> concepts if all what is added is an additional security layer. There are 
> also sessions to be managed, but this is also possible in a transparent 
> way without a dedicated server class. For security reasons a method as 
> acceptHandshakeRequests(boolean b) could be added to enable or disable 
> server like behavior.
> 
> In any case threads accessing the main I/O methods send(DatagramPacket 
> p) and receive() should never be blocked by security layer events, as 
> they are needed for bulk transfers from and to anywhere at any time. Of 
> course there must be mechanisms (e.g. callbacks) for users wanting 
> extended control.
> 
> TLS over TCP could attach session information to created sockets in a 
> 1:1 relationship. As we have just one (TLS)DatagramSocket socket for any 
> potential endpoint (1:n) this cannot be done easily in the case of UDP. 
> Since Java programmers never had to care about anything else but single 
> DatagramPackets in their application space, this shouldn't change for 
> anybody who doesn't need to deal with cryptographic details. So my 
> proposal would be letting sessions be managed by the socket, but 
> exposing control to those who need it.
> 
> Trying to accomplish full transparency on the receiving side is quite 
> easy. All packets for which there is no established session object and 
> which are not handshake requests are silently dropped. Handshake 
> requests instead get forwared to a Handshaker class, packets belonging 
> to an established session get unwrapped and are then fired through the 
> send-method of the attached TLSDatagramSocket.
> 
> Transparency on the sending side implies some trade-off decisions in 
> cases where the send-method gets packets for destinations without an 
> already established session.
> 
>    1. Full Transparency:
>          1. Session initiation is started, packets for an unestablished
>             target are buffered until the session is established and
>             then sent (or dropped if establishment failed).
>          2. Session initiation is started, packets get dropped (nobody
>             promised that UDP would be reliable).
>    2. Manual Session Initiation: A method as initiateSession(InetAddress
>       a, int port, CallbackHandler c) must be called before any packet
>       can be send to a specific endpoint.
> 
> 
> Buffers could fill up quite quickly under heavy load in the case of 1.1. 
> In the case of 1.2 no promises are broken, but it's not really good 
> style. An average handshake can take a second and a lot of packets can 
> already be lost during this time. The case No. 2 wouldn't be usable as a 
> drop-in replacement anymore.
> 
> Maybe some aspects could be combined for the best solution. What do you 
> think?
> 
> But that should be it for today... I'm looking forward to your remarks.
> 
> 
> Christian
> 
> 
> PS I've emailed the signed SCA today. It should get registered soon.
> 
> 
> Am 30.11.2007 um 02:42 schrieb Andreas Sterbenz:
> 
>> Christian Uebber wrote:
>>> Is anybody already working on this for Java DatagramSockets? I'd be 
>>> interested in doing the work. Integration into and reuse of the 
>>> existing JSSE code would also be my preferred way to go.
>>
>> That sounds like a great idea. We at Sun don't have any current plans 
>> to implement DTLS due to a lack of resources, but we could assist by 
>> answering questions about JSSE or commenting on your code. There are 
>> also some architectural issues about fitting a secure datagram 
>> transport into the current Networking APIs that we may want to discuss.
>>
>> BTW, you may want to look into signing the contributor agreement: 
>> http://openjdk.java.net/contribute/
>>
>> Andreas.
>>
>>
> 



From briefkasten at uebber.de  Tue Jan 29 11:39:08 2008
From: briefkasten at uebber.de (Christian Uebber)
Date: Tue, 29 Jan 2008 12:39:08 +0100
Subject: [security-dev 00058]: Re: DTLS design
In-Reply-To: <479EE956.9030700@sun.com>
References: <A59157C1-9468-469F-B040-32F2F41E427B@uebber.de>
	<474F6A8F.1050906@sun.com>
	<EFB73321-2D3D-4907-9F1B-A5EAC783639E@uebber.de>
	<479EE956.9030700@sun.com>
Message-ID: <3BBA6A01-3EDB-4528-886A-7A3BE893BD22@uebber.de>

The network and security layer are not as easily separable in the case  
of DTLS as they are in the case of TLS over TCP. During the exchange  
of control data (handshake, change_cipher_spec, alert) the network  
layer must provide reliability, but not anytime else.

As the SSLEngine must be extended anyway for a complete DTLS  
implementation, I'm going to follow your suggested route and do that  
first. I have had this option on the table anyways. Calling it the  
"nio centered approach" i was referring, in a historical sense, to the  
two traditional branches of network implementations in Java: the  
legacy blocking sockets with attached SSL functionality and the  
branch, which started with nio, where everything is nice, fresh, and  
clean. I may sometimes be prone to sloppy, not very precise English,  
when I'm missing precise vocabulary to express exactly what I want to  
say. But I think we'll work it out.

To make SSLEngine DTLS-able most changes do not affect its interface  
and could be implemented internally; for that alone we wouldn't even  
need a separate DTLSEngine. After all it's just  another record format  
and a slightly modified handshake. I haven't spend much time on the  
issue of how to integrate the reliable transport for the handshake  
phase into the completely network-independent design. I'll work that  
out and get back to you. If any ideas pop into your mind, let me know.

Christian




Am 29.01.2008 um 09:52 schrieb Andreas Sterbenz:

> Christian,
>
> as you point out, in a datagram world some things are more  
> complicated and there are more choices to make than in a socket  
> world. How to handle handshaking, buffer data, etc. This is in many  
> ways similar to the issues that came up for TLS with non-blocking I/ 
> O. There we made the decision to decouple the TLS aspects  
> (SSLEngine) from the I/O aspects. That way the choices of how to do  
> I/O, how many threads to use and for which tasks, etc. are left to  
> the application developer.
>
> A similar approach may be useful here. In fact, you may be able to  
> use the existing SSLEngine API and write an implementation that does  
> DTLS instead of SSL/TLS. Note that SSLEngine is not tied to java.nio  
> at all. The only link to NIO in the API is the use of ByteBuffers as  
> a generic abstraction for a memory region.
>
> Of course, having a drop-in replacement for DatagramSocket is still  
> useful. That could be implemented on top of the DTLS engine as as  
> simple way for applications to use DTLS without the extra  
> flexibility of the engine.
>
> What do you think?
>
> Andreas.
>
>
> Christian Uebber wrote:
>> Dear Andreas,
>> due to some other current business my DTLS efforts were set back  
>> for a couple of weeks. But I'm happy to be back on the task now.  
>> First I'd like to discuss some architectural issues. I have put  
>> much time into working out the best way of integrating DTLS into  
>> the current APIs as transparently as possible. All solutions have  
>> specific trade-offs.
>> The main class most users would use is going to be  
>> TLSDatagramSocket extending the well known DatagramSocket. The  
>> first design choice would be - DTLS differentiates between client  
>> and server - if we should keep an unified DatagramSocket class  
>> without a dedicated DatagramServerSocket. I would say yes and I  
>> think that's an easy one. Users shouldn't be forced to understand  
>> different Java networking concepts if all what is added is an  
>> additional security layer. There are also sessions to be managed,  
>> but this is also possible in a transparent way without a dedicated  
>> server class. For security reasons a method as  
>> acceptHandshakeRequests(boolean b) could be added to enable or  
>> disable server like behavior.
>> In any case threads accessing the main I/O methods  
>> send(DatagramPacket p) and receive() should never be blocked by  
>> security layer events, as they are needed for bulk transfers from  
>> and to anywhere at any time. Of course there must be mechanisms  
>> (e.g. callbacks) for users wanting extended control.
>> TLS over TCP could attach session information to created sockets in  
>> a 1:1 relationship. As we have just one (TLS)DatagramSocket socket  
>> for any potential endpoint (1:n) this cannot be done easily in the  
>> case of UDP. Since Java programmers never had to care about  
>> anything else but single DatagramPackets in their application  
>> space, this shouldn't change for anybody who doesn't need to deal  
>> with cryptographic details. So my proposal would be letting  
>> sessions be managed by the socket, but exposing control to those  
>> who need it.
>> Trying to accomplish full transparency on the receiving side is  
>> quite easy. All packets for which there is no established session  
>> object and which are not handshake requests are silently dropped.  
>> Handshake requests instead get forwared to a Handshaker class,  
>> packets belonging to an established session get unwrapped and are  
>> then fired through the send-method of the attached TLSDatagramSocket.
>> Transparency on the sending side implies some trade-off decisions  
>> in cases where the send-method gets packets for destinations  
>> without an already established session.
>>   1. Full Transparency:
>>         1. Session initiation is started, packets for an  
>> unestablished
>>            target are buffered until the session is established and
>>            then sent (or dropped if establishment failed).
>>         2. Session initiation is started, packets get dropped (nobody
>>            promised that UDP would be reliable).
>>   2. Manual Session Initiation: A method as  
>> initiateSession(InetAddress
>>      a, int port, CallbackHandler c) must be called before any packet
>>      can be send to a specific endpoint.
>> Buffers could fill up quite quickly under heavy load in the case of  
>> 1.1. In the case of 1.2 no promises are broken, but it's not really  
>> good style. An average handshake can take a second and a lot of  
>> packets can already be lost during this time. The case No. 2  
>> wouldn't be usable as a drop-in replacement anymore.
>> Maybe some aspects could be combined for the best solution. What do  
>> you think?
>> But that should be it for today... I'm looking forward to your  
>> remarks.
>> Christian
>> PS I've emailed the signed SCA today. It should get registered soon.
>> Am 30.11.2007 um 02:42 schrieb Andreas Sterbenz:
>>> Christian Uebber wrote:
>>>> Is anybody already working on this for Java DatagramSockets? I'd  
>>>> be interested in doing the work. Integration into and reuse of  
>>>> the existing JSSE code would also be my preferred way to go.
>>>
>>> That sounds like a great idea. We at Sun don't have any current  
>>> plans to implement DTLS due to a lack of resources, but we could  
>>> assist by answering questions about JSSE or commenting on your  
>>> code. There are also some architectural issues about fitting a  
>>> secure datagram transport into the current Networking APIs that we  
>>> may want to discuss.
>>>
>>> BTW, you may want to look into signing the contributor agreement: http://openjdk.java.net/contribute/
>>>
>>> Andreas.
>>>
>>>
>
>



From briefkasten at uebber.de  Tue Jan 29 13:56:12 2008
From: briefkasten at uebber.de (Christian Uebber)
Date: Tue, 29 Jan 2008 14:56:12 +0100
Subject: [security-dev 00059]: Re: DTLS design
In-Reply-To: <3BBA6A01-3EDB-4528-886A-7A3BE893BD22@uebber.de>
References: <A59157C1-9468-469F-B040-32F2F41E427B@uebber.de>
	<474F6A8F.1050906@sun.com>
	<EFB73321-2D3D-4907-9F1B-A5EAC783639E@uebber.de>
	<479EE956.9030700@sun.com>
	<3BBA6A01-3EDB-4528-886A-7A3BE893BD22@uebber.de>
Message-ID: <F5BA94C4-55B1-4C81-B4FB-CDDFE899C959@uebber.de>

I've finished a first sketch. The application knows about when the  
engine is handshaking by checking SSLEngineResult.HandshakeStatus. All  
we need to do is to provide a reliable UDP transport class (including  
fragmentation and reassembly) as defined in the DTLS spec, which MUST  
be used for transporting when the engine is not in the state of  
NOT_HANDSHAKING. Anything else could be seamlessly integrated into  
SSLEngine.

It would be nicer if this transport class wasn't specific to DTLS as  
current and future connectionless protocols could provide comparable  
features, but for DTLS 1.0 compliance I don't see a better way right  
now. We are not forced to make this specific class mandatory, so  
future implementations could just plug in alternatives when the  
standard evolves.

Christian

Am 29.01.2008 um 12:39 schrieb Christian Uebber:

> The network and security layer are not as easily separable in the  
> case of DTLS as they are in the case of TLS over TCP. During the  
> exchange of control data (handshake, change_cipher_spec, alert) the  
> network layer must provide reliability, but not anytime else.
>
> As the SSLEngine must be extended anyway for a complete DTLS  
> implementation, I'm going to follow your suggested route and do that  
> first. I have had this option on the table anyways. Calling it the  
> "nio centered approach" i was referring, in a historical sense, to  
> the two traditional branches of network implementations in Java: the  
> legacy blocking sockets with attached SSL functionality and the  
> branch, which started with nio, where everything is nice, fresh, and  
> clean. I may sometimes be prone to sloppy, not very precise English,  
> when I'm missing precise vocabulary to express exactly what I want  
> to say. But I think we'll work it out.
>
> To make SSLEngine DTLS-able most changes do not affect its interface  
> and could be implemented internally; for that alone we wouldn't even  
> need a separate DTLSEngine. After all it's just  another record  
> format and a slightly modified handshake. I haven't spend much time  
> on the issue of how to integrate the reliable transport for the  
> handshake phase into the completely network-independent design. I'll  
> work that out and get back to you. If any ideas pop into your mind,  
> let me know.
>
> Christian
>
>
>
>
> Am 29.01.2008 um 09:52 schrieb Andreas Sterbenz:
>
>> Christian,
>>
>> as you point out, in a datagram world some things are more  
>> complicated and there are more choices to make than in a socket  
>> world. How to handle handshaking, buffer data, etc. This is in many  
>> ways similar to the issues that came up for TLS with non-blocking I/ 
>> O. There we made the decision to decouple the TLS aspects  
>> (SSLEngine) from the I/O aspects. That way the choices of how to do  
>> I/O, how many threads to use and for which tasks, etc. are left to  
>> the application developer.
>>
>> A similar approach may be useful here. In fact, you may be able to  
>> use the existing SSLEngine API and write an implementation that  
>> does DTLS instead of SSL/TLS. Note that SSLEngine is not tied to  
>> java.nio at all. The only link to NIO in the API is the use of  
>> ByteBuffers as a generic abstraction for a memory region.
>>
>> Of course, having a drop-in replacement for DatagramSocket is still  
>> useful. That could be implemented on top of the DTLS engine as as  
>> simple way for applications to use DTLS without the extra  
>> flexibility of the engine.
>>
>> What do you think?
>>
>> Andreas.
>>
>>
>> Christian Uebber wrote:
>>> Dear Andreas,
>>> due to some other current business my DTLS efforts were set back  
>>> for a couple of weeks. But I'm happy to be back on the task now.  
>>> First I'd like to discuss some architectural issues. I have put  
>>> much time into working out the best way of integrating DTLS into  
>>> the current APIs as transparently as possible. All solutions have  
>>> specific trade-offs.
>>> The main class most users would use is going to be  
>>> TLSDatagramSocket extending the well known DatagramSocket. The  
>>> first design choice would be - DTLS differentiates between client  
>>> and server - if we should keep an unified DatagramSocket class  
>>> without a dedicated DatagramServerSocket. I would say yes and I  
>>> think that's an easy one. Users shouldn't be forced to understand  
>>> different Java networking concepts if all what is added is an  
>>> additional security layer. There are also sessions to be managed,  
>>> but this is also possible in a transparent way without a dedicated  
>>> server class. For security reasons a method as  
>>> acceptHandshakeRequests(boolean b) could be added to enable or  
>>> disable server like behavior.
>>> In any case threads accessing the main I/O methods  
>>> send(DatagramPacket p) and receive() should never be blocked by  
>>> security layer events, as they are needed for bulk transfers from  
>>> and to anywhere at any time. Of course there must be mechanisms  
>>> (e.g. callbacks) for users wanting extended control.
>>> TLS over TCP could attach session information to created sockets  
>>> in a 1:1 relationship. As we have just one (TLS)DatagramSocket  
>>> socket for any potential endpoint (1:n) this cannot be done easily  
>>> in the case of UDP. Since Java programmers never had to care about  
>>> anything else but single DatagramPackets in their application  
>>> space, this shouldn't change for anybody who doesn't need to deal  
>>> with cryptographic details. So my proposal would be letting  
>>> sessions be managed by the socket, but exposing control to those  
>>> who need it.
>>> Trying to accomplish full transparency on the receiving side is  
>>> quite easy. All packets for which there is no established session  
>>> object and which are not handshake requests are silently dropped.  
>>> Handshake requests instead get forwared to a Handshaker class,  
>>> packets belonging to an established session get unwrapped and are  
>>> then fired through the send-method of the attached  
>>> TLSDatagramSocket.
>>> Transparency on the sending side implies some trade-off decisions  
>>> in cases where the send-method gets packets for destinations  
>>> without an already established session.
>>>  1. Full Transparency:
>>>        1. Session initiation is started, packets for an  
>>> unestablished
>>>           target are buffered until the session is established and
>>>           then sent (or dropped if establishment failed).
>>>        2. Session initiation is started, packets get dropped (nobody
>>>           promised that UDP would be reliable).
>>>  2. Manual Session Initiation: A method as  
>>> initiateSession(InetAddress
>>>     a, int port, CallbackHandler c) must be called before any packet
>>>     can be send to a specific endpoint.
>>> Buffers could fill up quite quickly under heavy load in the case  
>>> of 1.1. In the case of 1.2 no promises are broken, but it's not  
>>> really good style. An average handshake can take a second and a  
>>> lot of packets can already be lost during this time. The case No.  
>>> 2 wouldn't be usable as a drop-in replacement anymore.
>>> Maybe some aspects could be combined for the best solution. What  
>>> do you think?
>>> But that should be it for today... I'm looking forward to your  
>>> remarks.
>>> Christian
>>> PS I've emailed the signed SCA today. It should get registered soon.
>>> Am 30.11.2007 um 02:42 schrieb Andreas Sterbenz:
>>>> Christian Uebber wrote:
>>>>> Is anybody already working on this for Java DatagramSockets? I'd  
>>>>> be interested in doing the work. Integration into and reuse of  
>>>>> the existing JSSE code would also be my preferred way to go.
>>>>
>>>> That sounds like a great idea. We at Sun don't have any current  
>>>> plans to implement DTLS due to a lack of resources, but we could  
>>>> assist by answering questions about JSSE or commenting on your  
>>>> code. There are also some architectural issues about fitting a  
>>>> secure datagram transport into the current Networking APIs that  
>>>> we may want to discuss.
>>>>
>>>> BTW, you may want to look into signing the contributor agreement: http://openjdk.java.net/contribute/
>>>>
>>>> Andreas.
>>>>
>>>>
>>
>>
>
>



From briefkasten at uebber.de  Tue Jan 29 14:44:10 2008
From: briefkasten at uebber.de (Christian Uebber)
Date: Tue, 29 Jan 2008 15:44:10 +0100
Subject: [security-dev 00060]: Re: State of TLS 1.1 implementation
In-Reply-To: <479E9ABF.20407@Sun.COM>
References: <29F10BCC-BB07-4CC9-9A52-55C791D66F15@uebber.de>
	<479E9ABF.20407@Sun.COM>
Message-ID: <2C0AD827-7C10-47F0-8CF4-93E30E03C1A3@uebber.de>


Am 29.01.2008 um 04:17 schrieb Andrew Fan:

>>
> We plan support TLS1.1 for JDK 7, the implementation is in progress.
>

As soon as you have got CBC with explicit IVs working in a pre-release  
it would be nice if you let me know. I don't need much else from the  
update.

It would be senseless to write my own CBC implementation for unit  
testing the DTLS code if yours is already waiting the pipeline.

Christian