Network Working Group P. Overell Internet-Draft: SRAP Demon Internet Ltd Document: draft-overell-srap-00.txt February 1998 Expires: August 1998 Simple Roaming Authentication Protocol: SRAP Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East (Coast), or ftp.isi.edu (US West Coast). Abstract The Simple Roaming Authentication Protocol is intended to provide an authentication facility for other non-authenticated protocols. It utilises registered SASL [SASL] mechanisms. This protocol has been developed in order that an ISP's roaming customers can be authenticated when connecting via other networks or ISPs. Rather than deploying new client software to handle authenticating versions of all protocols (SMTP, POP3, NNTP etc) a single SRAP applet is deployed that handles the authentication for all other protocols. When the server of a non-authenticated protocol wishes to authenticate a client the server starts another connection back to the client using SRAP. The SRAP conversation authenticates the client to the server. The original non-authenticated protocol can now proceed. For example with SMTP consider two machines Alice's and Bob's. Alice's runs an SMTP client and a SRAP authenticatee; Bob's runs an SMTP server and a SRAP authenticator. Alice's machine connects to Overell [Page 1]
Internet Draft SRAP February 1998 Bob's using SMTP. SMTP does not support authentication so another connection is made back from Bob's machine to Alice's, this time using SRAP. The SRAP conversation authenticates Alice to Bob. The SMTP conversation can now proceed. 1. Conventions Used in this Document In SASL terminology "server" means the authenticator and "client" means the authenticatee. In Internet text based protocols it is usual that the client issues the commands that the server obeys. Unfortunately, in SRAP this protocol usage of "client" and "server" contradicts the SASL usage. To avoid confusion this memo will use the terms "authenticator" and "authenticatee". Data from the authenticator to the authenticatee is either a "challenge" or a "command", data from the authenticatee to the authenticator is a "response" or, synonymously, a "reply". In examples, "C:" and "R:" indicate command or challenge, and response or reply respectively. The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. Syntax is expressed in ABNF [ABNF] and its core definitions. Authenticatee responses are like server responses in [SMTP]: a three digit reply code optionally followed by either a space or a dash followed by text. In SRAP this text is expressed UTF-8 [UTF-8]. If a dash follows the reply code then the line is part of a multiline reply and more lines follow, otherwise the line is the only line of a single line reply or is the last line of a multiline reply. Any reply MAY use a multiline reply. The reply codes are taken from [SMTP]. Although this memo documents particular reply codes an authenticator MUST be prepared at accept any reply code from the "Theory of Reply Codes" in [SMTP]. Syntax response = *(3DIGIT "-" *UTF-8-char CRLF) 3DIGIT [SP *UTF-8-char] CRLF UTF-8-char = <defined by [UTF-8]> Overell [Page 2]
Internet Draft SRAP February 1998 2. Commands and Responses Commands MAY be given in any order, except that further commands MUST NOT be given after QUIT. More than one successful AUTH command MAY be given during a session. 2.1 Initial Connection and Greeting Under TCP/IP the authenticatee listens on port 7745. When a connection is established the authenticatee responds with a multiline greeting: an initial banner and a list of capabilities, one per line. The banner is human readable text. The list of capabilities indicate which AUTHentication mechanisms are supported and which LANGuage ALERT text SHOULD be in. Each line starts "220-" except the final line, which starts "220 ". All supported AUTH mechanisms MUST be given. LANGuage capabilities MAY be given. The language(s) specified inform the authenticator of the preferred language(s) for alert text. The authenticator MAY ignore this information. The SRAP protocol allows an authenticee to formally reject a transaction while still allowing the initial connection as follows: a 521 response MAY be given in the initial connection opening message instead of the 220. An authenticee taking this approach MUST then close the connection. This enables an authenticatee to, for example, only accept connections from authenticators at particular IP addresses. Syntax greeting = "220" "-" *UTF-8-char CRLF *("220" "-" capability CRLF) "220" SP capability CRLF capability = "AUTH" "=" mechanism / "LANG" "=" Language-Tag mechanism = <registered SASL mechanism> Language-Tag = <defined in [LANG]> Examples C: 220-Simple Roaming Authenticatee v1.0 C: 220-LANG=en-gb C: 220 AUTH=ROAMING-ELGAMAL C: 521 No SRAP Service here Overell [Page 3]
Internet Draft SRAP February 1998 2.2 ALERT command The ALERT command specifies text that is to be displayed to the authenticatee's user. The language of the text SHOULD be one of the languages specified in the initial greeting, if any. The alert text is terminated by a line consisting of a single period. Any line of the text that starts with a period has another period prepended. This is the byte stuffing algorithm of [SMTP]. The text is an HTML extract [HTML], that is text which, if placed between <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <TITLE>Alert</TITLE> </HEAD> <BODY> and </BODY> </HTML> would be a valid HTML document. Although the text is specified to be in HTML implementors are warned that in practice SRAP authenticatees MAY only support a limited subset of HTML. However, an authenticatee MUST endeavour to display the text to the user even if the HTML contains unrecognized or unsupported tags. Syntax ALERT-command ="ALERT" CRLF *(*CHAR CRLF) "." CRLF Responses 230 OK Example C: ALERT C: <H1>Key Change</H1> C: Keys will be changed next Tuesday C: . R: 230 OK Overell [Page 4]
Internet Draft SRAP February 1998 2.3 AUTH command The AUTH command authenticates the authenticatee to the authenticator. The mechanism specified SHOULD be an SASL registered mechanism. The AUTH command initiates an exchange of authenticator challenges and authenticatee responses. Each authenticator challenge has an authenticatee response. At the end of the exchange both the authenticator and the authenticatee know if the authentication was successful. The data in challenges and responses are encoded as base64 strings [BASE64]. If the SASL mechanism requires that the authenticator starts the exchange then its initial challenge is included as part of the AUTH command. A particular user may possess a number of different "persona" (user names, user ids). The SRAP authenticator may wish to indicate which particular persona it is seeking authentication for. For example, a POP3 Server would know a USER name from its own protocol, which it may be able to map to a persona. Some SASL mechanisms may permit a persona as part of the initial challenge. In particular ROAMING- ELGAMAL [R-ELG] has been developed specifically for this application. If an authenticatee response requires a further authenticator challenge then the authenticatee uses a reply code of 334 with an optional encoded-response. A multi-line 334 response MAY be used to break-up a long encoded- response. The authenticator's final challenge indicates if authentication was successful. If no data is required then the final challenge MAY be empty. When the authenticator has given its final challenge the authenticatee replies with a 235. If the authenticatee wishes to abort the exchange then it MUST give a response with a 5xy reply code. If the authenticator wishes to abort the exchange it MUST issue a challenge consisting of just a * to which the authenticatee MUST reply with a 5xy. Syntax AUTH-command = "AUTH" SP mechanism [SP encoded-challenge] CRLF Overell [Page 5]
Internet Draft SRAP February 1998 AUTH-response =*("334" "-" encoded-response CRLF) "334" [SP encoded-response] CRLF AUTH-challenge =([encoded-challenge] / "*") CRLF encoded-challenge = base64 encoded-response = base64 base64 = *(4base64_char) [base64_terminal] base64_char = %30-39 / "+" / "/" / %x41-5A / %x61-7A base64_terminal = (2base64_char "==") / (3base64_char "=") Responses 235 Authenticated 334 <encoded-response> 501 Syntax error 504 Unrecognized authentication mechanism 505 Unrecognized challenge 535 Authentication refused Examples (fictitious) C: AUTH ROAMING-EXAMPLE bdgtsAJHKIYBgfvytAAeydhswjuu38qg37egh R: 334 hjfhUDSRUDS89753487FHSKSKgd8+esi C: 64gftgFDF757GFG R: 334 97847ngheyu35894== C: R: 235 Authenticated C: AUTH ROAMING-ELGAMAL bdgeg62tsAJHKIYBgfAey28eyduu38qg37egh R: 334 hjfhUDSRUDS89753487FHSKSKgd8+esi C: R: 235 Authenticated C: AUTH ROAMING-ELGAMAL bdgeg62tsAJHKIYytAAey28swjuu38qg37egh R: 334-hjfhUDSRUDS89753487FHSKSKgd8+esi R: 334 hgHHGhghhhjUIHJcfggh78hgfkji C: * R: 535 Authentication failed C: AUTH ROAMING-ELGAMAL bdgeg62tsAJHKAAey28eydhswjuu38qg37egh R: 535 Authentication failed Overell [Page 6]
Internet Draft SRAP February 1998 2.4 NOP command To prevent an inactivity timeout or to assure continuity of connection the authenticator MAY issue periodic NOP commands. A NOP has no effect other than to elicit a response. Syntax NOP-command = "NOP" CRLF Responses 230 OK Example C: NOP R: 230 OK 2.5 QUIT command Quit terminates the session, after which the connection SHOULD be broken. Syntax QUIT-command = "QUIT" CRLF Responses 230 OK Example C: QUIT R: 230 OK 3. References [ABNF] RFC2234, "Augmented BNF for syntax specifications: ABNF", D. Crocker and P. Overell, November 1997. [BASE64] RFC2045, "Multipurpose Internet Mail Extensions (MIME) Part one: Format of Internet Message Bodies", N. Freed et al, November 1996. [HTML] "HTML 3.2 Reference Specification", W3C Recommendation 14-Jan-1997 Overell [Page 7]
Internet Draft SRAP February 1998 [KEYWORDS] RFC2119, "Key words for use in RFCs to Indicate Requirement Levels", Bradner, March 1997. [LANG] RFC1766, "Tags for the Identification of Languages", H. Alvestrand, March 1995. [POP3] RFC1939, "Post Office Protocol - Version 3". J. Myers & M. Rose. May 1996. [R-ELG] Work in progress, "ROAMING-ELGAMAL SASL Authentication Mechanism", P.Overell, February 1998. [SASL] RFC2222, "Simple Authentication and Security Layer (SASL)", J. Myers, October 1997. [SMTP] RFC821, "Simple Mail Transfer Protocol", J. Postel, August 1982. [UTF-8] RFC2279 "UTF-8, a transformation format of ISO 10646". F. Yergeau. January 1998. 4. Security Considerations The security of the AUTH command is a matter for the particular SASL mechanism used. A denial-of-service attack is possible by sending spurious authentication requests or HTML alerts from arbitrary Internet hosts. If the chosen SASL mechanism has any weakness in respect of multiple authentications then the authenticatee can prevent this by refusing the initial connection unless it comes from a specific netblock or hostname; or by restricting the number of repeat connections from the same IP address. The NOP command can be used to demonstrate that there is still a TCP/IP connection to the authenticatee. If the TCP/IP stack at the authenticatee was stopped and restarted, or indeed replaced by a completely different machine (as might happen with a dial-up connection shared between many users) then the NOP command would show that the original authenticated authenticatee was no longer present. However, if someone could replace the original authenticated authenticatee by code that could handle the NOP command identically to the original authenticatee then security will have been breached. Similar TCP/IP considerations exist for the original service for which the authentication was done. It again is relying on the continuity of the TCP/IP connection, which is secure against Overell [Page 8]
Internet Draft SRAP February 1998 innocent reuse of the IP address by another machine, but is not secure against malevolent attack. 5. Author's Address P. Overell Demon Internet Ltd Dorking Business Park Dorking Surrey RH4 1HN UK mailto:paulo@turnpike.com Overell [Page 9]