idnits 2.17.1 draft-ietf-radius-saltencrypt-00.txt: ** The Abstract section seems to be numbered 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-19) 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. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 65: '...of the attribute MAY be obfuscated by ...' RFC 2119 keyword, line 132: '... [1], the vendor-defined information SHOULD consist of a sequence of...' RFC 2119 keyword, line 174: '...ypted attributes MUST at least observe...' RFC 2119 keyword, line 190: '... SHOULD be employed....' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 230 has weird spacing: '...avakoli olive...' -- 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 (November 20, 1997) is 9647 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) ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RADIUS Working Group P. Funk 2 INTERNET-DRAFT O. Tavakoli 3 Funk Software, Inc. 4 D. Mitton 5 D. Fox 6 Bay Networks, Inc. 7 November 20, 1997 9 Salt-Encryption of RADIUS Attributes 11 1. Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 This document expires May 25, 1998. 31 2. Abstract 33 This document defines a general mechanism for encrypting attributes 34 within RADIUS packets. This mechanism permits more than one attribute 35 within a RADIUS transaction (request and response) to be encrypted 36 without compromising the security of the encryption. 38 3. Introduction 40 For security reasons, it is necessary to encrypt certain attributes 41 that are passed between a NAS and a RADIUS server. 43 RADIUS [1] defines a password-hiding mechanism for use with the User- 44 Password attribute in an Access-Request; namely, that the Value of 45 the attribute is XORed with an octet sequence based on a one-way MD5 46 digest of the shared secret and the Request Authenticator. 48 This mechanism is not extensible to additional attributes in the 49 request packet or the RADIUS server�s response packet without 50 compromising the encryption. This is because the first 16 octets of 51 the XOR value will be identical for each encryption, allowing an 52 attacker who knows the clear text value of any of the encrypted 53 DRAFT Salt-Encryption of RADIUS Attributes 11/20/97 55 attributes to deduce the common XOR value and decipher the other 56 encrypted attributes. 58 The mechanism defined here -- called "salt-encryption" -- adds a 59 unique two-octet Salt value to each attribute to be encrypted. This 60 Salt would be concatenated with the shared secret and Request 61 Authenticator as input to the MD5 digest to produce an initial 16- 62 byte XOR value that is unique for each encrypted attribute in a 63 RADIUS transaction. The initial and subsequent XOR values are used to 64 encrypt the payload of the attribute. The length of the actual 65 information portion of the attribute MAY be obfuscated by encoding 66 the payload with the length of the actual data, followed by the data, 67 followed by optional padding. 69 4. Attribute Format 71 4.1 Standard Form 73 A summary of the standard form of the salt-encrypted attribute format 74 is shown below. The fields are transmitted from left to right. 76 0 1 2 3 77 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 78 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 79 | Type | Length | Salt | 80 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 81 | Encrypted Value ... 82 |+-+-+-+-+-+-+-+-+-+- 84 Type 86 The Type field is a single octet as defined in [1]. 88 Length 90 The Length field is a single octet as defined in [1]. 92 Salt 94 The Salt field is two octets, and is used to differentiate 95 encryption keys that are based on the same shared secret and 96 Request Authenticator. 98 The NAS and the RADIUS server are responsible for ensuring that 99 each salt within a single packet is unique. To ensure uniqueness 100 across a pair of packets constituting a transaction, each Salt in 101 an Access-Request packet sent by the NAS must have high-bit clear, 102 and each Salt in an Access-Accept, Access-Reject, or Access- 103 Challenge packet returned by the RADIUS server must have high-bit 104 set. 106 P. Funk et. al. 2 107 DRAFT Salt-Encryption of RADIUS Attributes 11/20/97 109 Encrypted Value 111 The Encrypted Value field is one or more octets, encrypted 112 according to the mechanism described below, containing data that 113 is length-prefixed and optionally padded. 115 The first octet indicates the number of significant data octets to 116 follow, excluding any padding. 118 The data that follows the first octet contains the information 119 specific to the Attribute. 121 Following the data, there may be additional octets of padding that 122 carry no information but serve to obfuscate the actual length of 123 the data. The technique used may be null-padding up to the next 124 multiple of 16 octets (as in the password-hiding mechanism defined 125 in [1]), padding by a random number of octets, or some other 126 method. 128 4.2 Standard Form for Vendor-Specific Attributes 130 A Vendor-Specific attribute consists of an attribute of type 26 that 131 contains a Vendor-Id and vendor-defined information. According to 132 [1], the vendor-defined information SHOULD consist of a sequence of 133 one or more sub-attributes, each of which consists of a Vendor type 134 and Vendor length. 136 A sub-attribute of a Vendor-Specific attribute may be salt-encrypted 137 using a format corresponding to an ordinary attribute. A summary of 138 the salt-encrypted Vendor-Specific Attribute format is shown below. 139 The fields are transmitted from left to right. 141 0 1 2 3 142 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Type | Length | Vendor-Id 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Vendor-Id (cont) | Vendor type | Vendor length | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Salt | Encrypted Value ... 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 151 All fields are as defined in [1] or as defined above. 153 4.3 Alternative Forms 155 New attributes may be defined that utilize salt-encryption without 156 strictly adhering to the standard formats described above. For 157 example, it might be desirable to encrypt only part of an attribute, 158 keeping the rest in clear text; or to include multiple salts within 159 an attribute to encrypt multiple sub-fields. It may also be desirable 161 P. Funk et. al. 3 162 DRAFT Salt-Encryption of RADIUS Attributes 11/20/97 164 to eliminate the length prefix and padding from the Encrypted Value, 165 particularly for fixed-length data where length obfuscation provides 166 no benefit. 168 The exact arrangement of the Salt field and the Encrypted Value field 169 within an attribute, and whether the Encrypted Value field utilizes 170 length-obfuscation, is a matter to be decided for each new attribute 171 as it is defined. It is expected that some, but not all, new 172 attributes will follow the standard formats as described above. 174 All salt-encrypted attributes MUST at least observe the following 175 requirements: Each Salt is 2 octets, unique within the packet, with 176 high-bit clear in requests and set in responses, and the 177 encryption/decryption follows the method outlined below. 179 5. Method of encryption/decryption 181 The salt-encryption method closely corresponds the password-hiding 182 method defined in [1]. The differences are: 184 (1) The Salt is concatenated to the shared secret and Request 185 Authenticator when computing the initial MD5 digest. 187 (2) An attribute may be padded to an arbitrary length or not at all. 188 However, in order to obfuscate the actual length of the data, a 189 padding strategy, such as null-padding to a multiple of 16 octets, 190 SHOULD be employed. 192 The salt-encryption method proceeds as follows: 194 Construct a clear text version of the information to be encrypted; 195 call this the Clear Text. 197 Call the shared secret S, the pseudo-random 128-bit Request 198 Authenticator RA, and the Salt SALT. Break the Clear Text into 199 chunks p1, p2, etc. of up to 16-octets each; the last chunk may 200 contain fewer than 16 octets. Call the ciphertext blocks c(1), c(2), 201 etc. We'll need intermediate values b1, b2, etc. 203 b1 = MD5(S + RA + SALT) c(1) = p1 xor b1 204 b2 = MD5(S + c(1)) c(2) = p2 xor b2 205 . . 206 . . 207 . . 208 bi = MD5(S + c(i-1)) c(i) = pi xor bi 210 Note that if the last chunk is fewer than 16 octets only the first 211 part of the final MD5 digest bi is used in the XOR operation. 213 The resulting Encrypted Value will contain c(1)+c(2)+...+c(i) where + 214 denotes concatenation. 216 P. Funk et. al. 4 217 DRAFT Salt-Encryption of RADIUS Attributes 11/20/97 219 On receipt, the process is reversed to yield the Clear Text. 221 6. Security Considerations 223 Security is the subject of this document. 225 7. Author�s Addresses 227 Authors may be contacted by email as follows: 229 Paul Funk paul@funk.com 230 Oliver Tavakoli oliver@funk.com 231 Dave Mitton dmitton@baynetworks.com 232 Daniel Fox dfox@baynetworks.com 234 8. Expiration Date 236 This document expires May 25, 1998. 238 9. References 240 [1] Rigney, C., et. al., "Remote Access Dial In User Service", RFC 241 2138, April 1997 243 P. Funk et. al. 5 245 +-------------------------------------------------------------+ 246 | Paul Funk | Tel: +1 617 497 6339 | 247 | Funk Software, Inc. | Fax: +1 617 547 1031 | 248 | 222 Third Street | Internet: paul@funk.com | 249 | Cambridge, MA 02142 USA | | 250 +-------------------------------------------------------------+