~ubuntu-branches/ubuntu/maverick/krb5/maverick : revision 17

1

2

3

4

5

6

7

Network Working Group K. Raeburn

8

Request for Comments: 3961 MIT

9

Category: Standards Track February 2005

10

11

12

Encryption and Checksum Specifications

13

for Kerberos 5

14

15

Status of This Memo

16

17

This document specifies an Internet standards track protocol for the

18

Internet community, and requests discussion and suggestions for

19

improvements. Please refer to the current edition of the "Internet

20

Official Protocol Standards" (STD 1) for the standardization state

21

and status of this protocol. Distribution of this memo is unlimited.

22

23

Copyright Notice

24

25

Copyright (C) The Internet Society (2005).

26

27

Abstract

28

29

This document describes a framework for defining encryption and

30

checksum mechanisms for use with the Kerberos protocol, defining an

31

abstraction layer between the Kerberos protocol and related

32

protocols, and the actual mechanisms themselves. The document also

33

defines several mechanisms. Some are taken from RFC 1510, modified

34

in form to fit this new framework and occasionally modified in

35

content when the old specification was incorrect. New mechanisms are

36

presented here as well. This document does NOT indicate which

37

mechanisms may be considered "required to implement".

38

39

Table of Contents

40

41

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2

42

2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 2

43

3. Encryption Algorithm Profile . . . . . . . . . . . . . . . . 4

44

4. Checksum Algorithm Profile . . . . . . . . . . . . . . . . . 9

45

5. Simplified Profile for CBC Ciphers with Key Derivation . . . 10

46

5.1. A Key Derivation Function . . . . . . . . . . . . . . . 10

47

5.2. Simplified Profile Parameters . . . . . . . . . . . . . 12

48

5.3. Cryptosystem Profile Based on Simplified Profile . . . 13

49

5.4. Checksum Profiles Based on Simplified Profile . . . . . 16

50

6. Profiles for Kerberos Encryption and Checksum Algorithms . . 16

51

6.1. Unkeyed Checksums . . . . . . . . . . . . . . . . . . . 17

52

6.2. DES-based Encryption and Checksum Types . . . . . . . . 18

53

6.3. Triple-DES Based Encryption and Checksum Types . . . . 28

54

7. Use of Kerberos Encryption Outside This Specification . . . . 30

55

56

57

58

Raeburn Standards Track [Page 1]

59

60

RFC 3961 Encryption and Checksum Specifications February 2005

61

62

63

8. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 31

64

9. Implementation Notes . . . . . . . . . . . . . . . . . . . . 32

65

10. Security Considerations . . . . . . . . . . . . . . . . . . . 33

66

11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35

67

12. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 36

68

A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 38

69

A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . 38

70

A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . 39

71

A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . 43

72

A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . 44

73

A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . 44

74

B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . 45

75

Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

76

Normative References. . . . . . . . . . . . . . . . . . . . . . . 47

77

Informative References. . . . . . . . . . . . . . . . . . . . . . 48

78

Editor's Address. . . . . . . . . . . . . . . . . . . . . . . . . 49

79

Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 50

80

81

1. Introduction

82

83

The Kerberos protocols [Kerb] are designed to encrypt messages of

84

arbitrary sizes, using block encryption ciphers or, less commonly,

85

stream encryption ciphers. Encryption is used to prove the

86

identities of the network entities participating in message

87

exchanges. However, nothing in the Kerberos protocol requires that

88

any specific encryption algorithm be used, as long as the algorithm

89

includes certain operations.

90

91

The following sections specify the encryption and checksum mechanisms

92

currently defined for Kerberos, as well as a framework for defining

93

future mechanisms. The encoding, chaining, padding, and other

94

requirements for each are described. Appendix A gives test vectors

95

for several functions.

96

97

2. Concepts

98

99

Both encryption and checksum mechanisms are profiled in later

100

sections. Each profile specifies a collection of operations and

101

attributes that must be defined for a mechanism. A Kerberos

102

encryption or checksum mechanism specification is not complete if it

103

does not define all of these operations and attributes.

104

105

An encryption mechanism must provide for confidentiality and

106

integrity of the original plaintext. (Incorporating a checksum may

107

permit integrity checking, if the encryption mode does not provide an

108

integrity check itself.) It must also provide non-malleability

109

110

111

112

113

114

Raeburn Standards Track [Page 2]

115

116

RFC 3961 Encryption and Checksum Specifications February 2005

117

118

119

[Bellare98] [Dolev91]. Use of a random confounder prepended to the

120

plaintext is recommended. It should not be possible to determine if

121

two ciphertexts correspond to the same plaintext without the key.

122

123

A checksum mechanism [1] must provide proof of the integrity of the

124

associated message and must preserve the confidentiality of the

125

message in case it is not sent in the clear. Finding two plaintexts

126

with the same checksum should be infeasible. It is NOT required that

127

an eavesdropper be unable to determine whether two checksums are for

128

the same message, as the messages themselves would presumably be

129

visible to any such eavesdropper.

130

131

Due to advances in cryptography, some cryptographers consider using

132

the same key for multiple purposes unwise. Since keys are used in

133

performing a number of different functions in Kerberos, it is

134

desirable to use different keys for each of these purposes, even

135

though we start with a single long-term or session key.

136

137

We do this by enumerating the different uses of keys within Kerberos

138

and by making the "usage number" an input to the encryption or

139

checksum mechanisms; such enumeration is outside the scope of this

140

document. Later sections define simplified profile templates for

141

encryption and checksum mechanisms that use a key derivation function

142

applied to a CBC mode (or similar) cipher and a checksum or hash

143

algorithm.

144

145

We distinguish the "base key" specified by other documents from the

146

"specific key" for a specific encryption or checksum operation. It

147

is expected but not required that the specific key be one or more

148

separate keys derived from the original protocol key and the key

149

usage number. The specific key should not be explicitly referenced

150

outside of this document. The typical language used in other

151

documents should be something like, "encrypt this octet string using

152

this key and this usage number"; generation of the specific key and

153

cipher state (described in the next section) are implicit. The

154

creation of a new cipher-state object, or the re-use of one from a

155

previous encryption operation, may also be explicit.

156

157

New protocols defined in terms of the Kerberos encryption and

158

checksum types should use their own key usage values. Key usages are

159

unsigned 32-bit integers; zero is not permitted.

160

161

All data is assumed to be in the form of strings of octets or eight-

162

bit bytes. Environments with other byte sizes will have to emulate

163

this behavior in order to get correct results.

164

165

166

167

168

169

170

Raeburn Standards Track [Page 3]

171

172

RFC 3961 Encryption and Checksum Specifications February 2005

173

174

175

Each algorithm is assigned an encryption type (or "etype") or

176

checksum type number, for algorithm identification within the

177

Kerberos protocol. The full list of current type number assignments

178

is given in section 8.

179

180

3. Encryption Algorithm Profile

181

182

An encryption mechanism profile must define the following attributes

183

and operations. The operations must be defined as functions in the

184

mathematical sense. No additional or implicit inputs (such as

185

Kerberos principal names or message sequence numbers) are permitted.

186

187

protocol key format

188

This describes which octet string values represent valid keys.

189

For encryption mechanisms that don't have perfectly dense key

190

spaces, this will describe the representation used for encoding

191

keys. It need not describe invalid specific values; all key

192

generation routines should avoid such values.

193

194

specific key structure

195

This is not a protocol format at all, but a description of the

196

keying material derived from the chosen key and used to encrypt or

197

decrypt data or compute or verify a checksum. It may, for

198

example, be a single key, a set of keys, or a combination of the

199

original key with additional data. The authors recommend using

200

one or more keys derived from the original key via one-way key

201

derivation functions.

202

203

required checksum mechanism

204

This indicates a checksum mechanism that must be available when

205

this encryption mechanism is used. Since Kerberos has no built in

206

mechanism for negotiating checksum mechanisms, once an encryption

207

mechanism is decided, the corresponding checksum mechanism can be

208

used.

209

210

key-generation seed length, K

211

This is the length of the random bitstring needed to generate a

212

key with the encryption scheme's random-to-key function (described

213

below). This must be a fixed value so that various techniques for

214

producing a random bitstring of a given length may be used with

215

key generation functions.

216

217

key generation functions

218

Keys must be generated in a number of cases, from different types

219

of inputs. All function specifications must indicate how to

220

generate keys in the proper wire format and must avoid generating

221

keys that significantly compromise the confidentiality of

222

encrypted data, if the cryptosystem has such. Entropy from each

223

224

225

226

Raeburn Standards Track [Page 4]

227

228

RFC 3961 Encryption and Checksum Specifications February 2005

229

230

231

source should be preserved as much as possible. Many of the

232

inputs, although unknown, may be at least partly predictable

233

(e.g., a password string is likely to be entirely in the ASCII

234

subset and of fairly short length in many environments; a semi-

235

random string may include time stamps). The benefit of such

236

predictability to an attacker must be minimized.

237

238

string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key)

239

This function generates a key from two UTF-8 strings and an opaque

240

octet string. One of the strings is usually the principal's pass

241

phrase, but generally it is merely a secret string. The other

242

string is a "salt" string intended to produce different keys from

243

the same password for different users or realms. Although the

244

strings provided will use UTF-8 encoding, no specific version of

245

Unicode should be assumed; all valid UTF-8 strings should be

246

allowed. Strings provided in other encodings MUST first be

247

converted to UTF-8 before applying this function.

248

249

The third argument, the octet string, may be used to pass

250

mechanism-specific parameters into this function. Since doing so

251

implies knowledge of the specific encryption system, generating

252

non-default parameter values should be an uncommon operation, and

253

normal Kerberos applications should be able to treat this

254

parameter block as an opaque object supplied by the Key

255

Distribution Center or defaulted to some mechanism-specific

256

constant value.

257

258

The string-to-key function should be a one-way function so that

259

compromising a user's key in one realm does not compromise it in

260

another, even if the same password (but a different salt) is used.

261

262

random-to-key (bitstring[K])->(protocol-key)

263

This function generates a key from a random bitstring of a

264

specific size. All the bits of the input string are assumed to be

265

equally random, even though the entropy present in the random

266

source may be limited.

267

268

key-derivation (protocol-key, integer)->(specific-key)

269

In this function, the integer input is the key usage value, as

270

described above. An attacker is assumed to know the usage values.

271

The specific-key output value was described in section 2.

272

273

string-to-key parameter format

274

This describes the format of the block of data that can be passed

275

to the string-to-key function above to configure additional

276

parameters for that function. Along with the mechanism of

277

encoding parameter values, bounds on the allowed parameters should

278

also be described to avoid allowing a spoofed KDC to compromise

279

280

281

282

Raeburn Standards Track [Page 5]

283

284

RFC 3961 Encryption and Checksum Specifications February 2005

285

286

287

the user's password. If practical it may be desirable to

288

construct the encoding so that values unacceptably weakening the

289

resulting key cannot be encoded.

290

291

Local security policy might permit tighter bounds to avoid excess

292

resource consumption. If so, the specification should recommended

293

defaults for these bounds. The description should also outline

294

possible weaknesses if bounds checks or other validations are not

295

applied to a parameter string received from the network.

296

297

As mentioned above, this should be considered opaque to most

298

normal applications.

299

300

default string-to-key parameters (octet string)

301

This default value for the "params" argument to the string-to-key

302

function should be used when the application protocol (Kerberos or

303

other) does not explicitly set the parameter value. As indicated

304

above, in most cases this parameter block should be treated as an

305

opaque object.

306

307

cipher state

308

This describes any information that can be carried over from one

309

encryption or decryption operation to the next, for use with a

310

given specific key. For example, a block cipher used in CBC mode

311

may put an initial vector of one block in the cipher state. Other

312

encryption modes may track nonces or other data.

313

314

This state must be non-empty and must influence encryption so that

315

messages are decrypted in the same order they were a encrypted, if

316

the cipher state is carried over from one encryption to the next.

317

Distinguishing out-of-order or missing messages from corrupted

318

messages is not required. If desired, this can be done at a

319

higher level by including sequence numbers and not "chaining" the

320

cipher state between encryption operations.

321

322

The cipher state may not be reused in multiple encryption or

323

decryption operations. These operations all generate a new cipher

324

state that may be used for following operations using the same key

325

and operation.

326

327

The contents of the cipher state must be treated as opaque outside

328

of encryption system specifications.

329

330

initial cipher state (specific-key, direction)->(state)

331

