idnits 2.17.1 draft-grayson-eap-authorisation-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard 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 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 (March 2003) is 7712 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '11' is mentioned on line 273, but not defined == Unused Reference: '6' is defined on line 586, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 589, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 592, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-05 -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 2284 (ref. '2') (Obsoleted by RFC 3748) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 2868 (ref. '4') == Outdated reference: A later version (-16) exists of draft-haverinen-pppext-eap-sim-10 ** Downref: Normative reference to an Informational draft: draft-haverinen-pppext-eap-sim (ref. '6') ** Obsolete normative reference: RFC 2486 (ref. '7') (Obsoleted by RFC 4282) -- Possible downref: Non-RFC (?) normative reference: ref. '8' == Outdated reference: A later version (-02) exists of draft-salowey-eap-protectedtlv-01 -- Possible downref: Normative reference to a draft: ref. '9' Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 INTERNET DRAFT M. Grayson 4 draft-grayson-eap-authorisation-01.txt J. Salowey 5 Expires: September 2003 Cisco Systems 6 March 2003 8 EAP Authorization 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Distribution of this memo 14 is unlimited. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum 1of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document specifies an Extensible Authentication Protocol (EAP) 34 mechanism for authorization information exchange. EAP TLV is a 35 container type for EAP messages. This mechanism describes an EAP TLV 36 for exchange of authorization related information which can take 37 place within the EAP framework. It allows an authentic user to 38 provide the network with additional information in order to 39 determine which Internet Service is being requested. It also allows 40 an EAP server to request authorization for session parameters from 41 an EAP peer. This mechanism may be chained after any EAP- 42 Authentication mechanism. 44 Table of Contents 46 Status of this Memo.........................................1 47 Abstract....................................................1 48 Table of Contents...........................................2 49 1. Introduction.............................................2 50 2. Terms....................................................3 51 3. Overview.................................................4 52 3.1. Providing Additional Information.......................5 53 3.2. Mandatory Tunnel Example...............................5 54 3.3. Billing Rate Authorization.............................6 55 4. Message Format...........................................6 56 4.1. EAP-TLV/Authorization-Request..........................6 57 4.2. EAP-TLV/Authorization-Response.........................7 58 4.3. Authorization Attribute Format.........................8 59 4.4. Protected TLV..........................................8 60 5. Defined attributes.......................................8 61 5.1. Status.................................................8 62 5.2. Authorization Identity.................................9 63 5.3. Quality of Service....................................10 64 5.4. Billing Rate..........................................10 65 5.5. Terms and Conditions..................................10 66 5.6. Service Type..........................................10 67 5.7. Tunnel FQDN...........................................10 68 5.8. Tunnel Password.......................................11 69 6. Protection of EAP-TLV/Authorization.....................12 70 IANA Considerations........................................12 71 Security Considerations....................................12 72 Intellectual Property Right Notice.........................12 73 Acknowledgements and Contributions.........................12 74 References.................................................12 75 Editor's Address...........................................13 77 1. Introduction 79 The Extensible Authentication Protocol (EAP), described in [2], 80 provides a standard mechanism for support of multiple authentication 81 methods. Through the use of EAP, support for a number of 82 authentication schemes may be added, including GSM smart card 83 support, one time password and others. 85 The encapsulation of EAP has been defined over IEEE 802 link layers 86 in IEEE 802.1X [3]. In 802.1X, an authentication failure will result 87 in denied access to the controlled port. Conversely, an 88 authenticated peer will be allowed access. 90 This document specifies an extension to EAP using TLV encapsulation 91 for authorization exchange which may be used to authorize additional 92 resources for the peer, e.g., above access to the controlled port 93 defined in 802.1X. In particular, this document describes techniques 94 for the definition and authorization of tunnel resources in a manner 95 which is secure, independent of the selected authentication method 96 and compatible with existing AAA based configuration, e.g., for 97 configuring compulsory network based tunnels [4]. The authorization 98 TLV provides a way for the EAP server to request the EAP Peer to 99 authorize certain session attributes such as quality of service or 100 charging options. 102 This method relies upon a security association to provide message 103 protection established using PEAP [1] or Protected TLV [9]. This 104 approach provides a consistent authorization interfaces for various 105 access systems and allows the authorization to be decoupled from a 106 specific authentication method. 108 2. Terms 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [5]. 114 This document frequently uses the following terms and abbreviations: 116 AAA protocol 118 Authentication, Authorization and Accounting protocol 120 Authentication service 122 The Authentication Service verifies, from the credentials 123 supplied by the peer, the claim of identity made by the peer. 125 Authorization Service 127 The Authorization Service verifies the service requested by the 128 peer is valid. Optionally, the Authorization Service may be 129 involved in configuring the authorized service on behalf of the 130 peer. 132 EAP 134 Extensible Authentication Protocol. 136 EAP Server 138 The network element that terminates the EAP protocol. Typically, 139 the EAP server functionality is implemented in a AAA server. In 140 this document, the AAA server provides both Authentication and 141 Authorization service. 143 NAI 145 Network Access Identifier 147 PEAP 148 Protected EAP 150 EAP Peer 152 A peer is an entity that is being authenticated by an 153 Authenticator. Once authenticity is validated the peer can be 154 allowed access to authorized resources. 156 TLV 158 A TLV is an attribute formatted as type, length and value. 160 3. Overview 162 Whilst established EAP methods define exchanges for providing an 163 Authentication Service for a peer, EAP-TLV/Authorization exchanges 164 define procedures for providing an Authorization Service. EAP- 165 TLV/Authorization uses a minimum of a single roundtrip to exchange 166 additional authorization information between the EAP peer and 167 server. The peer may be requested to authorize certain session 168 attributes such as quality of service or billing rate and the server 169 may be request to provide various services to the client. 171 The EAP Authorization phase must be chained after an EAP 172 Authentication mechanism has completed and a key is available for 173 protecting the confidentiality and authenticity of the authorization 174 exchange. The protection of the exchange may be provided by a 175 tunneling mechanism such as PEAP [1] or by Protected TLVs described 176 in [9]. 178 After authentication is complete and keys are established the server 179 sends a request of type EAP-TLV/Request-Authorization. The request 180 may contain attributes that the EAP-Server requests the client to 181 authorize. If the request does not contain any attributes it 182 indicates that the server is willing to accept an authorization 183 request from the client. 185 The peer responds with an EAP-TLV/Response-Authorization packet 186 including zero or more EAP-Authorization attributes which the peer 187 provides to the network in order to define service parameters which 188 are to be authorized. The EAP-TLV/Response-Authorization message 189 MUST contain a status attribute indicating the result of any 190 authorization carried out as a result of the EAP-TLV/Request- 191 Authorization Packet. 193 After receiving the EAP-TLV/Authorization-Request or EAP- 194 TLV/Response-Authorization packet, the EAP sever or EAP Peer can 195 confirm which services and attribute are being requested and perform 196 authorization checks. Authorization checks may involve third parties 197 for which the peer may use an identification distinct from that 198 which was previously used for port based authentication. The 199 Authorization Identity attribute provides the capability to carry 200 additional identification information. 202 The server may indicate authorization failure with a Authorization- 203 Status attribute in the Request-Authorization message or it may 204 indicate failure with an EAP-Failure message. An EAP-Failure 205 message will terminate the EAP conversation. Since the EAP-failure 206 message does not include the option to transport a Displayable 207 Message, the EAP server can use an EAP-Notification message to 208 provide the supplicant with additional information, e.g., if service 209 authorization fails. 211 3.1. Providing Additional Information 213 The specific information related to authorization will depend upon 214 the authorized resources being requested. The EAP-Authorization 215 methods are extensible to allow new authorization information to be 216 defined. The document describes the minimum supported attributes for 217 the mandatory tunnel service includes authorization identifier, 218 tunnel password and tunnel endpoint description. Additional 219 attributes may be defined to represent quality of service or billing 220 rate. 222 These are just two examples of how EAP Authorization may be used, 223 there are many other possibilities. 225 3.2. Mandatory Tunnel Example 227 In the mandatory tunnel example the client is requesting that a 228 secure tunnel be established from within the local network to which 229 the client is connected to a home network. A pre-arranged 230 relationship is established between the local network and the home 231 network to allow for this. The authentication is proxied by the 232 local network to the home network using AAA techniques. 234 After the user has successfully completed an EAP authentication 235 method such as EAP-MD5 within PEAP the authenticator sends an EAP- 236 TLV/Authorization-Request message to see if the client wishes to 237 request additional services. The client then responds with an EAP- 238 TLV/Authorization-Response message containing the following 239 attributes: 241 Status 242 Authorisation Identity 243 Service Type 244 Tunnel FQDN 245 Tunnel Password 247 The authenticator then verifies that the authenticated user is 248 allowed to use the authorisation identity and service defined by the 249 service type and tunnel FQDN. It may also verify the tunnel 250 password. The authenticator then saves these parameters to be 251 passed back to the local network using AAA, e.g., using RADIUS 252 attributes in the Access-Accept defined in RFC 2868. It is possible 253 that the authenticator may return different attributes to the local 254 network based on its policy (for example it may return a different 255 tunnel password). The local network then establishes a tunnel back 256 to the home network according to the parameters in the access 257 accept. The tunnel endpoint in the home network authenticates the 258 local endpoint using the username (authorization identity) and 259 password passed back in the access accept. 261 3.3. Billing Rate Authorization 263 If the peer is receiving service that it will be charged for the 264 EAP-Server may request authorization for those charges. In this case 265 the EAP-Server sends an EAP/Request-Authorization message with a 266 Billing Rate attribute. The request message may contain attributes 267 that ask for additional information for the peer. 269 4. Message Format 271 The authorization message consists of a series of attributes. The 272 collection of all attributes MUST be protected with PEAP and/or 273 protected TLV as in [11]. The following attributes are defined by 274 this document. 276 4.1. EAP-TLV/Authorization-Request 278 The EA-TLV/Authorization-Request message is used by a peer or server 279 to request authorization of certain services or session attributes. 280 It has the following format: 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 |M|R| Type | Length | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Value... 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 M 292 0 - Non-mandatory TLV 293 1 - Mandatory TLV 295 R 297 Reserved, set to zero (0) 299 Type 301 TBD TLV-Authorization-Request 303 Length 305 The length of the Value field in octets. 307 Value 309 One or more authorization attributes 311 4.2. EAP-TLV/Authorization-Response 313 The EAP-TLV/Authorization-Response message is used by an EAP Server 314 to request additional information from the peer related to certain 315 services authorization requests. It has the following format: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 |M|R| Type | Length | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Value... 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 M 327 0 - Non-mandatory TLV 328 1 - Mandatory TLV 330 R 332 Reserved, set to zero (0) 334 Type 336 TBD TLV-Authorization-Response 338 Length 340 The length of the Value field in octets. 342 Value 344 Status attribute and request for additional information from 345 the server. 347 4.3. Authorization Attribute Format 349 Each authorization attribute has the following format: 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Type | Length | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Value... 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 Type 361 Type of authorization attribute 363 Length 365 Length of value. The combine length of all the attributes MUST 366 NOT exceed 2^16. 368 Value 370 Value of attribute. 372 4.4. Protected TLV 374 The protected TLV is described in the protected TLV draft [9]. 376 5. Defined attributes 378 5.1. Status 380 The Status attribute is used to indicate the status of any 381 outstanding authorization requests. It MUST be present in an EAP- 382 TLV/Response-Authorization message. 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Type = Status | Length = 4 | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Status code | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Type 393 TBD Authorization-Status 395 Length 397 Length of value 399 Status Code 401 Result of the outstanding authorization indicated by the 402 following values. 404 STATUS_PASS = 0 405 STATUS_FAIL = 1 406 STATUS_PENDING = 2 408 A value of STATUS_PASS indicates that all authorization 409 requests passed. A value of STATUS_FAIL indicated that at least 410 one authorization request failed. A value of STATUS_PENDING 411 indicates that additional information is being requested. It 412 STATUS_PENDING is returned the message MUST contain additional 413 attributes indicating the information being requested. 415 5.2. Authorization Identity 417 This represents an alternate identity for the authenticated 418 principal. It may be a username on a specific system, a group name 419 that the user belongs to, or a proxy name. The authorizing service 420 SHOULD validate that the authenticated identity can use the 421 authorization identity. 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Type = AZN Identity | Length | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | | 429 . Value . 430 . . 431 | | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 Type 436 TBD Authorization-Identity 438 Length 440 Length of value 442 Value 443 String representation of the authorization identity 445 5.3. Quality of Service 447 449 5.4. Billing Rate 451 453 5.5. Terms and Conditions 455 457 5.6. Service Type 459 This attribute contains the type of service being requested. 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Type = Service type | Length | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | | 467 . Value . 468 . . 469 | | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 Type 474 TBD Service-Type 476 Length 478 Length of value 480 Value 482 This is a string representation of the service types. This 483 document defines the following service types: 485 None 486 Mandatory Tunnel 488 5.7. Tunnel FQDN 490 This attribute refers to the Mandatory Tunnel service. 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 | Type = Tunnel FQDN | Length | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | | 498 . Value . 499 . . 500 | | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 Type 505 Tunnel FQDN = 0x0101 507 Length 509 Length of Tunnel FQDN string 511 Value 513 A string corresponding to the FQDN identifying the tunnel 514 endpoint and can be used by the Authorization Service to 515 determine which resources require authorization, and possible 516 configuration. 518 5.8. Tunnel Password 520 This attribute refers to the mandatory tunnel service. 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Type = Tunnel Password | Length | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | | 528 . Value . 529 . . 530 | | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Type 535 Tunnel Client Password = 0xC023 537 Length 539 Length of packet format 541 Value 543 Tunnel password 545 6. Protection of EAP-TLV/Authorization 547 The EAP-TLV/Authorization mechanism MUST be protected. The 548 recommended way to achieve this is to run within a protected EAP 549 mechanism such as PEAP or Protected TLV. 551 IANA Considerations 553 Since multi-vendor interoperability is desired, an EAP Authorization 554 Type number is required to be allocated by IANA. 556 Security Considerations 558 The authorization exchange MUST be protected either by an external 559 mechanism such as PEAP or by using protected TLVs. The endpoints 560 must be careful to authenticate each other before requiring 561 authorization. These mechanisms SHOULD only be used when mutual 562 authentication is in place. 564 Intellectual Property Right Notice 566 Acknowledgements and Contributions 568 References 570 [1] H. Andersson, F. Josefsson, G. Zorn, D. Simon, A. Palekar, 571 "Protected EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap- 572 05.txt, September 2002 (work in progress) 574 [2] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol 575 (EAP)", RFC 2284, March 1998 577 [3] IEEE Standards for Local and Metropolitan Area Networks: Port 578 based Network Access Control, IEE Std 802.1X-2001, June 2001 580 [4] G. Zorn, "RADIUS Attributed for Tunnel Protocol Support", RFC 581 2868, June 2000 583 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement 584 Level", RFC 2119, March 1997 586 [6] H. Haverinen, J. Salowey, "EAP SIM Authentication", draft- 587 haverinen-pppext-eap-sim-10.txt, February 2003 (work in progress) 589 [7] B. Aboba, M. Beadles, "The Network Access Identifier", RFC 2486, 590 January 1999 592 [8] Hiller, Palekar, and Zorn "A Container Type for the Extensible 593 Authentication Protocol (EAP)", http://www.ietf.org/internet- 594 drafts/draft-hiller-eap-tlv-00.txt, October 2002 (work in progress) 596 [9] J. Salowey, "Protected EAP TLV", draft-salowey-eap-protectedtlv- 597 01.txt, March 2003 (work in progress) 599 Editor's Address 601 Joseph Salowey 602 Cisco Systems 603 2901 Third Avenue 604 Seattle, WA 98121 605 US 606 E-mail: jsalowey@cisco.com 607 Phone: +1 206 256 3380 609 Mark Grayson 610 Cisco Systems 611 11 Rue Desmoulins 612 Issy Les Moulineaux 613 92782 614 France 615 E-mail: mgrayson@cisco.com 616 Phone: +33 6 19 98 40 99