doc/specification/draft-overell-roaming-elgamal-sasl-00.txt

   1
   2
   3 Network Working Group                                  P. Overell
   4 Internet Draft: ROAMING-ELGAMAL                Demon Internet Ltd
   5 Document: draft-overell-roaming-elgamal-sasl-00.txt February 1998
   6                                              Expires: August 1998
   7
   8
   9            ROAMING-ELGAMAL SASL Authentication Mechanism
  10
  11 Status of this Memo
  12
  13    This document is an Internet-Draft.  Internet-Drafts are working
  14    documents of the Internet Engineering Task Force (IETF), its
  15    areas, and its working groups.  Note that other groups may also
  16    distribute working documents as Internet-Drafts.
  17
  18    Internet-Drafts are draft documents valid for a maximum of six
  19    months and may be updated, replaced, or obsoleted by other
  20    documents at any time.  It is inappropriate to use Internet-
  21    Drafts as reference material or to cite them other than as
  22    "work in progress."
  23
  24    To view the entire list of current Internet-Drafts, please check
  25    the "1id-abstracts.txt" listing contained in the Internet-Drafts
  26    Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
  27    (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
  28    (Coast), or ftp.isi.edu (US West Coast).
  29
  30 Abstract
  31
  32    ROAMING-ELGAMAL is an SASL [SASL] authentication mechanism in which
  33    ElGamal [ELG] public key cryptography is used to encrypt the persona
  34    and password thus giving a high degree of security.
  35
  36    Although specifically designed for the Simple Roaming Authentication
  37    Protocol [SRAP], ROAMING-ELGAMAL is intended to be a registered SASL
  38    mechanism and so could be adapted to other protocols.  The mechanism
  39    has been designed to resist attack from interception, man in the
  40    middle, and replay.  The security of the mechanism rests with the
  41    protection of the private key.
  42
  43 1. Conventions Used in this Document
  44
  45    In SASL terminology "server" means the authenticator and "client"
  46    means the authenticatee.  Data from the server to the client is a
  47    "challenge", data from the client to the server is a "response".
  48
  49    All syntax is specified using ABNF [ABNF] and its core definitions.
  50
  51
  52
  53
  54
  55 Overell                                                  [Page 1]
  56 \f
  57
  58
  59 Internet Draft           ROAMING-ELGAMAL            February 1998
  60
  61
  62
  63
  64 2. ROAMING-ELGAMAL Mechanism
  65
  66    The SASL authentication type associated with ROAMING-ELGAMAL is
  67    "ROAMING-ELGAMAL".
  68
  69    This memo is only concerned with authentication, however, a security
  70    layer could be easily added either by continuing to use ElGamal
  71    encryption for the remainder of the conversation; or by using a
  72    symmetric cipher with a session key derived from the calculated
  73    value of y^k, a value known to both parties only after
  74    authentication is complete.
  75
  76 2.1 Initial Server Challenge
  77
  78    The data encoded in the initial challenge is a persona, a
  79    fingerprint and a cookie.
  80
  81    The persona indicates which persona/password pair the server is
  82    seeking authentication for.  If no persona is specified (zero size)
  83    then the client may choose either to return any of its
  84    persona/passwords or fail the command.  If the persona is specified
  85    but not recognized then the client SHOULD fail the command.  An
  86    implementation MAY choose the persona to be the same as a "username"
  87    or "user id" but this memo does not require this interpretation.
  88
  89    The fingerprint indicates which public key the client should use to
  90    encrypt its response.  The fingerprint MAY be the MD5 or SHA-1 of
  91    the public key as per PGP, but this memo does not require this
  92    interpretation.
  93
  94    The cookie is a presumptively arbitrary string of random octets.
  95    The cookie should be unique and unpredictable, preferably a
  96    cryptographically strong random number.  Its purpose is to defeat
  97    replay attack.
  98
  99    This memo does not define the length or content of the persona,
 100    fingerprint or cookie.  To permit any octet to be used each element
 101    is preceded by its size in octets expressed as a number in text
 102    enclosed in braces.  The encoding used is defined by the host
 103    protocol.
 104
 105    Syntax
 106
 107       unencoded-challenge = size persona size fingerprint size cookie
 108
 109       persona = *OCTET
 110
 111       fingerprint = *OCTET
 112
 113
 114
 115
 116 Overell                                                  [Page 2]
 117 \f
 118
 119
 120 Internet Draft           ROAMING-ELGAMAL            February 1998
 121
 122
 123
 124
 125       cookie = *OCTET
 126
 127       size = "{" 1*DIGIT "}"
 128
 129    Example (fictitious)
 130
 131       {4}paul{32}AB246508F5217B54C77D3400239BCA45{16}9723763476348973
 132
 133 2.2 Client's Response
 134
 135    If the client wishes to proceed then it responds with an encoded
 136    string of the ElGamal encrypted string of the PKCS#1 [PKCS#1] packed
 137    string consisting of the client's persona, password and the server's
 138    cookie.  The server's public key is used for the encryption.  This
 139    memo does not describe how the client may obtain the server's public
 140    key.  The encoding used is defined by the host protocol
 141
 142    This memo places no restriction whatsoever on the content or length
 143    of persona, password or cookie.  In the unpacked-response each
 144    element is preceded by its size in octets expressed as a number in
 145    text enclosed in braces.
 146
 147    Syntax
 148
 149       persona = *OCTET
 150
 151       password = *OCTET
 152
 153       cookie = *OCTET
 154
 155       size = "{" 1*DIGIT "}"
 156
 157       unpacked-response = size persona size password size cookie
 158
 159       packed-response = %x00 %x02 8*padding %x00 unpacked-response
 160
 161       padding = %x01-FF
 162
 163    Example (fictitious)
 164
 165       {4}paul{8}sausages{20}b_basdlwyweyfbc73m8f
 166
 167 2.2.1 Packing and Encryption
 168
 169    Let L be the length in octets of the ElGamal encryption modulus.
 170
 171    If the length of the unpacked-response is greater than L - 11 octets
 172    then the unpacked-response is split into sections, each of which
 173    must be less than or equal to L - 11 octets long.
 174
 175
 176
 177 Overell                                                  [Page 3]
 178 \f
 179
 180
 181 Internet Draft           ROAMING-ELGAMAL            February 1998
 182
 183
 184
 185
 186    Each unpacked-response-section is then packed according to [PKCS#1]
 187    by preceding the unpacked-response-section with octet 0, octet 2, a
 188    padding string, and an octet 0.  The padding string consists of at
 189    least eight non-zero random octets.  The total length of the packed
 190    form is the same as the length of the ElGamal encryption modulus.
 191
 192    To encrypt a packed-response-section
 193
 194    Given the client's public key (p, g, y) where p is the prime modulus
 195    and y = g^x mod p where x is the private key.
 196
 197    M is the packed-response-section considered to be an integer with
 198    the first octet being the most significant.
 199
 200    Pick a random number k
 201
 202    a = g^k mod p
 203
 204    b = y^k M mod p
 205
 206    The encrypted-response-section is ab.  These two numbers are
 207    expressed as string consisting of two multiprecision fields as
 208    defined in [PGPFormat].
 209
 210       Definition.  A multiprecision field is the concatenation of two
 211       fields:
 212
 213          (a) a whole number field of length 2, with value B;
 214          (b) a whole number field, with value V.
 215
 216       Field (b) is of length [(B+7)/8], i.e., the greatest integer
 217       which is no larger than (B+7)/8.  The value of the
 218       multiprecision field is defined to be V.  V must be between
 219       2^{B-1} and 2^B - 1 inclusive.  In other words B must be exactly
 220       the number of significant bits in V.
 221
 222    The encrypted-response is formed by concatenating all of the
 223    encrypted-response-sections.
 224
 225    The encrypted-response is then encoded according to the host
 226    protocol.
 227
 228 2.3 Authentication
 229
 230    The server then decodes, decrypts and unpacks the string and then
 231    verifies the persona, password and cookie.  If correct the client is
 232    deemed to be authenticated.
 233
 234
 235
 236
 237
 238 Overell                                                  [Page 4]
 239 \f
 240
 241
 242 Internet Draft           ROAMING-ELGAMAL            February 1998
 243
 244
 245
 246
 247    ElGamal decryption is given by
 248
 249    M = b/a^x mod p
 250
 251 3. References
 252
 253    [ABNF]   RFC2234, "Augmented BNF for syntax specifications: ABNF",
 254             D. Crocker and P. Overell, November 1997.
 255
 256    [ELG]    "A Public-Key Cryptosystem and a Signature Scheme Based
 257             on Discrete Logarithms".  T. ElGamal, IEEE Transactions
 258             on Information Theory, v. IT-31, n. 4, 1985, pp. 469-472.
 259
 260    [PGPForm] RFC1991, "PGP Message Exchange Formats".  D. Atkins et
 261             al.  August 1996.
 262
 263    [PKCS#1] RSA Data Security, Inc.  Public-Key Cryptography
 264             Standards (PKCS).  PKCS #1, "RSA Encryption Standard".
 265             An RSA Laboratories Technical Note, version 1.5, revised
 266             November 1, 1993.
 267
 268    [SASL]   RFC2222, "Simple Authentication and Security Layer
 269             (SASL)".  J. Myers, Netscape Communications, October
 270             1997.
 271
 272    [SRAP]   Work in progress, "Simple Roaming Authentication
 273             Protocol", P. Overell, Demon Internet Ltd.  February 1998
 274
 275 4. Security Considerations
 276
 277    The use of ElGamal public key encryption together with a
 278    cryptographically strong cookie should make this mechanism resistant
 279    to interception, man in the middle and replay attacks.
 280
 281 5. Author's Address
 282
 283    P. Overell
 284    Demon Internet Ltd
 285    Dorking Business Park
 286    Dorking
 287    Surrey
 288    RH4 1HN
 289    UK
 290
 291    mailto:paulo@turnpike.com
 292
 293
 294
 295
 296
 297
 298
 299 Overell                                                  [Page 5]
 300 \f