This describes the generation of the initial value for the cipher

332

state if it is not being carried over from a previous encryption

333

or decryption operation.

334

335

336

337

338

Raeburn Standards Track [Page 6]

339

340

RFC 3961 Encryption and Checksum Specifications February 2005

341

342

343

This describes any initial state setup needed before encrypting

344

arbitrary amounts of data with a given specific key. The specific

345

key and the direction of operations to be performed (encrypt

346

versus decrypt) must be the only input needed for this

347

initialization.

348

349

This state should be treated as opaque in any uses outside of an

350

encryption algorithm definition.

351

352

IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what

353

degree an application protocol could exercise control over the

354

initial vector used in DES CBC operations. Some existing

355

implementations permit setting the initial vector. This framework

356

does not provide for application control of the cipher state

357

(beyond "initialize" and "carry over from previous encryption"),

358

as the form and content of the initial cipher state can vary

359

between encryption systems and may not always be a single block of

360

random data.

361

362

New Kerberos application protocols should not assume control over

363

the initial vector, or that one even exists. However, a general-

364

purpose implementation may wish to provide the capability, in case

365

applications explicitly setting it are encountered.

366

367

encrypt (specific-key, state, octet string)->(state, octet string)

368

This function takes the specific key, cipher state, and a non-

369

empty plaintext string as input and generates ciphertext and a new

370

cipher state as outputs. If the basic encryption algorithm itself

371

does not provide for integrity protection (e.g., DES in CBC mode),

372

then some form of verifiable MAC or checksum must be included.

373

Some random factor such as a confounder should be included so that

374

an observer cannot know if two messages contain the same

375

plaintext, even if the cipher state and specific keys are the

376

same. The exact length of the plaintext need not be encoded, but

377

if it is not and if padding is required, the padding must be added

378

at the end of the string so that the decrypted version may be

379

parsed from the beginning.

380

381

The specification of the encryption function must indicate not

382

only the precise contents of the output octet string, but also the

383

output cipher state. The application protocol may carry the

384

output cipher state forward from one encryption with a given

385

specific key to another; the effect of this "chaining" must be

386

defined [2].

387

388

Assuming that values for the specific key and cipher state are

389

correctly-produced, no input octet string may result in an error

390

indication.

391

392

393

394

Raeburn Standards Track [Page 7]

395

396

RFC 3961 Encryption and Checksum Specifications February 2005

397

398

399

decrypt (specific-key, state, octet string)->(state, octet string)

400

This function takes the specific key, cipher state, and ciphertext

401

as inputs and verifies the integrity of the supplied ciphertext.

402

If the ciphertext's integrity is intact, this function produces

403

the plaintext and a new cipher state as outputs; otherwise, an

404

error indication must be returned, and the data discarded.

405

406

The result of the decryption may be longer than the original

407

plaintext, as, for example, when the encryption mode adds padding

408

to reach a multiple of a block size. If this is the case, any

409

extra octets must come after the decoded plaintext. An

410

application protocol that needs to know the exact length of the

411

message must encode a length or recognizable "end of message"

412

marker within the plaintext [3].

413

414

As with the encryption function, a correct specification for this

415

function must indicate not only the contents of the output octet

416

string, but also the resulting cipher state.

417

418

pseudo-random (protocol-key, octet-string)->(octet-string)

419

This pseudo-random function should generate an octet string of

420

some size that is independent of the octet string input. The PRF

421

output string should be suitable for use in key generation, even

422

if the octet string input is public. It should not reveal the

423

input key, even if the output is made public.

424

425

These operations and attributes are all that is required to support

426

Kerberos and various proposed preauthentication schemes.

427

428

For convenience of certain application protocols that may wish to use

429

the encryption profile, we add the constraint that, for any given

430

plaintext input size, a message size must exist between that given

431

size and that size plus 65,535 such that the length of the decrypted

432

version of the ciphertext will never have extra octets at the end.

433

434

Expressed mathematically, for every message length L1, there exists a

435

message size L2 such that

436

437

L2 >= L1

438

L2 < L1 + 65,536

439

for every message M with |M| = L2, decrypt(encrypt(M)) = M

440

441

A document defining a new encryption type should also describe known

442

weaknesses or attacks, so that its security may be fairly assessed,

443

and should include test vectors or other validation procedures for

444

the operations defined. Specific references to information that is

445

readily available elsewhere are sufficient.

446

447

448

449

450

Raeburn Standards Track [Page 8]

451

452

RFC 3961 Encryption and Checksum Specifications February 2005

453

454

455

4. Checksum Algorithm Profile

456

457

A checksum mechanism profile must define the following attributes and

458

operations:

459

460

associated encryption algorithm(s)

461

This indicates the types of encryption keys this checksum

462

mechanism can be used with.

463

464

A keyed checksum mechanism may have more than one associated

465

encryption algorithm if they share the same wire-key format,

466

string-to-key function, default string-to-key-parameters, and key

467

derivation function. (This combination means that, for example, a

468

checksum type, key usage value, and password are adequate to get

469

the specific key used to compute a checksum.)

470

471

An unkeyed checksum mechanism can be used with any encryption

472

type, as the key is ignored, but its use must be limited to cases

473

where the checksum itself is protected, to avoid trivial attacks.

474

475

get_mic function

476

This function generates a MIC token for a given specific key (see

477

section 3) and message (represented as an octet string) that may

478

be used to verify the integrity of the associated message. This

479

function is not required to return the same deterministic result

480

for each use; it need only generate a token that the verify_mic

481

routine can check.

482

483

The output of this function will also dictate the size of the

484

checksum. It must be no larger than 65,535 octets.

485

486

verify_mic function

487

Given a specific key, message, and MIC token, this function

488

ascertains whether the message integrity has been compromised.

489

For a deterministic get_mic routine, the corresponding verify_mic

490

may simply generate another checksum and compare the two.

491

492

The get_mic and verify_mic operations must allow inputs of arbitrary

493

length; if any padding is needed, the padding scheme must be

494

specified as part of these functions.

495

496

These operations and attributes are all that should be required to

497

support Kerberos and various proposed preauthentication schemes.

498

499

As with encryption mechanism definition documents, documents defining

500

new checksum mechanisms should indicate validation processes and

501

known weaknesses.

502

503

504

505

506

Raeburn Standards Track [Page 9]

507

508

RFC 3961 Encryption and Checksum Specifications February 2005

509

510

511

5. Simplified Profile for CBC Ciphers with Key Derivation

512

513

The profile outlined in sections 3 and 4 describes a large number of

514

operations that must be defined for encryption and checksum

515

algorithms to be used with Kerberos. Here we describe a simpler

516

profile that can generate both encryption and checksum mechanism

517

definitions, filling in uses of key derivation in appropriate places,

518

providing integrity protection, and defining multiple operations for

519

the cryptosystem profile based on a smaller set of operations. Not

520

all of the existing cryptosystems for Kerberos fit into this

521

simplified profile, but we recommend that future cryptosystems use it

522

or something based on it [4].

523

524

Not all the operations in the complete profiles are defined through

525

this mechanism; several must still be defined for each new algorithm

526

pair.

527

528

5.1. A Key Derivation Function

529

530

Rather than define some scheme by which a "protocol key" is composed

531

of a large number of encryption keys, we use keys derived from a base

532

key to perform cryptographic operations. The base key must be used

533

only for generating the derived keys, and this derivation must be

534

non-invertible and entropy preserving. Given these restrictions,

535

compromise of one derived key does not compromise others. Attack of

536

the base key is limited, as it is only used for derivation and is not

537

exposed to any user data.

538

539

To generate a derived key from a base key, we generate a pseudorandom

540

octet string by using an algorithm DR, described below, and generate

541

a key from that octet string by using a function dependent on the

542

encryption algorithm. The input length needed for that function,

543

which is also dependent on the encryption algorithm, dictates the

544

length of the string to be generated by the DR algorithm (the value

545

"k" below). These procedures are based on the key derivation in

546

[Blumenthal96].

547

548

Derived Key = DK(Base Key, Well-Known Constant)

549

550

DK(Key, Constant) = random-to-key(DR(Key, Constant))

551

552

DR(Key, Constant) = k-truncate(E(Key, Constant,

553

initial-cipher-state))

554

555

Here DR is the random-octet generation function described below, and

556

DK is the key-derivation function produced from it. In this

557

construction, E(Key, Plaintext, CipherState) is a cipher, Constant is

558

a well-known constant determined by the specific usage of this

559

560

561

562

Raeburn Standards Track [Page 10]

563

564

RFC 3961 Encryption and Checksum Specifications February 2005

565

566

567

function, and k-truncate truncates its argument by taking the first k

568

bits. Here, k is the key generation seed length needed for the

569

encryption system.

570

571

The output of the DR function is a string of bits; the actual key is

572

produced by applying the cryptosystem's random-to-key operation on

573

this bitstring.

574

575

If the Constant is smaller than the cipher block size of E, then it

576

must be expanded with n-fold() so it can be encrypted. If the output

577

of E is shorter than k bits, it is fed back into the encryption as

578

many times as necessary. The construct is as follows (where |

579

indicates concatentation):

580

581

K1 = E(Key, n-fold(Constant), initial-cipher-state)

582

K2 = E(Key, K1, initial-cipher-state)

583

K3 = E(Key, K2, initial-cipher-state)

584

K4 = ...

585

586

DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...)

587

588

n-fold is an algorithm that takes m input bits and "stretches" them

589

to form n output bits with equal contribution from each input bit to

590

the output, as described in [Blumenthal96]:

591

592

We first define a primitive called n-folding, which takes a

593

variable-length input block and produces a fixed-length output

594

sequence. The intent is to give each input bit approximately

595

equal weight in determining the value of each output bit. Note

596

that whenever we need to treat a string of octets as a number, the

597

assumed representation is Big-Endian -- Most Significant Byte

598

first.

599

600

To n-fold a number X, replicate the input value to a length that

601

is the least common multiple of n and the length of X. Before

602

each repetition, the input is rotated to the right by 13 bit

603

positions. The successive n-bit chunks are added together using

604

1's-complement addition (that is, with end-around carry) to yield

605

a n-bit result....

606

607

Test vectors for n-fold are supplied in appendix A [5].

608

609

In this section, n-fold is always used to produce c bits of output,

610

where c is the cipher block size of E.

611

612

The size of the Constant must not be larger than c, because reducing

613

the length of the Constant by n-folding can cause collisions.

614

615

616

617

618

Raeburn Standards Track [Page 11]

619

620

RFC 3961 Encryption and Checksum Specifications February 2005

621

622

623

If the size of the Constant is smaller than c, then the Constant must

624

be n-folded to length c. This string is used as input to E. If the

625

block size of E is less than the random-to-key input size, then the

626

output from E is taken as input to a second invocation of E. This

627

process is repeated until the number of bits accumulated is greater

628

than or equal to the random-to-key input size. When enough bits have

629

been computed, the first k are taken as the random data used to

630

create the key with the algorithm-dependent random-to-key function.

631

632

As the derived key is the result of one or more encryptions in the

633

base key, deriving the base key from the derived key is equivalent to

634

determining the key from a very small number of plaintext/ciphertext

635

pairs. Thus, this construction is as strong as the cryptosystem

636

itself.

637

638

5.2. Simplified Profile Parameters

639

640

These are the operations and attributes that must be defined:

641

642

protocol key format

643

string-to-key function

644

default string-to-key parameters

645

key-generation seed length, k

646

random-to-key function

647

As above for the normal encryption mechanism profile.

648

649

unkeyed hash algorithm, H

650

This should be a collision-resistant hash algorithm with fixed-

651

size output, suitable for use in an HMAC [HMAC]. It must support

652

inputs of arbitrary length. Its output must be at least the

653

message block size (below).

654

655

HMAC output size, h

656

This indicates the size of the leading substring output by the

657

HMAC function that should be used in transmitted messages. It

658

should be at least half the output size of the hash function H,

659

and at least 80 bits; it need not match the output size.

660

661

message block size, m

662

This is the size of the smallest units the cipher can handle in

663

the mode in which it is being used. Messages will be padded to a

664

multiple of this size. If a block cipher is used in a mode that

665

666

667

668

669

670

671

672

673

674

Raeburn Standards Track [Page 12]

675

676

RFC 3961 Encryption and Checksum Specifications February 2005

677

678

679

can handle messages that are not multiples of the cipher block

680

size, such as CBC mode with cipher text stealing (CTS, see [RC5]),

681

