-
Enhancement
-
Resolution: Unresolved
-
P3
-
None
-
None
The GSSContext::initSecContext() method could either return a token when the call succeeds or throw a GSSException if there is a failure, but not *both*. The same applies to acceptSecContext().
However, according to RFC 2743 2.2.1 [1], the GSS-API spec,
>> It is the caller's responsibility to establish a communications path
>> to the target, and to transmit any returned output_token (independent
>> of the accompanying returned major_status value) to the target over
>> that path.
the methods should be able to emit an output token independent of the status (success or failure). This is a design flaw of JGSS-API (the C bindings of GSS-API can return both). The lack of this feature prevents any error message (or fallback hints) being sent to the communication peer, which leads to useless waiting and provide no error info. It also means the Java implementation of Kerberos 5 and SPNEGO are not standard compliant, since it is not able to send out any error token defined by the protocols.
This was discussed on http://mail.openjdk.java.net/pipermail/security-dev/2013-June/007716.html and http://www.ietf.org/mail-archive/web/kitten/current/msg04163.html. As a result, RFC 8353 added a new GSSException constructor to set the output token info and a new method getOutputToken() to retrieve it.
However, according to RFC 2743 2.2.1 [1], the GSS-API spec,
>> It is the caller's responsibility to establish a communications path
>> to the target, and to transmit any returned output_token (independent
>> of the accompanying returned major_status value) to the target over
>> that path.
the methods should be able to emit an output token independent of the status (success or failure). This is a design flaw of JGSS-API (the C bindings of GSS-API can return both). The lack of this feature prevents any error message (or fallback hints) being sent to the communication peer, which leads to useless waiting and provide no error info. It also means the Java implementation of Kerberos 5 and SPNEGO are not standard compliant, since it is not able to send out any error token defined by the protocols.
This was discussed on http://mail.openjdk.java.net/pipermail/security-dev/2013-June/007716.html and http://www.ietf.org/mail-archive/web/kitten/current/msg04163.html. As a result, RFC 8353 added a new GSSException constructor to set the output token info and a new method getOutputToken() to retrieve it.
- duplicates
-
JDK-8031377 Find a way to emit a response token even if initSecContext fails
- Closed