errata logo graphic

Found 3 records.

Status: Verified (1)

RFC2743, "Generic Security Service Application Program Interface Version 2, Update 1", January 2000

Source of RFC: cat (sec)

Errata ID: 4151

Status: Verified
Type: Technical

Reported By: Nicolas Williams
Date Reported: 2014-11-03
Verifier Name: Stephen Farrell
Date Verified: 2015-05-01

Section 2.2.4 says:

   o  GSS_S_FAILURE indicates that the context is recognized, but that
   the GSS_Process_context_token() operation could not be performed for
   reasons unspecified at the GSS-API level.

It should say:

   o  GSS_S_FAILURE indicates that the context is recognized, but
   either the GSS_Process_context_token() operation could not be
   performed for reasons unspecified at the GSS-API level, or the peer
   had an error consuming the last context token sent to it.  The latter
   occurs when the local side became fully established and produced one
   last token which was sent to the peer, but the peer encountered an
   error while processing that last context token.  In either case the
   minor status code provides additional information.

   In the case of successful processing of error tokens, the minor
   status code provides information from the input token.  The display
   string outputs of GSS_Display_status() as applied to such minor
   status codes should indicate that the error originated on the remote
   peer, along with the nature of the error.  Note that there is no
   way to distinguish failures of GSS_Process_context_token() from
   error token information other than to read the human-readable status
   display strings.

Notes:

The other major status codes that GSS_Process_context_token() can return are: GSS_S_COMPLETE (input token successfully processed), GSS_S_DEFECTIVE_TOKEN (e.g., integrity protection for the input token failed), GSS_S_NO_CONTEXT (invalid input security context).

This leaves a) no way to report error token information, b) no purpose for GSS_S_FAILURE, since the other major status codes cover all plausible error conditions.

But clearly the intention was that "asynchronous error tokens" should be passed to GSS_Process_context_token(), and for such tokens to be useful as far as conveying information about the error goes.

There are at least two easy ways to fix this: either have GSS_Process_context_token() report the error information in the minor status with a major status of GSS_S_COMPLETE, or decide that the GSS_S_FAILURE description was incorrect, that it should have been used to convey error token information. The latter is the more natural fix.

The KITTEN WG will have to review this erratum and decide whether to reject it, accept one fix, or the other. That review happened resulting in the corrected
text above.


Status: Held for Document Update (2)

RFC2743, "Generic Security Service Application Program Interface Version 2, Update 1", January 2000

Source of RFC: cat (sec)

Errata ID: 2758

Status: Held for Document Update
Type: Editorial

Reported By: Martin Rex
Date Reported: 2011-03-29
Held for Document Update by: Stephen Farrell

Section 2.1.4 says:

   o  actual_mechs SET OF OBJECT IDENTIFIER, -- if returned, caller must
   -- release with GSS_Release_oid_set()

   o  initiator_time_rec INTEGER -- in seconds, or reserved value for
   -- INDEFINITE

   o  acceptor_time_rec INTEGER -- in seconds, or reserved value for
   -- INDEFINITE

   o  cred_usage INTEGER, -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
   -- 2=ACCEPT-ONLY

   o  mech_set SET OF OBJECT IDENTIFIER -- full set of mechanisms
   -- supported by resulting credential.

   Return major_status codes:

It should say:

   o  actual_mechs SET OF OBJECT IDENTIFIER, -- full set of mechanisms
   -- supported by resulting credential.  If returned, caller must
   -- release with GSS_Release_oid_set()

   o  initiator_time_rec INTEGER -- in seconds, or reserved value for
   -- INDEFINITE

   o  acceptor_time_rec INTEGER -- in seconds, or reserved value for
   -- INDEFINITE

   Return major_status codes:

Notes:

There appears to be accidentally duplicated text trailing the list of output parameters in section 2.1.4: GSS_Add_cred call (top of page 38).

The parameter "cred_usage" is an input-only parameter and also listed under input parameters, and the parameter "mech_set" is a duplicate of the actual_mechs output parameter. Compare GSS-API C-Bindings document rfc2744, section 5.3. gss_add_cred

-Martin


Errata ID: 3797

Status: Held for Document Update
Type: Editorial

Reported By: Benjamin Kaduk
Date Reported: 2013-11-12
Held for Document Update by: Stephen Farrell
Date Held: 2014-05-08

Section 2.4.5 says:

   Outputs:

   o  major_status INTEGER,

   o  minor_status INTEGER,

   o  output_name INTERNAL NAME  -- caller must release with
   -- GSS_Release_name()

   Return major_status codes:

   o  GSS_S_COMPLETE indicates that a valid name representation is
   output in output_name and described by the type value in
   output_name_type.

It should say:

   Outputs:

   o  major_status INTEGER,

   o  minor_status INTEGER,

   o  output_name INTERNAL NAME  -- caller must release with
   -- GSS_Release_name()

   Return major_status codes:

   o  GSS_S_COMPLETE indicates that a valid name representation is
   output in output_name.

Notes:

The description of the GSS_S_COMPLETE return value from GSS_Import_name() indicates that the contents of the output_name field are "described by the type value in output_name_type". There is no such output_name_type parameter.


Report New Errata