doc/specification/draft-newman-nntpext-auth-01.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          C. Newman
   8 Internet Draft                                                  Innosoft
   9 Document: draft-ietf-nntpext-auth-01.txt                   November 1998
  10                                                    Expires in six months
  11
  12
  13                           NNTP Authentication
  14
  15
  16 Status of this memo
  17
  18      This document is an Internet-Draft.  Internet-Drafts are working
  19      documents of the Internet Engineering Task Force (IETF), its areas,
  20      and its working groups.  Note that other groups may also distribute
  21      working documents as Internet-Drafts.
  22
  23      Internet-Drafts are draft documents valid for a maximum of six
  24      months and may be updated, replaced, or obsoleted by other
  25      documents at any time.  It is inappropriate to use Internet-Drafts
  26      as reference material or to cite them other than as "work in
  27      progress."
  28
  29      To view the entire list of current Internet-Drafts, please check
  30      the "1id-abstracts.txt" listing contained in the Internet-Drafts
  31      Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
  32      (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
  33      (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
  34      West Coast).
  35
  36 Abstract
  37
  38      Although NNTP [NNTP] has traditionally provided public access to
  39      newsgroups, it is often useful to use authentication to control
  40      resource consumption as well as to create restricted-access
  41      newsgroups.  The NNTP AUTHINFO command described here provides a
  42      way to do this.
  43
  44 1. How to Read This Document
  45
  46      The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
  47      "RECOMMENDED" and "MAY" in this document are to be interpreted as
  48      defined in RFC 1123.
  49
  50      This document assumes you are familiar with NNTP [NNTP] and SASL
  51      [SASL].
  52
  53      In the examples, commands from the client are indicated with [C],
  54      and responses from the server are indicated with [S].
  55
  56
  57
  58 Newman                                                          [Page 1]
  59 \f
  60 Internet Draft            NNTP Authentication              November 1998
  61
  62
  63 2. AUTHINFO and SASL Capabilities
  64
  65      A server supporting the AUTHINFO command as defined in this
  66      specification will advertise the "AUTHINFO" capability in response
  67      to the "LIST EXTENSIONS" command.  The AUTHINFO capability has one
  68      OPTIONAL argument "USER" which indicates that AUTHINFO USER and
  69      AUTHINFO PASS are supported.
  70
  71      A server supporting AUTHINFO SASL will advertise the "SASL"
  72      capability in response to the "LIST EXTENSIONS" command.  The SASL
  73      capability is followed by a space-separated list of SASL mechanism
  74      names.
  75
  76      Example:
  77           [C] LIST EXTENSIONS
  78           [S] 202-Extensions supported:
  79           [S]  OVER
  80           [S]  PAT
  81           [S]  LISTGROUP
  82           [S]  AUTHINFO USER
  83           [S]  SASL CRAM-MD5 GSSAPI
  84           [S] .
  85
  86      It is not required to issue LIST EXTENSIONS prior to attempting use
  87      of AUTHINFO or any SASL mechanism.
  88
  89 3. Authentication Response Codes
  90
  91      An NNTP server MAY respond to any client command other than QUIT or
  92      AUTHINFO with a 450 failure response.  This indicates the client
  93      MUST authenticate in order to use that command or access that
  94      resource.
  95
  96      If a client has previously authenticated, but is not authorized to
  97      access a given resource, the server MAY respond with a 452 failure
  98      response.
  99
 100 4. AUTHINFO
 101
 102      AUTHINFO is used to authenticate a user.  In all cases, clients
 103      MUST provide this information when requested by the server.
 104      Servers are not required to accept authentication information that
 105      is volunteered by the client.  Clients MUST accommodate servers
 106      that reject any authentication information volunteered by the
 107      client.
 108
 109
 110
 111
 112
 113
 114 Newman                                                          [Page 2]
 115 \f
 116 Internet Draft            NNTP Authentication              November 1998
 117
 118
 119 4.1. AUTHINFO USER/PASS
 120
 121      AUTHINFO USER username
 122
 123      AUTHINFO PASS password
 124
 125      These commands permit the client to use a clear-text password to
 126      authenticate.  A compliant implementation MUST NOT implement this
 127      mechanism without also implementing support for a strong encryption
 128      layer or a stronger authentication mechanism.  Use of this
 129      mechanism is deprecated as it exposes the user's password to all
 130      parties on the network between the client and the server.  Any
 131      implementation of this mechanism SHOULD include a configuration
 132      option which disables it.
 133
 134      The client begins by issuing the AUTHINFO USER username command.
 135      If the server is willing to accept this form of authentication and
 136      a password is required, the server responds with a 350 response.
 137      The client continues by sending the AUTHINFO PASS password command.
 138      If the username/password combination is valid or no password is
 139      required, the server responds with a 250 response and the client
 140      MAY then retry the command which resulted in a 450 response.
 141
 142      If the server returns 501, this means that the command was
 143      syntactically incorrect, or that this form of AUTHINFO is not
 144      supported.
 145
 146      If the requested authenticator capability is not found or there is
 147      some other unspecified server program error, the server MUST return
 148      the 503 response code.
 149
 150      Only US-ASCII printable characters SHOULD be used in the username
 151      and password to permit maximal interoperability.  If non-US-ASCII
 152      characters are used in a username, they MUST use UTF-8.  Passwords
 153      MAY contain arbitrary binary data excluding NUL, CR and LF
 154      characters.  However, if a password is supplied to the client as a
 155      sequence of characters (e.g., a password dialog box), those
 156      characters MUST be encoded as UTF-8.
 157
 158      Example:
 159           [C] AUTHINFO USER fred
 160           [S] 350 Enter Passphrase
 161           [C] AUTHINFO PASS flintstone
 162           [S] 250 Authorization accepted
 163
 164 4.1.2. Responses
 165
 166      250 Authorization accepted
 167
 168
 169
 170 Newman                                                          [Page 3]
 171 \f
 172 Internet Draft            NNTP Authentication              November 1998
 173
 174
 175      350 Continue with authorization sequence
 176      450 Authorization required for this command
 177      452 Authorization rejected
 178      501 Command not supported or Command Syntax Error
 179      503 Program error, function not performed
 180
 181      Clients MUST support other response codes by processing them based
 182      on the first digit.
 183
 184 4.2. AUTHINFO SASL
 185
 186      AUTHINFO SASL mechanism [initial-response]
 187
 188      The AUTHINFO SASL command permits NNTP clients to authenticate
 189      using SASL [SASL] mechanisms such as CRAM-MD5 [CRAM-MD5],
 190      KERBEROS_V4, GSSAPI or EXTERNAL.  This profile of SASL uses the
 191      service name "news" for Kerberos and GSSAPI mechanisms.
 192
 193      If AUTHINFO is implemented, then AUTHINFO SASL and the DIGEST-MD5
 194      [DIGEST-MD5] mechanism MUST be implemented.  This is necessary to
 195      ensure that any two compliant clients and servers can be configured
 196      to authenticate without using unencrypted clear-text passwords.
 197      [NOTE:  CRAM-MD5 is an expedient alternative choice as it's already
 198      standards track.]
 199
 200      The optional initial-response argument is a base64-encoded string
 201      of the initial client response for SASL mechanisms with no initial
 202      server challenge.
 203
 204      The server MAY continue the authentication exchange with a 351
 205      response containing a base64-encoded server-challenge.  The client
 206      replies with a line containing a base64-encoded client-response
 207      followed by CRLF, or with a "*" followed by CRLF to cancel the
 208      exchange.  The server responds to "*" with a 501 response.
 209
 210      The server indicates successful completion with either a 250
 211      success response, or a 251 success response which contains a
 212      base64-encoded token with final server challenge data.  The server
 213      indicates failure with a 452, 501, 503 error.
 214
 215      If a security layer is negotiated, the server begins with the octet
 216      immediately after the CRLF at the end of a 250 or 251 success
 217      response, and the client begins with the octet immediately after
 218      the CRLF of the last client-response in the SASL exchange.  In
 219      addition, after a security layer is negotiated, the client SHOULD
 220      re-issue the LIST EXTENSIONS command to reduce the impact of active
 221      attacks prior to authentication.
 222
 223
 224
 225
 226 Newman                                                          [Page 4]
 227 \f
 228 Internet Draft            NNTP Authentication              November 1998
 229
 230
 231      In the following example, the username is "tim" and the password is
 232      "tanstaaftanstaaf".
 233
 234      Example:
 235           [C] AUTHINFO SASL CRAM-MD5
 236           [S] 351 PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
 237           [C] dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
 238           [S] 250 Authorization accepted
 239
 240 4.2.1 Responses
 241
 242      250 Authorization accepted
 243      251 final-server-challenge-data (client authorization accepted)
 244      351 server-challenge-data
 245      452 Authorization rejected
 246      501 Command not supported or Command Syntax Error
 247      503 Program error, function not performed
 248
 249      Clients MUST support other response codes by processing them based
 250      on the first digit.
 251
 252 4.3. AUTHINFO SIMPLE
 253
 254      The AUTHINFO SIMPLE command provided equiavlent functionality to
 255      AUTHINFO USER and AUTHINFO PASS.  It is now deprecated.  Some
 256      information about current use is documented in "Common NNTP
 257      Extensions" [NNTP-EXT-INFO].
 258
 259 4.4. AUTHINFO GENERIC
 260
 261      The AUTHINFO GENERIC command provided a service which is roughly
 262      comparable to the authentication framework which SASL provides,
 263      except that it requires authentication mechanisms to be designed
 264      specifically for NNTP.  It is now deprecated.  Some information
 265      about current use is documented in "Common NNTP Extensions" [NNTP-
 266      EXT-INFO].
 267
 268 4.5. Transition Issues
 269
 270      The implementations of AUTHINFO USER/PASS commonly in use prior to
 271      the release of this memo have a different response code set. The
 272      code 281 was used in place of 250, 381 and 480 were used in place
 273      of 450 and 482 and 502 were used in place of 452. Clients compliant
 274      with this spec MAY also want to be able to accommodate the older
 275      codes to lessen the impact of the transition to this specification.
 276
 277
 278
 279
 280
 281
 282 Newman                                                          [Page 5]
 283 \f
 284 Internet Draft            NNTP Authentication              November 1998
 285
 286
 287 4.6. Formal Syntax
 288
 289      This amends the formal syntax for NNTP [NNTP] to add these
 290      additional commands.  The syntax is defined using ABNF [ABNF],
 291      including the core rules from section 6 of ABNF.
 292
 293      authinfo-capability   = "AUTHINFO" [SP "USER"] CRLF
 294      sasl-capability       = "SASL" 1*(SP sasl-mech) CRLF
 295      command              /= authinfo-user-command /
 296                              authinfo-pass-command /
 297                              authinfo-sasl-command
 298      authinfo-user-command = "AUTHINFO" 1*WSP "USER" 1*WSP username
 299                              *WSP CRLF
 300      authinfo-pass-command = "AUTHINFO" 1*WSP "PASS" 1*WSP password
 301                              *WSP CRLF
 302      authinfo-sasl-command = "AUTHINFO" 1*WSP "SASL" 1*WSP sasl-mech
 303                              [1*WSP base64 *WSP] *(CRLF base64) CRLF
 304                     ; client waits for server response after each CRLF
 305      resp-sasl-data        = ("351" / "251") SP base64
 306
 307      sasl-mech             = 1*20mech-char
 308      mech-char             = %x41-5A / DIGIT / "-" / "_"
 309                     ; mech names restricted to uppercase letters,
 310                     ; digits, "-" and "_"
 311      username              = 1*UTF8-SAFE
 312      password              = 1*PASS-DATA
 313      PASS-DATA             = %x01-09 / %x0B-0C / %x0E-FF
 314      UTF8-SAFE             = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 /
 315                              UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6
 316      UTF8-1                = %x80-BF
 317      UTF8-2                = %xC0-DF UTF8-1
 318      UTF8-3                = %xE0-EF 2UTF8-1
 319      UTF8-4                = %xF0-F7 3UTF8-1
 320      UTF8-5                = %xF8-FB 4UTF8-1
 321      UTF8-6                = %xFC-FD 5UTF8-1
 322      base64                = *(4base64-char) [base64-terminal]
 323      base64-char           = ALPHA / DIGIT / "+" / "/"
 324                     ; case sensitive
 325      base64-terminal       = (2base64-char "==") / (3base64-char "=")
 326
 327 5. Security Considerations
 328
 329      The AUTHINFO USER and AUTHINFO PASS commands are subject to passive
 330      attacks and replay attacks and are therefore not safe for most
 331      real-world use.
 332
 333      The AUTHINFO SASL command inherits the security considerations of
 334      the underlying mechanism and the security considerations of SASL.
 335
 336
 337
 338 Newman                                                          [Page 6]
 339 \f
 340 Internet Draft            NNTP Authentication              November 1998
 341
 342
 343      When multiple authentication mechanisms are permitted by both
 344      client and server, then an active attacker can cause a down-
 345      negotiation to the weakest mechanism.  For this reason, both
 346      clients and servers SHOULD be configurable to forbid use of weaker
 347      mechanisms.
 348
 349      A SASL integrity protection layer can not protect protocol
 350      exchanges conducted prior to authentication.  For this reason, the
 351      LIST EXTENSIONS command SHOULD be re-issued after successful
 352      negotiation of integrity protection, and other protocol state
 353      SHOULD be re-negotiated as well.  When integrity protection is
 354      negotiated, the client MAY compare the list of available SASL
 355      mechanisms before and after authentication to detect active down-
 356      negotiation attacks.
 357
 358 6. Acknowledgements
 359
 360      A significant amount of this text was originally from the NNTP
 361      revision spec written by Stan Barber.
 362
 363 7. References
 364
 365      [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension
 366      for Simple Challenge/Response", RFC 2195, MCI, September 1997.
 367
 368      [DIGEST-MD5] Leach, P., Newman, C., "Using Digest Authentication as a
 369      SASL Mechanism", Work in Progress.
 370
 371      [NNTP] Barber, S., "Network News Transport Protocol", Work in
 372      Progress.
 373
 374      [NNTP-EXT-INFO] Barber, S., "Common NNTP Extensions", Work in Progress.
 375
 376      [SASL] Myers, "Simple Authentication and Security Layer (SASL)", RFC
 377      2222, Netscape Communications, October 1997.
 378
 379      [UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646",
 380      RFC 2279, Alis Technologies, January 1998.
 381
 382 8. Authors' Addresses
 383
 384      Chris Newman
 385      Innosoft International, Inc.
 386      1050 Lakes Drive
 387      West Covina, CA 91790 USA
 388
 389      Email: chris.newman@innosoft.com
 390
 391
 392
 393
 394 Newman                                                          [Page 7]