this value would be one octet. For traditional CBC mode with

682

padding, it would be the underlying cipher's block size.

683

684

This value must be a multiple of eight bits (one octet).

685

686

encryption/decryption functions, E and D

687

These are basic encryption and decryption functions for messages

688

of sizes that are multiples of the message block size. No

689

integrity checking or confounder should be included here. For

690

inputs these functions take the IV or similar data, a protocol-

691

format key, and an octet string, returning a new IV and octet

692

string.

693

694

The encryption function is not required to use CBC mode but is

695

assumed to be using something with similar properties. In

696

particular, prepending a cipher block-size confounder to the

697

plaintext should alter the entire ciphertext (comparable to

698

choosing and including a random initial vector for CBC mode).

699

700

The result of encrypting one cipher block (of size c, above) must

701

be deterministic for the random octet generation function DR in

702

the previous section to work. For best security, it should also

703

be no larger than c.

704

705

cipher block size, c

706

This is the block size of the block cipher underlying the

707

encryption and decryption functions indicated above, used for key

708

derivation and for the size of the message confounder and initial

709

vector. (If a block cipher is not in use, some comparable

710

parameter should be determined.) It must be at least 5 octets.

711

712

This is not actually an independent parameter; rather, it is a

713

property of the functions E and D. It is listed here to clarify

714

the distinction between it and the message block size, m.

715

716

Although there are still a number of properties to specify, they are

717

fewer and simpler than in the full profile.

718

719

5.3. Cryptosystem Profile Based on Simplified Profile

720

721

The above key derivation function is used to produce three

722

intermediate keys. One is used for computing checksums of

723

unencrypted data. The other two are used for encrypting and

724

checksumming plaintext to be sent encrypted.

725

726

727

728

729

730

Raeburn Standards Track [Page 13]

731

732

RFC 3961 Encryption and Checksum Specifications February 2005

733

734

735

The ciphertext output is the concatenation of the output of the basic

736

encryption function E and a (possibly truncated) HMAC using the

737

specified hash function H, both applied to the plaintext with a

738

random confounder prefix and sufficient padding to bring it to a

739

multiple of the message block size. When the HMAC is computed, the

740

key is used in the protocol key form.

741

742

Decryption is performed by removing the (partial) HMAC, decrypting

743

the remainder, and verifying the HMAC. The cipher state is an

744

initial vector, initialized to zero.

745

746

The substring notation "[1..h]" in the following table should be read

747

as using 1-based indexing; leading substrings are used.

748

749

750

751

752

753

754

755

756

757

758

759

760

761

762

763

764

765

766

767

768

769

770

771

772

773

774

775

776

777

778

779

780

781

782

783

784

785

786

Raeburn Standards Track [Page 14]

787

788

RFC 3961 Encryption and Checksum Specifications February 2005

789

790

791

Cryptosystem from Simplified Profile

792

------------------------------------------------------------------------

793

protocol key format As given.

794

795

specific key structure Three protocol-format keys: { Kc, Ke, Ki }.

796

797

key-generation seed As given.

798

length

799

800

required checksum As defined below in section 5.4.

801

mechanism

802

803

cipher state Initial vector (usually of length c)

804

805

initial cipher state All bits zero

806

807

encryption function conf = Random string of length c

808

pad = Shortest string to bring confounder

809

and plaintext to a length that's a

810

multiple of m.

811

(C1, newIV) = E(Ke, conf | plaintext | pad,

812

oldstate.ivec)

813

H1 = HMAC(Ki, conf | plaintext | pad)

814

ciphertext = C1 | H1[1..h]

815

newstate.ivec = newIV

816

817

decryption function (C1,H1) = ciphertext

818

(P1, newIV) = D(Ke, C1, oldstate.ivec)

819

if (H1 != HMAC(Ki, P1)[1..h])

820

report error

821

newstate.ivec = newIV

822

823

default string-to-key As given.

824

params

825

826

pseudo-random function tmp1 = H(octet-string)

827

tmp2 = truncate tmp1 to multiple of m

828

PRF = E(DK(protocol-key, prfconstant),

829

tmp2, initial-cipher-state)

830

831

The "prfconstant" used in the PRF operation is the three-octet string

832

"prf".

833

834

835

836

837

838

839

840

841

842

Raeburn Standards Track [Page 15]

843

844

RFC 3961 Encryption and Checksum Specifications February 2005

845

846

847

Cryptosystem from Simplified Profile

848

------------------------------------------------------------------------

849

key generation functions:

850

851

string-to-key function As given.

852

853

random-to-key function As given.

854

855

key-derivation function The "well-known constant" used for the DK

856

function is the key usage number, expressed as

857

four octets in big-endian order, followed by

858

one octet indicated below.

859

860

Kc = DK(base-key, usage | 0x99);

861

Ke = DK(base-key, usage | 0xAA);

862

Ki = DK(base-key, usage | 0x55);

863

864

5.4. Checksum Profiles Based on Simplified Profile

865

866

When an encryption system is defined with the simplified profile

867

given in section 5.2, a checksum algorithm may be defined for it as

868

follows:

869

870

Checksum Mechanism from Simplified Profile

871

--------------------------------------------------

872

associated cryptosystem As defined above.

873

874

get_mic HMAC(Kc, message)[1..h]

875

876

verify_mic get_mic and compare

877

878

The HMAC function and key Kc are as described in section 5.3.

879

880

6. Profiles for Kerberos Encryption and Checksum Algorithms

881

882

These profiles describe the encryption and checksum systems defined

883

for Kerberos. The astute reader will notice that some of them do not

884

fulfill all the requirements outlined in previous sections. These

885

systems are defined for backward compatibility; newer implementations

886

should (whenever possible) attempt to utilize encryption systems that

887

satisfy all the profile requirements.

888

889

The full list of current encryption and checksum type number

890

assignments, including values currently reserved but not defined in

891

this document, is given in section 8.

892

893

894

895

896

897

898

Raeburn Standards Track [Page 16]

899

900

RFC 3961 Encryption and Checksum Specifications February 2005

901

902

903

6.1. Unkeyed Checksums

904

905

These checksum types use no encryption keys and thus can be used in

906

combination with any encryption type, but they may only be used with

907

caution, in limited circumstances where the lack of a key does not

908

provide a window for an attack, preferably as part of an encrypted

909

message [6]. Keyed checksum algorithms are recommended.

910

911

6.1.1. The RSA MD5 Checksum

912

913

The RSA-MD5 checksum calculates a checksum by using the RSA MD5

914

algorithm [MD5-92]. The algorithm takes as input an input message of

915

arbitrary length and produces as output a 128-bit (sixteen octet)

916

checksum.

917

918

rsa-md5

919

----------------------------------------------

920

associated cryptosystem any

921

922

get_mic rsa-md5(msg)

923

924

verify_mic get_mic and compare

925

926

The rsa-md5 checksum algorithm is assigned a checksum type number of

927

seven (7).

928

929

6.1.2. The RSA MD4 Checksum

930

931

The RSA-MD4 checksum calculates a checksum using the RSA MD4

932

algorithm [MD4-92]. The algorithm takes as input an input message of

933

arbitrary length and produces as output a 128-bit (sixteen octet)

934

checksum.

935

936

rsa-md4

937

----------------------------------------------

938

associated cryptosystem any

939

940

get_mic md4(msg)

941

942

verify_mic get_mic and compare

943

944

The rsa-md4 checksum algorithm is assigned a checksum type number of

945

two (2).

946

947

948

949

950

951

952

953

954

Raeburn Standards Track [Page 17]

955

956

RFC 3961 Encryption and Checksum Specifications February 2005

957

958

959

6.1.3. CRC-32 Checksum

960

961

This CRC-32 checksum calculates a checksum based on a cyclic

962

redundancy check as described in ISO 3309 [CRC] but modified as

963

described below. The resulting checksum is four (4) octets in

964

length. The CRC-32 is neither keyed nor collision-proof; thus, the

965

use of this checksum is not recommended. An attacker using a

966

probabilistic chosen-plaintext attack as described in [SG92] might be

967

able to generate an alternative message that satisfies the checksum.

968

969

The CRC-32 checksum used in the des-cbc-crc encryption mode is

970

identical to the 32-bit FCS described in ISO 3309 with two

971

exceptions: The sum with the all-ones polynomial times x**k is

972

omitted, and the final remainder is not ones-complemented. ISO 3309

973

describes the FCS in terms of bits, whereas this document describes

974

the Kerberos protocol in terms of octets. To clarify the ISO 3309

975

definition for the purpose of computing the CRC-32 in the des-cbc-crc

976

encryption mode, the ordering of bits in each octet shall be assumed

977

to be LSB first. Given this assumed ordering of bits within an

978

octet, the mapping of bits to polynomial coefficients shall be

979

identical to that specified in ISO 3309.

980

981

Test values for this modified CRC function are included in appendix

982

A.5.

983

984

crc32

985

----------------------------------------------

986

associated cryptosystem any

987

988

get_mic crc32(msg)

989

990

verify_mic get_mic and compare

991

992

The crc32 checksum algorithm is assigned a checksum type number of

993

one (1).

994

995

6.2. DES-Based Encryption and Checksum Types

996

997

These encryption systems encrypt information under the Data

998

Encryption Standard [DES77] by using the cipher block chaining mode

999

[DESM80]. A checksum is computed as described below and placed in

1000

the cksum field. DES blocks are eight bytes. As a result, the data

1001

to be encrypted (the concatenation of confounder, checksum, and

1002

message) must be padded to an eight byte boundary before encryption.

1003

The values of the padding bytes are unspecified.

1004

1005

1006

1007

1008

1009

1010

Raeburn Standards Track [Page 18]

1011

1012

RFC 3961 Encryption and Checksum Specifications February 2005

1013

1014

1015

Plaintext and DES ciphertext are encoded as blocks of eight octets,

1016

which are concatenated to make the 64-bit inputs for the DES

1017

algorithms. The first octet supplies the eight most significant bits

1018

(with the octet's MSB used as the DES input block's MSB, etc.), the

1019

second octet the next eight bits, and so on. The eighth octet

1020

supplies the 8 least significant bits.

1021

1022

Encryption under DES using cipher block chaining requires an

1023

additional input in the form of an initialization vector; this vector

1024

is specified below for each encryption system.

1025

1026

The DES specifications [DESI81] identify four 'weak' and twelve

1027

'semi-weak' keys; these keys SHALL NOT be used for encrypting

1028

messages for use in Kerberos. The "variant keys" generated for the

1029

RSA-MD5-DES, RSA-MD4-DES, and DES-MAC checksum types by an

1030

eXclusive-OR of a DES key with a constant are not checked for this

1031

property.

1032

1033

A DES key is eight octets of data. This consists of 56 bits of

1034

actual key data, and eight parity bits, one per octet. The key is

1035

encoded as a series of eight octets written in MSB-first order. The

1036

bits within the key are also encoded in MSB order. For example, if

1037

the encryption key is

1038

(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8), where

1039

B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the

1040

parity bits, the first octet of the key would be B1,B2,...,B7,P1

1041

(with B1 as the most significant bit). See the [DESM80] introduction

1042

for reference.

1043

1044

Encryption Data Format

1045

1046

The format for the data to be encrypted includes a one-block

1047

confounder, a checksum, the encoded plaintext, and any necessary

1048

padding, as described in the following diagram. The msg-seq field

1049

contains the part of the protocol message to be encrypted.

1050

1051

+-----------+----------+---------+-----+

1052

1053

+-----------+----------+---------+-----+

1054

1055

One generates a random confounder of one block, placing it in

1056

'confounder'; zeros out the 'checksum' field (of length appropriate

1057

to exactly hold the checksum to be computed); adds the necessary

1058

padding; calculates the appropriate checksum over the whole sequence,

1059

placing the result in 'checksum'; and then encrypts using the

1060

specified encryption type and the appropriate key.

1061

1062

1063

1064

1065

1066

Raeburn Standards Track [Page 19]

1067

1068

RFC 3961 Encryption and Checksum Specifications February 2005

1069

1070

1071

String or Random-Data to Key Transformation

1072

1073

To generate a DES key from two UTF-8 text strings (password and

1074

salt), the two strings are concatenated, password first, and the

1075

result is then padded with zero-valued octets to a multiple of eight

1076

octets.

1077

1078

The top bit of each octet (always zero if the password is plain

1079

ASCII, as was assumed when the original specification was written) is

1080

discarded, and the remaining seven bits of each octet form a

1081

