idnits 2.17.1 draft-neumann-oauth-token-transfer-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2010) is 4932 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-31) exists of draft-ietf-oauth-v2-10 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Neumann, Ed. 3 Internet-Draft F. Tegeler 4 Intended status: Standards Track X. Fu 5 Expires: April 21, 2011 University of Goettingen 6 October 18, 2010 8 Secure Token Transfer Protocol (STTP) 9 draft-neumann-oauth-token-transfer-00 11 Abstract 13 The Secure Token Transfer Protocol (STTP) provides the means for two 14 entities to exchange a set of tokens that is needed to perform a 15 certain task such as authentication. The exact context of the tokens 16 and their further usage is outside the scope of the protocol. STTP 17 is intended to be employed to in case a mechanism to securely 18 transfer tokens is missing for a particular scenario or context 19 within other protocols. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 21, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Requirements Notation and Conventions . . . . . . . . . . 5 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.2. Dynamic Password Provisioning . . . . . . . . . . . . . . 6 61 3. Protocol details . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. STTP over HTTP . . . . . . . . . . . . . . . . . . . . . . 7 63 4. Token Types . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.1. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.2. Generic Tokens . . . . . . . . . . . . . . . . . . . . . . 8 66 5. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.1. Server authentication . . . . . . . . . . . . . . . . . . 8 68 5.2. Client authentication . . . . . . . . . . . . . . . . . . 8 69 5.2.1. Authentication Method Negotiation . . . . . . . . . . 8 70 5.2.2. Authenticated Request . . . . . . . . . . . . . . . . 9 71 5.2.3. SCRAM-SHA-1 . . . . . . . . . . . . . . . . . . . . . 9 72 5.2.4. RSA-SHA1 . . . . . . . . . . . . . . . . . . . . . . . 9 73 6. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 6.1. GETTOKENS . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6.1.1. Arguments . . . . . . . . . . . . . . . . . . . . . . 10 76 7. Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 7.1. Service-URI . . . . . . . . . . . . . . . . . . . . . . . 10 78 7.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 11 79 7.3. Server-Nonce . . . . . . . . . . . . . . . . . . . . . . . 11 80 7.4. Client-Nonce . . . . . . . . . . . . . . . . . . . . . . . 11 81 7.5. Reflection-Key . . . . . . . . . . . . . . . . . . . . . . 11 82 7.5.1. TLS-based transport . . . . . . . . . . . . . . . . . 11 83 7.5.2. Other transport . . . . . . . . . . . . . . . . . . . 11 84 7.5.3. Manual verification . . . . . . . . . . . . . . . . . 12 85 7.6. Auth-Scheme . . . . . . . . . . . . . . . . . . . . . . . 12 86 7.7. Client-Proof . . . . . . . . . . . . . . . . . . . . . . . 12 87 7.8. Auth-Proposals . . . . . . . . . . . . . . . . . . . . . . 12 88 7.9. Iteration-Count . . . . . . . . . . . . . . . . . . . . . 12 89 7.10. Message . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 7.11. Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 7.11.1. Plain . . . . . . . . . . . . . . . . . . . . . . . . 12 92 7.11.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . 13 93 7.12. Expires-In . . . . . . . . . . . . . . . . . . . . . . . . 13 94 7.13. OAuth-Grant-Type . . . . . . . . . . . . . . . . . . . . . 13 95 7.14. OAuth-Client-Id . . . . . . . . . . . . . . . . . . . . . 13 96 7.15. OAuth-Client-Secret . . . . . . . . . . . . . . . . . . . 13 97 7.16. OAuth-Code . . . . . . . . . . . . . . . . . . . . . . . . 13 98 7.17. OAuth-Access-Token . . . . . . . . . . . . . . . . . . . . 13 99 7.18. OAuth-Refresh-Token . . . . . . . . . . . . . . . . . . . 13 100 7.19. IToken . . . . . . . . . . . . . . . . . . . . . . . . . . 13 101 7.20. AToken . . . . . . . . . . . . . . . . . . . . . . . . . . 13 102 8. Response Codes . . . . . . . . . . . . . . . . . . . . . . . . 13 103 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 13 104 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 13 105 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 13 106 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 14 107 8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 14 108 8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 14 109 8.4.2. 401 Authentication Required . . . . . . . . . . . . . 14 110 8.4.3. 402 Not Responsible . . . . . . . . . . . . . . . . . 14 111 8.4.4. 403 Authentication Failed . . . . . . . . . . . . . . 14 112 8.4.5. 404 No Common Authentication Scheme . . . . . . . . . 14 113 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 14 114 8.5.1. 501 Not Implemented . . . . . . . . . . . . . . . . . 14 115 9. Security considerations . . . . . . . . . . . . . . . . . . . 14 116 9.1. Token security . . . . . . . . . . . . . . . . . . . . . . 14 117 9.2. Man-in-the-middle attacks . . . . . . . . . . . . . . . . 14 118 9.3. Privacy protection . . . . . . . . . . . . . . . . . . . . 15 119 10. Normative References . . . . . . . . . . . . . . . . . . . . . 15 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 122 1. Overview 124 Tokens are commonly used in access authentication and authorization, 125 for example, in a rather generic way in form of usernames and 126 passwords or in more complex ways such as OAuth access tokens. The 127 Secure Token Transfer Protocol (STTP) provides means to securely 128 transfer such access tokens between different entities that might be 129 involved in the provisioning of such tokens. While tokens are 130 commonly required for authentication and authorization purposes 131 within protocols, they do not always provide means to securely 132 transport or provision them in every scenario. If such means are 133 missing for a specific protocol or scenario, STTP can be used for 134 such tasks. 136 Figure 1 shows an example where STTP is used to transport a set of 137 tokens between three entities to access a resource that is available 138 on a fourth entity. Client A wants to access a protected resource on 139 a server. Between Client A and the server an application specific 140 authentication or authorization protocol is employed (e.g. HTTP 141 Basic Access Authentication or OAuth) within an application specific 142 workflow to access a protected resource (A). The server in turn 143 requests an authentication or authorization protocol specific set of 144 tokens in order to grant the Client access to the requested resource 145 (B). As a set of appropriate tokens is not available on Client A it 146 uses STTP to request a set of tokens from Client B which is under the 147 control and trusted by the resource owner (C). Client A and Client B 148 can be running in different applications and even on different 149 devices. If the user approves the token request, Client B will again 150 use STTP to request a set of tokens that matches the request from 151 Client A from the appropriate authentication or authorization server 152 (D). The corresponding request can be authenticated within STTP if 153 the server requires so. If the user is authorized to access the 154 protected resource the authentication or authorization server will 155 issue a corresponding set of tokens that are opaque to STTP (E). 156 Client B transfers this set of tokens to Client A (F) which in turn 157 can use it in a protocol specific way to authenticate or authorize 158 the access request to the protected resource (G). 160 ----+ 161 +----------+ +-----------------+ |Appl. 162 | Client A |--(A) Access request ---------->| Resource | |spec. 163 | |<-(B) Access token req. --------| | |prot. 164 |(Consumer)|--(G) Access request + token -->| Server | | 165 +----------+ +-----------------+ | 166 | ^ ----+ 167 | | ----+ 168 (C) GETTOKENS | 169 | | | 170 | (F) 200 OK + tokens | 171 | | |STTP 172 V | | 173 +----------+ +-----------------+ | 174 | Client B |--(D) GETTOKENS --------------->| Authentication/ | | 175 |(Resource | | Authorization | | 176 | owner) |<-(E) 200 OK + tokens ----------| Server | | 177 +----------+ +-----------------+ | 178 ----+ 180 Figure 1: STTP Example 182 1.1. Requirements Notation and Conventions 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in RFC 2119 [RFC2119]. 188 1.2. Terminology 190 The following terminology is used throughout this document: 192 Token A data string that is required by another protocol to perform 193 a specific task such as authentication or authorization. The 194 exact context and the further use of tokens is outside the scope 195 of this document. Tokens are opaque to STTP. 197 Client The entity requesting a set of tokens. 199 Server The entity that a set of tokens is requested from. 201 2. Usage Scenarios 203 This document addresses a number of particular scenarios where STTP 204 could be used that are detailed below. 206 2.1. OAuth 208 The OAuth 2.0 Protocol [I-D.ietf-oauth-v2] specifies a workflow that 209 requires end-user authorization. To acquire end-user authorization 210 an application needs to either access a HTTP resource (the end-user 211 authorization endpoint) with an appropriate user-agent or have access 212 to the user's credentials and perform HTTP Basic authentication. In 213 cases where an application does not have access to such an 214 appropriate user-agent or where HTTP Basic authentication is not 215 supported, STTP can be used to request the corresponding OAuth 216 tokens. 218 OAuth also requires the transfer of an Access Grant and an Access 219 Token between the entity accessing the resource server and the 220 application accessing the authorization server. In scenarios where 221 these entities are not part of the same application, STTP can be used 222 to transfer the tokens securely between applications even if they are 223 running on different hosts (e.g. the authorizing application is 224 running on a mobile device). 226 2.2. Dynamic Password Provisioning 228 Passwords as shared secrets are very common for authentication and 229 authorization. While in many cases they are pre-established, STTP 230 can be used to dynamically provision passwords for specific 231 scenarios. An example scenario is the generation of one-time- 232 passwords that can be used to access services over an untrusted link 233 or using an untrusted device. For example, a user can use a trusted 234 mobile device that connects over a secure low-bandwidth link to the 235 authentication and authorization server to retrieve a (one time) 236 token that he can use to access a service on a public Internet 237 terminal that uses a non-secured WiFi connection. In such a scenario 238 the application on the public terminal could use STTP to request a 239 set of tokens from the user's device which in turn uses STTP to 240 retrieve the tokens (after a successful authentication) from the 241 authentication and authorization server. 243 3. Protocol details 245 To transfer a set of tokens a STTP client contacts a STTP server over 246 an appropriate protocol and they exchanges a set of requests and 247 responses. A request is a command string followed by a number of 248 arguments and a response is a numeric code together with a textual 249 representation followed by a number of arguments. Within one 250 connection multiple requests and responses can be exchanged until 251 either the client or the server terminate the connection. 253 GETTOKENS 254 Type: OAuth 255 OAuth-Grant-Type: authorization_code 256 OAuth-Client-Id: s6BhdRkqt3 257 OAuth-Client-Secret: gX1fBat3bV 258 OAuth-Code: i1WsRn1uB 260 Example of a request message 262 200 OK 263 Type: OAuth 264 OAuth-Access-Token: SlAV32hkKG 265 OAuth-Refresh-Token: 8xLOxBtZp8 266 Expires-In: 3600 268 Example of a response message 270 3.1. STTP over HTTP 272 STTP can be used over HTTP(s). When using STTP over HTTP(s) a 273 command MUST be included in the entity-body of a HTTP "POST" request 274 with the "application/x-www-form-urlencoded" content-type. 275 POST /resource HTTP/1.1 276 Host: server.example.com 277 Content-Type: application/x-www-form-urlencoded 279 GETTOKENS 280 Type: Plain 281 Identifier: john.doe@example.com 283 STTP over HTTP example request 285 4. Token Types 287 STTP supports a number of different token types. 289 4.1. OAuth 291 OAuth tokens are OAuth access grant tokens that can be further used 292 by an application to gain access to a resource that is protected 293 using the OAuth protocol. 295 4.2. Generic Tokens 297 Generic tokens are sets of each an identifier token (e.g. a username) 298 and an authentication token (e.g. a password) that be further used by 299 an application to gain access to a username/password protected 300 resource. 302 5. Authentication 304 STTP delegates server authentication to the (optionally) underlying 305 TLS protocol. This document does describe its own methods to perform 306 client authentication. Currently, client authentication via public/ 307 private key cryptography and password-based authentication using the 308 Salted Challenge Response Authentication Mechanism (SCRAM) is 309 supported. 311 5.1. Server authentication 313 Server authentication is performed using certificates during the TLS 314 handshake (see [RFC5246], Section 7.4.2.). If the server did not 315 authentication itself during the TLS handshake, the STTP client MAY 316 terminate the connection if it requires server authentication. 318 5.2. Client authentication 320 If a server requires client authentication for a particular command, 321 it will send a "Authentication Required" response message (see 322 Section 8.4.2) on receiving a command message that does not include 323 sufficient arguments to authenticate the client. The server MUST 324 include a Server-Nonce argument in the response message. 326 5.2.1. Authentication Method Negotiation 328 To negotiate an authentication method, the client includes an Auth- 329 Proposals argument in a command message which contains a list of 330 supported authentication methods. If the client expects that an 331 authentication will be required, for example, for the first command 332 message of an STTP session, it can effectively save one protocol- 333 round-trip by including an Auth-Proposals argument in the initial 334 command message instead of waiting for an "Authentication Required" 335 response message. A command message that includes an Auth-Proposals 336 argument MUST also include a Client-Nonce argument. 338 When the server receives a command message that includes an Auth- 339 Proposals argument and the server does indeed require client 340 authentication, it MUST choose one of the proposals and return a 341 "Authentication Required" response message with an appropriate Auth- 342 Scheme argument and the corresponding arguments that are required for 343 the particular authentication method including the Client-Nonce. If 344 the server does require client authentication but does not support 345 any of the offered authentication methods it MUST respond with a "No 346 Common Authentication Scheme" message. If the server does not 347 require client authentication but the command message includes an 348 Auth-Proposals argument, the server MUST ignore the argument. 350 When selecting an authentication methods the server SHOULD assume 351 that the list of authentication proposals is ordered by client 352 preference. The server SHOULD try to honor the client preferences by 353 selecting the first authentication methods on the list that the 354 server supports. However, operational or administrative directives 355 MAY implement a server-side preference list (for example, by ranking 356 the different authentication methods by the server load they induce) 357 which CAN be used to override the client preferences. 359 5.2.2. Authenticated Request 361 To successfully complete an authentication, the client must compose 362 an authenticated command message. An authenticated command message 363 is a command message that includes a valid Client-Proof argument. 364 The Client-Proof is an authentication method specific string that is 365 computed over the particular command message. Please refer to the 366 details of the authentication methods for the details how the Client- 367 Proof is calculated. The input string for the calculation of the 368 Client-Proof MUST be identical to the command message that the 369 Client-Proof is valid for exclusive of the Client-Proof argument 370 itself. Besides the Client-Proof argument, an authenticated command 371 message MUST also include a Server-Nonce argument that reflects the 372 Server-Nonce that was included by the server in the initial 373 "Authentication Required" response message, a Client-Nonce argument, 374 and a Reflection-Key argument. 376 5.2.3. SCRAM-SHA-1 378 SCRAM authentication is based on the Salted Challenge Response 379 Authentication Mechanism (SCRAM) as described in [RFC5802] with the 380 AuthMessage being the authenticated command message itself (without 381 the Client-Proof argument). SCRAM is only used to authenticate the 382 client. 384 5.2.4. RSA-SHA1 386 Authentication based on Section 8.2. of [RFC3447] (RSASSA-PKCS1-v1_5) 387 with the message to be signed (M) being the authenticated command 388 message (without the Client-Proof argument). 390 6. Commands 392 6.1. GETTOKENS 394 The GETTOKENS command is used by an agent to request a token pair for 395 a particular service URI. 397 6.1.1. Arguments 399 A client MUST include the following arguments in every GETTOKENS 400 command: 402 o Service-URI 404 A client CAN include the following arguments in a GETTOKENS command: 406 o Auth-Proposals 408 o Client-Nonce 410 o Reflection-Key 412 o ... 414 7. Arguments 416 A STTP command can have a number of arguments. Arguments consist of 417 an identifier followed by a colon (":") and the argument value. An 418 argument is terminated by a line break. Basically 4.2 in [RFC2661] 420 7.1. Service-URI 422 The particular service URI that the current command pertains to. 423 Within the context of a GETTOKENS command this is the service URI 424 that the client is requesting a set of tokens for. 426 The Service-URI argument MUST follow the syntax described in 427 [RFC3986]. When determining if a Service-URI matches a valid 428 resource, a server MUST follow the rules for URI comparison for the 429 particular service context (e.g. [RFC2616] for HTTP resources). If 430 no service specific rules exists, a server MUST use a case-sensitive 431 octet-by-octet comparison of the given URI with the following 432 exceptions: 434 o Comparisons of scheme names MUST be case-insensitive; 435 o Comparisons of host names MUST be case-insensitive; 437 o A port that is empty or not given is equivalent to the default 438 port for the particular scheme; 440 o An empty path component is equivalent to the root path "/". 442 Characters that are not classified as "reserved" by [RFC3986] are 443 equivalent to their corresponding percent-encoding ("%" HEXDIG 444 HEXDIG). 446 7.2. Identifier 448 The identifier token (e.g. a username) of the entity that the current 449 exchange is intended for (either a user or another STTP agent). 451 7.3. Server-Nonce 453 A nonce value 455 7.4. Client-Nonce 457 A nonce value 459 7.5. Reflection-Key 461 To prevent man-in-the-middle attacks during authenticated requests, 462 STTP introduces a Reflection-Key. The Reflection-Key argument is 463 included in an authenticated request and reflects the server that the 464 client is talking to. If a server receives a Reflection-Key that 465 doesn't match it's own properties, it MUST terminate the connection. 466 The actual value of the Reflection-Key is dependent on the protocol 467 that STTP is run over. 469 7.5.1. TLS-based transport 471 When STTP is run over a TLS-based protocol such as HTTPS the 472 Reflection-Key argument is the SHA-1 fingerprint of the public key 473 that was used to establish the TLS connection. 475 7.5.2. Other transport 477 When STTP is run over other transport protocols the Reflection-Key 478 argument is the SHA-1 hash of the IP-Address and port number that was 479 used to initiate the connection. 481 7.5.3. Manual verification 483 In n-party scenarios where a STTP server is used to request a token 484 on behalf on another client (e.g. a mobile device is used to request 485 a token for an untrusted terminal) the STTP server and the STTP 486 client SHOULD present the user with a human readable form of the 487 Reflection-Key. This allows the user to manually verify that both 488 Reflection-Keys match and to prevent a man-in-the-middle attack. 490 7.6. Auth-Scheme 492 The authentication scheme that is used in the request. 494 7.7. Client-Proof 496 The client-side result of an authentication run. 498 7.8. Auth-Proposals 500 Comma separated list of authentication schemes that are supported by 501 the client to perform client authentication. MUST be included in a 502 request that follows a "Authentication Required" response for the 503 same service URI. 505 7.9. Iteration-Count 507 Integer value 509 7.10. Message 511 A message which contains more verbose information and that is 512 intended to be displayed to the end user. 514 7.11. Type 516 The type of tokens that are being transferred. 518 o PLAIN 520 o OAuth 522 7.11.1. Plain 524 If the Type argument is set to Plain, the tokens that are being 525 requested/transferred are generic tokens. 527 7.11.2. OAuth 529 If the Type argument is set to Plain, the tokens that are being 530 requested/transferred are OAuth tokens. 532 7.12. Expires-In 534 Number of seconds the transferred tokens are still valid for. 536 7.13. OAuth-Grant-Type 538 7.14. OAuth-Client-Id 540 7.15. OAuth-Client-Secret 542 7.16. OAuth-Code 544 7.17. OAuth-Access-Token 546 7.18. OAuth-Refresh-Token 548 7.19. IToken 550 Generic identifier token (e.g. username). 552 7.20. AToken 554 Generic authentication token (e.g. password). 556 8. Response Codes 558 A server's response starts with a response code that reflects the 559 outcome of the last client request. The available response codes are 560 described in this section including the arguments that are valid for 561 each response. 563 8.1. Informational 1xx 565 Currently no use. 567 8.2. Successful 2xx 569 8.2.1. 200 OK 570 8.3. Redirection 3xx 572 8.4. Client Error 4xx 574 8.4.1. 400 Bad Request 576 8.4.2. 401 Authentication Required 578 8.4.3. 402 Not Responsible 580 8.4.4. 403 Authentication Failed 582 8.4.5. 404 No Common Authentication Scheme 584 8.5. Server Error 5xx 586 8.5.1. 501 Not Implemented 588 9. Security considerations 590 9.1. Token security 592 Currently STTP relies on the transport protocol to protect the 593 tokens. STTP MUST be used over a secure transport protocol such as 594 HTTPS if the tokens are to be protected from eavesdropping. 596 9.2. Man-in-the-middle attacks 598 The goal of an adversary in STTP is to obtain a valid set of tokens 599 pair which he can use to authenticate as the user or to obtain the 600 user's credentials themselves. There are two possible attacks if an 601 adversary successfully tricks a client to connect to a fraudulent 602 server: either the adversary continues with a phishing attack with 603 the goal to obtain user credentials or he switches to a man-in-the- 604 middle attack to gain access to a valid set of tokens that are being 605 transferred. In case he continues the phishing attack the fraudulent 606 server is setup to successfully complete the user authentication even 607 if the credentials cannot be verified. However, STTP only supports a 608 very selective number of authentication methods that do not rely on 609 shared secrets. Neither of the methods supported provide the party 610 that a user is authenticating to with any data that can be used to 611 impersonate the user. In case the attacker switches to a man-in-the- 612 middle attack the STTP authentication that is being relayed from the 613 attacker to the proper STTP server will fail since the Reflection-Key 614 attribute (c.p. Section 7.5) during the authentication doesn't 615 match. However in cases where no user authentication is used, STTP 616 relies on user interaction to manually compare the Reflection-Keys. 618 9.3. Privacy protection 620 To protect the users privacy against eavesdroppers, a secure 621 transport protocol such as TLS-based transports must be used. If 622 such a secure transport is not used, STTP discloses privacy-relevant 623 information such as the URI that tokens are being requested for and 624 the username. 626 10. Normative References 628 [I-D.ietf-oauth-v2] 629 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 630 2.0 Protocol", draft-ietf-oauth-v2-10 (work in progress), 631 July 2010. 633 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 634 Requirement Levels", BCP 14, RFC 2119, March 1997. 636 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 637 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 638 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 640 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 641 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 642 RFC 2661, August 1999. 644 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 645 Standards (PKCS) #1: RSA Cryptography Specifications 646 Version 2.1", RFC 3447, February 2003. 648 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 649 Resource Identifier (URI): Generic Syntax", STD 66, 650 RFC 3986, January 2005. 652 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 653 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 655 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 656 "Salted Challenge Response Authentication Mechanism 657 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 659 Authors' Addresses 661 Niklas Neumann (editor) 662 University of Goettingen 663 Computer Networks Group 664 Goldschmidtstrasse 7 665 Goettingen 37077 666 Germany 668 Email: neumann@cs.uni-goettingen.de 670 Florian Tegeler 671 University of Goettingen 672 Computer Networks Group 673 Goldschmidtstrasse 7 674 Goettingen 37077 675 Germany 677 Email: tegeler@cs.uni-goettingen.de 679 Xiaoming Fu 680 University of Goettingen 681 Computer Networks Group 682 Goldschmidtstrasse 7 683 Goettingen 37077 684 Germany 686 Email: fu@cs.uni-goettingen.de