Secure Token Transfer Protocol (STTP)

Tokens are commonly used in access authentication and authorization, for example, in a rather generic way in form of usernames and passwords or in more complex ways such as OAuth access tokens. The Secure Token Transfer Protocol (STTP) provides means to securely transfer such access tokens between different entities that might be involved in the provisioning of such tokens. While tokens are commonly required for authentication and authorization purposes within protocols, they do not always provide means to securely transport or provision them in every scenario. If such means are missing for a specific protocol or scenario, STTP can be used for such tasks. shows an example where STTP is used to transport a set of tokens between three entities to access a resource that is available on a fourth entity. Client A wants to access a protected resource on a server. Between Client A and the server an application specific authentication or authorization protocol is employed (e.g. HTTP Basic Access Authentication or OAuth) within an application specific workflow to access a protected resource (A). The server in turn requests an authentication or authorization protocol specific set of tokens in order to grant the Client access to the requested resource (B). As a set of appropriate tokens is not available on Client A it uses STTP to request a set of tokens from Client B which is under the control and trusted by the resource owner (C). Client A and Client B can be running in different applications and even on different devices. If the user approves the token request, Client B will again use STTP to request a set of tokens that matches the request from Client A from the appropriate authentication or authorization server (D). The corresponding request can be authenticated within STTP if the server requires so. If the user is authorized to access the protected resource the authentication or authorization server will issue a corresponding set of tokens that are opaque to STTP (E). Client B transfers this set of tokens to Client A (F) which in turn can use it in a protocol specific way to authenticate or authorize the access request to the protected resource (G).

| Resource | |spec. | |<-(B) Access token req. --------| | |prot. |(Consumer)|--(G) Access request + token -->| Server | | +----------+ +-----------------+ | | ^ ----+ | | ----+ (C) GETTOKENS | | | | | (F) 200 OK + tokens | | | |STTP V | | +----------+ +-----------------+ | | Client B |--(D) GETTOKENS --------------->| Authentication/ | | |(Resource | | Authorization | | | owner) |<-(E) 200 OK + tokens ----------| Server | | +----------+ +-----------------+ | ----+ ]]>

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

The following terminology is used throughout this document: A data string that is required by another protocol to perform a specific task such as authentication or authorization. The exact context and the further use of tokens is outside the scope of this document. Tokens are opaque to STTP. The entity requesting a set of tokens. The entity that a set of tokens is requested from.

This document addresses a number of particular scenarios where STTP could be used that are detailed below.

The OAuth 2.0 Protocol specifies a workflow that requires end-user authorization. To acquire end-user authorization an application needs to either access a HTTP resource (the end-user authorization endpoint) with an appropriate user-agent or have access to the user's credentials and perform HTTP Basic authentication. In cases where an application does not have access to such an appropriate user-agent or where HTTP Basic authentication is not supported, STTP can be used to request the corresponding OAuth tokens. OAuth also requires the transfer of an Access Grant and an Access Token between the entity accessing the resource server and the application accessing the authorization server. In scenarios where these entities are not part of the same application, STTP can be used to transfer the tokens securely between applications even if they are running on different hosts (e.g. the authorizing application is running on a mobile device).

Passwords as shared secrets are very common for authentication and authorization. While in many cases they are pre-established, STTP can be used to dynamically provision passwords for specific scenarios. An example scenario is the generation of one-time-passwords that can be used to access services over an untrusted link or using an untrusted device. For example, a user can use a trusted mobile device that connects over a secure low-bandwidth link to the authentication and authorization server to retrieve a (one time) token that he can use to access a service on a public Internet terminal that uses a non-secured WiFi connection. In such a scenario the application on the public terminal could use STTP to request a set of tokens from the user's device which in turn uses STTP to retrieve the tokens (after a successful authentication) from the authentication and authorization server.

