idnits 2.17.1 draft-overell-srap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** The abstract seems to contain references ([SASL]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 83: '... reply MAY use a multiline reply. T...' RFC 2119 keyword, line 87: '... MUST be prepared at accept any repl...' RFC 2119 keyword, line 99: '... Commands MAY be given in any order,...' RFC 2119 keyword, line 100: '... MUST NOT be given after QUIT. More...' RFC 2119 keyword, line 101: '... MAY be given during a session....' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1998) is 9567 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) -- Missing reference section? 'SASL' on line 353 looks like a reference -- Missing reference section? 'KEYWORDS' on line 341 looks like a reference -- Missing reference section? 'ABNF' on line 331 looks like a reference -- Missing reference section? 'SMTP' on line 356 looks like a reference -- Missing reference section? 'UTF-8' on line 359 looks like a reference -- Missing reference section? 'HTML' on line 338 looks like a reference -- Missing reference section? 'BASE64' on line 334 looks like a reference -- Missing reference section? 'R-ELG' on line 350 looks like a reference -- Missing reference section? 'LANG' on line 344 looks like a reference -- Missing reference section? 'POP3' on line 347 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Overell 3 Internet-Draft: SRAP Demon Internet Ltd 4 Document: draft-overell-srap-00.txt February 1998 5 Expires: August 1998 7 Simple Roaming Authentication Protocol: SRAP 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 "work in progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 26 (Coast), or ftp.isi.edu (US West Coast). 28 Abstract 30 The Simple Roaming Authentication Protocol is intended to provide an 31 authentication facility for other non-authenticated protocols. It 32 utilises registered SASL [SASL] mechanisms. 34 This protocol has been developed in order that an ISP's roaming 35 customers can be authenticated when connecting via other networks or 36 ISPs. Rather than deploying new client software to handle 37 authenticating versions of all protocols (SMTP, POP3, NNTP etc) a 38 single SRAP applet is deployed that handles the authentication for 39 all other protocols. 41 When the server of a non-authenticated protocol wishes to 42 authenticate a client the server starts another connection back to 43 the client using SRAP. The SRAP conversation authenticates the 44 client to the server. The original non-authenticated protocol can 45 now proceed. 47 For example with SMTP consider two machines Alice's and Bob's. 48 Alice's runs an SMTP client and a SRAP authenticatee; Bob's runs an 49 SMTP server and a SRAP authenticator. Alice's machine connects to 50 Bob's using SMTP. SMTP does not support authentication so another 51 connection is made back from Bob's machine to Alice's, this time 52 using SRAP. The SRAP conversation authenticates Alice to Bob. The 53 SMTP conversation can now proceed. 55 1. Conventions Used in this Document 57 In SASL terminology "server" means the authenticator and "client" 58 means the authenticatee. In Internet text based protocols it is 59 usual that the client issues the commands that the server obeys. 60 Unfortunately, in SRAP this protocol usage of "client" and "server" 61 contradicts the SASL usage. To avoid confusion this memo will use 62 the terms "authenticator" and "authenticatee". 64 Data from the authenticator to the authenticatee is either a 65 "challenge" or a "command", data from the authenticatee to the 66 authenticator is a "response" or, synonymously, a "reply". 68 In examples, "C:" and "R:" indicate command or challenge, and 69 response or reply respectively. 71 The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 72 in this document are to be interpreted as defined in "Key words for 73 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 75 Syntax is expressed in ABNF [ABNF] and its core definitions. 77 Authenticatee responses are like server responses in [SMTP]: a three 78 digit reply code optionally followed by either a space or a dash 79 followed by text. In SRAP this text is expressed UTF-8 [UTF-8]. If 80 a dash follows the reply code then the line is part of a multiline 81 reply and more lines follow, otherwise the line is the only line of 82 a single line reply or is the last line of a multiline reply. Any 83 reply MAY use a multiline reply. The reply codes are taken from 84 [SMTP]. 86 Although this memo documents particular reply codes an authenticator 87 MUST be prepared at accept any reply code from the "Theory of Reply 88 Codes" in [SMTP]. 90 Syntax 92 response = *(3DIGIT "-" *UTF-8-char CRLF) 93 3DIGIT [SP *UTF-8-char] CRLF 95 UTF-8-char = 97 2. Commands and Responses 99 Commands MAY be given in any order, except that further commands 100 MUST NOT be given after QUIT. More than one successful AUTH command 101 MAY be given during a session. 103 2.1 Initial Connection and Greeting 105 Under TCP/IP the authenticatee listens on port 7745. When a 106 connection is established the authenticatee responds with a 107 multiline greeting: an initial banner and a list of capabilities, 108 one per line. The banner is human readable text. The list of 109 capabilities indicate which AUTHentication mechanisms are supported 110 and which LANGuage ALERT text SHOULD be in. Each line starts "220-" 111 except the final line, which starts "220 ". 113 All supported AUTH mechanisms MUST be given. LANGuage capabilities 114 MAY be given. The language(s) specified inform the authenticator of 115 the preferred language(s) for alert text. The authenticator MAY 116 ignore this information. 118 The SRAP protocol allows an authenticee to formally reject a 119 transaction while still allowing the initial connection as follows: 120 a 521 response MAY be given in the initial connection opening 121 message instead of the 220. An authenticee taking this approach 122 MUST then close the connection. This enables an authenticatee to, 123 for example, only accept connections from authenticators at 124 particular IP addresses. 126 Syntax 128 greeting = "220" "-" *UTF-8-char CRLF 129 *("220" "-" capability CRLF) 130 "220" SP capability CRLF 132 capability = "AUTH" "=" mechanism 133 / "LANG" "=" Language-Tag 135 mechanism = 137 Language-Tag = 139 Examples 141 C: 220-Simple Roaming Authenticatee v1.0 142 C: 220-LANG=en-gb 143 C: 220 AUTH=ROAMING-ELGAMAL 145 C: 521 No SRAP Service here 147 2.2 ALERT command 149 The ALERT command specifies text that is to be displayed to the 150 authenticatee's user. The language of the text SHOULD be one of the 151 languages specified in the initial greeting, if any. The alert text 152 is terminated by a line consisting of a single period. Any line of 153 the text that starts with a period has another period prepended. 154 This is the byte stuffing algorithm of [SMTP]. 156 The text is an HTML extract [HTML], that is text which, if placed 157 between 159 160 161 162 Alert 163 164 166 and 168 169 171 would be a valid HTML document. 173 Although the text is specified to be in HTML implementors are warned 174 that in practice SRAP authenticatees MAY only support a limited 175 subset of HTML. However, an authenticatee MUST endeavour to display 176 the text to the user even if the HTML contains unrecognized or 177 unsupported tags. 179 Syntax 181 ALERT-command ="ALERT" CRLF 182 *(*CHAR CRLF) 183 "." CRLF 185 Responses 187 230 OK 189 Example 191 C: ALERT 192 C:

