A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID
Extracted elements (26)
OpenID's two standard indirect communication methods (HTTP redirects and HTML form submission) are not directly applicable for SASL, so a new method encoding OpenID message content as a URI is defined to ensure compatibility with OpenID 2.0 capable OPs.
The client sends a fixed '=' SASL response to indicate that authentication flow has shifted to the browser for OpenID processing. The alternative — signaling from the browser back to the SASL client — raises substantial inter-process communication complexity, making externalization to the browser preferable.
The mechanism requires no changes to the OpenID Provider (OP), as it is a design constraint to interoperate with existing IdPs. Indirect messaging required by OpenID is tunneled through the SASL/GSS-API mechanism.
A client that does not support SREG MUST ignore SREG attributes sent by the server; a client MUST also ignore unknown attributes.
Applications MUST match the TLS server identity with the target name as discussed in RFC 6125, since the mechanism itself cannot confirm the name due to TLS being managed outside the GSS-API mechanism.
OpenID GSS-API security contexts MUST have mutual_state flag (GSS_C_MUTUAL_FLAG) set to TRUE and MUST have deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE, as credential delegation is not supported.
RPs MUST NOT automatically retry on failed authentication attempts. OPs SHOULD only redirect to RPs with the same domain component of the base URI. Applications SHOULD NOT invoke browsers to communicate with unconfigured OPs.
The client MUST handle both user authentication to the OP and confirmation or rejection of the authentication by the RP via the SASL mechanism.
The gs2-cb-flag in the GS2 header MUST be 'n' because channel binding is not supported by this mechanism.
The OpenID mechanism MUST only be used over channels protected by TLS, and the client MUST successfully validate the server certificate per RFC 5280 and RFC 6125.
The Relying Party MUST encode a nonce or transaction ID of at least 2^32 bits in the return_to URI to uniquely identify each authentication transaction and bind requests in the absence of OpenID transaction IDs.
The SASL server MUST append a unique transaction ID to the return_to portion of the authentication request, and it SHOULD be large enough to be resistant to being guessed or attacked.
XRIs (Extensible Resource Identifiers) MUST NOT be used as identifiers; only URIs per RFC 3986 are permitted.
The OpenID Provider is aware of each Relying Party a user logs into; nothing in the protocol prevents the OP from tracking user access to services and collecting additional information. SASL servers should be aware of this OP visibility.
OpenID supports GSS_C_NT_HOSTBASED_SERVICE for acceptors and only GSS_C_NT_USER_NAME for initiators. The default name type is GSS_C_NT_USER_NAME. No OpenID-specific name syntaxes are defined.
The four-message exchange consists of: (1) client initial-response with GS2 header and OpenID identifier, (2) server authentication_request URI, (3) client fixed '=' response, and (4) server outcome_data with optional SREG attributes.
The GSS-API mechanism attributes for OPENID20 are GSS_C_MA_MECH_CONCRETE, GSS_C_MA_ITOK_FRAMED, and GSS_C_MA_AUTH_INIT per RFC 5587. Per-message tokens and GSS_Pseudo_random are not supported.
The OpenID GSS-API mechanism OID is 1.3.6.1.5.5.16, with DER encoding 0x2b 0x06 0x01 0x05 0x05 0x10. GSS-API messages differ from SASL in that the GS2 header is excluded and the initial context token header from RFC 2743 Section 3.1 is prefixed.
The SASL mechanism name is 'OPENID20'. It is client-first, capable of transferring an authorization identity via gs2-header, and does not offer a security layer.
IANA has registered the SASL mechanism 'OPENID20' in the 'SASL Mechanisms' registry with intended usage COMMON, and has assigned OID 1.3.6.1.5.5.16 in the 'SMI Security for Mechanism Codes' registry for the GSS-API mechanism.
A malicious client can transmit a crafted URL in the initial SASL response to cause the RP to perform port scans, contact unauthorized hosts, or invoke non-HTTP protocols. Mitigations include authorized URI base lists, no automatic retries on failure, logging, and query rate limiting.
A server is responsible for binding OpenIDs to specific authorization identities, requiring a prior registration process or a predefined mapping from trusted OpenID Providers; without this, authentication may not yield correct authorization.
In case of failure, outcome-data MUST follow the syntax: outcome-data = 'openid.error' '=' sreg-val *( ',' sreg-avp ), sent as an additional challenge due to RFC 4422 Section 3.6 prohibiting extra data in unsuccessful outcomes.
SREG outcome data is encoded by stripping 'openid.sreg.' from attribute names and concatenating as URI parameters separated by '&', URI-encoded absent scheme/authority/question-mark. ABNF: outcome-data = [ sreg-avp *( ',' sreg-avp ) ].
The client's initial response is encoded as 'gs2-header Auth-Identifier' where Auth-Identifier is a URI per OpenID 2.0 Section 7.2. XRIs MUST NOT be used. The gs2-nonstd-flag MUST NOT be present, and gs2-cb-flag MUST be 'n'.
The server's authentication request is a URI containing an openid.mode of either 'checkid_immediate' or 'checkid_setup' per OpenID 2.0 Section 9.1, with a unique transaction ID appended to the return_to parameter.