To transfer a set of tokens a STTP client contacts a STTP server over an appropriate protocol and they exchanges a set of requests and responses. A request is a command string followed by a number of arguments and a response is a numeric code together with a textual representation followed by a number of arguments. Within one connection multiple requests and responses can be exchanged until either the client or the server terminate the connection.

STTP can be used over HTTP(s). When using STTP over HTTP(s) a command MUST be included in the entity-body of a HTTP "POST" request with the "application/x-www-form-urlencoded" content-type.

STTP supports a number of different token types.

OAuth tokens are OAuth access grant tokens that can be further used by an application to gain access to a resource that is protected using the OAuth protocol.

Generic tokens are sets of each an identifier token (e.g. a username) and an authentication token (e.g. a password) that be further used by an application to gain access to a username/password protected resource.

STTP delegates server authentication to the (optionally) underlying TLS protocol. This document does describe its own methods to perform client authentication. Currently, client authentication via public/private key cryptography and password-based authentication using the Salted Challenge Response Authentication Mechanism (SCRAM) is supported.

Server authentication is performed using certificates during the TLS handshake (see , Section 7.4.2.). If the server did not authentication itself during the TLS handshake, the STTP client MAY terminate the connection if it requires server authentication.

If a server requires client authentication for a particular command, it will send a "Authentication Required" response message (see ) on receiving a command message that does not include sufficient arguments to authenticate the client. The server MUST include a Server-Nonce argument in the response message.

To negotiate an authentication method, the client includes an Auth-Proposals argument in a command message which contains a list of supported authentication methods. If the client expects that an authentication will be required, for example, for the first command message of an STTP session, it can effectively save one protocol-round-trip by including an Auth-Proposals argument in the initial command message instead of waiting for an "Authentication Required" response message. A command message that includes an Auth-Proposals argument MUST also include a Client-Nonce argument. When the server receives a command message that includes an Auth-Proposals argument and the server does indeed require client authentication, it MUST choose one of the proposals and return a "Authentication Required" response message with an appropriate Auth-Scheme argument and the corresponding arguments that are required for the particular authentication method including the Client-Nonce. If the server does require client authentication but does not support any of the offered authentication methods it MUST respond with a "No Common Authentication Scheme" message. If the server does not require client authentication but the command message includes an Auth-Proposals argument, the server MUST ignore the argument. When selecting an authentication methods the server SHOULD assume that the list of authentication proposals is ordered by client preference. The server SHOULD try to honor the client preferences by selecting the first authentication methods on the list that the server supports. However, operational or administrative directives MAY implement a server-side preference list (for example, by ranking the different authentication methods by the server load they induce) which CAN be used to override the client preferences.

To successfully complete an authentication, the client must compose an authenticated command message. An authenticated command message is a command message that includes a valid Client-Proof argument. The Client-Proof is an authentication method specific string that is computed over the particular command message. Please refer to the details of the authentication methods for the details how the Client-Proof is calculated. The input string for the calculation of the Client-Proof MUST be identical to the command message that the Client-Proof is valid for exclusive of the Client-Proof argument itself. Besides the Client-Proof argument, an authenticated command message MUST also include a Server-Nonce argument that reflects the Server-Nonce that was included by the server in the initial "Authentication Required" response message, a Client-Nonce argument, and a Reflection-Key argument.

SCRAM authentication is based on the Salted Challenge Response Authentication Mechanism (SCRAM) as described in with the AuthMessage being the authenticated command message itself (without the Client-Proof argument). SCRAM is only used to authenticate the client.

Authentication based on Section 8.2. of (RSASSA-PKCS1-v1_5) with the message to be signed (M) being the authenticated command message (without the Client-Proof argument).

The GETTOKENS command is used by an agent to request a token pair for a particular service URI.

A client MUST include the following arguments in every GETTOKENS command: Service-URI A client CAN include the following arguments in a GETTOKENS command: Auth-Proposals Client-Nonce Reflection-Key ...

A STTP command can have a number of arguments. Arguments consist of an identifier followed by a colon (":") and the argument value. An argument is terminated by a line break. Basically 4.2 in

