[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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).


   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

   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].


      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.


      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]>


      C: 220-Simple Roaming Authenticatee v1.0
      C: 220-LANG=en-gb

      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

      <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">



   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.


      ALERT-command ="ALERT" CRLF
                     *(*CHAR CRLF)
                     "." CRLF


      230 OK


      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

   If the SASL mechanism requires that the authenticator starts the
   exchange then its initial challenge is included as part of the AUTH

   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

   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-

   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.


      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 "=")


      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==
      R: 235 Authenticated

      C: AUTH ROAMING-ELGAMAL bdgeg62tsAJHKIYBgfAey28eyduu38qg37egh
      R: 334 hjfhUDSRUDS89753487FHSKSKgd8+esi
      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.


      NOP-command =  "NOP" CRLF


      230 OK


      C: NOP
      R: 230 OK

2.5 QUIT command

   Quit terminates the session, after which the connection SHOULD be


      QUIT-command = "QUIT" CRLF


      230 OK


      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

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
   RH4 1HN


Overell                                                  [Page 9]