idnits 2.17.1 draft-overell-roaming-elgamal-sasl-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-20) 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 4 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 ([ELG], [SRAP], [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 70: '... then the client SHOULD fail the comma...' RFC 2119 keyword, line 71: '... implementation MAY choose the person...' RFC 2119 keyword, line 75: '... The fingerprint MAY be the MD5 or SHA...' 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 9561 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 216 looks like a reference -- Missing reference section? 'ELG' on line 204 looks like a reference -- Missing reference section? 'SRAP' on line 220 looks like a reference -- Missing reference section? 'ABNF' on line 201 looks like a reference -- Missing reference section? 'PGPFormat' on line 169 looks like a reference -- Missing reference section? 'PGPForm' on line 208 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Overell 3 Internet Draft: ROAMING-ELGAMAL Demon Internet Ltd 4 Document: draft-overell-roaming-elgamal-sasl-00.txt February 1998 5 Expires: August 1998 7 ROAMING-ELGAMAL SASL Authentication Mechanism 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 ROAMING-ELGAMAL is an SASL [SASL] authentication mechanism in which 31 ElGamal [ELG] public key cryptography is used to encrypt the persona 32 and password thus giving a high degree of security. 34 Although specifically designed for the Simple Roaming Authentication 35 Protocol [SRAP], ROAMING-ELGAMAL is intended to be a registered SASL 36 mechanism and so could be adapted to other protocols. The mechanism 37 has been designed to resist attack from interception, man in the 38 middle, and replay. The security of the mechanism rests with the 39 protection of the private key. 41 1. Conventions Used in this Document 43 In SASL terminology "server" means the authenticator and "client" 44 means the authenticatee. Data from the server to the client is a 45 "challenge", data from the client to the server is a "response". 47 All syntax is specified using ABNF [ABNF] and its core definitions. 49 2. ROAMING-ELGAMAL Mechanism 51 The SASL authentication type associated with ROAMING-ELGAMAL is 52 "ROAMING-ELGAMAL". 54 This memo is only concerned with authentication, however, a security 55 layer could be easily added either by continuing to use ElGamal 56 encryption for the remainder of the conversation; or by using a 57 symmetric cipher with a session key derived from the calculated 58 value of y^k, a value known to both parties only after 59 authentication is complete. 61 2.1 Initial Server Challenge 63 The data encoded in the initial challenge is a persona, a 64 fingerprint and a cookie. 66 The persona indicates which persona/password pair the server is 67 seeking authentication for. If no persona is specified (zero size) 68 then the client may choose either to return any of its 69 persona/passwords or fail the command. If the persona is specified 70 but not recognized then the client SHOULD fail the command. An 71 implementation MAY choose the persona to be the same as a "username" 72 or "user id" but this memo does not require this interpretation. 74 The fingerprint indicates which public key the client should use to 75 encrypt its response. The fingerprint MAY be the MD5 or SHA-1 of 76 the public key as per PGP, but this memo does not require this 77 interpretation. 79 The cookie is a presumptively arbitrary string of random octets. 80 The cookie should be unique and unpredictable, preferably a 81 cryptographically strong random number. Its purpose is to defeat 82 replay attack. 84 This memo does not define the length or content of the persona, 85 fingerprint or cookie. To permit any octet to be used each element 86 is preceded by its size in octets expressed as a number in text 87 enclosed in braces. The encoding used is defined by the host 88 protocol. 90 Syntax 92 unencoded-challenge = size persona size fingerprint size cookie 94 persona = *OCTET 96 fingerprint = *OCTET 97 cookie = *OCTET 99 size = "{" 1*DIGIT "}" 101 Example (fictitious) 103 {4}paul{32}AB246508F5217B54C77D3400239BCA45{16}9723763476348973 105 2.2 Client's Response 107 If the client wishes to proceed then it responds with an encoded 108 string of the ElGamal encrypted string of the PKCS#1 [PKCS#1] packed 109 string consisting of the client's persona, password and the server's 110 cookie. The server's public key is used for the encryption. This 111 memo does not describe how the client may obtain the server's public 112 key. The encoding used is defined by the host protocol 114 This memo places no restriction whatsoever on the content or length 115 of persona, password or cookie. In the unpacked-response each 116 element is preceded by its size in octets expressed as a number in 117 text enclosed in braces. 119 Syntax 121 persona = *OCTET 123 password = *OCTET 125 cookie = *OCTET 127 size = "{" 1*DIGIT "}" 129 unpacked-response = size persona size password size cookie 131 packed-response = %x00 %x02 8*padding %x00 unpacked-response 133 padding = %x01-FF 135 Example (fictitious) 137 {4}paul{8}sausages{20}b_basdlwyweyfbc73m8f 139 2.2.1 Packing and Encryption 141 Let L be the length in octets of the ElGamal encryption modulus. 143 If the length of the unpacked-response is greater than L - 11 octets 144 then the unpacked-response is split into sections, each of which 145 must be less than or equal to L - 11 octets long. 147 Each unpacked-response-section is then packed according to [PKCS#1] 148 by preceding the unpacked-response-section with octet 0, octet 2, a 149 padding string, and an octet 0. The padding string consists of at 150 least eight non-zero random octets. The total length of the packed 151 form is the same as the length of the ElGamal encryption modulus. 153 To encrypt a packed-response-section 155 Given the client's public key (p, g, y) where p is the prime modulus 156 and y = g^x mod p where x is the private key. 158 M is the packed-response-section considered to be an integer with 159 the first octet being the most significant. 161 Pick a random number k 163 a = g^k mod p 165 b = y^k M mod p 167 The encrypted-response-section is ab. These two numbers are 168 expressed as string consisting of two multiprecision fields as 169 defined in [PGPFormat]. 171 Definition. A multiprecision field is the concatenation of two 172 fields: 174 (a) a whole number field of length 2, with value B; 175 (b) a whole number field, with value V. 177 Field (b) is of length [(B+7)/8], i.e., the greatest integer 178 which is no larger than (B+7)/8. The value of the 179 multiprecision field is defined to be V. V must be between 180 2^{B-1} and 2^B - 1 inclusive. In other words B must be exactly 181 the number of significant bits in V. 183 The encrypted-response is formed by concatenating all of the 184 encrypted-response-sections. 186 The encrypted-response is then encoded according to the host 187 protocol. 189 2.3 Authentication 191 The server then decodes, decrypts and unpacks the string and then 192 verifies the persona, password and cookie. If correct the client is 193 deemed to be authenticated. 195 ElGamal decryption is given by 197 M = b/a^x mod p 199 3. References 201 [ABNF] RFC2234, "Augmented BNF for syntax specifications: ABNF", 202 D. Crocker and P. Overell, November 1997. 204 [ELG] "A Public-Key Cryptosystem and a Signature Scheme Based 205 on Discrete Logarithms". T. ElGamal, IEEE Transactions 206 on Information Theory, v. IT-31, n. 4, 1985, pp. 469-472. 208 [PGPForm] RFC1991, "PGP Message Exchange Formats". D. Atkins et 209 al. August 1996. 211 [PKCS#1] RSA Data Security, Inc. Public-Key Cryptography 212 Standards (PKCS). PKCS #1, "RSA Encryption Standard". 213 An RSA Laboratories Technical Note, version 1.5, revised 214 November 1, 1993. 216 [SASL] RFC2222, "Simple Authentication and Security Layer 217 (SASL)". J. Myers, Netscape Communications, October 218 1997. 220 [SRAP] Work in progress, "Simple Roaming Authentication 221 Protocol", P. Overell, Demon Internet Ltd. February 1998 223 4. Security Considerations 225 The use of ElGamal public key encryption together with a 226 cryptographically strong cookie should make this mechanism resistant 227 to interception, man in the middle and replay attacks. 229 5. Author's Address 231 P. Overell 232 Demon Internet Ltd 233 Dorking Business Park 234 Dorking 235 Surrey 236 RH4 1HN 237 UK 239 mailto:paulo@turnpike.com