idnits 2.17.1 draft-jwalker-eap-archie-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 37 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 38 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7619 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'IEEE.802-1X.2001' on line 114 == Unused Reference: '3' is defined on line 1589, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1595, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2284 (ref. '4') (Obsoleted by RFC 3748) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 3394 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2486 (ref. '9') (Obsoleted by RFC 4282) == Outdated reference: A later version (-07) exists of draft-aboba-pppext-key-problem-05 -- Possible downref: Normative reference to a draft: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Jesse Walker 3 Expiration: September 2003 Intel Corporation 4 File: draft-jwalker-eap-archie-01.txt Russ Housley 5 Expires: December 23, 2003 Vigil Security 6 June 2003 8 The EAP Archie Protocol 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2003). All Rights Reserved. 34 Abstract 36 This memo defines an EAP authentication protocol based on pre-shared 37 keys, called EAP-Archie. This protocol performs mutual authentication, 38 session establishment, and session key derivation. EAP-Archie is based 39 on a static pre-shared key. EAP-Archie is designed as a native EAP 40 method. 42 Table Of Contents 44 1. Introduction ............................................ 3 45 1.1. Specification of Requirements ...................... 3 46 1.2. Terminology ........................................ 3 47 2. Protocol Overview ....................................... 4 48 2.1. Overview of EAP-Archie ............................. 4 49 2.2. Retry Behavior ..................................... 6 50 2.3. Fragmentation ...................................... 7 51 2.4. Identity Verification .............................. 7 52 2.5. Key Derivation ..................................... 7 53 3. Cryptographic Algorithms ................................ 9 54 3.1. AES-CBC-MAC-128 and AES-CBC-MAC-96 ................. 9 55 3.2. The Archie-PRF ..................................... 9 56 4. Detailed Description of EAP-Archie ...................... 10 57 4.1. Archie Message Format Summary ...................... 10 58 4.2. Archie-Request Message ............................. 11 59 4.3. Archie-Response Message ............................ 15 60 4.4. Archie-Confirm Message ............................. 22 61 4.5. Archie-Finish Message .............................. 27 62 5. IANA Considerations ..................................... 30 63 6. Security Considerations ................................. 30 64 6.1. Intended Use ....................................... 30 65 6.2. Mechanism .......................................... 30 66 6.3. Security Claims .................................... 31 67 6.4. Key Strength ....................................... 35 68 6.5. Key Hierarchy ...................................... 35 69 6.6. Vulnerabilities .................................... 35 70 7. Ackowledgements ......................................... 36 71 8. References .............................................. 36 72 9. Author Addresses ........................................ 37 73 10. Full Copyright Statement ............................... 37 74 11. Expiration Date......................................... 38 75 1. Introduction 77 The Extensible Authentication Protocol (EAP), described in [4], 78 provides a standard mechanism for support of additional authentication 79 methods within PPP. EAP is also used within IEEE 802 networks through 80 the IEEE 802.1X [8] framework. 82 EAP supports many authentication schemes, including smart cards, 83 Kerberos, Public Key, One Time Passwords, TLS, and others. This memo 84 defines a new authentication scheme, called the EAP-Archie. EAP-Archie 85 performs mutual authentication, session establishment, and fresh 86 session key derivation. Eap-Archie is based on a static pre-shared 87 key. 89 1.1. Specification of requirements 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [7]. 95 1.2 Terminology 97 This document frequently uses the following terms: 99 Backend Authentication Server 100 A backend authentication server is an entity that provides 101 an authentication service to an authenticator. When used, 102 this server typically executes EAP Methods for the 103 Authenticator. [This terminology is also used in 104 [IEEE.802-1X.2001].] 106 EAP Authenticator 107 The end of the EAP link initiating the EAP authentication 108 methods. [Note: This terminology is also used in 109 [IEEE.802-1X.2001], and has the same meaning in this 110 document]. 112 EAP Peer 113 The end of the EAP Link that responds to the 114 authenticator. [Note: In [IEEE.802-1X.2001], this end is 115 known as the Supplicant.] 117 EAP Server 118 The entity that terminates the EAP authentication with the 119 peer. In the case where there is no Backend Authentication 120 Server, this term refers to the EAP Authenticator. Where 121 the EAP Authenticator operates in pass-through, it refers 122 to the Backend Authentication Server. 124 2. Protocol Overview 126 2.1. Overview of EAP-Archie 128 EAP-Archie is a native EAP authentication method. That is, EAP-Archie 129 is an authentication protocol, and a stand-alone version of EAP-Archie 130 outside of EAP is not defined. Its design follows the Bellare-Rogaway 131 authentication paradigm [11], adapted somewhat to fit EAP. 133 EAP-Archie assumes a long-lived 512-bit secret shared between the EAP 134 Peer and the EAP Server. This long-lived secret is called the Archie 135 Key. The Archie Key has an internal structure. It consists of two 136 128-bit subkeys and a 256-bit subkey, respectively called the 137 key-confirmation key (KCK), the key-encryption key (KEK), and the 138 key-derivation key (KDK). The protocol uses the KCK to mutually 139 authenticate the EAP Peer and the EAP Server. The protocol uses the 140 KEK to distribute secret nonces used for session key derivation. The 141 protocol uses the KDK to derive a session key between the EAP Peer and 142 the EAP Server. EAP-Archie assumes that the Archie Key is known only 143 to the EAP Peer and EAP Server, and the security properties of the 144 protocol may be compromised if the pre-shared secret has wider 145 distribution. The protocol also assumes the EAP Server and EAP Peer 146 identify the correct Archie Key to use with the other by their 147 respective NAIs [9]. 149 A successful instance of the Archie protocol establishes a session, 150 sometimes also called a security association. 152 EAP-Archie uses four messages consisting of two EAP request/response 153 transactions. As with all EAP methods, the EAP Server initiates the 154 exchange. Figure 1 depicts the EAP-Archie message flow: 156 EAP Peer EAP Server 157 ======== ========== 158 <--- EAP-Request/EAP-Type=Archie 159 (AuthID | SessionID) 160 EAP-Response/EAP-Type=Archie ---> 161 (SessionID | PeerID | NonceP | 162 Binding | MAC1) 163 <--- EAP-Request/EAP-Type=Archie 164 (SessionID | NonceA | Binding | 165 MAC2) 166 EAP-Response/EAP-Type=Archie ---> 167 (SessionID | MAC3) 169 Figure 1. The EAP-Archie Message Flow 171 The first message is called an Archie-Start message. The Archie-Start 172 message initiates the EAP-Archie exchange. The EAP Server sends the 173 Archie-Start message to the EAP Peer in an EAP-Request message of type 174 Archie. The Archie-Start message requests that the EAP Peer 175 authenticate itself using EAP-Archie. The Archie-Start message is 176 unauthenticated but does suggest the identity of the EAP Server, 177 denoted by AuthID, and a challenge value, denoted SessionID. The 178 AuthID is an NAI [9] identifying the EAP Server, and SessionID is a 179 256-bit random value. The AuthID allows the EAP Peer to identify the 180 pre-shared secret for this context. SessionID serves several 181 purposes. First, since it is unpredictable, it allows the EAP Server 182 to detect replay attacks. Second, it provides the EAP server with a 183 session identifier for the entire exchange. 185 The response to the Archie-Start is called the Archie-Response 186 message. The EAP Peer sends the Archie-Response message to the EAP 187 Server in an EAP-Response message of type Archie. The Archie-Response 188 message authenticates the EAP Peer to the EAP Server, and requests the 189 EAP Server to authenticate itself to the EAP Peer. This message 190 conveys five values, called SessionID, PeerID, NonceP, Binding, and 191 MAC1. SessionID is the value of the same name from the Archie-Request 192 to which this Archie-Response replies. PeerID is an NAI identifying 193 the EAP Peer to the EAP Server. NonceP is a 256-bit random value 194 selected by the EAP Peer, encrypted under the KEK using the AES Key 195 Wrap [6]; the EAP Peer and EAP Server use the decrypted nonce value to 196 derive a session key, as explained in Section 2.5. MAC1 is a message 197 authentication code computed over the Archie-Request's AuthID field 198 and the prior Archie-Response message fields. The Message 199 Authentication Code (MAC) algorithm is AES-CBC-MAC-96, defined in 200 Section 3.1, using the KCK as the key. SessionID identifies the 201 session to which this Archie-Response belongs. PeerID allows the EAP 202 Server to identify the pre-shared secret to use in this protocol 203 instance. If the unencrypted nonce value is random, the encrypted 204 value NonceP will be unpredictable as well, and thus NonceP can serve 205 as a challenge from the EAP Peer to the EAP Server. Binding is the 206 addressing information the EAP Peer believes it is using during this 207 session. It indicates the identifier the EAP Peer uses for itself, as 208 well as that of its intended communication partner, which is typically 209 some sort of Network Access Server (NAS). Finally, a correct MAC1 210 value protects the Archie-Response undetected alteration, so 211 authenticates the Archie-Response message and hence the EAP Peer to 212 the EAP Server. Inclusion of the AuthID field from the Archie-Request 213 in the MAC1 calculation binds the identities of the EAP Server and EAP 214 Peer, thus helping to defeat invalid binding attacks and as a first 215 step toward establishing a consistent view of the session. 217 The response to the Archie-Response message is called the 218 Archie-Confirm message. The EAP Server sends the Archie-Confirm 219 message to the EAP Peer in an EAP-Request message of type Archie. The 220 Archie-Confirm message authenticates the EAP Server to the EAP 221 Peer. The Archie-Confirm message conveys four values, SessionID, 222 NonceA, Binding, and MAC2. SessionID is the value from the 223 Archie-Request and Archie-Response for this instance of the Archie 224 Protocol. NonceA is a 256-bit random value selected by the EAP Server 225 and encrypted under the KEK using the AES Key Wrap; the EAP Peer and 226 EAP Server use the decrypted nonce value to derive a session key, as 227 explained in Section 2.5. Binding is a copy of field of the same name 228 from the Archie-Response message, and confirms the target 229 addressing. MAC2 is a message authentication code computed over the 230 Archie Request's AuthID field, the Archie-Response's NonceP field, 231 followed by the prior Archie-Confirm fields, using the KCK as the key 232 and AES-CBC-MAC-96 as the MAC algorithm. Including the 233 Archie-Response's AuthID field binds the EAP Server's name to this 234 instance of the protocol, allowing the EAP Server and EAP Peer to form 235 a consistent view of the protocol instance participants. Including the 236 NonceP value in the MAC2 calculation also proves that the 237 Archie-Confirm is live if the EAP Peer randomly selects its nonce 238 value encrypted in the Archie-Response NonceP field. MAC2, if valid, 239 authenticates the Archie-Confirm message and hence the EAP Server to 240 the EAP Peer. 242 The final message responds to the Archie-Confirm, and is called the 243 Archie-Finish message. The EAP Peer sends the Archie-Finish message to 244 the EAP Server in an EAP-Response message of type Archie. This message 245 consists of SessionID and MAC3. SessionID is the same value as in the 246 Archie-Request, Archie-Response, and Archie-Confirm messages for this 247 instance of the EAP-Archie protocol. MAC3 is the AES-CBC-MAC-96 digest 248 of the fields of the Archie-Finish prior to the MAC3 field. This 249 message is defined since every EAP-Request requires an 250 EAP-Response. The Archie-Finish message includes MAC3 to prevent 251 undetected forgery attacks, and allows the EAP Server to avoid some 252 denial-of-service attacks. 254 2.2. Retry Behavior 256 As with other EAP protocols, the EAP Server is responsible for retry 257 behavior. This means that if the EAP Server does not receive a reply 258 from the peer, it MUST resend the EAP-Request for which it has not yet 259 received an EAP-Response. However, the EAP Peer MUST NOT resend 260 EAP-Response messages without first being prompted by the EAP Server. 262 For example, if the initial Archie-Start message sent by the EAP 263 Server were to be lost, then the EAP Peer would not receive this 264 message, so would not respond to it. As a result, the EAP Server would 265 resend the Archie-Start message. Once the EAP Peer received the 266 Archie-Start message, it would send an EAP-Response conveying the 267 Archie-Response message. If the EAP-Response were to be lost, then the 268 EAP Server would resend the initial Archie-Start, triggering the EAP 269 Peer to resend the EAP-Response. 271 As a result, it is possible that an EAP Peer will receive duplicate 272 EAP-Request messages, and may send duplicate EAP-Responses. Both the 273 EAP Peer and the EAP Server should be engineered to handle this 274 possibility. 276 2.3. Fragmentation 278 EAP-Archie does not require fragmentation. 280 2.4. Identity Verification 282 EAP-Archie always performs mutual authentication. EAP-Archie uses the 283 Archie Key, a 512-bit long-lived pre-shared secret, identified to the 284 EAP Peer by the EAP Server's NAI, and to the EAP Server by the EAP 285 Peer's NAI. EAP-Archie uses the first 16 octets (first 128 bits) of 286 the pre-shared secret serves as an authentication key, called the KCK. 288 The EAP Server considers the EAP Peer successfully authenticated if 289 MAC1 from the Archie-Response message is valid. An EAP Server 290 implementation of EAP-Archie MUST silently discard any EAP-Response 291 messages of type Archie it receives with invalid MAC1 field. 293 Similarly, the EAP Peer considers the EAP Server authenticated if the 294 MAC2 value from the Archie-Confirm message is valid. An EAP Peer 295 implementation of EAP-Archie MUST silently discard any EAP-Request 296 messages of type Archie it receives with invalid MAC2 field. 298 The EAP Server MAY require that the Binding field from the 299 Archie-Response message be consistent with the verified identity and 300 the NAS in use. For instance, the Binding might identify the MAC 301 address of the EAP Peer. If it knows the proper value for this, the 302 EAP Server MAY declare the message a forgery if this MAC address does 303 not match the EAP Peer's reported NAI. 305 2.5. Key Derivation 307 Each instance of EAP-Archie constitutes a session, and derives an EAP 308 Master Key (EMK) from the KDK portion of the long-lived pre-shared 309 secret. The derived keying material consists of 32 octets (256 310 bits). This section describes how the EMK is derived. It also 311 describes how to derive a Transient EAP Key (TSK), used as a session 312 oriented authorization token to protect a channel between the EAP Peer 313 and NAS. 315 EAP-Archie relies on the Archie Key. EAP-Archie uses the second 16 316 octets (second 128 bits) of the pre-shared secret as a key encryption 317 key, or KEK, and it uses the final 32 octets (512 bits) of the 318 pre-shared key as a key derivation key, or KDK. 320 When using EAP-Archie, the EAP Peer selects a random value called 321 PeerNonce, wraps it using the AES Key Wrap algorithm under the KEK to 322 produce a field called NonceP, and sends NonceP to the EAP Server in 323 the Archie-Response message. PeerNonce is 256-bits. The EAP Server 324 uses KEK and the AES Key Wrap algorithm to recover PeerNonce. 326 Similarly, the EAP Server selects a random value called AuthNonce, 327 wraps it using the AES Key Wrap algorithm under the KEK to produce a 328 field called NonceA, and sends NonceA to the EAP Peer in the 329 Archie-Confirm message. AuthNonce is 256 bits. The EAP Peer uses the 330 KEK and the AES Key Wrap algorithm to recover AuthNonce. 332 Once both the EAP Server and Peer have both AuthNonce and PeerNonce, 333 they derive the EMK using the KDK, AuthNonce, PeerNonce, and the text 334 string "Archie session key", using a function called the Archie-PRF: 336 EMK = Archie-PRF(KDK, 337 AuthNonce | PeerNonce | "Archie session key", 338 32) 340 Here, the "|" symbol denotes string concatenation. Section 3.2 defines 341 the Archie-PRF. The parameter "32" indicates that the EMK consists of 342 32 octets. 344 Note that the AES Key Wrap has its own internal integrity 345 check. Potential evidence of compromise of the KCK is the AES Key Wrap 346 integrity check of either NonceP or NonceS fails but the MAC of the 347 Archie message delivering the nonce is valid. 349 The derived EMK is uniquely identified by the 5-tuple , where AuthID is the NAI the EAP 351 Server presents in the Archie-Request message, PeerID is the NAI the 352 EAP Peer presents in the Archie-Response message, SessionID is the 353 random challenge value the EAP Server presents in the Archie-Request 354 message, and where AutheNonce and PeerNonce are as above. 356 The Archie EMK can be used to derive new cryptographic keys for use in 357 other contexts, e.g., PPP encryption or to protect an 802 358 link. Following [10], the way to accomplish this is as follows: 360 TSK = Archie-PRF(SK, AddrS | AddrP | "Archie transient EAP key", 361 128) 363 The derived key TSK is the first 128 octets of the output of the 364 Archie_PRF. In the language of [10], the first 32 octets of the TEK 365 is called the PMK. 367 3. Cryptographic Algorithms 369 3.1. AES-CBC-MAC-128 and AES-CBC-MAC-96 371 This section reviews the definition of the AES-CBC-MAC. 373 Let K denote an AES key, and let AES-Encrypt denote the AES encrypt 374 primitive. The AES-CBC-MAC-128 of a string S is defined using the 375 following steps: 377 a. Let L denote the length of S in octets. Let L' = L + p, where p 378 is the unique integer 0 <= p < 16 needed so that L' is a 379 multiple of 16. 380 b. Let n = L'/16, and partition S into substrings, such that 381 S = S[1] S[2] ... S[n-1] S'[n], with S[1], S[2], ..., S[n-1] 382 consisting of 16 octets each and S'[n] consisting of 16 octets 383 if p is 0 and 16-p octets otherwise. Let S[n] = S'[n]0^p, where 384 0^p denotes p octets of zero pad. 385 c. Set IV to 16 zero octets. 386 d. For i = 1 to n do 387 IV = AES-Encrypt(K, S[i] XOR IV) 388 e. Return IV. 390 The EAP-Archie protocol uses a variant of AES-CBC-MAC-128 called 391 AES-CBC-MAC-96. This variant differs from the AES-CBC-MAC-128 392 described above in only step e, which it replaces by: 394 e'. Return the first 12 octets of IV. 396 Note that any padding added in step b is used to compute the MAC value 397 only, and is never sent as part of an EAP-Archie message. 399 3.2. The Archie-PRF 401 This section defines the Archie-PRF function. 403 Let K denote a key, and let Length denote the number of octets 404 desired. The Archie-PRF of a string S is defined by the following 405 steps: 407 a. Output is initialized to the null string. 408 b. For i = 1 to (Length+15)/16 do 409 Output = Output | AES-CBC-MAC-128(K, i | S | Length) 410 c. Return first Length octets of Output 412 In step b, the loop index i and the Length are encoded as 32-bit 413 big-Endian unsigned integers. 415 4. Detailed Description of EAP-Archie 417 4.1. Archie Message Format Summary 419 A summary of the Archie Request/Response packet format is shown 420 below. The fields are transmitted from left to right. 422 0 1 2 3 423 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Code | Identifier | Length | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Type | Msg ID | Data | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 429 | Data ... 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Code 434 1 - Request 435 2 - Response 437 Identifier 439 The identifier field is one octet and aids in matching 440 responses with requests. 442 Length 444 The Length field is two octets and indicates the length of the 445 EAP message including the Code, Identifier, Length, Type, and 446 Data fields. Octets outside the range of the Length field 447 should be treated as Data Link Layer padding and should be 448 ignored on reception. 450 Type 452 TBS - Archie 454 MsgID 455 1 - Archie-Request 456 2 - Archie-Response 457 3 - Archie-Confirm 458 4 - Archie-Finish 460 Data 462 The format of the Data field is determined by the Code and 463 MsgID fields. 465 This specification refers to the Code, Identifier, and Length fields 466 as the EAP Header. The EAP Header is a standard construction starting 467 every EAP message. It is implemented by EAP proper and not necessarily 468 by EAP-Archie. 470 This specification uses the notation of the message name, followed by 471 a parenthesized range list to indicate a substring of message included 472 in some cryptographic computation. For example, 474 Archie-Request(Type...AuthID) 476 denotes the octet string formed by taking the Type through the AuthID 477 fields of an Archie Request message. This includes the Type, MsgID, 478 Reserved, NaiLength, SessionID, and AuthID fields of the Archie 479 Request message. To refer to a single field in an EAP-Archie message 480 we use the same notation but with a single argument instead. For 481 instance 483 Archie-Response(NonceP) 485 denotes the NonceP field of an Archie-Response message. 487 4.2. Archie-Request Message 489 A summary of the Archie-Request message format is shown below. The 490 fields are transmitted from left to right. 492 0 1 2 3 493 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Code | Identifier | Length | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Type | MsgID | Reserved | NaiLength | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 . . 500 . . 501 | AuthID (256 octets) | 502 . . 503 . . 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 . . 506 . . 507 | SessionID (32 octets) | 508 . . 509 . . 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 Code 514 1 516 Identifier 518 The Identifier field is one octet and aids in matching 519 Responses with Requests. The Identifier field MUST be changed 520 on each Request message. 522 Length 524 The Length field is two octets and indicates the length of the 525 EAP message including the Code, Identifier, Length, Type, 526 MsgID, Reserved, NaiLength, AuthID, and SessionID fields. Its 527 value is 296. 529 Type 531 TBS - Archie 533 MsgID 535 1 - Archie-Request 537 Reserved 538 Set to 0 on send, ignored on receive 540 NaiLength 542 The number of octets used in the AuthID field. The value 0 means 543 the AuthID is the full 256 octets in length. 545 AuthID 547 The AuthID field gives the NAI the EAP Server uses to identify 548 itself to the EAP Peer. The first NaiLength octets of this field 549 are non-zero, while any remaining octets of the AuthID field 550 MUST be zero on transmit and ignored on receive. 552 SessionID 554 The SessionID field is 32 octets. This value represents the 555 session id for this instance of the EAP-Archie protocol. 557 4.2.1. Archie-Request Message Transmission 559 The EAP Server creates a new session to initiate a new instance of 560 EAP-Archie. The Archie-Request is the first message of the new 561 session. To construct and send an Archie-Request, the EAP Server 562 performs the following steps: 564 o Sets the Code field to 1. 566 o Generates a new EAP Identifier value for the Identifier field. 568 o Sets the Length field to 296, encoded in network byte order. 570 o Sets the Type field to Archie. 572 o Sets the MsgID field to 1 (Archie-Request). 574 o Sets the Reserved field to 0. 576 o Sets the NaiLength field value to the number of actual octets 577 of the AuthID field, excluding any zero pad. If the AuthID is 578 256 octets, then the EAP Server sets the NaiLength to 0 579 instead. 581 o Inserts the NAI the EAP Server uses to identify itself into the 582 first NaiLength octets of the AuthID field and zeros any unused 583 octets remaining in the field. 585 o Generates a 32 octet value and inserts this into the 586 SessionID field. The SessionID value MUST be random, as it 587 the security of the protocol requires it be unpredictable. This 588 also means that with very high probability the SessionID of 589 every Archie Request will be different. 591 The EAP Server sends the Archie-Request message to the EAP Peer. The 592 EAP Server SHOULD set a timer and a retry count to detect lost 593 messages. The EAP Server MUST save whatever state it needs to verify 594 whether an Archie-Response message received later is a valid response 595 to this Archie-Request. In particular, the saved state SHOULD include 596 the SessionID value, to identify other messages that are a part of 597 this session. 599 4.2.2. Archie-Request Message Reception 601 If the EAP Peer does not expect to receive an Archie-Request message, 602 it MUST silently discard the Request. 604 An Archie-Request message is an EAP-Request of Type Archie, Length 296 605 octets, and MsgID 1. An EAP Peer MUST silently discard EAP-Requests of 606 Type Archie and MsgID 1 of a different length. An Archie-Request 607 responds to no other message, so always initiates a new session. Note 608 that it is not a protocol error for multiple Archie-Request messages 609 with different SessionID to be outstanding simultaneously. 611 The EAP Peer can identify a retried Archie-Request by matching the 612 Archie-Request AuthID and SessionID fields against those received in a 613 prior Archie-Request whose Archie-Response is still unacknowledged by 614 an Archie-Confirm message. When interpreting the AuthID field, the EAP 615 Peer MUST ignore any AuthID characters beyond the first NaiLength 616 octets in the field. If the EAP Peer receives an Archie-Request 617 matching an outstanding Archie-Response, it MUST retransmit its 618 Archie-Response if it wants to authenticate via Archie. 620 If the EAP Peer does not have an Archie-Response outstanding, i.e., if 621 this represents a new protocol instance, then the Peer MUST first 622 attempt to match the AuthID field value against the name of some EAP 623 Server in its database of authorized EAP Servers. If the EAP Peer does 624 not recognize the name, then it MUST NOT respond to the message with 625 an Archie-Response message. In this case, the EAP Peer MAY wait for 626 another Archie-Request message, or it may terminate the 627 authentication. In either case, if a database entry for the EAP 628 Server's NAI cannot be found, the EAP Peer silently discards the 629 alleged Archie-Request message. 631 If the EAP Peer locates a database entry for the EAP Server's NAI, 632 then it MAY choose to authenticate using EAP-Archie. In this case, it 633 MUST create a new session and respond with an Archie-Response message, 634 and for this session the EAP Peer MUST select the Archie Key it 635 associates with this NAI. 637 4.3. Archie-Response Message 639 A summary of the Archie-Response message format is shown below. The 640 fields are transmitted from left to right. 642 0 1 2 3 643 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Code | Identifier | Length | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Type | MsgID | Reserved | NaiLength | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 . . 650 . . 651 | SessionID (32 octets) | 652 . . 653 . . 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 . . 656 . . 657 | PeerID (256 octets) | 658 . . 659 . . 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 . . 662 . . 663 | NonceP (40 octets) | 664 . . 665 . . 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 . . 668 . . 669 | Binding (516 octets) | 670 . . 671 . . 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | | 674 | MAC1 (12 octets) | 675 | | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 Code 679 2 681 Identifier 683 The Identifier field is one octet and MUST match the Identifier 684 field from the corresponding request. 686 Length 688 The Length field is two octets and indicates the length of the 689 EAP message including the Code, Identifier, Length, Type, 690 MsgID, Reserved, NaiLength, PeerID, NonceP, Binding, and MAC1 691 fields. Its value is 864. 693 Type 695 TBS - Archie 697 MsgID 699 2 - Archie Response 701 Reserved 703 Set to 0 on send, ignored on receive. 705 NaiLength 707 The number of octets used in the PeerID field. The value 0 means 708 the PeerID is the full 256 octets in length. 710 SessionID 712 The SessionID field is 32 octets. 714 PeerID 716 The PeerID field gives the NAI the EAP Peer uses to identify 717 itself to the EAP Server. The first NaiLength octets of this 718 field are non-zero, while any remaining octets of the PeerID 719 field MUST be zero on transmit and ignored on receive. 721 NonceP 722 The NonceP field is 40 octets, conveying the value of a 32-octet 723 nonce selected by the EAP Peer and encrypted using AES key wrap 724 under the KEK portion of the Archie Key. 726 Binding 728 The Binding field is 516 octets. It has its own internal 729 structure: 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | BType | Slength | PLength | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 . . 735 . . 736 | AddrS (256 octets) | 737 . . 738 . . 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 . . 741 . . 742 | AddrP (256 octets) | 743 . . 744 . . 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 BType 749 Btype identifies the type of address in the binding 750 structure. The value of this subfield is an Address Family 751 Number as defined by the IANA Assigned Numbers database. 753 SLength 755 The number of octets of addressing information the AddrS 756 Subfield contains. The value 0 is reserved for addressing 757 Information which is 256 octets in length. 759 PLength 761 The number of octets of addressing information the AddrP 762 Subfield contains. The value 0 is reserved for addressing 763 Information which is 256 octets in length. 765 AddrS 766 AddrS identifies address of the party with whom the EAP Peer 767 wants to communicate, typically a NAS device. This field 768 assumes a different format depending of the value of the 769 BType field. The AddrS subfield uses the standard encoding 770 for the address of its BType. The sender SHALL zero pad any 771 unused AddrS subfield octets. 773 AddrP 775 AddrP identifies address the EAP Peer wants to use when 776 communicating with the targeted system, typically a NAS 777 device. This field assumes a different format depending of 778 the value of the BType field. The formatting rules for the 779 AddrS field apply to this field verbatim. The sender SHALL 780 zero pad any unused AddrS subfield octets. 782 The Binding field allows the EAP Peer to bind the derived TSK to 783 a particular pair of addresses. This helps identify when the TSK 784 is being used in an unauthorized context. In particular, the 785 Bindings field are the EAP Peer's request for a TSK for use 786 between the set of addresses the Bindings field specifies. 788 MAC1 790 The MAC1 field is 12 octets. The value of this field MUST be the 791 AES-CBC-MAC-96 of the AutheID field from the Archie-Request 792 message, followed by the Archie-Response message, less the EAP 793 Header and MAC1 field: 795 MAC1 = AES-CBC-MAC-96(KCK, Archie-Request(Type...AuthID) | 796 Archie-Response(Type...Binding)) 798 where "|" denotes concatenation. 800 4.3.1. Archie-Response Message Transmission 802 The EAP Peer performs the following steps to construct and send an 803 Archie-Response message: 805 o Sets the Code field to 2. 807 o Sets the EAP Identifier value to that in the EAP-Request 808 message to which this message responds 810 o Sets the Length field to 864, encoded in network byte order. 812 o Sets the Type field to Archie. 814 o Sets the MsgID field to 2 (Archie-Response). 816 o Sets the Reserved field to 0. 818 o Sets the NaiLength field value to the number of actual octets 819 of the PeerID field, excluding any zero pad. If the PeerID is 820 256 octets, then the EAP Server sets the NaiLength to 0 821 instead. 823 o Inserts the NAI the EAP Peer uses to identify itself into the 824 first NaiLength octets of the PeerID field, zeroing any unused 825 octets in the field. 827 o Copies the SessionID field of the Archie-Request message 828 into the SessionID field of the Archie-Response. 830 o Creates the NonceP field as follows: 832 -- Generates a 32 octet (256-bit) random or pseudo-random value 833 called PeerNonce, to be used as the EAP Peer's nonce for 834 this session. 836 -- Uses the AES key wrap algorithm [6] under the KEK portion of 837 the Archie Key for this protocol instance, to encrypt 838 PeerNonce. 840 -- Copies the encrypted PeerNonce into the NonceP field. 842 o Creates the Bindings field as follows: 844 -- Encodes the Address Family identifier used as the Bindings 845 field BType value. The EAP Peer encodes this in network 846 byte order. 848 -- Sets the SLength subfield to the number of octets used 849 in the AddrS subfield, with the convention that 0 850 designates that the AddrS is 256 octets long. 852 -- Sets the PLength subfield to the number of octets used 853 in the AddrP subfield, with the convention that 0 854 designates that the AddrP is 256 octets long. 856 -- Encodes the address of BType its NAS will use with the 857 derived TEK in the first SLength octets of the AddrS 858 subfield, zeroing the remaining unused octets of the 859 subfield. 861 -- Encodes the address of BType it will use for itself with the 862 derived TEK in the first PLength octets of the AddrP 863 subfield, zeroing the remaining unused octets of the 864 subfield. 866 o Creates the MAC1 field by using the KCK portion of the 867 selected Archie key to compute the AES-CRC-MAC-96 of 868 the concatenation of (1) the Type, MsgID, Reserved, NaiLength, 869 and AuthID field from the Archie-Request to which the EAP Peer 870 is responding and (2) the Archie-Response, less its EAP Header 871 and MAC1 field. This includes the Type, MsgID, Reserved, 872 NaiLength, SessionID, and AuthID fields from the Archie 873 Request, and the Type, MsgID, Reserved, NaiLength, SessionID, 874 PeerID, NonceP, and Bindings fields from the Archie-Response. 876 The EAP Peer sends the completed Archie-Response message to the EAP 877 Server. The EAP Peer SHOULD set a timer bounding the time it will wait 878 to receive a valid Archie-Confirm message replying to its Archie 879 Response. The EAP Peer MUST save whatever state it needs to verify 880 whether an Archie-Confirm message received later is a valid response 881 to this Archie-Response message. 883 4.3.2. Archie-Response Message Reception 885 An Archie-Response message is an EAP-Response of Type Archie, Length 886 864 octets, MsgID 2, and with the EAP Identifier field of an 887 outstanding EAP-Request and SessionID of the corresponding 888 authentication instance. An EAP Server MUST silently discard 889 EAP-Responses of Type Archie and MsgID 2 of a different length, as 890 well as one whose Identifier field does not correspond to any 891 EAP-Request, as well as an Archie-Response whose SessionID fails to 892 match an active authentication instance. If the EAP Server receives an 893 unexpected Archie-Response message, it MUST silently discard the 894 Response. 896 Since an Archie-Response replies to an Archie-Request message, its 897 reception makes sense only in one of two contexts: either the EAP 898 Server has an Archie-Request outstanding, and this Archie-Response 899 might be a response to that request, or else the Archie-Response might 900 a response to a retried Archie-Request that was retried before a 901 Archie-Response was received. In the latter case it is possible that 902 the EAP Server might have received a prior Archie-Response and so has 903 an Archie-Confirm outstanding. 905 If the EAP Server has an Archie-Confirm outstanding, i.e., if it has 906 already received an Archie-Response, it can identify whether this 907 Archie-Response is a retry by verifying the message as being the same 908 octet string as the original Archie-Response, if valid, received 909 earlier. If the SessionID is the same but any other field after the 910 EAP header differs from the earlier Archie-Response, the retried 911 Archie-Response is invalid. The EAP Server MUST silently discard an 912 alleged the retried Archie-Response in this case. Otherwise, the 913 Archie-Response represents a valid reply, and the EAP Server SHOULD 914 retransmit its Archie-Confirm message. 916 If the Archie-Response is not a retry, i.e., if the EAP Server has not 917 yet received an Archie-Response replying to its Archie-Request, then 918 it MUST first attempt to locate the PeerID field value in its database 919 of authorized EAP Peers. If the EAP Server does not recognize the 920 PeerID, then it MUST silently discard the message. If the EAP Server 921 locates the PeerID in its database, then it tentatively selects the 922 Archie Key corresponding to the PeerID for this session. The EAP 923 Server uses the KCK portion of the Archie Key to verify the MAC1 field 924 of the Response. It does this by computing the AES-CBC-MAC-96 over the 925 Archie-Request, less EAP Header, for this SessionId, followed by the 926 Archie-Response, less EAP Header and MAC1 field. 928 MAC = AES-CBC-MAC-96(KCK, Archie-Request(Type...AuthID) | 929 Archie-Response(Type...Bindings)) 931 Specifically, the EAP Server computes the MAC value over concatenation 932 of (1) the Type, MsgID, Reserved, NaiLength, and AuthID fields from 933 the Archie-Request, and (2) the Archie-Response, less its EAP Header 934 and MAC1 field, which includes the Type, MsgID, Reserved, NaiLength, 935 SessionID, PeerID, NonceP, and Bindings fields from the 936 Archie-Response. 938 If the computed AES-CBC-MAC-96 value MAC is a different octet string 939 than the MAC1 field value, then the EAP Server MUST silently discard 940 the message as a forgery, and the EAP Server dissolves the binding of 941 the selected Archie Key and the authentication instance. If the 942 computed AES-CBC-MAC-96 value is identical to the MAC1 field, then the 943 message is authentic, and the EAP Server makes the selected key a 944 permanent part of this authentication instance. 946 If it tracks the addressing information in the Bindings field, the EAP 947 Server SHOULD verify the validity of the Bindings. In this case, the 948 EAP Server SHOULD verify that the AddrP field is an expected address 949 for the EAP Peer, and that the AddrS field is an expected address for 950 the NAS. If either fails to correspond in the expected way, the EAP 951 Server MAY suspect a man-in-the-middle attack and deny the 952 authentication. Alternately, it may report the discrepancy in the 953 Archie-Confirm message as described in Section 4.4. 955 If it verifies that the Archie-Response is valid, the EAP Server 956 obtain the PeerNonce value by unwrapping the NonceP field by using the 957 AES key wrap algorithm [6] under the KEK portion of the Archie Key for 958 this session. If the key unwrap fails, the EAP Server should log an 959 alert and silently discard the message; this is a strong indication 960 that the Archie Key has been compromised and needs to be 961 replaced. Otherwise, the EAP Server MUST reply to the Archie-Response 962 by constructing and returning an Archie-Confirm message. 964 4.4. Archie-Confirm Message 966 A summary of the Archie-Confirm message format is shown below. The 967 fields are transmitted from left to right. 969 0 1 2 3 970 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | Code | Identifier | Length | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Type | MsgID | Reserved | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 . . 977 . . 978 | SessionID (32 octets) | 979 . . 980 . . 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 . . 983 . . 984 | NonceA (40 octets) | 985 . . 986 . . 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 . . 989 . . 990 | Binding (516 octets) | 991 . . 992 . . 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | | 995 | MAC2 (12 octets) | 996 | | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 Code 1001 1 1003 Identifier 1005 The Identifier field is one octet and aids in matching 1006 Responses with Requests. The Identifier field MUST be changed 1007 on each Request message. 1009 Length 1011 The Length field is two octets and indicates the length of the 1012 EAP message including the Code, Identifier, Length, Type, MsgID, 1013 Reserved, SessionID, NonceA, Binding, and MAC2 fields. Its value 1014 is 608. 1016 Type 1018 TBS - Archie 1020 MsgID 1022 3 - Archie-Confirm 1024 Reserved 1026 Set to 0 on transmit, value ignored on receive 1028 SessionID 1030 The SessionID field is 32 octets. 1032 NonceA 1034 The NonceA field is 40 octets, which is a 32-octet random value 1035 encrypted by the AES key wrap under the KEK portion of the 1036 Archie Key. 1038 Binding 1040 The Binding field is 516 octets. It is encoded as in the 1041 Archie-Response message. The EAP Server SHOULD copy the value of 1042 this field from the Binding field of the Archie-Response message 1043 for this authentication instance. The EAP Server MAY alter the 1044 AddrS or AddrP values to indicate something wrong with the 1045 Archie-Response message Binding values (e.g., the AddrS MAC 1046 address does not belong to the NAS that forwarded the 1047 Archie-Response message), but the Archie-Confirm Binding BType 1048 value MUST be identical to that of the Archie-Response Binding 1049 BType. 1051 MAC2 1053 The MAC2 field is 12 octets. The value of this field MUST be the 1054 AES-CBC-MAC-96 of the (1) the Type, MsgID, Reserved, NaiLength, 1055 and AuthID field from the Archie-Request this protocol instance, 1056 followed by the NonceP field from the Archie-Response for this 1057 session, followed by this Archie Confirm, less its EAP Heaer and 1058 MAC2 field. Specifically, MAC2 is computed over the Type, MsgID, 1059 Reserved, NaiLength, and AuthID from the Archie-Request, the 1060 NonceP from the Archie-Request, and the Type, MsgID, Reserved, 1061 SessionID, NonceA, and Binding fields of this Archie-Confirm, 1062 using the KCK portion of the long-lived pre-shared secret as the 1063 authentication key. 1065 4.4.1. Archie-Confirm Message Transmission 1067 The EAP Server performs the following steps to construct and send an 1068 Archie-Confirm message: 1070 o Sets the Code field to 1. 1072 o Generates a new EAP Identifier value for the Identifier field. 1074 o Sets the Length field to 608, encoded in network byte order. 1076 o Sets the Type field to Archie. 1078 o Sets the MsgID field to 3 (Archie-Confirm). 1080 o Sets the Reserved field to 0. 1082 o Copies the SessionID field for this authentication instance 1083 into the SessionID field of the Archie-Confirm. 1085 o Creates the NonceA field, using the following steps: 1087 -- Generates a 32 octet (256-bit) random or pseudo-random value 1088 to be used as the EAP Server's nonce for this session. 1090 -- Uses the KEK portion of the selected Archie long-lived key 1091 with the AES Key Wrap algorithm to encrypt the EAP Server's 1092 nonce value. The resulting string is 40 octets. 1094 -- Copies the encrypted EAP Peer nonce into the NonceP field. 1096 o Copies the Bindings field from the Archie Response into the 1097 Bindings field of the Archie-Confirm. The EAP Server MAY alter 1098 The value of either the Bindings AddrS or AddrP subfields if 1099 either fails to correspond with the EAP Server's expectation. 1101 o Creates the MAC2 field by using the KCK portion of the 1102 selected long-lived Archie key to compute the AES-CRC-MAC-96 of 1103 the concatenation of the (1) Type, MsgID, Reserved, NaiLength, 1104 and AuthID fields of the Archie-Request, (2) the NonceP field 1105 of the Archie-Response, and (3) this Archie-Confirm, less the 1106 EAP header and MAC2 fields, i.e., Type, MsgID, Reserved, 1107 SessionID, NonceA, and Bindings fields. 1109 The EAP Server sends the completed Archie-Confirm message to the EAP 1110 Peer. The EAP Server SHOULD set a timer and a retry count to detect 1111 lost messages. 1113 4.4.2. Archie-Confirm Message Reception 1115 An Archie-Confirm is an EAP-Request of Type Archie, Length 608 octets, 1116 MsgID 3, and SessionID of an active authentication instance. An EAP 1117 Peer MUST silently discard EAP-Requests of Type Archie and MsgID 3 of 1118 a different length, as well as an Archie-Confirm whose SessionID fails 1119 to match the authentication instance. If the EAP Peer receives an 1120 unexpected Archie-Confirm message, it MUST silently discard the 1121 Confirm. 1123 Since an Archie-Confirm replies to an Archie-Response message, its 1124 reception makes sense only in one of two contexts: either the EAP Peer 1125 has an Archie-Response outstanding, and the Archie-Confirm might be a 1126 reply to that Archie-Response, or else the Archie-Confirm might a 1127 reply to the EAP Peer's own reply to a retried Archie-Request. In the 1128 latter case it is possible that the EAP Peer might have received a 1129 prior Archie-Confirm and so has complete EAP-Archie 1130 authentication. Hence it is necessary for the EAP Peer to continue to 1131 be able to respond to retried Archie-Confirm messages received for 1132 some period after receiving an initial Archie-Confirm. 1134 If the EAP Peer has already completed EAP-Archie authentication by 1135 sending an Archie-Finish, it can identify a retried Archie-Confirm by 1136 matching the Archie Confirm against a prior one received with a valid 1137 MAC2 field. If the Archie-Confirm, less EAP header, consists of the 1138 same octet string as the earlier valid Archie-Confirm, then the EAP 1139 Peer SHOULD retransmit its Archie-Finish message. The EAP Peer MUST 1140 silently discard an alleged retried Archie-Confirm if any of the 1141 octets differ from the earlier Archie Confirm. 1143 If the EAP Peer locates the SessionID among its active Archie 1144 authentication instances, then it uses the KCK portion of the Archie 1145 Key to verify the MAC2 field of the Archie-Confirm. It does this by 1146 computing the AES-CBC-MAC-96 as follows: 1148 MAC = AES-CBC-MAC-96(KCK, Archie-Request(Type...AuthID) | 1149 Archie-Response(NonceP) | 1150 Archie-Confirm(Type...Bindings)) 1152 That is, it recomputes the MAC value over the Archie-Request Type, 1153 MsgID, Reserved, NaiLength, and AuthID fields from the Archie-Request 1154 for this session, followed by the NonceP value it sent in the 1155 Archie-Response for this session, followed by the Type, MsgID, 1156 Reserved, SessionID, NonceA, and Bindings values in the 1157 Archie-Confirm. If the computed MAC value is a different octet string 1158 than the received MAC2 field value, then the EAP Peer MUST silently 1159 discard the message as a forgery. If the computed MAC value is 1160 identical to the MAC2 field, then the message is authentic. 1162 If it verifies that the Archie Confirm is valid, the EAP Peer uses the 1163 KEK portion of the Archie Key for this session with the AES Key Wrap 1164 algorithm to obtain the EAP Server's nonce value by unwrapping the 1165 NonceA field. If recovery of the AuthNonce from the NonceA field fails 1166 due to an AES Key Wrap integrity check failure, the EAP Peer MUST log 1167 an error and break off the authentication; this is evidence that the 1168 Archie Key has been compromised. 1170 If the recovery of the AuthNonce value succeeds, the EAP Peer MUST 1171 implement one final validity check. If the EAP Server has altered the 1172 addressing information in the Bindings field from that sent in the 1173 Archie Response, then the EAP Peer SHOULD take this as a report of a 1174 man-in-the-middle attack and end its association with the NAS. 1176 If the Archie-Confirm is valid, then the EAP Peer derives the EMK and 1177 TEK as described in 2.5, and replies to the Archie-Confirm by 1178 constructing and returning an Archie-Finish message. 1180 4.5. Archie-Finish Message 1182 A summary of the Archie-Finish message format is shown below. The 1183 fields are transmitted from left to right. 1185 0 1 2 3 1186 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | Code | Identifier | Length | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Type | MsgID | Reserved | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 . . 1193 . . 1194 | SessionID (32 octets) | 1195 . . 1196 . . 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | | 1199 | MAC3 (12 octets) | 1200 | | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 Code 1205 2 1207 Identifier 1209 The Identifier field is one octet and MUST match the Identifier 1210 field from the corresponding request. 1212 Length 1214 The Length field is two octets and indicates the length of the 1215 EAP message including the Code, Identifier, Length, Type, 1216 MsgID, Reserved, SessionID, and MAC3 fields. Its value is 52. 1218 Type 1220 TBS - Archie 1222 MsgID 1224 4 - Archie-Finish 1226 Reserved 1228 0 on send and ignored on receive 1230 SessionID 1231 The SessionID field is 32 octets. 1233 MAC3 1235 The MAC3 field is 12 octets. The value of this field MUST be the 1236 AES-CBC-MAC-96 of the Type, MsdID, Reserved, and SessionID fields of 1237 this Archie-Finish message, using the KCK portion of the Archie Key as 1238 the authentication key. 1240 4.5.1. Archie-Finish Message Transmission 1242 The EAP Peer performs the following steps to construct and send an 1243 Archie-Finish message: 1245 o Sets the Code field to 2. 1247 o Sets the EAP Identifier value to that in the EAP-Request 1248 message to which this message responds 1250 o Sets the Length field to 52, encoded in network byte order. 1252 o Sets the Type field to Archie. 1254 o Sets the MsgID field to 4 (Archie-Finish). 1256 o Sets the Reserved field to 0. 1258 o Copies the SessionID field for this Archie authentication 1259 instance into the SessionID field of the Archie-Confirm. 1261 o Creates the MAC3 field by using the KCK portion of the 1262 Archie Key for this authentication instance to compute the 1263 AES-CRC-MAC-96 of the Type, MsgID, Reserved, and SessionID 1264 fields of this Archie-Finish message. 1266 The EAP Peer sends the completed Archie-Finish message to the EAP 1267 Server. The EAP Peer SHOULD set a timer bounding the time it will 1268 continue wait to receive a retried Archie-Confirm message. 1270 4.5.2. Archie-Finish Message Reception 1272 An Archie-Finish message is an EAP-Response of Type Archie, Length 52 1273 octets, MsgID 4, with the EAP Identifier field of an outstanding 1274 EAP-Request and SessionID of the corresponding authentication 1275 instance. An EAP Server MUST silently discard EAP-Responses of Type 1276 Archie and MsgID 4 of a different length, as well as one whose 1277 Identifier field does not correspond to any EAP-Request, as well as an 1278 Archie-Finish whose SessionID fails to match the authentication 1279 instance. If the EAP Server receives an unexpected Archie-Finish 1280 message, it MUST silently discard the Finish. 1282 If the EAP Server is waiting for an Archie-Finish, then it uses the 1283 KCK portion of the Archie Key to verify the MAC3 field of the 1284 Archie-Finish. It does this by computing the AES-CBC-MAC-96 over 1285 Archie-Finish message less EAP Header, i.e., 1287 MAC = AES-CBC-MAC-96(KCK, Archie-Finish(Type...SessionID)) 1289 If the computed MAC value is a different octet string than the 1290 received MAC3 field value, then the EAP Server MUST silently discard 1291 the message as a forgery. If the computed MAC value is identical to 1292 the MAC3 field, then the message is authentic. and the EAP Server 1293 makes the selected key a permanent part of this authentication 1294 instance. 1296 If it verifies that the Archie-Finish is valid, the EAP Server uses 1297 the KDK portion of the Archie Key to derive the EMK and TEK as 1298 described in 2.5. 1300 5. IANA Considerations 1302 This document introduces one new IANA considerations. 1304 It requires IANA to allocate a new EAP Type for EAP-Archie. 1306 6. Security Considerations 1308 6.1. Intended use 1310 EAP-Archie is designed to be useful over an insecure network. The 1311 protocol implements mechanisms to protect an EAP-Archie exchange from 1312 both active and passive attack. 1314 6.2. Mechanism 1316 EAP-Archie relies on a 512-bit pre-shared secret. The protocol does 1317 not restrict how the secret is constructed nor address how it comes 1318 into being. However, the protocol does not increase the entropy of the 1319 shared secret in any way; if the shared secret does not provide 1320 sufficient entropy, then any derived keys can have less entropy as 1321 well, and it may be possible to compromise the Archie exchange as 1322 well. 1324 6.3. Security Claims 1326 EAP-Archie provides: 1328 a. Conservative use of cryptography, 1329 b. Integrity protection, 1330 c. Replay protection, 1331 f. Man-in-the-middle resistance, 1332 d. Mutual authentication, 1333 e. Session formation, 1334 f. Consistent view, 1335 g. Peer liveness, 1336 h. Fresh key derivation, 1337 i. Key strength, 1338 j. Dictionary attack resistance, and 1339 g. Limited Denial-of-Service protection. 1341 6.3.1. Conservative use of Cryptography 1343 EAP-Archie uses AES as its sole cryptographic primitive. AES is 1344 believed to be a conservative choice of a block cipher. 1346 EAP-Archie uses AES is two ways: in the CBC-MAC construction and in 1347 the AES key wrap. The CBC-MAC construction results in a pseudorandom 1348 function if the underlying block cipher is a pseudorandom permutation 1349 [12]. Since it is standard to assume that AES effectively models a 1350 pseudorandom permutation, this makes AES-CBC-MAC safe to use as a MAC 1351 and for key derivation. It is also a standard assumption that the AES 1352 key wrap protects its wrapped contents from disclosure or alteration 1353 if the KEK has sufficient entropy and is not exposed. 1355 EAP-Archie uses message formats each of whose lengths are fixed and 1356 known a priori, meaning CBC-MAC is a safe construction if the 1357 underlying block cipher has not been compromised [12]. 1359 EAP-Archie's design provides strong key separation by dividing the 1360 Archie Key into three non-overlapping subkeys: the KCK, the KEK, and 1361 the KDK. EAP-Archie uses the KCK only for message authentication, the 1362 KEK for key encryption, and the KDK for message derivation. This 1363 property means that cryptanalytic progress against the KCK does not 1364 contribute any useful knowledge to make cryptanalytic progress against 1365 the KDK and KEK, and hence against the EMK. Similar, this separation 1366 guarantees that cryptographic progress against the EMK, KDK, or KEK 1367 contributes nothing to the analysis of the KCK. 1369 All nonces used by EAP-Archie are 256-bits and are specified as 1370 random. 1372 6.3.2. Integrity Protection 1374 EAP-Archie provides integrity protection of its messages by computing 1375 the AES-CBC-MAC-96 of each of the messages exchanged in a protocol 1376 instance, using the KCK of the pre-shared Archie Key as the MAC 1377 key. If the KCK is well chosen, then its 128-bit size precludes 1378 exhaustive search. The 96 bit MAC size protects the protocol from an 1379 active birthday attacks attempting to forge a packet in significantly 1380 fewer that 2^48 messages. AES used in CBC-MAC mode provide message 1381 integrity against all other forgery attacks provided AES is not broken 1382 [12]. Truncation of the AES-CBC-MAC to 96 bits helps protect the KCK 1383 from attack by examination of the protocol messages. 1385 6.3.3. Replay Protection 1387 EAP-Archie provides replay protection-that is, message 1388 freshness-through the SessionID and NonceP fields. 1390 If the EAP Server selects the SessionID randomly, then it is 1391 unpredictable and an adversary has one chance in 2^256 to guess its 1392 value. Since SessionID is included in each Archie Message, it is 1393 protected by the AES-CBC-MAC-96. The EAP Server will ignore Archie 1394 messages with SessionIDs that are not part of a current instance, and 1395 the AES-CBC-MAC-96 will allow the EAP Server detect attempts to alter 1396 the SessionID in Archie messages. This precludes an attacker from 1397 causing the EAP Peer to construct a useful dictionary of pre-computed 1398 Archie Response, Confirm, or Finish messages. 1400 EAP-Archie's use of NonceP for replay protection is similar but 1401 subtler. NonceP appears explicitly only in the Archie-Response 1402 message. However, the protocol requires the EAP Server to include the 1403 Archie-Response message in calculating the MAC2 value of the 1404 Archie-Confirm message. If the EAP Peer randomly selects the nonce 1405 encrypted as NonceP, an adversary has at most one chance in 2^256 in 1406 selecting the right NonceP value, so the EAP Peer can detect replayed 1407 Archie-Confirm messages by invalid MAC2 values. 1409 6.3.4. Man-in-the-Middle Attack Resistance 1411 The EAP-Archie design defends against man-in-the-middle attack against 1412 an instance of the Archie protocol itself if the KCK portion of the 1413 pre-shared key has sufficient entropy to resist cryptanalytic 1414 attack. This can be verified using the argument showing how EAP-Archie 1415 accomplishes mutual authentication: since the MAC1 value in the Archie 1416 Response message is over both SessionID and NonceP, it is not possible 1417 that the Archie-Response message could be interwoven from a different 1418 Archie protocol instance, so the EAP Server knows there can be no 1419 man-in-the-middle. Similarly, the MAC2 value in the Confirm message is 1420 computed over both the Archie-Response NonceP value and the body of 1421 the Confirm, so the EAP Peer may conclude that the Confirm has not 1422 been interleaved from a different Archie protocol instance. 1424 EAP-Archie defends against the man-in-the-middle attack against the 1425 TSK by including the addresses of the NAS and of the EAP Peer to the 1426 TSK. 1428 6.3.5. Mutual Authentication 1430 The Archie-Request, Archie-Response, and Archie-Confirm messages and 1431 the mapping of NAIs to a common pre-shared Archie Key accomplish 1432 mutual authentication. The Archie-Request message includes the EAP 1433 Server's NAI, and then includes this again in the MAC2 computation of 1434 its Archie-Confirm message. By assumption, the EAP Peer maps the NAI 1435 from the Archie-Request to the correct Archie Key. If it receives a 1436 valid Archie-Confirm message as part of the same protocol instance, 1437 then this authenticates the EAP Server to the EAP Peer, because the 1438 Archie-Confirm is fresh and has a correct MAC2, so could only be 1439 constructed by another entity that possesses the Archie Key, and 1440 because the Archie-Confirm format is different from any other protocol 1441 message and is only constructed by the EAP Server. By similar 1442 reasoning, the Archie-Response authenticates the EAP Peer to the EAP 1443 Server. 1445 6.3.6. Session Formation 1447 EAP-Archie accomplishes session formation by binding each particular 1448 protocol instance to a distinct pair. The 1449 5-tuple 1450 distinguishes this session from any other sessions if the EAP Server 1451 selects SessionID or its AuthNonce value randomly, or if the EAP Peer 1452 selects its PeerNonce randomly. The mutual authentication provided by 1453 the KCK portion of the pre-shared Archie key confirms this information 1454 as belonging to a single session entity. Similarly, the use of the KCK 1455 binds each EAP-Archie message to this session. Other session 1456 attributes are the derived EMK, the derived TEK, and the binding. The 1457 5-tuple can be used 1458 to name both the session and its EMK. Use of the EMK demonstrates 1459 authorization to participate in this session. 1461 6.3.6. Consistent View 1463 When an instance of EAP-Archie succeeds, both the EAP Server and EAP 1464 Peer share the same view of the participants in the protocol instance 1465 and their respective roles, and of the protocol state. Both parties 1466 view the EAP Server as the initiator of the protocol instance, and 1467 that it is named by the AuthID from the Archie-Request message. Both 1468 parties view the EAP Peer as the responder of the protocol instance, 1469 and that it is named by the PeerID from the Archie-Response message. 1471 6.3.7. Peer Liveness 1473 EAP-Archie's replay protection mechanism also assures both the EAP 1474 Server and EAP Peer that the other is live, if the period either is 1475 willing to wait for a message is bounded. 1477 6.3.6. Fresh Key Derivation 1479 EAP-Archie derives both fresh session keys EMK and TEK, as described 1480 in 2.5. The EMK is fresh if either the nonce decrypted from NonceP or 1481 NonceS is fresh. 1483 6.3.7. Key Strength 1485 The key strength of the derived EMK depends on the key derivation 1486 algorithm and on the strength of the KEK and KDK portions of the 1487 Archie Key. 1489 Since AES-CBC-MAC is a pseudorandom function if AES is a pseudorandom 1490 permutation, and since it is standard to assume that AES models a 1491 pseudorandom permutation, we can assume the derived keys will be 1492 strong if the KDK and KEK contain sufficient entropy. 1494 Since the KDK portion of the Archie Key is 256-bits, the KDK can 1495 contribute at most 256-bits of entropy to the EMK. 1497 While the AuthNonce and PeerNonce values used to derive the EMK are 1498 not public information, and while they combine to contribute 512 bits 1499 to the key derivation, they do not contribute 512 bits of entropy to 1500 the EMK. instead they are encrypted under the KEK portion of the 1501 Archie Key. Since the KEK is 128-bits, the nonces provide at most 1502 128-bits of entropy of the EMK. 1504 6.3.8. Dictionary Attack Resistance 1505 EAP-Archie provides resistance to on- and off-line dictionary attack 1506 if the KCK and KEK portions of the Archie Key have sufficient entropy 1507 to resist dictionary attack. 1509 6.3.10. Limited Denial-of-Service Resistance 1511 EAP-Archie provides limited denial-of-service resistance for the EAP 1512 server through the Archie-Finish message. If the EAP Server does not 1513 receive the Archie-Finish in a timely fashion, it can safely 1514 deallocate the corresponding session, thus freeing resources for 1515 another session. 1517 6.4. Key Hierarchy 1519 EAP-Archie uses a three-level key hierarchy. 1521 Level 1 is the Archie Key. This is a 512-bit key partitioned into 1522 three subkeys: the 128-bit key confirmation key (KCK) used for mutual 1523 authentication, the 128-bit key encryption key (KEK) used for nonce 1524 hiding, and the 256-bit key derivation key (KDK), which is used to 1525 derive the next level of the hierarchy. 1527 The second level of the hierarchy is the session key, called the 1528 EMK. The session key is derived from the KCK and the nonces using the 1529 Archie-PRF. Because it includes nonces in its derivation, the master 1530 key is fresh key if either nonce is random. The session key is known 1531 only to the EAP Peer and EAP Server. 1533 The final level of the hierarchy is the derived TEK, which are bound 1534 to particular pairs. The TEK is derived from the 1535 session key and addressing information of the EAP Peer and NAS. Since 1536 the EMK is fresh, the derived TEK is also fresh. 1538 6.5. Vulnerabilities 1540 The Archie Request message is vulnerable to spoofing. The Archie 1541 Request message could be MACed, but this would not eliminate the 1542 problem, as the first message of any session establishment protocol 1543 such as EAP-Archie is subject to replay. 1545 EAP-Archie cannot provide mutual authentication if the 128 most 1546 significant bits of the Archie Key are known to any party other than 1547 the EAP Server and the EAP Peer. 1549 EAP-Archie cannot guarantee that the derived session keys EMK and TSK 1550 are secure unless the last 256 bits of the Archie Key are known only 1551 to the EAP Server and the EAP Peer. 1553 If the Archie Key is derived from a low-entropy quantity such as a 1554 password, then EAP-Archie is subject to both on- and off-line 1555 dictionary attacks, and the EMK and TSK are both subject to off-line 1556 dictionary attack. 1558 To defend against on-line dictionary attack, implementations SHOULD 1559 keep track of the number of EAP-Archie messages received with invalid 1560 message authentication codes throughout the Archie Key lifetime, and 1561 SHOULD force the Archie Key to be changed if the number exceeds some 1562 threshold. 1564 The protocol is not secure unless SessionID is random in the sense of 1565 being unpredictable to any computationally bound adversary. If 1566 SessionID is not unpredictable, then an attacker can masquerade as the 1567 EAP Server to the EAP Peer for the purpose of generating the 1568 Archie-Response. The attacker can then replay the Archie-Response to 1569 the EAP Server at a later time, when the Server actually would issue 1570 SessionID. 1572 7. Acknowledgements 1574 EAP-Archie evolved from an earlier unpublished Archie protocol defined 1575 by Bob Moskowitz, Doug Whiting, Greg Chesson, Jesse Walker, Russ 1576 Housley, and Thomas Hardjono. Bernard Aboba, Doug Whiting, and Glen 1577 Zorn also contributed useful comments that led to the protocol's 1578 evolution. 1580 8. References 1582 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 1583 51, RFC 1661, July 1994. 1585 [2] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. 1586 Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, 1587 August 1996. 1589 [3] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1590 1994. 1592 [4] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication 1593 Protocol (EAP)", RFC 2284, March 1998. 1595 [5] National Bureau of Standards, "Secure Hash Standard", FIPS 1596 PUB 180-1 (April 1995). 1598 [6] Housley, R., "Advance Encryption Standard (AES) Key Wrap 1599 Algorithm", RFC 3394, September 2002. 1601 [7] Bradner, S., "Key words for use in RFCs to Indicate 1602 Requirement Levels", BCP 14, RFC 2119, March 1997. 1604 [8] IEEE STD 802.1X, Standards for Local and Metropolitan Area 1605 Networks: Port Based Access Control, June 14, 2001 1607 [9] Aboba, B., and M. Beadles, "The Network Access Identifier", 1608 RFC 2486, January 1999. 1610 [10] Aboba, B., and D. Simon, "EAP Keying Framework", draft-aboba- 1611 pppext-key-problem-05.txt, December 2002 1613 [11] Bellare, M, and P. Rogaway, "Entity Authentication and Key 1614 Distribution," CRYPTO 93, LNCS 773, pp232-249, Springer- 1615 Verlag, Berlin, 1994. 1617 [12] Bellare, M., J Kilian, and P. Rogaway, "The Security of 1618 Cipher Block Chaining," Journal of Computer and System 1619 Sciences, Vol. 61, No. 3, Dec 2000, pp 362-399. 1621 9. Author Addresses 1623 Jesse R. Walker 1624 Intel Corporation 1625 2111 N.E. 25th Avenue 1626 Hillsboro, OR 97214 1627 USA 1628 jesse.walker@intel.com 1630 Russell Housley 1631 Vigil Security, LLC 1632 918 Spring Knoll Drive 1633 Herndon, VA 20170 1634 USA 1635 housley@vigilsec.com 1637 10. Full Copyright Statement 1639 Copyright (C) The Internet Society (2003). All Rights Reserved. This 1640 document and translations of it may be copied and furnished to others, 1641 and derivative works that comment on or otherwise explain it or assist 1642 in its implementation may be prepared, copied, published and 1643 distributed, in whole or in part, without restriction of any kind, 1644 provided that the above copyright notice and this paragraph are 1645 included on all such copies and derivative works. However, this 1646 document itself may not be modified in any way, such as by removing 1647 the copyright notice or references to the Internet Society or other 1648 Internet organizations, except as needed for the purpose of developing 1649 Internet standards in which case the procedures for copyrights defined 1650 in the Internet Standards process must be followed, or as required to 1651 translate it into languages other than English. The limited 1652 permissions granted above are perpetual and will not be revoked by the 1653 Internet Society or its successors or assigns. This document and the 1654 information contained herein is provided on an "AS IS" basis and THE 1655 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 1656 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1657 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 1658 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1659 PARTICULAR PURPOSE." 1661 11. Expiration Date 1663 This memo is filed as , and expires 1664 December 23, 2003.