ietf-corpus

rfc-5554

Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings

N. Williams
date2009-05 streamIETF areasec wgkitten statusPROPOSED STANDARD pages4 canonicalhttps://www.rfc-editor.org/rfc/rfc5554 doi10.17487/RFC5554
This document clarifies and generalizes the Generic Security Service Application Programming Interface (GSS-API) "channel bindings" facility, and imposes requirements on future GSS-API mechanisms and programming language bindings of the GSS-API. [STANDARDS-TRACK]

updates

Extracted elements (9)

design-rationale §4

The channel bindings structure in the C-bindings specification (RFC 2744) is actually generic in nature despite being expressed in C syntax; this document generalizes it using pseudo-ASN.1 to make it accessible to all language bindings, fixing an incomplete treatment in the base RFC 2743 specification.

security, crypto

design-rationale §4

The GSS-CHANNEL-BINDINGS structure is presented in pseudo-ASN.1 but no standard encoding is mandated because this structure is part of an abstract API, not a protocol defining bits on the wire; each GSS-API mechanism encodes the contents in a mechanism-specific way.

security, crypto

interoperability-note §4

RFC 4121 (Kerberos V GSS-API mechanism) defines an encoding of the GSS-CHANNEL-BINDINGS structure that hashes the encoded form; other GSS-API mechanisms are free to reuse that encoding.

security, crypto

normative-requirement §3 MUST

All new GSS-API mechanisms that support channel binding MUST conform to RFC 5056 (On the Use of Channel Bindings to Secure Channels).

security, crypto

normative-requirement §4 SHOULD

New language-specific bindings of the GSS-API SHOULD specify a language-specific formulation of the abstract GSS-CHANNEL-BINDINGS structure.

security, crypto

normative-requirement §4 MUST

Where a language binding of the GSS-API models channel bindings as OCTET STRINGs (or the language's equivalent), the implementation MUST assume that the given bindings correspond only to the application-data field of GSS-CHANNEL-BINDINGS, rather than some encoding of the full GSS-CHANNEL-BINDINGS structure.

security, crypto

protocol-element §4

The abstract GSS-CHANNEL-BINDINGS structure is defined as a SEQUENCE containing: initiator-address-type (INTEGER), initiator-address (OCTET STRING), acceptor-address-type (INTEGER), acceptor-address (OCTET STRING), and application-data (OCTET STRING). Address field semantics follow RFC 2744; application-data follows RFC 5056.

security, crypto

security-consideration §5

End-point channel bindings must not be modeled as network addresses; if they were, such channel bindings might not be usable with all language bindings of the GSS-API, limiting interoperability and security guarantees.

security, crypto

security-consideration §5

Language bindings that use OCTET STRING for channel bindings will not support network addresses as channel bindings, but this does not cause security problems because using network addresses as channel bindings is not generally secure.

security, crypto