bitstring. This is then fan-folded and eXclusive-ORed with itself to

1082

produce a 56-bit string. An eight-octet key is formed from this

1083

string, each octet using seven bits from the bitstring, leaving the

1084

least significant bit unassigned. The key is then "corrected" by

1085

correcting the parity on the key, and if the key matches a 'weak' or

1086

'semi-weak' key as described in the DES specification, it is

1087

eXclusive-ORed with the constant 0x00000000000000F0. This key is

1088

then used to generate a DES CBC checksum on the initial string with

1089

the salt appended. The result of the CBC checksum is then

1090

"corrected" as described above to form the result, which is returned

1091

as the key.

1092

1093

For purposes of the string-to-key function, the DES CBC checksum is

1094

calculated by CBC encrypting a string using the key as IV and the

1095

final eight byte block as the checksum.

1096

1097

Pseudocode follows:

1098

1099

removeMSBits(8byteblock) {

1100

/* Treats a 64 bit block as 8 octets and removes the MSB in

1101

each octet (in big endian mode) and concatenates the

1102

result. E.g., the input octet string:

1103

01110000 01100001 11110011 01110011 11110111 01101111

1104

11110010 01100100

1105

results in the output bitstring:

1106

1110000 1100001 1110011 1110011 1110111 1101111

1107

1110010 1100100 */

1108

}

1109

1110

reverse(56bitblock) {

1111

/* Treats a 56-bit block as a binary string and reverses it.

1112

E.g., the input string:

1113

1000001 1010100 1001000 1000101 1001110 1000001

1114

0101110 1001101

1115

results in the output string:

1116

1011001 0111010 1000001 0111001 1010001 0001001

1117

0010101 1000001 */

1118

}

1119

1120

1121

1122

Raeburn Standards Track [Page 20]

1123

1124

RFC 3961 Encryption and Checksum Specifications February 2005

1125

1126

1127

add_parity_bits(56bitblock) {

1128

/* Copies a 56-bit block into a 64-bit block, left shifts

1129

content in each octet, and add DES parity bit.

1130

E.g., the input string:

1131

1100000 0001111 0011100 0110100 1000101 1100100

1132

0110110 0010111

1133

results in the output string:

1134

11000001 00011111 00111000 01101000 10001010 11001000

1135

01101101 00101111 */

1136

}

1137

1138

key_correction(key) {

1139

fixparity(key);

1140

if (is_weak_key(key))

1141

key = key XOR 0xF0;

1142

return(key);

1143

}

1144

1145

mit_des_string_to_key(string,salt) {

1146

odd = 1;

1147

s = string | salt;

1148

tempstring = 0; /* 56-bit string */

1149

pad(s); /* with nulls to 8 byte boundary */

1150

for (8byteblock in s) {

1151

56bitstring = removeMSBits(8byteblock);

1152

if (odd == 0) reverse(56bitstring);

1153

odd = ! odd;

1154

tempstring = tempstring XOR 56bitstring;

1155

}

1156

tempkey = key_correction(add_parity_bits(tempstring));

1157

key = key_correction(DES-CBC-check(s,tempkey));

1158

return(key);

1159

}

1160

1161

des_string_to_key(string,salt,params) {

1162

if (length(params) == 0)

1163

type = 0;

1164

else if (length(params) == 1)

1165

type = params[0];

1166

else

1167

error("invalid params");

1168

if (type == 0)

1169

mit_des_string_to_key(string,salt);

1170

else

1171

error("invalid params");

1172

}

1173

1174

1175

1176

1177

1178

Raeburn Standards Track [Page 21]

1179

1180

RFC 3961 Encryption and Checksum Specifications February 2005

1181

1182

1183

One common extension is to support the "AFS string-to-key" algorithm,

1184

which is not defined here, if the type value above is one (1).

1185

1186

For generation of a key from a random bitstring, we start with a 56-

1187

bit string and, as with the string-to-key operation above, insert

1188

parity bits. If the result is a weak or semi-weak key, we modify it

1189

by eXclusive-OR with the constant 0x00000000000000F0:

1190

1191

des_random_to_key(bitstring) {

1192

return key_correction(add_parity_bits(bitstring));

1193

}

1194

1195

6.2.1. DES with MD5

1196

1197

The des-cbc-md5 encryption mode encrypts information under DES in CBC

1198

mode with an all-zero initial vector and with an MD5 checksum

1199

(described in [MD5-92]) computed and placed in the checksum field.

1200

1201

The encryption system parameters for des-cbc-md5 are as follows:

1202

1203

des-cbc-md5

1204

--------------------------------------------------------------------

1205

protocol key format 8 bytes, parity in low bit of each

1206

1207

specific key structure copy of original key

1208

1209

required checksum rsa-md5-des

1210

mechanism

1211

1212

key-generation seed 8 bytes

1213

length

1214

1215

cipher state 8 bytes (CBC initial vector)

1216

1217

initial cipher state all-zero

1218

1219

encryption function des-cbc(confounder | checksum | msg | pad,

1220

ivec=oldstate)

1221

where

1222

checksum = md5(confounder | 0000...

1223

| msg | pad)

1224

1225

newstate = last block of des-cbc output

1226

1227

decryption function decrypt encrypted text and verify checksum

1228

1229

newstate = last block of ciphertext

1230

1231

1232

1233

1234

Raeburn Standards Track [Page 22]

1235

1236

RFC 3961 Encryption and Checksum Specifications February 2005

1237

1238

1239

des-cbc-md5

1240

--------------------------------------------------------------------

1241

default string-to-key empty string

1242

params

1243

1244

pseudo-random function des-cbc(md5(input-string), ivec=0)

1245

1246

key generation functions:

1247

1248

string-to-key des_string_to_key

1249

1250

random-to-key des_random_to_key

1251

1252

key-derivation identity

1253

1254

The des-cbc-md5 encryption type is assigned the etype value three

1255

(3).

1256

1257

6.2.2. DES with MD4

1258

1259

The des-cbc-md4 encryption mode also encrypts information under DES

1260

in CBC mode, with an all-zero initial vector. An MD4 checksum

1261

(described in [MD4-92]) is computed and placed in the checksum field.

1262

1263

des-cbc-md4

1264

--------------------------------------------------------------------

1265

protocol key format 8 bytes, parity in low bit of each

1266

1267

specific key structure copy of original key

1268

1269

required checksum rsa-md4-des

1270

mechanism

1271

1272

key-generation seed 8 bytes

1273

length

1274

1275

cipher state 8 bytes (CBC initial vector)

1276

1277

initial cipher state all-zero

1278

1279

encryption function des-cbc(confounder | checksum | msg | pad,

1280

ivec=oldstate)

1281

where

1282

checksum = md4(confounder | 0000...

1283

| msg | pad)

1284

1285

newstate = last block of des-cbc output

1286

1287

1288

1289

1290

Raeburn Standards Track [Page 23]

1291

1292

RFC 3961 Encryption and Checksum Specifications February 2005

1293

1294

1295

des-cbc-md4

1296

--------------------------------------------------------------------

1297

1298

decryption function decrypt encrypted text and verify checksum

1299

1300

newstate = last block of ciphertext

1301

1302

default string-to-key empty string

1303

params

1304

1305

pseudo-random function des-cbc(md5(input-string), ivec=0)

1306

1307

key generation functions:

1308

1309

string-to-key des_string_to_key

1310

1311

random-to-key copy input, then fix parity bits

1312

1313

key-derivation identity

1314

1315

Note that des-cbc-md4 uses md5, not md4, in the PRF definition.

1316

1317

The des-cbc-md4 encryption algorithm is assigned the etype value two

1318

(2).

1319

1320

6.2.3. DES with CRC

1321

1322

The des-cbc-crc encryption type uses DES in CBC mode with the key

1323

used as the initialization vector, with a four-octet CRC-based

1324

checksum computed as described in section 6.1.3. Note that this is

1325

not a standard CRC-32 checksum, but a slightly modified one.

1326

1327

des-cbc-crc

1328

--------------------------------------------------------------------

1329

protocol key format 8 bytes, parity in low bit of each

1330

1331

specific key structure copy of original key

1332

1333

required checksum rsa-md5-des

1334

mechanism

1335

1336

key-generation seed 8 bytes

1337

length

1338

1339

cipher state 8 bytes (CBC initial vector)

1340

1341

1342

1343

1344

1345

1346

Raeburn Standards Track [Page 24]

1347

1348

RFC 3961 Encryption and Checksum Specifications February 2005

1349

1350

1351

des-cbc-crc

1352

--------------------------------------------------------------------

1353

initial cipher state copy of original key

1354

1355

encryption function des-cbc(confounder | checksum | msg | pad,

1356

ivec=oldstate)

1357

where

1358

checksum = crc(confounder | 00000000

1359

| msg | pad)

1360

1361

newstate = last block of des-cbc output

1362

1363

decryption function decrypt encrypted text and verify checksum

1364

1365

newstate = last block of ciphertext

1366

1367

default string-to-key empty string

1368

params

1369

1370

pseudo-random function des-cbc(md5(input-string), ivec=0)

1371

1372

key generation functions:

1373

1374

string-to-key des_string_to_key

1375

1376

random-to-key copy input, then fix parity bits

1377

1378

key-derivation identity

1379

1380

The des-cbc-crc encryption algorithm is assigned the etype value one

1381

(1).

1382

1383

6.2.4. RSA MD5 Cryptographic Checksum Using DES

1384

1385

The RSA-MD5-DES checksum calculates a keyed collision-proof checksum

1386

by prepending an eight octet confounder before the text, applying the

1387

RSA MD5 checksum algorithm, and encrypting the confounder and the

1388

checksum by using DES in cipher-block-chaining (CBC) mode with a

1389

variant of the key, where the variant is computed by eXclusive-ORing

1390

the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0. The

1391

initialization vector should be zero. The resulting checksum is 24

1392

octets long.

1393

1394

1395

1396

1397

1398

1399

1400

1401

1402

Raeburn Standards Track [Page 25]

1403

1404

RFC 3961 Encryption and Checksum Specifications February 2005

1405

1406

1407

rsa-md5-des

1408

----------------------------------------------------------------

1409

associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc

1410

1411

get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,

1412

conf | rsa-md5(conf | msg))

1413

1414

verify_mic decrypt and verify rsa-md5 checksum

1415

1416

The rsa-md5-des checksum algorithm is assigned a checksum type number

1417

of eight (8).

1418

1419

6.2.5. RSA MD4 Cryptographic Checksum Using DES

1420

1421

The RSA-MD4-DES checksum calculates a keyed collision-proof checksum

1422

by prepending an eight octet confounder before the text, applying the

1423

RSA MD4 checksum algorithm [MD4-92], and encrypting the confounder

1424

and the checksum using DES in cipher-block-chaining (CBC) mode with a

1425

variant of the key, where the variant is computed by eXclusive-ORing

1426

the key with the constant 0xF0F0F0F0F0F0F0F0 [7]. The initialization

1427

vector should be zero. The resulting checksum is 24 octets long.

1428

1429

rsa-md4-des

1430

----------------------------------------------------------------

1431

associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc

1432

1433

get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,

1434

conf | rsa-md4(conf | msg),

1435

ivec=0)

1436

1437

verify_mic decrypt and verify rsa-md4 checksum

1438

1439

The rsa-md4-des checksum algorithm is assigned a checksum type number

1440

of three (3).

1441

1442

6.2.6. RSA MD4 Cryptographic Checksum Using DES Alternative

1443

1444

The RSA-MD4-DES-K checksum calculates a keyed collision-proof

1445

checksum by applying the RSA MD4 checksum algorithm and encrypting

1446

the results by using DES in cipher block chaining (CBC) mode with a

1447

DES key as both key and initialization vector. The resulting

1448

checksum is 16 octets long. This checksum is tamper-proof and

1449

believed to be collision-proof. Note that this checksum type is the

1450

old method for encoding the RSA-MD4-DES checksum; it is no longer

1451

recommended.

1452

1453

1454

1455

1456

1457

1458

Raeburn Standards Track [Page 26]

1459

1460

RFC 3961 Encryption and Checksum Specifications February 2005

1461

1462

1463

rsa-md4-des-k

1464

----------------------------------------------------------------

1465

associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc

1466

1467

get_mic des-cbc(key, md4(msg), ivec=key)

1468

1469

verify_mic decrypt, compute checksum and compare

1470

1471

The rsa-md4-des-k checksum algorithm is assigned a checksum type