The particular service URI that the current command pertains to. Within the context of a GETTOKENS command this is the service URI that the client is requesting a set of tokens for. The Service-URI argument MUST follow the syntax described in . When determining if a Service-URI matches a valid resource, a server MUST follow the rules for URI comparison for the particular service context (e.g. for HTTP resources). If no service specific rules exists, a server MUST use a case-sensitive octet-by-octet comparison of the given URI with the following exceptions: Comparisons of scheme names MUST be case-insensitive; Comparisons of host names MUST be case-insensitive; A port that is empty or not given is equivalent to the default port for the particular scheme; An empty path component is equivalent to the root path "/". Characters that are not classified as "reserved" by are equivalent to their corresponding percent-encoding ("%" HEXDIG HEXDIG).

The identifier token (e.g. a username) of the entity that the current exchange is intended for (either a user or another STTP agent).

A nonce value

To prevent man-in-the-middle attacks during authenticated requests, STTP introduces a Reflection-Key. The Reflection-Key argument is included in an authenticated request and reflects the server that the client is talking to. If a server receives a Reflection-Key that doesn't match it's own properties, it MUST terminate the connection. The actual value of the Reflection-Key is dependent on the protocol that STTP is run over.

When STTP is run over a TLS-based protocol such as HTTPS the Reflection-Key argument is the SHA-1 fingerprint of the public key that was used to establish the TLS connection.

When STTP is run over other transport protocols the Reflection-Key argument is the SHA-1 hash of the IP-Address and port number that was used to initiate the connection.

In n-party scenarios where a STTP server is used to request a token on behalf on another client (e.g. a mobile device is used to request a token for an untrusted terminal) the STTP server and the STTP client SHOULD present the user with a human readable form of the Reflection-Key. This allows the user to manually verify that both Reflection-Keys match and to prevent a man-in-the-middle attack.

The authentication scheme that is used in the request.

The client-side result of an authentication run.

Comma separated list of authentication schemes that are supported by the client to perform client authentication. MUST be included in a request that follows a "Authentication Required" response for the same service URI.

Integer value

A message which contains more verbose information and that is intended to be displayed to the end user.

The type of tokens that are being transferred. PLAIN OAuth

If the Type argument is set to Plain, the tokens that are being requested/transferred are generic tokens.

If the Type argument is set to Plain, the tokens that are being requested/transferred are OAuth tokens.

Number of seconds the transferred tokens are still valid for.

Generic identifier token (e.g. username).

Generic authentication token (e.g. password).

A server's response starts with a response code that reflects the outcome of the last client request. The available response codes are described in this section including the arguments that are valid for each response.

Currently no use.

Currently STTP relies on the transport protocol to protect the tokens. STTP MUST be used over a secure transport protocol such as HTTPS if the tokens are to be protected from eavesdropping.

The goal of an adversary in STTP is to obtain a valid set of tokens pair which he can use to authenticate as the user or to obtain the user's credentials themselves. There are two possible attacks if an adversary successfully tricks a client to connect to a fraudulent server: either the adversary continues with a phishing attack with the goal to obtain user credentials or he switches to a man-in-the-middle attack to gain access to a valid set of tokens that are being transferred. In case he continues the phishing attack the fraudulent server is setup to successfully complete the user authentication even if the credentials cannot be verified. However, STTP only supports a very selective number of authentication methods that do not rely on shared secrets. Neither of the methods supported provide the party that a user is authenticating to with any data that can be used to impersonate the user. In case the attacker switches to a man-in-the-middle attack the STTP authentication that is being relayed from the attacker to the proper STTP server will fail since the Reflection-Key attribute (c.p. ) during the authentication doesn't match. However in cases where no user authentication is used, STTP relies on user interaction to manually compare the Reflection-Keys.

To protect the users privacy against eavesdroppers, a secure transport protocol such as TLS-based transports must be used. If such a secure transport is not used, STTP discloses privacy-relevant information such as the URI that tokens are being requested for and the username.