Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol

A GSS-API Mechanism for the Extensible Authentication Protocol

“…Section 7.3 of [RFC4462]describes the problem referencing the Secure Shell (SSH) Protocol key exchange negotiation and the SPNEGO GSS-API mechanism. If a client preferred an EAP method A, a non-EAP authentication mechanism B, and then an EAP RFC 7055 EAP GSS-API December 2013 method C, then the client would have to commit to using EAP before learning whether A is actually supported.…”

“…The only flag defined so far is GSS_C_MUTUAL_FLAG, indicating that the initiator successfully performed mutual authentication of the acceptor. This flag is communicated to the acceptor because some protocols [RFC4462] require the acceptor to know whether the initiator has confirmed its identity. This flag has the value 0x2 to be consistent with RFC 2744.…”

“…Multiple layer negotiations are vulnerable to a bid-down attack when a mechanism negotiated at the outer layer is preferred to some but not all mechanisms negotiated at the inner layer; see Section 7.3 of [RFC4462] for an example. One possible approach to mitigate this attack is to construct security policy such that the preference for all mechanisms negotiated in the inner layer falls between preferences for two outer-layer mechanisms or falls at one end of the overall ranked preferences including both the inner and outer layer.…”

X.509v3 Certificates for Secure Shell Authentication

“…The public key algorithms and encodings defined in this document SHOULD be accepted any place in the Secure Shell protocol suite where public keys are used, including, but not limited to, the following protocol messages for server authentication and user authentication: o in the SSH_MSG_USERAUTH_REQUEST message when "publickey" authentication is used [RFC4252] o in the SSH_MSG_USERAUTH_REQUEST message when "hostbased" authentication is used [RFC4252] o in the SSH_MSG_KEXDH_REPLY message [RFC4253] o in the SSH_MSG_KEXRSA_PUBKEY message [RFC4432] o in the SSH_MSG_KEXGSS_HOSTKEY message [RFC4462] o in the SSH_MSG_KEX_ECDH_REPLY message [RFC5656] o in the SSH_MSG_KEX_ECMQV_REPLY message [RFC5656] When a public key from this specification is included in the input to a hash algorithm, the exact bytes that are transmitted on the wire must be used as input to the hash functions. In particular, implementations MUST NOT omit any of the chain certificates or OCSP responses that were included on the wire, nor change encoding of the certificate or OCSP data.…”

Structure of the Generic Security Service (GSS) Negotiation Loop

“…As such, individual application protocol specifications have had to specify the structure of their GSS negotiation loops, including error handling, on a perprotocol basis (see [RFC4462], [RFC3645], [RFC5801], [RFC4752], and [RFC2203]). This represents a substantial duplication of effort, and the various specifications go into different levels of detail and describe different possible error conditions.…”