1472

number of six (6).

1473

1474

6.2.7. DES CBC Checksum

1475

1476

The DES-MAC checksum is computed by prepending an eight octet

1477

confounder to the plaintext, padding with zero-valued octets if

1478

necessary to bring the length to a multiple of eight octets,

1479

performing a DES CBC-mode encryption on the result by using the key

1480

and an initialization vector of zero, taking the last block of the

1481

ciphertext, prepending the same confounder, and encrypting the pair

1482

by using DES in cipher-block-chaining (CBC) mode with a variant of

1483

the key, where the variant is computed by eXclusive-ORing the key

1484

with the constant 0xF0F0F0F0F0F0F0F0. The initialization vector

1485

should be zero. The resulting checksum is 128 bits (sixteen octets)

1486

long, 64 bits of which are redundant. This checksum is tamper-proof

1487

and collision-proof.

1488

1489

des-mac

1490

---------------------------------------------------------------------

1491

associated des-cbc-md5, des-cbc-md4, des-cbc-crc

1492

cryptosystem

1493

1494

get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,

1495

conf | des-mac(key, conf | msg | pad, ivec=0),

1496

ivec=0)

1497

1498

verify_mic decrypt, compute DES MAC using confounder, compare

1499

1500

The des-mac checksum algorithm is assigned a checksum type number of

1501

four (4).

1502

1503

6.2.8. DES CBC Checksum Alternative

1504

1505

The DES-MAC-K checksum is computed by performing a DES CBC-mode

1506

encryption of the plaintext, with zero-valued padding bytes if

1507

necessary to bring the length to a multiple of eight octets, and by

1508

using the last block of the ciphertext as the checksum value. It is

1509

keyed with an encryption key that is also used as the initialization

1510

vector. The resulting checksum is 64 bits (eight octets) long. This

1511

1512

1513

1514

Raeburn Standards Track [Page 27]

1515

1516

RFC 3961 Encryption and Checksum Specifications February 2005

1517

1518

1519

checksum is tamper-proof and collision-proof. Note that this

1520

checksum type is the old method for encoding the DESMAC checksum; it

1521

is no longer recommended.

1522

1523

des-mac-k

1524

----------------------------------------------------------------

1525

associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc

1526

1527

get_mic des-mac(key, msg | pad, ivec=key)

1528

1529

verify_mic compute MAC and compare

1530

1531

The des-mac-k checksum algorithm is assigned a checksum type number

1532

of five (5).

1533

1534

6.3. Triple-DES Based Encryption and Checksum Types

1535

1536

This encryption and checksum type pair is based on the Triple DES

1537

cryptosystem in Outer-CBC mode and on the HMAC-SHA1 message

1538

authentication algorithm.

1539

1540

A Triple DES key is the concatenation of three DES keys as described

1541

above for des-cbc-md5. A Triple DES key is generated from random

1542

data by creating three DES keys from separate sequences of random

1543

data.

1544

1545

Encrypted data using this type must be generated as described in

1546

section 5.3. If the length of the input data is not a multiple of

1547

the block size, zero-valued octets must be used to pad the plaintext

1548

to the next eight-octet boundary. The confounder must be eight

1549

random octets (one block).

1550

1551

The simplified profile for Triple DES, with key derivation as defined

1552

in section 5, is as follows:

1553

1554

des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd

1555

------------------------------------------------

1556

protocol key format 24 bytes, parity in low

1557

bit of each

1558

1559

key-generation seed 21 bytes

1560

length

1561

1562

1563

1564

1565

1566

1567

1568

1569

1570

Raeburn Standards Track [Page 28]

1571

1572

RFC 3961 Encryption and Checksum Specifications February 2005

1573

1574

1575

des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd

1576

------------------------------------------------

1577

hash function SHA-1

1578

1579

HMAC output size 160 bits

1580

1581

message block size 8 bytes

1582

1583

default string-to-key empty string

1584

params

1585

1586

encryption and triple-DES encrypt and

1587

decryption functions decrypt, in outer-CBC

1588

mode (cipher block size

1589

8 octets)

1590

1591

key generation functions:

1592

1593

random-to-key DES3random-to-key (see

1594

below)

1595

1596

string-to-key DES3string-to-key (see

1597

below)

1598

1599

The des3-cbc-hmac-sha1-kd encryption type is assigned the value

1600

sixteen (16). The hmac-sha1-des3-kd checksum algorithm is assigned a

1601

checksum type number of twelve (12).

1602

1603

6.3.1. Triple DES Key Production (random-to-key, string-to-key)

1604

1605

The 168 bits of random key data are converted to a protocol key value

1606

as follows. First, the 168 bits are divided into three groups of 56

1607

bits, which are expanded individually into 64 bits as follows:

1608

1609

DES3random-to-key:

1610

1 2 3 4 5 6 7 p

1611

9 10 11 12 13 14 15 p

1612

17 18 19 20 21 22 23 p

1613

25 26 27 28 29 30 31 p

1614

33 34 35 36 37 38 39 p

1615

41 42 43 44 45 46 47 p

1616

49 50 51 52 53 54 55 p

1617

56 48 40 32 24 16 8 p

1618

1619

The "p" bits are parity bits computed over the data bits. The output

1620

of the three expansions, each corrected to avoid "weak" and "semi-

1621

weak" keys as in section 6.2, are concatenated to form the protocol

1622

key value.

1623

1624

1625

1626

Raeburn Standards Track [Page 29]

1627

1628

RFC 3961 Encryption and Checksum Specifications February 2005

1629

1630

1631

The string-to-key function is used to transform UTF-8 passwords into

1632

DES3 keys. The DES3 string-to-key function relies on the "N-fold"

1633

algorithm and DK function, described in section 5.

1634

1635

The n-fold algorithm is applied to the password string concatenated

1636

with a salt value. For 3-key triple DES, the operation will involve

1637

a 168-fold of the input password string, to generate an intermediate

1638

key, from which the user's long-term key will be derived with the DK

1639

function. The DES3 string-to-key function is shown here in

1640

pseudocode:

1641

1642

DES3string-to-key(passwordString, salt, params)

1643

if (params != emptyString)

1644

error("invalid params");

1645

s = passwordString + salt

1646

tmpKey = random-to-key(168-fold(s))

1647

key = DK (tmpKey, KerberosConstant)

1648

1649

Weak key checking is performed in the random-to-key and DK

1650

operations. The KerberosConstant value is the byte string {0x6b 0x65

1651

0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to the ASCII

1652

encoding for the string "kerberos".

1653

1654

7. Use of Kerberos Encryption Outside This Specification

1655

1656

Several Kerberos-based application protocols and preauthentication

1657

systems have been designed and deployed that perform encryption and

1658

message integrity checks in various ways. Although in some cases

1659

there may be good reason for specifying these protocols in terms of

1660

specific encryption or checksum algorithms, we anticipate that in

1661

many cases this will not be true, and more generic approaches

1662

independent of particular algorithms will be desirable. Rather than

1663

have each protocol designer reinvent schemes for protecting data,

1664

using multiple keys, etc., we have attempted to present in this

1665

section a general framework that should be sufficient not only for

1666

the Kerberos protocol itself but also for many preauthentication

1667

systems and application protocols, while trying to avoid some of the

1668

assumptions that can work their way into such protocol designs.

1669

1670

Some problematic assumptions we've seen (and sometimes made) include

1671

the following: a random bitstring is always valid as a key (not true

1672

for DES keys with parity); the basic block encryption chaining mode

1673

provides no integrity checking, or can easily be separated from such

1674

checking (not true for many modes in development that do both

1675

simultaneously); a checksum for a message always results in the same

1676

value (not true if a confounder is incorporated); an initial vector

1677

is used (may not be true if a block cipher in CBC mode is not in

1678

use).

1679

1680

1681

1682

Raeburn Standards Track [Page 30]

1683

1684

RFC 3961 Encryption and Checksum Specifications February 2005

1685

1686

1687

Although such assumptions the may hold for any given set of

1688

encryption and checksum algorithms, they may not be true of the next

1689

algorithms to be defined, leaving the application protocol unable to

1690

make use of those algorithms without updates to its specification.

1691

1692

The Kerberos protocol uses only the attributes and operations

1693

described in sections 3 and 4. Preauthentication systems and

1694

application protocols making use of Kerberos are encouraged to use

1695

them as well. The specific key and string-to-key parameters should

1696

generally be treated as opaque. Although the string-to-key

1697

parameters are manipulated as an octet string, the representation for

1698

the specific key structure is implementation defined; it may not even

1699

be a single object.

1700

1701

We don't recommend doing so, but some application protocols will

1702

undoubtedly continue to use the key data directly, even if only in

1703

some of the currently existing protocol specifications. An

1704

implementation intended to support general Kerberos applications may

1705

therefore need to make the key data available, as well as the

1706

attributes and operations described in sections 3 and 4 [8].

1707

1708

8. Assigned Numbers

1709

1710

The following encryption-type numbers are already assigned or

1711

reserved for use in Kerberos and related protocols.

1712

1713

encryption type etype section or comment

1714

-----------------------------------------------------------------

1715

des-cbc-crc 1 6.2.3

1716

des-cbc-md4 2 6.2.2

1717

des-cbc-md5 3 6.2.1

1718

[reserved] 4

1719

des3-cbc-md5 5

1720

[reserved] 6

1721

des3-cbc-sha1 7

1722

dsaWithSHA1-CmsOID 9 (pkinit)

1723

md5WithRSAEncryption-CmsOID 10 (pkinit)

1724

sha1WithRSAEncryption-CmsOID 11 (pkinit)

1725

rc2CBC-EnvOID 12 (pkinit)

1726

rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5)

1727

rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0)

1728

des-ede3-cbc-Env-OID 15 (pkinit)

1729

des3-cbc-sha1-kd 16 6.3

1730

aes128-cts-hmac-sha1-96 17 [KRB5-AES]

1731

aes256-cts-hmac-sha1-96 18 [KRB5-AES]

1732

rc4-hmac 23 (Microsoft)

1733

rc4-hmac-exp 24 (Microsoft)

1734

subkey-keymaterial 65 (opaque; PacketCable)

1735

1736

1737

1738

Raeburn Standards Track [Page 31]

1739

1740

RFC 3961 Encryption and Checksum Specifications February 2005

1741

1742

1743

(The "des3-cbc-sha1" assignment is a deprecated version using no key

1744

derivation. It should not be confused with des3-cbc-sha1-kd.)

1745

1746

Several numbers have been reserved for use in encryption systems not

1747

defined here. Encryption-type numbers have unfortunately been

1748

overloaded on occasion in Kerberos-related protocols, so some of the

1749

reserved numbers do not and will not correspond to encryption systems

1750

fitting the profile presented here.

1751

1752

The following checksum-type numbers are assigned or reserved. As

1753

with encryption-type numbers, some overloading of checksum numbers

1754

has occurred.

1755

1756

Checksum type sumtype checksum section or

1757

value size reference

1758

---------------------------------------------------------------------

1759

CRC32 1 4 6.1.3

1760

rsa-md4 2 16 6.1.2

1761

rsa-md4-des 3 24 6.2.5

1762

des-mac 4 16 6.2.7

1763

des-mac-k 5 8 6.2.8

1764

rsa-md4-des-k 6 16 6.2.6

1765

rsa-md5 7 16 6.1.1

1766

rsa-md5-des 8 24 6.2.4

1767

rsa-md5-des3 9 24 ??

1768

sha1 (unkeyed) 10 20 ??

1769

hmac-sha1-des3-kd 12 20 6.3

1770

hmac-sha1-des3 13 20 ??

1771

sha1 (unkeyed) 14 20 ??

1772

hmac-sha1-96-aes128 15 20 [KRB5-AES]

1773

hmac-sha1-96-aes256 16 20 [KRB5-AES]

1774

[reserved] 0x8003 ? [GSS-KRB5]

1775

1776

Encryption and checksum-type numbers are signed 32-bit values. Zero

1777

is invalid, and negative numbers are reserved for local use. All

1778

standardized values must be positive.

1779

1780

9. Implementation Notes

1781

1782

The "interface" described here is the minimal information that must

1783

be defined to make a cryptosystem useful within Kerberos in an

1784

interoperable fashion. The use of functional notation used in some

1785

places is not an attempt to define an API for cryptographic

1786

functionality within Kerberos. Actual implementations providing

1787

clean APIs will probably make additional information available, that

1788

could be derived from a specification written to the framework given

1789