Key Change

193 C: Keys will be changed next Tuesday 194 C: . 195 R: 230 OK 197 2.3 AUTH command 199 The AUTH command authenticates the authenticatee to the 200 authenticator. The mechanism specified SHOULD be an SASL registered 201 mechanism. The AUTH command initiates an exchange of authenticator 202 challenges and authenticatee responses. Each authenticator 203 challenge has an authenticatee response. At the end of the exchange 204 both the authenticator and the authenticatee know if the 205 authentication was successful. 207 The data in challenges and responses are encoded as base64 strings 208 [BASE64]. 210 If the SASL mechanism requires that the authenticator starts the 211 exchange then its initial challenge is included as part of the AUTH 212 command. 214 A particular user may possess a number of different "persona" (user 215 names, user ids). The SRAP authenticator may wish to indicate which 216 particular persona it is seeking authentication for. For example, a 217 POP3 Server would know a USER name from its own protocol, which it 218 may be able to map to a persona. Some SASL mechanisms may permit a 219 persona as part of the initial challenge. In particular ROAMING- 220 ELGAMAL [R-ELG] has been developed specifically for this 221 application. 223 If an authenticatee response requires a further authenticator 224 challenge then the authenticatee uses a reply code of 334 with an 225 optional encoded-response. 227 A multi-line 334 response MAY be used to break-up a long encoded- 228 response. 230 The authenticator's final challenge indicates if authentication was 231 successful. If no data is required then the final challenge MAY be 232 empty. When the authenticator has given its final challenge the 233 authenticatee replies with a 235. 235 If the authenticatee wishes to abort the exchange then it MUST give 236 a response with a 5xy reply code. If the authenticator wishes to 237 abort the exchange it MUST issue a challenge consisting of just a * 238 to which the authenticatee MUST reply with a 5xy. 240 Syntax 242 AUTH-command = "AUTH" SP mechanism 243 [SP encoded-challenge] CRLF 245 AUTH-response =*("334" "-" encoded-response CRLF) 246 "334" [SP encoded-response] CRLF 248 AUTH-challenge =([encoded-challenge] / "*") CRLF 250 encoded-challenge = base64 252 encoded-response = base64 254 base64 = *(4base64_char) [base64_terminal] 256 base64_char = %30-39 / "+" / "/" / %x41-5A / %x61-7A 258 base64_terminal = (2base64_char "==") / (3base64_char "=") 260 Responses 262 235 Authenticated 263 334 264 501 Syntax error 265 504 Unrecognized authentication mechanism 266 505 Unrecognized challenge 267 535 Authentication refused 269 Examples (fictitious) 271 C: AUTH ROAMING-EXAMPLE bdgtsAJHKIYBgfvytAAeydhswjuu38qg37egh 272 R: 334 hjfhUDSRUDS89753487FHSKSKgd8+esi 273 C: 64gftgFDF757GFG 274 R: 334 97847ngheyu35894== 275 C: 276 R: 235 Authenticated 278 C: AUTH ROAMING-ELGAMAL bdgeg62tsAJHKIYBgfAey28eyduu38qg37egh 279 R: 334 hjfhUDSRUDS89753487FHSKSKgd8+esi 280 C: 281 R: 235 Authenticated 283 C: AUTH ROAMING-ELGAMAL bdgeg62tsAJHKIYytAAey28swjuu38qg37egh 284 R: 334-hjfhUDSRUDS89753487FHSKSKgd8+esi 285 R: 334 hgHHGhghhhjUIHJcfggh78hgfkji 286 C: * 287 R: 535 Authentication failed 289 C: AUTH ROAMING-ELGAMAL bdgeg62tsAJHKAAey28eydhswjuu38qg37egh 290 R: 535 Authentication failed 292 2.4 NOP command 294 To prevent an inactivity timeout or to assure continuity of 295 connection the authenticator MAY issue periodic NOP commands. A NOP 296 has no effect other than to elicit a response. 298 Syntax 300 NOP-command = "NOP" CRLF 302 Responses 304 230 OK 306 Example 308 C: NOP 309 R: 230 OK 311 2.5 QUIT command 313 Quit terminates the session, after which the connection SHOULD be 314 broken. 316 Syntax 318 QUIT-command = "QUIT" CRLF 320 Responses 322 230 OK 324 Example 326 C: QUIT 327 R: 230 OK 329 3. References 331 [ABNF] RFC2234, "Augmented BNF for syntax specifications: 332 ABNF", D. Crocker and P. Overell, November 1997. 334 [BASE64] RFC2045, "Multipurpose Internet Mail Extensions (MIME) 335 Part one: Format of Internet Message Bodies", N. 336 Freed et al, November 1996. 338 [HTML] "HTML 3.2 Reference Specification", W3C Recommendation 339 14-Jan-1997 341 [KEYWORDS] RFC2119, "Key words for use in RFCs to Indicate 342 Requirement Levels", Bradner, March 1997. 344 [LANG] RFC1766, "Tags for the Identification of Languages", 345 H. Alvestrand, March 1995. 347 [POP3] RFC1939, "Post Office Protocol - Version 3". J. Myers 348 & M. Rose. May 1996. 350 [R-ELG] Work in progress, "ROAMING-ELGAMAL SASL Authentication 351 Mechanism", P.Overell, February 1998. 353 [SASL] RFC2222, "Simple Authentication and Security Layer 354 (SASL)", J. Myers, October 1997. 356 [SMTP] RFC821, "Simple Mail Transfer Protocol", J. Postel, 357 August 1982. 359 [UTF-8] RFC2279 "UTF-8, a transformation format of ISO 10646". 360 F. Yergeau. January 1998. 362 4. Security Considerations 364 The security of the AUTH command is a matter for the particular SASL 365 mechanism used. 367 A denial-of-service attack is possible by sending spurious 368 authentication requests or HTML alerts from arbitrary Internet 369 hosts. If the chosen SASL mechanism has any weakness in respect of 370 multiple authentications then the authenticatee can prevent this by 371 refusing the initial connection unless it comes from a specific 372 netblock or hostname; or by restricting the number of repeat 373 connections from the same IP address. 375 The NOP command can be used to demonstrate that there is still a 376 TCP/IP connection to the authenticatee. If the TCP/IP stack at the 377 authenticatee was stopped and restarted, or indeed replaced by a 378 completely different machine (as might happen with a dial-up 379 connection shared between many users) then the NOP command would 380 show that the original authenticated authenticatee was no longer 381 present. However, if someone could replace the original 382 authenticated authenticatee by code that could handle the NOP 383 command identically to the original authenticatee then security will 384 have been breached. 386 Similar TCP/IP considerations exist for the original service for 387 which the authentication was done. It again is relying on the 388 continuity of the TCP/IP connection, which is secure against 389 innocent reuse of the IP address by another machine, but is not 390 secure against malevolent attack. 392 5. Author's Address 394 P. Overell 395 Demon Internet Ltd 396 Dorking Business Park 397 Dorking 398 Surrey 399 RH4 1HN 400 UK 402 mailto:paulo@turnpike.com