idnits 2.17.1 draft-tschofenig-nsis-qos-ext-authz-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 618. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 595. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 602. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 608. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 624), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (July 12, 2004) is 7228 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) == Unused Reference: 'I-D.ietf-nsis-nslp-natfw' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nsis-ntlp' is defined on line 505, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qos-nslp (ref. 'I-D.ietf-nsis-qos-nslp') ** Downref: Normative reference to an Informational RFC: RFC 3579 == Outdated reference: A later version (-05) exists of draft-alfano-aaa-qosprot-00 == Outdated reference: A later version (-04) exists of draft-arkko-eap-service-identity-auth-00 == Outdated reference: A later version (-16) exists of draft-arkko-pppext-eap-aka-12 == Outdated reference: A later version (-10) exists of draft-ietf-aaa-eap-08 == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-01 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-02 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-02 == Outdated reference: A later version (-06) exists of draft-ietf-nsis-rsvp-sec-properties-04 == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-04 == Outdated reference: A later version (-04) exists of draft-walker-ieee802-req-01 Summary: 9 errors (**), 0 flaws (~~), 16 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NSIS H. Tschofenig 2 Internet-Draft J. Kross 3 Expires: January 10, 2005 Siemens AG 4 July 12, 2004 6 Extended QoS Authorization for the QoS NSLP 7 draft-tschofenig-nsis-qos-ext-authz-00 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 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 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 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. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 10, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 Proper authorization is essential for a Quality of Service signaling 41 protocol. Three authorization models have been identified: a 42 two-party model, a token-based three-party model, and a generic 43 three-party model 45 This document discusses two possible solution for the generic 46 three-party model: a challenge/response based and an EAP-based 47 approach. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Protocol Alternatives . . . . . . . . . . . . . . . . . . . . 6 55 4.1 Challenge/Response-based Authentication/Authorization . . 6 56 4.2 EAP-based Authentication/Authorization . . . . . . . . . . 7 57 5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 10 58 5.1 Challenge/Response-based Authentication/Authorization . . 10 59 5.2 EAP-based Authentication/Authorization . . . . . . . . . . 10 60 5.3 Integrity Object . . . . . . . . . . . . . . . . . . . . . 11 61 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 7. Security considerations . . . . . . . . . . . . . . . . . . . 13 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 65 8.2 Informative References . . . . . . . . . . . . . . . . . . . 14 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 67 Intellectual Property and Copyright Statements . . . . . . . . 17 69 1. Introduction 71 Three authorization models are described in Section 3.6 of 72 [I-D.ietf-nsis-qos-nslp]: 74 o Two party approach 76 o Token based three party approach 78 o Generic three party approach 80 The two party approach is sketched in Section 3.6.1 of 81 [I-D.ietf-nsis-qos-nslp], the token based three party approach is 82 described in Section 3.6.2 of [I-D.ietf-nsis-qos-nslp] (based on 83 [RFC3520] and [RFC3521]), and an overview of the generic three party 84 approach is provided with Section 3.6.3 of [I-D.ietf-nsis-qos-nslp]. 86 It is obvious that these authorization approaches offer different 87 security and address different deployment scenarios. 89 This document focuses on a more detailed discussion of the generic 90 three party approach. Section 3 provides an overview of the generic 91 three party approach. Section 4 lists two possible solution 92 approaches. For completeness, object payloads are described in 93 Section 5. A short conclusion is given in Section 6. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 3. Overview 103 This section offers message flows and protocol-specific details about 104 authorization for QoS reservations for the generic three party 105 approach. 107 Figure 1 illustrates a case where an entity A (e.g., an end host) 108 sends an NSIS QoS signaling message towards an entity B (e.g, a NSIS 109 aware router). This request cannot be authorized by entity B itself 110 but is rather forwarded to another entity C. The protocol used 111 between entity A and entity B is based on NSIS whereas the protocol 112 used between entity B and entity C is, for example, Diameter. A 113 proposal for a Diameter QoS application is provided with 114 [I-D.alfano-aaa-qosprot]. 116 +--------------+ 117 | Entity C | 118 | authorizing | 119 | resource | 120 | request | 121 +-----------+--+ 122 ^ | 123 | | 124 QoS | | QoS 125 authz| |authz 126 req.| | res. 127 | | 128 QoS | v 129 +-------------+ request +--+-----------+ 130 | Entity |----------------->| Entity B | 131 | requesting | | performing | 132 | resource |granted / rejected| QoS | 133 | A |<-----------------| reservation | 134 +-------------+ +--------------+ 136 Figure 1: Three party approach 138 In the following, two alternative solution proposals for this model 139 are shown: 141 o Challenge/Response-based Authentication and Authorization 143 o EAP-based Authentication and Authorization 145 4. Protocol Alternatives 147 4.1 Challenge/Response-based Authentication/Authorization 149 Figure 2 shows a message flow for the generic three party approach 150 with a challenge-response mechanism. In this case, after entity B 151 asked entity C for authorization of a QoS request, entity C issues a 152 challenge to entity A, which is passed on by entity B. Entity A 153 resubmits its QoS request, including a response to the challenge. 154 This is again forwarded to entity C, which verifies whether entity A 155 is the one it claims to be, and if so, and after checking for entity 156 A's authorization to use the resources it requests, either grants or 157 denies the request. 159 +--------------------+ 160 | Entity C | 161 | authenticating / | 162 | authorizing | 163 | resource | 164 | request | 165 +----+-------------+-+ 166 ^ |c ^ | 167 | |h |R | 168 | |a |e | 169 | |l |s | QoS 170 | |l |p |authz 171 QoS | |e |o | res. 172 authz| |n |n | 173 req.| |g |s | 174 | |e |e | 175 QoS | v | v 176 +-------------+ request +---------+----------+ 177 | Entity |----------------->| Entity B | 178 | requesting | challenge | performing | 179 | resource |<-----------------| QoS | 180 | A | response | reservation | 181 | +----------------->| | 182 | |granted / rejected| | 183 | |<-----------------+ | 184 +-------------+ +--------------------+ 186 Figure 2: Three party challenge-response based approach 188 Please note that the QoS NSLP does not explicitly send a successful 189 response message for the challenge/response protocol after a QoS 190 reservation request. Instead the successful outcome of the protocol 191 run is implicated by the successul commitment of the entire QoS 192 reservation. An unsuccessful outcome of the challenge/response 193 protocol, however, would be indicated explicitly by a reject message 194 returned immediately - the error codes still need to be defined in 195 [I-D.ietf-nsis-qos-nslp]. 197 The properties of this approach are intentionally similar to the 198 digest-authentication used with SIP (see [RFC3261]). This approach 199 provides better security properties than a token-based authorization 200 approach since a stronger liveness check needs to be provided. The 201 QoS request and the result of the challenge/response authentication 202 and authorization need to be associated with each other. 203 Furthermore, it is necessary to bind subsequent refresh messages to 204 the initial authentication and authorization protocol step. This is 205 typically accomplished with the establishment of session keys and the 206 protection of signaling messages between entity A and B. 208 The necessary steps for the QoS NSLP are the following: 210 o A challenge/response protocol needs to be defined or selected. A 211 number of protocols can be reused, including the 212 digest-authentication approach listed in [RFC3261]. This 213 authentication and key exchange protocol needs to provide mutual 214 authentication, replay protection and session key establishment. 215 It seems to be reasonable to investigate some of the requirements 216 raised in [I-D.walker-ieee802-req] regarding the selection of such 217 a protocol. 219 o Integrity protection needs to be applied to signaling messages 220 exchanged between the entity A and entity B once a session key is 221 available. 223 o Since the authentication and key establishment is executed betwen 224 entity A and entity C, it is necessary to forward the established 225 keying material from entity C to entity B (using AAA protocols). 227 o In some circumstances it might be necessary to combine the 228 security protection at the NTLP with the security protection at 229 the NSLP. This can, for example, be accomplished by combining the 230 session keys of both security protocols as suggested in 231 [I-D.puthenkulam-eap-binding]. Such a binding is necessary if the 232 reused challenge/response protocol is also used in other 233 protocols. 235 4.2 EAP-based Authentication/Authorization 237 The Extensible Authentication Protocol (EAP) serves as a container 238 for EAP methods. EAP methods themselves are authentication and key 239 exchange protocols. EAP is agnostic with regard to the underlying 240 protocol carrying the EAP payloads. 242 The main difference between the EAP-based approach discussed in this 243 section, and the challenge/response based approach discussed in 244 Section 4.1 is related to the flexible choice of authentication and 245 key exchange protocols with EAP on the one hand, and some degree of 246 inefficiency introduced with EAP (such as the EAP-Request/Identity, 247 EAP-Response/Identity and EAP-Success messages) on the other hand. 249 Due to the usage of EAP in IEEE 802.1X and also in PANA, the security 250 properties have been studied extensively. The discussions in the EAP 251 keying framework (see [I-D.ietf-eap-keying]) are also applicable. 252 Please note that EAP is not necessarily a three party protocol - EAP 253 also supports the two party scenario. 255 An example message flow is shown in Figure 3 which uses the EAP-AKA 256 method [I-D.arkko-pppext-eap-aka] for authentication and session key 257 establishment. Please note that the AAA messages triggered by this 258 exchange are not shown for editorial reasons. 260 +---------+ +---------+ 261 | MN | | R1 | 262 +---------+ +---------+ 263 (a) + <---------------------------------------------> + 264 | Discovery Request/Response (NTLP) | 265 | | 266 (b) | ----------------------------------------------> | 267 | C-Mode | 268 | NTLP/NSLP QoS CREATE Req. | 269 | (EAP-Auth/Authz requested; | Initial 270 | EAP-Identity) | Setup 271 | | 272 (c) | <---------------------------------------------- | 273 | C-Mode | 274 | NTLP/NSLP QoS CREATE Resp. | 275 | (EAP-Request/AKA-Challenge | 276 | (AT_RAND, AT_AUTN, AT_MAC)) | 277 | (Algorithm/Parameter Negotiation) | 278 (d) | ----------------------------------------------> | 279 | C-Mode | 280 | NTLP/NSLP QoS CREATE Req. | 281 | (EAP-Response/AKA-Challenge | 282 | (AT_RES, AT_MAC)) | 283 | (Algorithm/Parameter Negotiation) | 284 +~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~+ 286 (e) | Authentication Authorization finished | 287 | Secure channel at the NSLP layer established | 288 +~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~+ 289 (f) | <---------------------------------------------- | 290 | NTLP/NSLP QoS CREATE Resp. | 291 | NTLP/NSLP QoS CREATE Req. | 292 | (EAP-Success) | 293 | (Secure Confirmation) | 294 | | 295 + + 296 .......... 297 + + 298 | ----------------------------------------------> | 299 (g) | NTLP/NSLP QoS REFRSH msg | Refresh 300 | | Msg 301 | <---------------------------------------------- | 302 | NTLP/NSLP QoS ACK msg | 303 + + 305 Figure 3: EAP based Auth/Authz exchange using EAP-AKA 307 The message exchange shown in Figure 3 starts with the optional 308 discovery of the next QoS NSLP aware node (messages (a)). The first 309 QoS NSLP message with a resource request is sent with the Network 310 Access Identity and a request to perform EAP-based authentication 311 (message (b)). Note that this exchange assumes that the EAP-Request/ 312 Identity and the EAP-Response/Identity exchange is omitted. This 313 exchange is optional in EAP if the identity can be provided by other 314 means. Router 1 contacts the AAA infrastructure, and the EAP server 315 starts the message exchange. The AAA message communication is not 316 shown. Subsequently, two messages (messages (c) and (d)) are 317 exchanged between the EAP peer and the EAP server which contain 318 EAP-AKA specific information. After successful authentication and 319 authorization, session keys are derived and provided to R1 via AAA 320 mechanisms (see [I-D.ietf-aaa-eap] and [RFC3579]). These session 321 keys can then be used to protect subsequent NSLP messages as 322 indicated by (e). The EAP-Success message can already experience 323 such a protection (see message (f)). Furthermore, it is useful to 324 repeat the previously sent objects. Subsequent refresh messages (g) 325 are protected with the previously established session keys and are 326 therefore associated with the previous authentication and 327 authorization protocol execution. 329 5. Payload Formats 331 5.1 Challenge/Response-based Authentication/Authorization 333 For carrying the credentials for the challenge/response-based 334 authentication and authorization approach within the QoS NSLP, it is 335 proposed to use a new Policy Element, called CR policy element. Its 336 format is shown in Figure 4. 338 +-------------+-------------+-------------+-------------+ 339 | Length | P-Type = AUTHZ_CR | 340 +---------------------------+---------------------------+ 341 | | 342 // CR Packet (Opaque to QoS NSLP) // 343 | | 344 +-------------------------------------------------------+ 346 Figure 4: Format of CR Policy Element 348 CR Packet: The CR Packet contains the information required for the 349 Challenge/Response handshake. Further details will be described in a 350 future version of this document. 352 5.2 EAP-based Authentication/Authorization 354 Figure 3 illustrates an example message flow for EAP-based 355 authentication and authorization. This section proposes how to 356 integrate the data required for the EAP exchange into the QoS NSLP 357 message format. 359 [I-D.ietf-nsis-qos-nslp] describes the generic format for Policy 360 Elements. It is proposed that the EAP data is carried within a new 361 Policy Element, called EAP Policy Element. It follows the generic 362 format of Policy elements as defined in Appendix A.7.3 of 363 [I-D.ietf-nsis-qos-nslp]. Figure 5 illustrates the specific format. 365 +-------------+-------------+-------------+-------------+ 366 | Length | P-Type = AUTHZ_EAP | 367 +---------------------------+---------------------------+ 368 | | 369 // EAP Packet (Opaque to QoS NSLP) // 370 | | 371 +-------------------------------------------------------+ 373 Figure 5: Format of EAP Policy Element 375 EAP Packet: The EAP Packet contains an EAP packet in the format of 376 [RFC3748], section 4. 378 5.3 Integrity Object 380 A future version of this document will describe the payload format of 381 an Integrity Object. 383 6. Conclusion 385 The QoS NSLP has to be provided for the generic three party case in 386 order to be complete. This document discusses two possible 387 solutions: the challenge/response and the EAP-based approach 389 The working group needs to make the following two decisions: 391 o Should a challenge/response or an EAP-based scheme be developed? 393 o Should this work be included in the main QoS NSLP 394 [I-D.ietf-nsis-qos-nslp] document? 396 There are some technical aspects that need to be addressed, as 397 explained throughout the text. Hence, the enhancement is more 398 complex than just adding one new payload to the NSLP. Some security 399 issues and also non-security issues need to be solved. For example, 400 EAP itself is only a container and does not provide fragmentation and 401 reliable transmission of EAP payloads. Carrying EAP within the QoS 402 NSLP requires further investigations since different transport 403 protocols have to be supported by GIMPS (see 404 [I-D.schulzrinne-nsis-ntlp]). These issues have already been 405 discussed in, for example, PANA [I-D.ietf-pana-pana]. 407 7. Security considerations 409 Selected security aspects with the challenge/response based approach 410 have been mentioned in Section 4.1 and with respect to EAP in Section 411 4.2. 413 If security protection is provided by GIMPS (which is an 414 instantiation of the NTLP) and also at the NSLP with the mechanisms 415 discussed in this document, then the two phases should be combined 416 since security vulnerabilities are introduced otherwise. For 417 example, running EAP over TLS for client-side authentication could be 418 one possibility but it raises issues with the discovered 419 man-in-the-middle attack problems for tunneled authentication (see 420 [I-D.puthenkulam-eap-binding]). 422 There is certainly a tradeoff between the flexibility of EAP and the 423 simplicity of a challenge/response protocol. 425 In some scenarios, it is necessary to cope with the 'lying NAS' 426 problem. With the usage of EAP, it is necessary to provide the EAP 427 server with enough information to perform the authorization steps. 428 However, EAP methods themselves are independent of the environment in 429 which they are executed. Hence, an adversary (acting as an NSIS NSLP 430 node) could misuse an EAP exchange to create the illusion for the EAP 431 server that the context is different (e.g., wireless LAN access). 432 The work in the area [I-D.arkko-eap-service-identity-auth] and 433 [I-D.mariblanca-aaa-eap-lla] is applicable in this context. The goal 434 is to give both, the EAP peer and the EAP server, enough assurance 435 that the Authenticator (i.e., QoS NSLP in this context) is not lying. 437 It might be worth mentioning that the introduction of COPS in RSVP 438 (see [RFC2749]) and the usage of POLICY_OBJECT [RFC3182] already 439 provided a first attempt in offering a generic three party 440 authorization model. Hence, the problem is not artifical. 441 Unfortunately, the multiple-roundtrip communication and the AAA 442 infrastructure was not fully worked out at that time. The 443 deficiencies in a roaming environment have first been mentioned with 444 [I-D.thomas-nsis-rsvp-analysis]. A more detailed treatment of the 445 security properties are provided with 446 [I-D.ietf-nsis-rsvp-sec-properties]. 448 8. References 450 8.1 Normative References 452 [I-D.ietf-nsis-qos-nslp] 453 Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for 454 Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-03 455 (work in progress), May 2004. 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", March 1997. 460 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 461 Dial In User Service) Support For Extensible 462 Authentication Protocol (EAP)", RFC 3579, September 2003. 464 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 465 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 466 3748, June 2004. 468 8.2 Informative References 470 [I-D.alfano-aaa-qosprot] 471 Alfano, F., McCann, P. and H. Tschofenig, "Diameter 472 Quality of Service Application", 473 draft-alfano-aaa-qosprot-00 (work in progress), July 2004, 474 . 476 [I-D.arkko-eap-service-identity-auth] 477 Arkko, J. and P. Eronen, "Authenticated Service Identities 478 for the Extensible Authentication Protocol (EAP)", 479 draft-arkko-eap-service-identity-auth-00 (work in 480 progress), April 2004, 481 . 483 [I-D.arkko-pppext-eap-aka] 484 Arkko, J. and H. Haverinen, "EAP AKA Authentication", 485 draft-arkko-pppext-eap-aka-12 (work in progress), April 486 2004, . 488 [I-D.ietf-aaa-eap] 489 Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 490 Authentication Protocol (EAP) Application", 491 draft-ietf-aaa-eap-08 (work in progress), June 2004, 492 . 494 [I-D.ietf-eap-keying] 495 Aboba, B., "EAP Key Management Framework", 496 draft-ietf-eap-keying-01 (work in progress), October 2003, 497 . 499 [I-D.ietf-nsis-nslp-natfw] 500 Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun, 501 "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 502 draft-ietf-nsis-nslp-natfw-02 (work in progress), May 503 2004. 505 [I-D.ietf-nsis-ntlp] 506 Schulzrinne, H. and R. Hancock, "GIMPS: General Internet 507 Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-02 508 (work in progress), May 2004. 510 [I-D.ietf-nsis-rsvp-sec-properties] 511 Tschofenig, H. and R. Graveman, "RSVP Security 512 Properties", draft-ietf-nsis-rsvp-sec-properties-04 (work 513 in progress), February 2004, 514 . 516 [I-D.ietf-pana-pana] 517 Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. 518 Yegin, "Protocol for Carrying Authentication for Network 519 Access (PANA)", draft-ietf-pana-pana-04 (work in 520 progress), May 2004, . 522 [I-D.mariblanca-aaa-eap-lla] 523 Mariblanca, D., "EAP lower layer attributes for AAA 524 protocols", draft-mariblanca-aaa-eap-lla-01 (work in 525 progress), June 2004, 526 . 528 [I-D.puthenkulam-eap-binding] 529 Puthenkulam, J., "The Compound Authentication Binding 530 Problem", draft-puthenkulam-eap-binding-04 (work in 531 progress), October 2003, 532 . 534 [I-D.schulzrinne-nsis-ntlp] 535 Schulzrinne, H., "GIMPS: General Internet Messaging 536 Protocol for Signaling", draft-schulzrinne-nsis-ntlp-00 537 (work in progress), June 2003, 538 . 540 [I-D.thomas-nsis-rsvp-analysis] 541 Thomas, M., "Analysis of Mobile IP and RSVP Interactions", 542 draft-thomas-nsis-rsvp-analysis-00 (work in progress), 543 November 2002, 544 . 546 [I-D.walker-ieee802-req] 547 Stanley, D., "EAP Method Requirements for Wireless LANs", 548 draft-walker-ieee802-req-01 (work in progress), May 2004, 549 . 551 [RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R. 552 and A. Sastry, "COPS usage for RSVP", RFC 2749, January 553 2000, . 555 [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 556 Herzog, S. and R. Hess, "Identity Representation for 557 RSVP", RFC 3182, October 2001, . 559 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 560 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 561 "SIP: Session Initiation Protocol", RFC 3261, June 2002, 562 . 564 [RFC3520] Hamer, L., Gage, B., Kosinski, B. and H. Shieh, "Session 565 Authorization Policy Element", RFC 3520, April 2003. 567 [RFC3521] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session 568 Set-up with Media Authorization", RFC 3521, April 2003. 570 Authors' Addresses 572 Hannes Tschofenig 573 Siemens AG 574 Otto-Hahn-Ring 6 575 Munich, Bayern 81739 576 Germany 578 EMail: Hannes.Tschofenig@siemens.com 580 Joachim Kross 581 Siemens AG 582 Otto-Hahn-Ring 6 583 Munich, Bayern 81739 584 Germany 586 Intellectual Property Statement 588 The IETF takes no position regarding the validity or scope of any 589 Intellectual Property Rights or other rights that might be claimed to 590 pertain to the implementation or use of the technology described in 591 this document or the extent to which any license under such rights 592 might or might not be available; nor does it represent that it has 593 made any independent effort to identify any such rights. Information 594 on the procedures with respect to rights in RFC documents can be 595 found in BCP 78 and BCP 79. 597 Copies of IPR disclosures made to the IETF Secretariat and any 598 assurances of licenses to be made available, or the result of an 599 attempt made to obtain a general license or permission for the use of 600 such proprietary rights by implementers or users of this 601 specification can be obtained from the IETF on-line IPR repository at 602 http://www.ietf.org/ipr. 604 The IETF invites any interested party to bring to its attention any 605 copyrights, patents or patent applications, or other proprietary 606 rights that may cover technology that may be required to implement 607 this standard. Please address the information to the IETF at 608 ietf-ipr@ietf.org. 610 Disclaimer of Validity 612 This document and the information contained herein are provided on an 613 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 614 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 615 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 616 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 617 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 618 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 620 Copyright Statement 622 Copyright (C) The Internet Society (2004). This document is subject 623 to the rights, licenses and restrictions contained in BCP 78, and 624 except as set forth therein, the authors retain all their rights. 626 Acknowledgment 628 Funding for the RFC Editor function is currently provided by the 629 Internet Society.