here. For example, an application designer may wish to determine the

1790

largest number of bytes that can be encrypted without overflowing a

1791

1792

1793

1794

Raeburn Standards Track [Page 32]

1795

1796

RFC 3961 Encryption and Checksum Specifications February 2005

1797

1798

1799

certain size output buffer or conversely, the maximum number of bytes

1800

that might be obtained by decrypting a ciphertext message of a given

1801

size. (In fact, an implementation of the GSS-API Kerberos mechanism

1802

[GSS-KRB5] will require some of these.)

1803

1804

The presence of a mechanism in this document should not be taken to

1805

indicate that it must be implemented for compliance with any

1806

specification; required mechanisms will be specified elsewhere.

1807

Indeed, some of the mechanisms described here for backward

1808

compatibility are now considered rather weak for protecting critical

1809

data.

1810

1811

10. Security Considerations

1812

1813

Recent years have brought so many advancements in large-scale attacks

1814

capability against DES that it is no longer considered a strong

1815

encryption mechanism. Triple-DES is generally preferred in its

1816

place, despite its poorer performance. See [ESP-DES] for a summary

1817

of some of the potential attacks and [EFF-DES] for a detailed

1818

discussion of the implementation of particular attacks. However,

1819

most Kerberos implementations still have DES as their primary

1820

interoperable encryption type.

1821

1822

DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of

1823

single-DES here avoids them. However, DES also has 48 'possibly-

1824

weak' keys [Schneier96] (note that the tables in many editions of the

1825

reference contains errors) that are not avoided.

1826

1827

DES weak keys have the property that E1(E1(P)) = P (where E1 denotes

1828

encryption of a single block with key 1). DES semi-weak keys, or

1829

"dual" keys, are pairs of keys with the property that E1(P) = D2(P),

1830

and thus E2(E1(P)) = P. Because of the use of CBC mode and the

1831

leading random confounder, however, these properties are unlikely to

1832

present a security problem.

1833

1834

Many of the choices concerning when to perform weak-key corrections

1835

relate more to compatibility with existing implementations than to

1836

any risk analysis.

1837

1838

Although checks are also done for the component DES keys in a

1839

triple-DES key, the nature of the weak keys make it extremely

1840

unlikely that they will weaken the triple-DES encryption. It is only

1841

slightly more likely than having the middle of the three sub-keys

1842

match one of the other two, which effectively converts the encryption

1843

to single-DES - a case we make no effort to avoid.

1844

1845

1846

1847

1848

1849

1850

Raeburn Standards Track [Page 33]

1851

1852

RFC 3961 Encryption and Checksum Specifications February 2005

1853

1854

1855

The true CRC-32 checksum is not collision-proof; an attacker could

1856

use a probabilistic chosen-plaintext attack to generate a valid

1857

message even if a confounder is used [SG92]. The use of collision-

1858

proof checksums is of course recommended for environments where such

1859

attacks represent a significant threat. The "simplifications" (read:

1860

bugs) introduced when CRC-32 was implemented for Kerberos cause

1861

leading zeros effectively to be ignored, so messages differing only

1862

in leading zero bits will have the same checksum.

1863

1864

[HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm.

1865

Unlike [IPSEC-HMAC], the triple-DES specification here does not use

1866

the suggested truncation of the HMAC output. As pointed out in

1867

[IPSEC-HMAC], SHA-1 was not developed for use as a keyed hash

1868

function, which is a criterion of HMAC. [HMAC-TEST] contains test

1869

vectors for HMAC-SHA-1.

1870

1871

The mit_des_string_to_key function was originally constructed with

1872

the assumption that all input would be ASCII; it ignores the top bit

1873

of each input byte. Folding with XOR is also not an especially good

1874

mixing mechanism for preserving randomness.

1875

1876

The n-fold function used in the string-to-key operation for des3-

1877

cbc-hmac-sha1-kd was designed to cause each bit of input to

1878

contribute equally to the output. It was not designed to maximize or

1879

equally distribute randomness in the input, and conceivably

1880

randomness may be lost in cases of partially structured input. This

1881

should only be an issue for highly structured passwords, however.

1882

1883

[RFC1851] discusses the relative strength of triple-DES encryption.

1884

The relatively slow speed of triple-DES encryption may also be an

1885

issue for some applications.

1886

1887

[Bellovin91] suggests that analyses of encryption schemes include a

1888

model of an attacker capable of submitting known plaintexts to be

1889

encrypted with an unknown key, as well as be able to perform many

1890

types of operations on known protocol messages. Recent experiences

1891

with the chosen-plaintext attacks on Kerberos version 4 bear out the

1892

value of this suggestion.

1893

1894

The use of unkeyed encrypted checksums, such as those used in the

1895

single-DES cryptosystems specified in [Kerb1510], allows for cut-

1896

and-paste attacks, especially if a confounder is not used. In

1897

addition, unkeyed encrypted checksums are vulnerable to chosen-

1898

plaintext attacks: An attacker with access to an encryption oracle

1899

can easily encrypt the required unkeyed checksum along with the

1900

1901

1902

1903

1904

1905

1906

Raeburn Standards Track [Page 34]

1907

1908

RFC 3961 Encryption and Checksum Specifications February 2005

1909

1910

1911

chosen plaintext. [Bellovin99] These weaknesses, combined with a

1912

common implementation design choice described below, allow for a

1913

cross-protocol attack from version 4 to version 5.

1914

1915

The use of a random confounder is an important means to prevent an

1916

attacker from making effective use of protocol exchanges as an

1917

encryption oracle. In Kerberos version 4, the encryption of constant

1918

plaintext to constant ciphertext makes an effective encryption oracle

1919

for an attacker. The use of random confounders in [Kerb1510]

1920

frustrates this sort of chosen-plaintext attack.

1921

1922

Using the same key for multiple purposes can enable or increase the

1923

scope of chosen-plaintext attacks. Some software that implements

1924

both versions 4 and 5 of the Kerberos protocol uses the same keys for

1925

both versions. This enables the encryption oracle of version 4 to be

1926

used to attack version 5. Vulnerabilities to attacks such as this

1927

cross-protocol attack make it unwise to use a key for multiple

1928

purposes.

1929

1930

This document, like the Kerberos protocol, does not address limiting

1931

the amount of data a key may be used with to a quantity based on the

1932

robustness of the algorithm or size of the key. It is assumed that

1933

any defined algorithms and key sizes will be strong enough to support

1934

very large amounts of data, or they will be deprecated once

1935

significant attacks are known.

1936

1937

This document also places no bounds on the amount of data that can be

1938

handled in various operations. To avoid denial of service attacks,

1939

implementations will probably seek to restrict message sizes at some

1940

higher level.

1941

1942

11. IANA Considerations

1943

1944

Two registries for numeric values have been created: Kerberos

1945

Encryption Type Numbers and Kerberos Checksum Type Numbers. These

1946

are signed values ranging from -2147483648 to 2147483647. Positive

1947

values should be assigned only for algorithms specified in accordance

1948

with this specification for use with Kerberos or related protocols.

1949

Negative values are for private use; local and experimental

1950

algorithms should use these values. Zero is reserved and may not be

1951

assigned.

1952

1953

Positive encryption- and checksum-type numbers may be assigned

1954

following either of two policies described in [BCP26].

1955

1956

Standards-track specifications may be assigned values under the

1957

Standards Action policy.

1958

1959

1960

1961

1962

Raeburn Standards Track [Page 35]

1963

1964

RFC 3961 Encryption and Checksum Specifications February 2005

1965

1966

1967

Specifications in non-standards track RFCs may be assigned values

1968

after Expert Review. A non-IETF specification may be assigned values

1969

by publishing an Informational or standards-track RFC referencing the

1970

external specification; that specification must be public and

1971

published in some permanent record, much like the IETF RFCs. It is

1972

highly desirable, though not required, that the full specification be

1973

published as an IETF RFC.

1974

1975

Smaller encryption type values should be used for IETF standards-

1976

track mechanisms, and much higher values (16777216 and above) for

1977

other mechanisms. (Rationale: In the Kerberos ASN.1 encoding,

1978

smaller numbers encode to smaller octet sequences, so this favors

1979

standards-track mechanisms with slightly smaller messages.) Aside

1980

from that guideline, IANA may choose numbers as it sees fit.

1981

1982

Internet-Draft specifications should not include values for

1983

encryption- and checksum-type numbers. Instead, they should indicate

1984

that values would be assigned by IANA when the document is approved

1985

as an RFC. For development and interoperability testing, values in

1986

the private-use range (negative values) may be used but should not be

1987

included in the draft specification.

1988

1989

Each registered value should have an associated unique reference

1990

name. The lists given in section 8 were used to create the initial

1991

registry; they include reservations for specifications in progress in

1992

parallel with this document, and certain other values believed to

1993

already be in use.

1994

1995

12. Acknowledgements

1996

1997

This document is an extension of the encryption specification

1998

included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much

1999

of the text of the background, concepts, and DES specifications is

2000

drawn directly from that document.

2001

2002

The abstract framework presented in this document was put together by

2003

Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn,

2004

and Tom Yu, and the details were refined several times based on

2005

comments from John Brezak and others.

2006

2007

Marc Horowitz wrote the original specification of triple-DES and key

2008

derivation in a pair of Internet-Drafts (under the names draft-

2009

horowitz-key-derivation and draft-horowitz-kerb-key-derivation) that

2010

were later folded into a draft revision of [Kerb1510], from which

2011

this document was later split off.

2012

2013

2014

2015

2016

2017

2018

Raeburn Standards Track [Page 36]

2019

2020

RFC 3961 Encryption and Checksum Specifications February 2005

2021

2022

2023

Tom Yu provided the text describing the modifications to the standard

2024

CRC algorithm as Kerberos implementations actually use it, and some

2025

of the text in the Security Considerations section.

2026

2027

Miroslav Jurisic provided information for one of the UTF-8 test cases

2028

for the string-to-key functions.

2029

2030

Marcus Watts noticed some errors in earlier versions and pointed out

2031

that the simplified profile could easily be modified to support

2032

cipher text stealing modes.

2033

2034

Simon Josefsson contributed some clarifications to the DES "CBC

2035

checksum" and string-to-key and weak key descriptions, and some test

2036

vectors.

2037

2038

Simon Josefsson, Louis LeVay, and others also caught some errors in

2039

earlier versions of this document.

2040

2041

2042

2043

2044

2045

2046

2047

2048

2049

2050

2051

2052

2053

2054

2055

2056

2057

2058

2059

2060

2061

2062

2063

2064

2065

2066

2067

2068

2069

2070

2071

2072

2073

2074

Raeburn Standards Track [Page 37]

2075

2076

RFC 3961 Encryption and Checksum Specifications February 2005

2077

2078

2079

A. Test Vectors

2080

2081

This section provides test vectors for various functions defined or

2082

described in this document. For convenience, most inputs are ASCII

2083

strings, though some UTF-8 samples are provided for string-to-key

2084

functions. Keys and other binary data are specified as hexadecimal

2085

strings.

2086

2087

A.1. n-fold

2088

2089

The n-fold function is defined in section 5.1. As noted there, the

2090

sample vector in the original paper defining the algorithm appears to

2091

be incorrect. Here are some test cases provided by Marc Horowitz and

2092

Simon Josefsson:

2093

2094

64-fold("012345") =

2095

64-fold(303132333435) = be072631276b1955

2096

2097

56-fold("password") =

2098

56-fold(70617373776f7264) = 78a07b6caf85fa

2099

2100

64-fold("Rough Consensus, and Running Code") =

2101

64-fold(526f75676820436f6e73656e7375732c20616e642052756e

2102

6e696e6720436f6465) = bb6ed30870b7f0e0

2103

2104

168-fold("password") =

2105

168-fold(70617373776f7264) =

2106

59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e

2107

2108

192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")

2109

192-fold(4d41535341434856534554545320494e5354495456544520

2110

4f4620544543484e4f4c4f4759) =

2111

db3b0d8f0b061e603282b308a50841229ad798fab9540c1b

2112

2113

168-fold("Q") =

2114

168-fold(51) =

2115

518a54a2 15a8452a 518a54a2 15a8452a

2116

518a54a2 15

2117

2118

168-fold("ba") =

2119

168-fold(6261) =

2120

fb25d531 ae897449 9f52fd92 ea9857c4

2121

ba24cf29 7e

2122

2123

Here are some additional values corresponding to folded values of the

2124

string "kerberos"; the 64-bit form is used in the des3 string-to-key

2125

(section 6.3.1).

2126

2127

2128

2129

2130

Raeburn Standards Track [Page 38]

2131

2132

RFC 3961 Encryption and Checksum Specifications February 2005

2133

2134

2135

64-fold("kerberos") =

2136

6b657262 65726f73

2137

128-fold("kerberos") =

2138

6b657262 65726f73 7b9b5b2b 93132b93

2139

168-fold("kerberos") =

2140

8372c236 344e5f15 50cd0747 e15d62ca

2141

7a5a3bce a4

2142

256-fold("kerberos") =

2143

6b657262 65726f73 7b9b5b2b 93132b93

2144

5c9bdcda d95c9899 c4cae4de e6d6cae4

2145

2146

Note that the initial octets exactly match the input string when the

2147

output length is a multiple of the input length.

2148

2149

A.2. mit_des_string_to_key

2150

2151

The function mit_des_string_to_key is defined in section 6.2. We

2152

present here several test values, with some of the intermediate

2153

results. The fourth test demonstrates the use of UTF-8 with three

2154

characters. The last two tests are specifically constructed so as to

2155

trigger the weak-key fixups for the intermediate key produced by

2156

fan-folding; we have no test cases that cause such fixups for the

2157

final key.

2158

2159

UTF-8 encodings used in test vector:

2160

eszett U+00DF C3 9F s-caron U+0161 C5 A1

2161

c-acute U+0107 C4 87 g-clef U+1011E F0 9D 84 9E

2162

2163

Test vector:

2164

2165

salt: "ATHENA.MIT.EDUraeburn"

2166

415448454e412e4d49542e4544557261656275726e

2167

password: "password" 70617373776f7264

2168

fan-fold result: c01e38688ac86c2e

2169

intermediate key: c11f38688ac86d2f

2170

DES key: cbc22fae235298e3

2171

2172

salt: "WHITEHOUSE.GOVdanny"

2173

5748495445484f5553452e474f5664616e6e79

2174

password: "potatoe" 706f7461746f65

2175

fan-fold result: a028944ee63c0416

2176

intermediate key: a129944fe63d0416

2177

DES key: df3d32a74fd92a01

2178

2179

salt: "EXAMPLE.COMpianist" 4558414D504C452E434F4D7069616E697374

2180

password: g-clef (U+1011E) f09d849e

2181

fan-fold result: 3c4a262c18fab090

2182

intermediate key: 3d4a262c19fbb091

2183

2184

2185

2186

Raeburn Standards Track [Page 39]

2187

2188

RFC 3961 Encryption and Checksum Specifications February 2005

2189

2190

2191

DES key: 4ffb26bab0cd9413

2192

2193

salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i" + c-acute(U+0107)

2194

415448454e412e4d49542e4544554a757269c5a169c487

2195

password: eszett(U+00DF)

2196

c39f

2197

fan-fold result:b8f6c40e305afc9e

2198

intermediate key: b9f7c40e315bfd9e

2199

DES key: 62c81a5232b5e69d

2200

2201

salt: "AAAAAAAA" 4141414141414141

2202

password: "11119999" 3131313139393939

2203

fan-fold result: e0e0e0e0f0f0f0f0

2204

intermediate key: e0e0e0e0f1f1f101

2205

DES key: 984054d0f1a73e31

2206

2207

salt: "FFFFAAAA" 4646464641414141

2208

password: "NNNN6666" 4e4e4e4e36363636

2209

fan-fold result: 1e1e1e1e0e0e0e0e

2210

intermediate key: 1f1f1f1f0e0e0efe

2211

DES key: c4bf6b25adf7a4f8

2212

2213

This trace provided by Simon Josefsson shows the intermediate

2214

processing stages of one of the test inputs:

2215

2216

string_to_key (des-cbc-md5, string, salt)

2217

;; string:

2218

;; `password' (length 8 bytes)

2219

;; 70 61 73 73 77 6f 72 64

2220

;; salt:

2221

;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)

2222

;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61

2223

;; 65 62 75 72 6e

2224

des_string_to_key (string, salt)

2225

;; String:

2226

;; `password' (length 8 bytes)

2227

;; 70 61 73 73 77 6f 72 64

2228

;; Salt:

2229

;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)

