RFC Errata
Found 3 records.
Status: Verified (1)
RFC 2743, "Generic Security Service Application Program Interface Version 2, Update 1", January 2000
Note: This RFC has been updated by RFC 5554, RFC 5896
Source of RFC: cat (sec)
Errata ID: 4151
Status: Verified
Type: Technical
Publication Format(s) : TEXT
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)
RFC 2743, "Generic Security Service Application Program Interface Version 2, Update 1", January 2000
Note: This RFC has been updated by RFC 5554, RFC 5896
Source of RFC: cat (sec)
Errata ID: 2758
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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.