Network Working Group N. Neumann, Ed.
Internet-Draft F. Tegeler
Intended status: Standards Track X. Fu
Expires: April 21, 2011 University of Goettingen
October 18, 2010
Secure Token Transfer Protocol (STTP)
draft-neumann-oauth-token-transfer-00
Abstract
The Secure Token Transfer Protocol (STTP) provides the means for two
entities to exchange a set of tokens that is needed to perform a
certain task such as authentication. The exact context of the tokens
and their further usage is outside the scope of the protocol. STTP
is intended to be employed to in case a mechanism to securely
transfer tokens is missing for a particular scenario or context
within other protocols.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Neumann, et al. Expires April 21, 2011 [Page 1]
Internet-Draft Secure Token Transfer Protocol (STTP) October 2010
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation and Conventions . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Dynamic Password Provisioning . . . . . . . . . . . . . . 6
3. Protocol details . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. STTP over HTTP . . . . . . . . . . . . . . . . . . . . . . 7
4. Token Types . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Generic Tokens . . . . . . . . . . . . . . . . . . . . . . 8
5. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Server authentication . . . . . . . . . . . . . . . . . . 8
5.2. Client authentication . . . . . . . . . . . . . . . . . . 8
5.2.1. Authentication Method Negotiation . . . . . . . . . . 8
5.2.2. Authenticated Request . . . . . . . . . . . . . . . . 9
5.2.3. SCRAM-SHA-1 . . . . . . . . . . . . . . . . . . . . . 9
5.2.4. RSA-SHA1 . . . . . . . . . . . . . . . . . . . . . . . 9
6. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. GETTOKENS . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1.1. Arguments . . . . . . . . . . . . . . . . . . . . . . 10
7. Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Service-URI . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. Server-Nonce . . . . . . . . . . . . . . . . . . . . . . . 11
7.4. Client-Nonce . . . . . . . . . . . . . . . . . . . . . . . 11
7.5. Reflection-Key . . . . . . . . . . . . . . . . . . . . . . 11
7.5.1. TLS-based transport . . . . . . . . . . . . . . . . . 11
7.5.2. Other transport . . . . . . . . . . . . . . . . . . . 11
7.5.3. Manual verification . . . . . . . . . . . . . . . . . 12
7.6. Auth-Scheme . . . . . . . . . . . . . . . . . . . . . . . 12
7.7. Client-Proof . . . . . . . . . . . . . . . . . . . . . . . 12
7.8. Auth-Proposals . . . . . . . . . . . . . . . . . . . . . . 12
7.9. Iteration-Count . . . . . . . . . . . . . . . . . . . . . 12
7.10. Message . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.11. Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.11.1. Plain . . . . . . . . . . . . . . . . . . . . . . . . 12
7.11.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . 13
7.12. Expires-In . . . . . . . . . . . . . . . . . . . . . . . . 13
7.13. OAuth-Grant-Type . . . . . . . . . . . . . . . . . . . . . 13
7.14. OAuth-Client-Id . . . . . . . . . . . . . . . . . . . . . 13
Neumann, et al. Expires April 21, 2011 [Page 2]
Internet-Draft Secure Token Transfer Protocol (STTP) October 2010
7.15. OAuth-Client-Secret . . . . . . . . . . . . . . . . . . . 13
7.16. OAuth-Code . . . . . . . . . . . . . . . . . . . . . . . . 13
7.17. OAuth-Access-Token . . . . . . . . . . . . . . . . . . . . 13
7.18. OAuth-Refresh-Token . . . . . . . . . . . . . . . . . . . 13
7.19. IToken . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.20. AToken . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Response Codes . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 13
8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 13
8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 13
8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 14
8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 14
8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 14
8.4.2. 401 Authentication Required . . . . . . . . . . . . . 14
8.4.3. 402 Not Responsible . . . . . . . . . . . . . . . . . 14
8.4.4. 403 Authentication Failed . . . . . . . . . . . . . . 14
8.4.5. 404 No Common Authentication Scheme . . . . . . . . . 14
8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 14
8.5.1. 501 Not Implemented . . . . . . . . . . . . . . . . . 14
9. Security considerations . . . . . . . . . . . . . . . . . . . 14
9.1. Token security . . . . . . . . . . . . . . . . . . . . . . 14
9.2. Man-in-the-middle attacks . . . . . . . . . . . . . . . . 14
9.3. Privacy protection . . . . . . . . . . . . . . . . . . . . 15
10. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Neumann, et al. Expires April 21, 2011 [Page 3]
Internet-Draft Secure Token Transfer Protocol (STTP) October 2010
1. Overview
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.
Figure 1 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).
Neumann, et al. Expires April 21, 2011 [Page 4]
Internet-Draft Secure Token Transfer Protocol (STTP) October 2010
----+
+----------+ +-----------------+ |Appl.
| Client A |--(A) Access request ---------->| 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 | |
+----------+ +-----------------+ |
----+
Figure 1: STTP Example
1.1. Requirements Notation and Conventions
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 [RFC2119].
1.2. Terminology
The following terminology is used throughout this document:
Token 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.
Client The entity requesting a set of tokens.
Server The entity that a set of tokens is requested from.
2. Usage Scenarios
This document addresses a number of particular scenarios where STTP
could be used that are detailed below.
Neumann, et al. Expires April 21, 2011 [Page 5]
Internet-Draft Secure Token Transfer Protocol (STTP) October 2010
2.1. OAuth
The OAuth 2.0 Protocol [I-D.ietf-oauth-v2] 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).
2.2. Dynamic Password Provisioning
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.
3. Protocol details
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.
Neumann, et al. Expires April 21, 2011 [Page 6]
Internet-Draft Secure Token Transfer Protocol (STTP) October 2010
GETTOKENS
Type: OAuth
OAuth-Grant-Type: authorization_code
OAuth-Client-Id: s6BhdRkqt3
OAuth-Client-Secret: gX1fBat3bV
OAuth-Code: i1WsRn1uB
Example of a request message
200 OK
Type: OAuth
OAuth-Access-Token: SlAV32hkKG
OAuth-Refresh-Token: 8xLOxBtZp8
Expires-In: 3600
Example of a response message
3.1. STTP over HTTP
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.
POST /resource HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
GETTOKENS
Type: Plain
Identifier: john.doe@example.com
STTP over HTTP example request
4. Token Types
STTP supports a number of different token types.
4.1. OAuth
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.
Neumann, et al. Expires April 21, 2011 [Page 7]
Internet-Draft Secure Token Transfer Protocol (STTP) October 2010
4.2. Generic Tokens
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.
5. Authentication
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.
5.1. Server authentication
Server authentication is performed using certificates during the TLS
handshake (see [RFC5246], 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.
5.2. Client authentication
If a server requires client authentication for a particular command,
it will send a "Authentication Required" response message (see
Section 8.4.2) 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.
5.2.1. Authentication Method Negotiation
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-
Neumann, et al. Expires April 21, 2011 [Page 8]
Internet-Draft Secure Token Transfer Protocol (STTP) October 2010
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.
5.2.2. Authenticated Request
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.
5.2.3. SCRAM-SHA-1
SCRAM authentication is based on the Salted Challenge Response
Authentication Mechanism (SCRAM) as described in [RFC5802] with the
AuthMessage being the authenticated command message itself (without
the Client-Proof argument). SCRAM is only used to authenticate the
client.
5.2.4. RSA-SHA1
Authentication based on Section 8.2. of [RFC3447] (RSASSA-PKCS1-v1_5)
with the message to be signed (M) being the authenticated command
message (without the Client-Proof argument).
Neumann, et al. Expires April 21, 2011 [Page 9]
Internet-Draft Secure Token Transfer Protocol (STTP) October 2010
6. Commands
6.1. GETTOKENS
The GETTOKENS command is used by an agent to request a token pair for
a particular service URI.
6.1.1. Arguments
A client MUST include the following arguments in every GETTOKENS
command:
o Service-URI
A client CAN include the following arguments in a GETTOKENS command:
o Auth-Proposals
o Client-Nonce
o Reflection-Key
o ...
7. Arguments
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 [RFC2661]
7.1. Service-URI
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
[RFC3986]. 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. [RFC2616] 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:
o Comparisons of scheme names MUST be case-insensitive;
Neumann, et al. Expires April 21, 2011 [Page 10]
Internet-Draft Secure Token Transfer Protocol (STTP) October 2010
o Comparisons of host names MUST be case-insensitive;
o A port that is empty or not given is equivalent to the default
port for the particular scheme;
o An empty path component is equivalent to the root path "/".
Characters that are not classified as "reserved" by [RFC3986] are
equivalent to their corresponding percent-encoding ("%" HEXDIG
HEXDIG).
7.2. Identifier
The identifier token (e.g. a username) of the entity that the current
exchange is intended for (either a user or another STTP agent).
7.3. Server-Nonce
A nonce value
7.4. Client-Nonce
A nonce value
7.5. Reflection-Key
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.
7.5.1. TLS-based transport
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.
7.5.2. Other transport
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.
Neumann, et al. Expires April 21, 2011 [Page 11]
Internet-Draft Secure Token Transfer Protocol (STTP) October 2010
7.5.3. Manual verification
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.
7.6. Auth-Scheme
The authentication scheme that is used in the request.
7.7. Client-Proof
The client-side result of an authentication run.
7.8. Auth-Proposals
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.
7.9. Iteration-Count
Integer value
7.10. Message
A message which contains more verbose information and that is
intended to be displayed to the end user.
7.11. Type
The type of tokens that are being transferred.
o PLAIN
o OAuth
7.11.1. Plain
If the Type argument is set to Plain, the tokens that are being
requested/transferred are generic tokens.
Neumann, et al. Expires April 21, 2011 [Page 12]
Internet-Draft Secure Token Transfer Protocol (STTP) October 2010
7.11.2. OAuth
If the Type argument is set to Plain, the tokens that are being
requested/transferred are OAuth tokens.
7.12. Expires-In
Number of seconds the transferred tokens are still valid for.
7.13. OAuth-Grant-Type
7.14. OAuth-Client-Id
7.15. OAuth-Client-Secret
7.16. OAuth-Code
7.17. OAuth-Access-Token
7.18. OAuth-Refresh-Token
7.19. IToken
Generic identifier token (e.g. username).
7.20. AToken
Generic authentication token (e.g. password).
8. Response Codes
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.
8.1. Informational 1xx
Currently no use.
8.2. Successful 2xx
8.2.1. 200 OK
Neumann, et al. Expires April 21, 2011 [Page 13]
Internet-Draft Secure Token Transfer Protocol (STTP) October 2010
8.3. Redirection 3xx
8.4. Client Error 4xx
8.4.1. 400 Bad Request
8.4.2. 401 Authentication Required
8.4.3. 402 Not Responsible
8.4.4. 403 Authentication Failed
8.4.5. 404 No Common Authentication Scheme
8.5. Server Error 5xx
8.5.1. 501 Not Implemented
9. Security considerations
9.1. Token security
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.
9.2. Man-in-the-middle attacks
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. Section 7.5) 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.
Neumann, et al. Expires April 21, 2011 [Page 14]
Internet-Draft Secure Token Transfer Protocol (STTP) October 2010
9.3. Privacy protection
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.
10. Normative References
[I-D.ietf-oauth-v2]
Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth
2.0 Protocol", draft-ietf-oauth-v2-10 (work in progress),
July 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
"Salted Challenge Response Authentication Mechanism
(SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.
Neumann, et al. Expires April 21, 2011 [Page 15]
Internet-Draft Secure Token Transfer Protocol (STTP) October 2010
Authors' Addresses
Niklas Neumann (editor)
University of Goettingen
Computer Networks Group
Goldschmidtstrasse 7
Goettingen 37077
Germany
Email: neumann@cs.uni-goettingen.de
Florian Tegeler
University of Goettingen
Computer Networks Group
Goldschmidtstrasse 7
Goettingen 37077
Germany
Email: tegeler@cs.uni-goettingen.de
Xiaoming Fu
University of Goettingen
Computer Networks Group
Goldschmidtstrasse 7
Goettingen 37077
Germany
Email: fu@cs.uni-goettingen.de
Neumann, et al. Expires April 21, 2011 [Page 16]