2230

;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61

2231

;; 65 62 75 72 6e

2232

odd = 1;

2233

s = string | salt;

2234

tempstring = 0; /* 56-bit string */

2235

pad(s); /* with nulls to 8 byte boundary */

2236

;; s = pad(string|salt):

2237

;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00'

2238

;; (length 32 bytes)

2239

2240

2241

2242

Raeburn Standards Track [Page 40]

2243

2244

RFC 3961 Encryption and Checksum Specifications February 2005

2245

2246

2247

;; 70 61 73 73 77 6f 72 64 41 54 48 45 4e 41 2e 4d

2248

;; 49 54 2e 45 44 55 72 61 65 62 75 72 6e 00 00 00

2249

for (8byteblock in s) {

2250

;; loop iteration 0

2251

;; 8byteblock:

2252

;; `password' (length 8 bytes)

2253

;; 70 61 73 73 77 6f 72 64

2254

;; 01110000 01100001 01110011 01110011 01110111 01101111

2255

;; 01110010 01100100

2256

56bitstring = removeMSBits(8byteblock);

2257

;; 56bitstring:

2258

;; 1110000 1100001 1110011 1110011 1110111 1101111

2259

;; 1110010 1100100

2260

if (odd == 0) reverse(56bitstring); ;; odd=1

2261

odd = ! odd

2262

tempstring = tempstring XOR 56bitstring;

2263

;; tempstring

2264

;; 1110000 1100001 1110011 1110011 1110111 1101111

2265

;; 1110010 1100100

2266

2267

for (8byteblock in s) {

2268

;; loop iteration 1

2269

;; 8byteblock:

2270

;; `ATHENA.M' (length 8 bytes)

2271

;; 41 54 48 45 4e 41 2e 4d

2272

;; 01000001 01010100 01001000 01000101 01001110 01000001

2273

;; 00101110 01001101

2274

56bitstring = removeMSBits(8byteblock);

2275

;; 56bitstring:

2276

;; 1000001 1010100 1001000 1000101 1001110 1000001

2277

;; 0101110 1001101

2278

if (odd == 0) reverse(56bitstring); ;; odd=0

2279

reverse(56bitstring)

2280

;; 56bitstring after reverse

2281

;; 1011001 0111010 1000001 0111001 1010001 0001001

2282

;; 0010101 1000001

2283

odd = ! odd

2284

tempstring = tempstring XOR 56bitstring;

2285

;; tempstring

2286

;; 0101001 1011011 0110010 1001010 0100110 1100110

2287

;; 1100111 0100101

2288

2289

for (8byteblock in s) {

2290

;; loop iteration 2

2291

;; 8byteblock:

2292

;; `IT.EDUra' (length 8 bytes)

2293

;; 49 54 2e 45 44 55 72 61

2294

;; 01001001 01010100 00101110 01000101 01000100 01010101

2295

2296

2297

2298

Raeburn Standards Track [Page 41]

2299

2300

RFC 3961 Encryption and Checksum Specifications February 2005

2301

2302

2303

;; 01110010 01100001

2304

56bitstring = removeMSBits(8byteblock);

2305

;; 56bitstring:

2306

;; 1001001 1010100 0101110 1000101 1000100 1010101

2307

;; 1110010 1100001

2308

if (odd == 0) reverse(56bitstring); ;; odd=1

2309

odd = ! odd

2310

tempstring = tempstring XOR 56bitstring;

2311

;; tempstring

2312

;; 1100000 0001111 0011100 0001111 1100010 0110011

2313

;; 0010101 1000100

2314

2315

for (8byteblock in s) {

2316

;; loop iteration 3

2317

;; 8byteblock:

2318

;; `eburn\x00\x00\x00' (length 8 bytes)

2319

;; 65 62 75 72 6e 00 00 00

2320

;; 01100101 01100010 01110101 01110010 01101110 00000000

2321

;; 00000000 00000000

2322

56bitstring = removeMSBits(8byteblock);

2323

;; 56bitstring:

2324

;; 1100101 1100010 1110101 1110010 1101110 0000000

2325

;; 0000000 0000000

2326

if (odd == 0) reverse(56bitstring); ;; odd=0

2327

reverse(56bitstring)

2328

;; 56bitstring after reverse

2329

;; 0000000 0000000 0000000 0111011 0100111 1010111

2330

;; 0100011 1010011

2331

odd = ! odd

2332

tempstring = tempstring XOR 56bitstring;

2333

;; tempstring

2334

;; 1100000 0001111 0011100 0110100 1000101 1100100

2335

;; 0110110 0010111

2336

2337

for (8byteblock in s) {

2338

}

2339

;; for loop terminated

2340

2341

tempkey = key_correction(add_parity_bits(tempstring));

2342

;; tempkey

2343

;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes)

2344

;; c1 1f 38 68 8a c8 6d 2f

2345

;; 11000001 00011111 00111000 01101000 10001010 11001000

2346

;; 01101101 00101111

2347

2348

key = key_correction(DES-CBC-check(s,tempkey));

2349

;; key

2350

;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)

2351

2352

2353

2354

Raeburn Standards Track [Page 42]

2355

2356

RFC 3961 Encryption and Checksum Specifications February 2005

2357

2358

2359

;; cb c2 2f ae 23 52 98 e3

2360

;; 11001011 11000010 00101111 10101110 00100011 01010010

2361

;; 10011000 11100011

2362

2363

;; string_to_key key:

2364

;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)

2365

;; cb c2 2f ae 23 52 98 e3

2366

2367

A.3. DES3 DR and DK

2368

2369

These tests show the derived-random and derived-key values for the

2370

des3-hmac-sha1-kd encryption scheme, using the DR and DK functions

2371

defined in section 6.3.1. The input keys were randomly generated;

2372

the usage values are from this specification.

2373

2374

key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92

2375

usage: 0000000155

2376

DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705

2377

DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd

2378

2379

key: 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2

2380

usage: 00000001aa

2381

DR: 9f58e5a047d894101c469845d67ae3c5249ed812f2

2382

DK: 9e58e5a146d9942a101c469845d67a20e3c4259ed913f207

2383

2384

key: 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc

2385

usage: 0000000155

2386

DR: 12fff90c773f956d13fc2ca0d0840349dbd39908eb

2387

DK: 13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf

2388

2389

key: 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5

2390

usage: 00000001aa

2391

DR: f8debf05b097e7dc0603686aca35d91fd9a5516a70

2392

DK: f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e

2393

2394

key: d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb

2395

usage: 6b65726265726f73 ("kerberos")

2396

DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da

2397

DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43

2398

2399

key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da

2400

usage: 0000000155

2401

DR: 348056ec98fcc517171d2b4d7a9493af482d999175

2402

DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7

2403

2404

key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c

2405

usage: 00000001aa

2406

DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5

2407

2408

2409

2410

Raeburn Standards Track [Page 43]

2411

2412

RFC 3961 Encryption and Checksum Specifications February 2005

2413

2414

2415

DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1

2416

2417

key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443

2418

usage: 0000000155

2419

DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a

2420

DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49

2421

2422

key: 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016

2423

usage: 00000001aa

2424

DR: f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec

2425

DK: f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d

2426

2427

A.4. DES3string_to_key

2428

2429

These are the keys generated for some of the above input strings for

2430

triple-DES with key derivation as defined in section 6.3.1.

2431

2432

salt: "ATHENA.MIT.EDUraeburn"

2433

passwd: "password"

2434

key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e

2435

2436

salt: "WHITEHOUSE.GOVdanny"

2437

passwd: "potatoe"

2438

key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a

2439

2440

salt: "EXAMPLE.COMbuckaroo"

2441

passwd: "penny"

2442

key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a

2443

2444

salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i"

2445

+ c-acute(U+0107)

2446

passwd: eszett(U+00DF)

2447

key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0

2448

2449

salt: "EXAMPLE.COMpianist"

2450

passwd: g-clef(U+1011E)

2451

key: 85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19

2452

2453

A.5. Modified CRC-32

2454

2455

Below are modified-CRC32 values for various ASCII and octet strings.

2456

Only the printable ASCII characters are checksummed, without a C-

2457

style trailing zero-valued octet. The 32-bit modified CRC and the

2458

