One document matched: draft-ietf-radius-saltencrypt-00.txt
RADIUS Working Group P. Funk
INTERNET-DRAFT O. Tavakoli
<draft-ietf-radius-saltencrypt-00.txt> Funk Software, Inc.
D. Mitton
D. Fox
Bay Networks, Inc.
November 20, 1997
Salt-Encryption of RADIUS Attributes
1. 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).
This document expires May 25, 1998.
2. Abstract
This document defines a general mechanism for encrypting attributes
within RADIUS packets. This mechanism permits more than one attribute
within a RADIUS transaction (request and response) to be encrypted
without compromising the security of the encryption.
3. Introduction
For security reasons, it is necessary to encrypt certain attributes
that are passed between a NAS and a RADIUS server.
RADIUS [1] defines a password-hiding mechanism for use with the User-
Password attribute in an Access-Request; namely, that the Value of
the attribute is XORed with an octet sequence based on a one-way MD5
digest of the shared secret and the Request Authenticator.
This mechanism is not extensible to additional attributes in the
request packet or the RADIUS server’s response packet without
compromising the encryption. This is because the first 16 octets of
the XOR value will be identical for each encryption, allowing an
attacker who knows the clear text value of any of the encrypted
DRAFT Salt-Encryption of RADIUS Attributes 11/20/97
attributes to deduce the common XOR value and decipher the other
encrypted attributes.
The mechanism defined here -- called "salt-encryption" -- adds a
unique two-octet Salt value to each attribute to be encrypted. This
Salt would be concatenated with the shared secret and Request
Authenticator as input to the MD5 digest to produce an initial 16-
byte XOR value that is unique for each encrypted attribute in a
RADIUS transaction. The initial and subsequent XOR values are used to
encrypt the payload of the attribute. The length of the actual
information portion of the attribute MAY be obfuscated by encoding
the payload with the length of the actual data, followed by the data,
followed by optional padding.
4. Attribute Format
4.1 Standard Form
A summary of the standard form of the salt-encrypted attribute format
is shown below. The fields are transmitted from left to right.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Salt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Value ...
|+-+-+-+-+-+-+-+-+-+-
Type
The Type field is a single octet as defined in [1].
Length
The Length field is a single octet as defined in [1].
Salt
The Salt field is two octets, and is used to differentiate
encryption keys that are based on the same shared secret and
Request Authenticator.
The NAS and the RADIUS server are responsible for ensuring that
each salt within a single packet is unique. To ensure uniqueness
across a pair of packets constituting a transaction, each Salt in
an Access-Request packet sent by the NAS must have high-bit clear,
and each Salt in an Access-Accept, Access-Reject, or Access-
Challenge packet returned by the RADIUS server must have high-bit
set.
P. Funk et. al. 2
DRAFT Salt-Encryption of RADIUS Attributes 11/20/97
Encrypted Value
The Encrypted Value field is one or more octets, encrypted
according to the mechanism described below, containing data that
is length-prefixed and optionally padded.
The first octet indicates the number of significant data octets to
follow, excluding any padding.
The data that follows the first octet contains the information
specific to the Attribute.
Following the data, there may be additional octets of padding that
carry no information but serve to obfuscate the actual length of
the data. The technique used may be null-padding up to the next
multiple of 16 octets (as in the password-hiding mechanism defined
in [1]), padding by a random number of octets, or some other
method.
4.2 Standard Form for Vendor-Specific Attributes
A Vendor-Specific attribute consists of an attribute of type 26 that
contains a Vendor-Id and vendor-defined information. According to
[1], the vendor-defined information SHOULD consist of a sequence of
one or more sub-attributes, each of which consists of a Vendor type
and Vendor length.
A sub-attribute of a Vendor-Specific attribute may be salt-encrypted
using a format corresponding to an ordinary attribute. A summary of
the salt-encrypted Vendor-Specific Attribute format is shown below.
The fields are transmitted from left to right.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor type | Vendor length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt | Encrypted Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
All fields are as defined in [1] or as defined above.
4.3 Alternative Forms
New attributes may be defined that utilize salt-encryption without
strictly adhering to the standard formats described above. For
example, it might be desirable to encrypt only part of an attribute,
keeping the rest in clear text; or to include multiple salts within
an attribute to encrypt multiple sub-fields. It may also be desirable
P. Funk et. al. 3
DRAFT Salt-Encryption of RADIUS Attributes 11/20/97
to eliminate the length prefix and padding from the Encrypted Value,
particularly for fixed-length data where length obfuscation provides
no benefit.
The exact arrangement of the Salt field and the Encrypted Value field
within an attribute, and whether the Encrypted Value field utilizes
length-obfuscation, is a matter to be decided for each new attribute
as it is defined. It is expected that some, but not all, new
attributes will follow the standard formats as described above.
All salt-encrypted attributes MUST at least observe the following
requirements: Each Salt is 2 octets, unique within the packet, with
high-bit clear in requests and set in responses, and the
encryption/decryption follows the method outlined below.
5. Method of encryption/decryption
The salt-encryption method closely corresponds the password-hiding
method defined in [1]. The differences are:
(1) The Salt is concatenated to the shared secret and Request
Authenticator when computing the initial MD5 digest.
(2) An attribute may be padded to an arbitrary length or not at all.
However, in order to obfuscate the actual length of the data, a
padding strategy, such as null-padding to a multiple of 16 octets,
SHOULD be employed.
The salt-encryption method proceeds as follows:
Construct a clear text version of the information to be encrypted;
call this the Clear Text.
Call the shared secret S, the pseudo-random 128-bit Request
Authenticator RA, and the Salt SALT. Break the Clear Text into
chunks p1, p2, etc. of up to 16-octets each; the last chunk may
contain fewer than 16 octets. Call the ciphertext blocks c(1), c(2),
etc. We'll need intermediate values b1, b2, etc.
b1 = MD5(S + RA + SALT) c(1) = p1 xor b1
b2 = MD5(S + c(1)) c(2) = p2 xor b2
. .
. .
. .
bi = MD5(S + c(i-1)) c(i) = pi xor bi
Note that if the last chunk is fewer than 16 octets only the first
part of the final MD5 digest bi is used in the XOR operation.
The resulting Encrypted Value will contain c(1)+c(2)+...+c(i) where +
denotes concatenation.
P. Funk et. al. 4
DRAFT Salt-Encryption of RADIUS Attributes 11/20/97
On receipt, the process is reversed to yield the Clear Text.
6. Security Considerations
Security is the subject of this document.
7. Author’s Addresses
Authors may be contacted by email as follows:
Paul Funk paul@funk.com
Oliver Tavakoli oliver@funk.com
Dave Mitton dmitton@baynetworks.com
Daniel Fox dfox@baynetworks.com
8. Expiration Date
This document expires May 25, 1998.
9. References
[1] Rigney, C., et. al., "Remote Access Dial In User Service", RFC
2138, April 1997
P. Funk et. al. 5
+-------------------------------------------------------------+
| Paul Funk | Tel: +1 617 497 6339 |
| Funk Software, Inc. | Fax: +1 617 547 1031 |
| 222 Third Street | Internet: paul@funk.com |
| Cambridge, MA 02142 USA | |
+-------------------------------------------------------------+
| PAFTECH AB 2003-2026 | 2026-04-23 04:21:12 |