Hello,
Could you please review the following patch:
JBS: https://bugs.openjdk.java.net/browse/JDK-8245527
Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/
The Windows LDAP server with LdapEnforceChannelBinding=2 uses the
tls-server-end-point channel binding
(based on the TLS
On Mon, 21 Sep 2020 08:19:28 GMT, Alexey Bakhtin wrote:
> Hi,
>
> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support
> for Java GSS/Kerberos.
> Initial review is available at core-devs:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-
On Tue, 22 Sep 2020 15:36:24 GMT, Daniel Fuchs wrote:
>> No, It is not used.
>> However, I'd like to leave it as is (it is mentioned in the documentation as
>> unsupported value).
>> Otherwise, TlsChannelBindingType enum will have one element only and should
>> be simplified/removed in all
On Tue, 22 Sep 2020 15:11:57 GMT, Weijun Wang wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8245527: version.01
>
> src/jdk.security.jgss/share/classes/com/sun/security/sasl/gssk
que" CB type from the list of possible channel
> binding types. The only supported type is
> "tls-server-end-point"
> CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311
>
> Thank you
> Alexey
Alexey Bakhtin has updated the pull request increm
On Tue, 22 Sep 2020 14:47:35 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support
>> for Java GSS/Kerberos.
>> Initial review is available at core-devs:
>>
On Tue, 22 Sep 2020 14:41:57 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support
>> for Java GSS/Kerberos.
>> Initial review is available at core-devs:
>>
oth of them have default values set to '-1' which means that the LDAP stack
> would not set any timeouts for connect and/or reading operations.
>
> Could you, please, share the failures you're observing with no connect
> timeout set?
>
> Best,
> Aleksei
>
> On 27/
> This could be configured as a SASL property and it would add the benefit that
> you don't need the instance specific if in the gssstub native code if you
> instead have two different types values?
>
> Gruss
> Bernd
>
> Von: security-dev im Auftrag von
> Alexey Bakh
ote:
>
>
>
>> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote:
>>
>> The hash algorithm is selected on the base of the certificate
>> signature algorithm.
>> Also, the client should use SHA-256 algorithm, in case of the
>> certificate s
hannelBinding the type
> fo the adress. So will change my opinion a bit:
>
> No property for AD/non-AD is necessary, but handling of UNSPEC is
> required. JGSS shall remain at NULLADDR. The subtype
> UnspecEmptyInetAddress should be at least evaluated.
>
> Michael
>
/
Also, please see my comments below.
Regards
Alexey
> On 24 May 2020, at 02:38, Michael Osipov <1983-01...@gmx.net> wrote:
>
> Am 2020-05-21 um 09:35 schrieb Alexey Bakhtin:
>> Hello,
>>
>> Could you please review the following patch:
>>
>> JBS: htt
ve to have knowledge of channel binding
>> and extract the certificates from the SSLSocket to pass them to
>> the lower layer. Ideally this should rather be handled by the
>> SASL layers?
>>
>> best regards,
>>
>> -- daniel
>>
>>
>> On 25/05/2020 16:33, Alexey Bakhtin wrote:
>>> Updated webrev is available
>>> at:http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v1/
>>
nfo.
>
> From my reading of the code change, it looks like this cbData can be
> calculated on the LDAP side.
>
> Thanks,
> Max
>
>> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote:
>>
>> Hello,
>>
>> Could you please review the follo
SPEC instead of GSS_C_AF_NULLADDR (line 194-195).
>
> Can you try and see if Window works with GSS_C_AF_NULLADDR? If yes, I'd
> prefer to not changing the default value for addresstype for the same reason
> which Michael has already stated.
>
> Thanks,
> Valerie
>
>
>
Hi,
Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for
Java GSS/Kerberos.
Initial review is available at core-devs:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html
This version removes "tls-unique" CB type from the list of possible
Gentle ping
Regards
Alexey
> On 15 Jul 2020, at 14:18, Alexey Bakhtin wrote:
>
> Hello Daniel,
>
> I’ve updated CSR as you suggested and added kerberos ldap setup commands for
> the client host in the JDK-8245527
>
> Regards
> Alexey
Hello Daniel,
Thank you for review.
I have updated LdapCBPropertiesTest according to your comments.
Updated webrev at http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v9/
Regards
Alexey
Hello Sean, Daniel,
Thank you for review
I’ve added “com.sun.jndi.ldap.tls.cbtype” property into the module-info file
and updated synchronisation using CompletableFuture.
Also, I have added new test cases : successful and unsuccessful TLS handshake,
synchronous and asynchronous TLS handshake.
> I would suggest removing it. At least for the SASL GSS-API mech, it seems the
> GSSContext object will not be leaked and no one has a chance to call
> setChannelBinding again on it.
>
> There is no spec saying setChannelBinding() can only be called once, so I'd
> rather we don't enforce
ready, but can you explain why the
>>> "com.sun.jndi.ldap.connect.timeout" property needs to be set in order to
>>> use this feature? That property is mostly used in tests to avoid long
>>> socket timeouts, etc.
>>>
>>> Why does that need
Hello Daniel,
I’ve updated CSR as you suggested and added kerberos ldap setup commands for
the client host in the JDK-8245527
Regards
Alexey
> On 14 Jul 2020, at 18:28, Daniel Fuchs wrote:
>
> Hi Alexey,
>
> On 10/07/2020 21:37, Alexey Bakhtin wrote:
>>
Hello All,
Thank you for review.
> 1. If the change in java.security.jgss/share/classes/module-info.java is
> unavoidable, can we create a sub-package for this single class so that we
> only need to export it?
As suggested by Max I’ve moved TlsChannelBindingImpl class into sub-package, so
duce its code size.
Thank you for suggestion. Updated to use BaseLdapServer in the test
>
> LdapCBPropertiesTest.java:122 - could use no param Hastable constructor
Fixed
>
> I've also run your latest patch through our CI system and it showed no
> failures with your latest changes.
Hello Daniel,
Thank you for review.
As you suggested I’ve added static factory methods to create TlsChannelBinding
class and changed connectionTimeout verification to "if (connectTimeout <= 0)"
Also, I’ve added simple regression test to verify Channel Binding parameters.
Please find updated
t.Method.invoke(Method.java:564)
> at
> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:832)
>
>
> For information about CSR process you can start from this wiki page:
> https://wiki.openjdk.
Hello Sean,
The link to CSR for this feature :
https://bugs.openjdk.java.net/browse/JDK-8247311
Regards
Alexey
> On 9 Jun 2020, at 19:50, Sean Mullan wrote:
>
> On 6/9/20 12:40 PM, Xuelei Fan wrote:
>> About the prefix, it may follow RFC 5056 (See page 7, section 2.1).
>>o
CHANNEL_BINDING_TYPE + " property.");
> 2585 }
>
> is not correct - as IllegalArgumentException, IllegalStateException and
> UnsupportedOperationException will percolate up to the calling code, and
> are not documented at the public API level.
> These should really be Namin
yet. I did not find any suitable test case
that can be reused.
Thank you
Alexey
> On 6 Jun 2020, at 09:44, Weijun Wang wrote:
>
>
>
>> On Jun 6, 2020, at 2:41 PM, Weijun Wang wrote:
>>
>>
>>
>>> On Jun 5, 2020, at 11:03 PM, Alexey Bakhtin
-and-channel-binding-hash-aka-extended-protection-for-authentication
So, it is hard to say - is it a standard or Microsoft implementation specific
Regards
Alexey
> On 9 Jun 2020, at 18:35, Sean Mullan wrote:
>
> On 6/8/20 5:33 PM, Alexey Bakhtin wrote:
>> Hello Sean,
>> Yes, I
> our SQE can see if we can setup some internal tests. Then we can add
> noreg-hard with some justification to the test and go on.
>
> I cannot comment on LdapCtx.java, but the others look fine to me.
>
> Thanks,
> Max
>
>> On Jun 7, 2020, at 3:45 AM, Alexey Bakhti
annel binding property
>> + if (cbType != null && connectTimeout == -1) {
>> + throw new NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE +
>> + " property requires com.sun.jndi.ldap.connect.timeout" +
>> + &
ndent with any application level info.
>
> From my reading of the code change, it looks like this cbData can be
> calculated on the LDAP side.
>
> Thanks,
> Max
>
>> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote:
>>
>> Hello,
>>
>> Could you
hen we also have the chance to modify the approach later.
>
> Thanks,
> Max
>
>
>> On Jun 5, 2020, at 2:15 AM, Alexey Bakhtin wrote:
>>
>> Hello,
>>
>> Could you please review new version of the patch:
>> http://cr.openjdk.java.net/~abakhtin/
rds,
>> -- daniel
>> On 14/08/2020 14:18, Sean Mullan wrote:
>>> On 8/14/20 8:41 AM, Alexey Bakhtin wrote:
>>>> Hello Sean,
>>>>
>>>> Thank you for review.
>>>> I’ve changed wording and replaced @code with @systemProperty (tested,
OK
Updated for all properties in the module-info.java
Webrev at: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v16/
Regards
Alexey
> On 14 Aug 2020, at 16:18, Sean Mullan wrote:
>
> On 8/14/20 8:41 AM, Alexey Bakhtin wrote:
>> Hello Sean,
>> Thank you for review.
&g
state to "Proposed".
>> best regards,
>> -- daniel
>> [1] https://bugs.openjdk.java.net/browse/JDK-8247311
>> On 30/07/2020 10:17, Alexey Bakhtin wrote:
>>> Gentle ping
>>>
>>> Regards
>>> Alexey
On Wed, 20 Jan 2021 15:08:56 GMT, Aleksei Efimov wrote:
>> That look reasonable to me. But what would happen if at some point after
>> performing some LDAP operations, you called StartTLSResponse::close and then
>> after some more time you tried to again create a StartTLSRequest on the same
> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS
> Extension.
> Test from the bug report and jtreg javax/naming tests are passed.
Alexey Bakhtin has updated the pull request incrementally with one additional
commit since the last revision:
On Wed, 20 Jan 2021 15:54:41 GMT, Daniel Fuchs wrote:
>> New ChannelBinding Data will be recreated for every TLS connection and
>> provided to SASL Client in the new environment properties set (cloned from
>> the original).
>> LdapSasl.java lines 133 - 136:
>>
> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS
> Extension.
> Test from the bug report and jtreg javax/naming tests are passed.
Alexey Bakhtin has updated the pull request incrementally with one additional
commit since the last revision:
Update copyr
On Thu, 14 Jan 2021 19:28:27 GMT, Alexey Bakhtin wrote:
> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS
> Extension.
> Test from the bug report and jtreg javax/naming tests are passed.
This pull request has now been integrated.
Changeset: 874aef
> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS
> Extension.
> Test from the bug report and jtreg javax/naming tests are passed.
Alexey Bakhtin has updated the pull request incrementally with one additional
commit since the last revision:
Add
On Thu, 21 Jan 2021 18:19:10 GMT, Aleksei Efimov wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> separate tlsHandshakeCompleted for every StartTLS connection
>
> src/java.naming/s
On Tue, 19 Jan 2021 20:24:21 GMT, Sean Mullan wrote:
>> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS
>> Extension.
>> Test from the bug report and jtreg javax/naming tests are passed.
>
> Can you add a test for this or is it too hard? There are existing tests for
On Wed, 20 Jan 2021 14:01:45 GMT, Sean Mullan wrote:
>> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS
>> Extension.
>> Test from the bug report and jtreg javax/naming tests are passed.
>
> Marked as reviewed by mullan (Reviewer).
Sean, Thank you for review
Please review a small patch to enable LDAP TLS Channel Binding with StartTLS
Extension.
Test from the bug report and jtreg javax/naming tests are passed.
-
Commit messages:
- 8259707: LDAP channel binding does not work with StartTLS extension
Changes:
47 matches
Mail list logo