sequence of output bytes as used in Kerberos are shown. (The octet

2459

values are separated here to emphasize that they are octet values and

2460

not 32-bit numbers, which will be the most convenient form for

2461

manipulation in some implementations. The bit and byte order used

2462

2463

2464

2465

2466

Raeburn Standards Track [Page 44]

2467

2468

RFC 3961 Encryption and Checksum Specifications February 2005

2469

2470

2471

internally for such a number is irrelevant; the octet sequence

2472

generated is what is important.)

2473

2474

mod-crc-32("foo") = 33 bc 32 73

2475

mod-crc-32("test0123456789") = d6 88 3e b8

2476

mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3

2477

mod-crc-32(8000) = 4b 98 83 3b

2478

mod-crc-32(0008) = 32 88 db 0e

2479

mod-crc-32(0080) = 20 83 b8 ed

2480

mod-crc-32(80) = 20 83 b8 ed

2481

mod-crc-32(80000000) = 3b b6 59 ed

2482

mod-crc-32(00000001) = 96 30 07 77

2483

2484

B. Significant Changes from RFC 1510

2485

2486

The encryption and checksum mechanism profiles are new. The old

2487

specification defined a few operations for various mechanisms but

2488

didn't outline what abstract properties should be required of new

2489

mechanisms, or how to ensure that a mechanism specification is

2490

complete enough for interoperability between implementations. The

2491

new profiles differ from the old specification in a few ways:

2492

2493

Some message definitions in [Kerb1510] could be read as permitting

2494

the initial vector to be specified by the application; the text

2495

was too vague. It is explicitly not permitted in this

2496

specification. Some encryption algorithms may not use

2497

initialization vectors, so relying on chosen, secret

2498

initialization vectors for security is unwise. Also, the

2499

prepended confounder in the existing algorithms is roughly

2500

equivalent to a per-message initialization vector that is revealed

2501

in encrypted form. However, carrying state across from one

2502

encryption to another is explicitly permitted through the opaque

2503

"cipher state" object.

2504

2505

The use of key derivation is new.

2506

2507

Several new methods are introduced, including generation of a key

2508

in wire-protocol format from random input data.

2509

2510

The means for influencing the string-to-key algorithm are laid out

2511

more clearly.

2512

2513

Triple-DES support is new.

2514

2515

The pseudo-random function is new.

2516

2517

The des-cbc-crc, DES string-to-key and CRC descriptions have been

2518

updated to align them with existing implementations.

2519

2520

2521

2522

Raeburn Standards Track [Page 45]

2523

2524

RFC 3961 Encryption and Checksum Specifications February 2005

2525

2526

2527

[Kerb1510] did not indicate what character set or encoding might be

2528

used for pass phrases and salts.

2529

2530

In [Kerb1510], key types, encryption algorithms, and checksum

2531

algorithms were only loosely associated, and the association was not

2532

well described. In this specification, key types and encryption

2533

algorithms have a one-to-one correspondence, and associations between

2534

encryption and checksum algorithms are described so that checksums

2535

can be computed given negotiated keys, without requiring further

2536

negotiation for checksum types.

2537

2538

Notes

2539

2540

[1] Although Message Authentication Code (MAC) or Message Integrity

2541

Check (MIC) would be more appropriate terms for many of the uses

2542

in this document, we continue to use the term checksum for

2543

historical reasons.

2544

2545

[2] Extending CBC mode across messages would be one obvious example

2546

of this chaining. Another might be the use of counter mode, with

2547

a counter randomly initialized and attached to the ciphertext; a

2548

second message could continue incrementing the counter when

2549

chaining the cipher state, thus avoiding having to transmit

2550

another counter value. However, this chaining is only useful for

2551

uninterrupted, ordered sequences of messages.

2552

2553

[3] In the case of Kerberos, the encrypted objects will generally be

2554

ASN.1 DER encodings, which contain indications of their length in

2555

the first few octets.

2556

2557

[4] As of the time of this writing, new modes of operation have been

2558

proposed, some of which may permit encryption and integrity

2559

protection simultaneously. After some of these proposals have

2560

been subjected to adequate analysis, we may wish to formulate a

2561

new simplified profile based on one of them.

2562

2563

[5] It should be noted that the sample vector in appendix B.2 of the

2564

original paper appears to be incorrect. Two independent

2565

implementations from the specification (one in C by Marc

2566

Horowitz, and another in Scheme by Bill Sommerfeld) agree on a

2567

value different from that in [Blumenthal96].

2568

2569

[6] For example, in MIT's implementation of [Kerb1510], the rsa-md5

2570

unkeyed checksum of application data may be included in an

2571

authenticator encrypted in a service's key.

2572

2573

[7] Using a variant of the key limits the use of a key to a

2574

particular function, separating the functions of generating a

2575

2576

2577

2578

Raeburn Standards Track [Page 46]

2579

2580

RFC 3961 Encryption and Checksum Specifications February 2005

2581

2582

2583

checksum from other encryption performed using the session key.

2584

The constant 0xF0F0F0F0F0F0F0F0 was chosen because it maintains

2585

key parity. The properties of DES precluded the use of the

2586

complement. The same constant is used for similar purpose in the

2587

Message Integrity Check in the Privacy Enhanced Mail standard.

2588

2589

[8] Perhaps one of the more common reasons for directly performing

2590

encryption is direct control over the negotiation and to select a

2591

"sufficiently strong" encryption algorithm (whatever that means

2592

in the context of a given application). Although Kerberos

2593

directly provides no direct facility for negotiating encryption

2594

types between the application client and server, there are other

2595

means to accomplish similar goals (for example, requesting only

2596

"strong" session key types from the KDC, and assuming that the

2597

type actually returned by the KDC will be understood and

2598

supported by the application server).

2599

2600

Normative References

2601

2602

[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing

2603

an IANA Considerations Section in RFCs", BCP 26, RFC

2604

2434, October 1998.

2605

2606

[Bellare98] Bellare, M., Desai, A., Pointcheval, D., and P.

2607

Rogaway, "Relations Among Notions of Security for

2608

Public-Key Encryption Schemes". Extended abstract

2609

published in Advances in Cryptology-Crypto 98

2610

Proceedings, Lecture Notes in Computer Science Vol.

2611

1462, H. Krawcyzk ed., Springer-Verlag, 1998.

2612

2613

[Blumenthal96] Blumenthal, U. and S. Bellovin, "A Better Key Schedule

2614

for DES-Like Ciphers", Proceedings of PRAGOCRYPT '96,

2615

1996.

2616

2617

[CRC] International Organization for Standardization, "ISO

2618

Information Processing Systems - Data Communication -

2619

High-Level Data Link Control Procedure - Frame

2620

Structure," IS 3309, 3rd Edition, October 1984.

2621

2622

[DES77] National Bureau of Standards, U.S. Department of

2623

Commerce, "Data Encryption Standard," Federal

2624

Information Processing Standards Publication 46,

2625

Washington, DC, 1977.

2626

2627

2628

2629

2630

2631

2632

2633

2634

Raeburn Standards Track [Page 47]

2635

2636

RFC 3961 Encryption and Checksum Specifications February 2005

2637

2638

2639

[DESI81] National Bureau of Standards, U.S. Department of

2640

Commerce, "Guidelines for implementing and using NBS

2641

Data Encryption Standard," Federal Information

2642

Processing Standards Publication 74, Washington, DC,

2643

1981.

2644

2645

[DESM80] National Bureau of Standards, U.S. Department of

2646

Commerce, "DES Modes of Operation," Federal

2647

Information Processing Standards Publication 81,

2648

Springfield, VA, December 1980.

2649

2650

[Dolev91] Dolev, D., Dwork, C., and M. Naor, "Non-malleable

2651

cryptography", Proceedings of the 23rd Annual

2652

Symposium on Theory of Computing, ACM, 1991.

2653

2654

[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:

2655

Keyed-Hashing for Message Authentication", RFC 2104,

2656

February 1997.

2657

2658

[KRB5-AES] Raeburn, K., "Advanced Encryption Standard (AES)

2659

Encryption for Kerberos 5", RFC 3962, February 2005.

2660

2661

[MD4-92] Rivest, R., "The MD4 Message-Digest Algorithm", RFC

2662

1320, April 1992.

2663

2664

[MD5-92] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC

2665

1321, April 1992.

2666

2667

[SG92] Stubblebine, S. and V. D. Gligor, "On Message

2668

Integrity in Cryptographic Protocols," in Proceedings

2669

of the IEEE Symposium on Research in Security and

2670

Privacy, Oakland, California, May 1992.

2671

2672

Informative References

2673

2674

[Bellovin91] Bellovin, S. M. and M. Merrit, "Limitations of the

2675

Kerberos Authentication System", in Proceedings of the

2676

Winter 1991 Usenix Security Conference, January, 1991.

2677

2678

[Bellovin99] Bellovin, S. M. and D. Atkins, private communications,

2679

1999.

2680

2681

[EFF-DES] Electronic Frontier Foundation, "Cracking DES: Secrets

2682

of Encryption Research, Wiretap Politics, and Chip

2683

Design", O'Reilly & Associates, Inc., May 1998.

2684

2685

[ESP-DES] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher

2686

Algorithm With Explicit IV", RFC 2405, November 1998.

2687

2688

2689

2690

Raeburn Standards Track [Page 48]

2691

2692

RFC 3961 Encryption and Checksum Specifications February 2005

2693

2694

2695

[GSS-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",

2696

RFC 1964, June 1996.

2697

2698

[HMAC-TEST] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and

2699

HMAC-SHA-1", RFC 2202, September 1997.

2700

2701

[IPSEC-HMAC] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96

2702

within ESP and AH", RFC 2404, November 1998.

2703

2704

[Kerb] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The

2705

Kerberos Network Authentication Service (V5)", Work in

2706

Progress, September 2004.

2707

2708

[Kerb1510] Kohl, J. and C. Neuman, "The Kerberos Network

2709

Authentication Service (V5)", RFC 1510, September

2710

1993.

2711

2712

[RC5] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-

2713

CBC-Pad, and RC5-CTS Algorithms", RFC 2040, October

2714

1996.

2715

2716

[RFC1851] Karn, P., Metzger, P., and W. Simpson, "The ESP Triple

2717

DES Transform", RFC 1851, September 1995.

2718

2719

[Schneier96] Schneier, B., "Applied Cryptography Second Edition",

2720

John Wiley & Sons, New York, NY, 1996. ISBN 0-471-

2721

12845-7.

2722

2723

Editor's Address

2724

2725

Kenneth Raeburn

2726

Massachusetts Institute of Technology

2727

77 Massachusetts Avenue

2728

Cambridge, MA 02139

2729

2730

EMail: raeburn@mit.edu

2731

2732

2733

2734

2735

2736

2737

2738

2739

2740

2741

2742

2743

2744

2745

2746

Raeburn Standards Track [Page 49]

2747

2748

RFC 3961 Encryption and Checksum Specifications February 2005

2749

2750

2751

Full Copyright Statement

2752

2753

2754

2755

This document is subject to the rights, licenses and restrictions

2756

contained in BCP 78, and except as set forth therein, the authors

2757

retain all their rights.

2758

2759

This document and the information contained herein are provided on an

2760

"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

2761

OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET

2762

ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,

2763

INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE

2764

INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

2765

WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

2766

2767

Intellectual Property

2768

2769

The IETF takes no position regarding the validity or scope of any

2770

Intellectual Property Rights or other rights that might be claimed to

2771

pertain to the implementation or use of the technology described in

2772

this document or the extent to which any license under such rights

2773

might or might not be available; nor does it represent that it has

2774

made any independent effort to identify any such rights. Information

2775

on the IETF's procedures with respect to rights in IETF Documents can

2776

be found in BCP 78 and BCP 79.

2777

2778

Copies of IPR disclosures made to the IETF Secretariat and any

2779

assurances of licenses to be made available, or the result of an

2780

attempt made to obtain a general license or permission for the use of

2781

such proprietary rights by implementers or users of this

2782

specification can be obtained from the IETF on-line IPR repository at

2783

http://www.ietf.org/ipr.

2784

2785

The IETF invites any interested party to bring to its attention any

2786

copyrights, patents or patent applications, or other proprietary

2787

rights that may cover technology that may be required to implement

2788

this standard. Please address the information to the IETF at ietf-

2789

ipr@ietf.org.

2790

2791

Acknowledgement

2792

2793

Funding for the RFC Editor function is currently provided by the

2794

Internet Society.

2795

2796

2797

2798

2799

2800

2801

2802

Raeburn Standards Track [Page 50]

2803