idnits 2.17.00 (12 Aug 2021) /tmp/idnits1726/draft-tschofenig-pana-bootstrap-kerberos-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 585. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 592. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 598. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 614), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** 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 6515 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) == Outdated reference: draft-ietf-eap-rfc2284bis has been published as RFC 3748 == Outdated reference: draft-ietf-pana-pana has been published as RFC 5191 ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) == Outdated reference: draft-iab-research-funding has been published as RFC 3869 == Outdated reference: draft-ietf-cat-kerberos-pk-init has been published as RFC 4556 == Outdated reference: draft-ietf-eap-keying has been published as RFC 5247 == Outdated reference: draft-ietf-kink-kink has been published as RFC 4430 == Outdated reference: draft-ietf-krb-wg-kerberos-clarifications has been published as RFC 4120 == Outdated reference: A later version (-04) exists of draft-le-aaa-diameter-mobileipv6-03 Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PANA Working Group H. Tschofenig 2 Internet-Draft Siemens 3 Expires: January 10, 2005 V. Sankhla 4 University of Southern California 5 July 12, 2004 7 Bootstrapping Kerberos 8 draft-tschofenig-pana-bootstrap-kerberos-00 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 10, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document proposes a mechanism to obtain a Kerberos Ticket 42 Granting Ticket based on a successful EAP authentication and key 43 agreement message exchange. The initial network access 44 authentication procedure based on EAP is ideal for this purpose. 45 This proposal allows Kerberos to be used within a local network 46 without relying on a global Kerberos infrastructure. It should allow 47 an incremental deployment of Kerberos and a wider distribution of 48 Kerberos into roaming environments. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . 5 55 4. Solution Approach . . . . . . . . . . . . . . . . . . . . . 6 56 5. What are the advantages? . . . . . . . . . . . . . . . . . . 11 57 6. What are the disadvanges? . . . . . . . . . . . . . . . . . 12 58 7. Security Considerations . . . . . . . . . . . . . . . . . . 13 59 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 14 60 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 62 10.1 Normative References . . . . . . . . . . . . . . . . . . . 17 63 10.2 Informative References . . . . . . . . . . . . . . . . . . 17 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 65 Intellectual Property and Copyright Statements . . . . . . . 20 67 1. Introduction 69 Kerberos (see [RFC1510] and 70 [I-D.ietf-krb-wg-kerberos-clarifications]) is a well-known security 71 protocol which provides authentication, authorization and key 72 distribution and is used to secure a number of protocols - a list too 73 large to mention here. It is widely deployed in enterprise networks 74 where cross-realm authentication is not required at all or only to a 75 certain extend (in a environment with a hierarchical organizational 76 structure). In mobility environments Kerberos is, unfortunately, not 77 widely deployed since AAA protocols (such as RADIUS and DIAMETER), 78 which have different cross-realm (or inter-domain) signaling message 79 exchanges, are heavily used. The security properties of AAA 80 protocols and Kerberos also differ. The EAP key management framework 81 is described in [I-D.ietf-eap-keying]. This proposal tries to 82 combine the two protocols: Kerberos is used within the local network 83 and the AAA protocol is used as part of the network access 84 authentication and for communication between the visited network and 85 the home network. 87 2. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 3. Problem Statement 95 RADIUS [RFC2865] and DIAMETER [RFC3588] are used in an environment 96 where accounting and charging is an important functionality. 97 Kerberos was never designed to provide these features. Kerberos 98 provides cross-realm functionality in a way which is different to 99 EAP/AAA protocols. Even though the cross-realm authentication 100 approach used by Kerberos might provide better security properties 101 (such as denial of service protection) the EAP/AAA is gaining 102 importance. 104 By combining the functionality of AAA protocols (cross-realm/ 105 inter-domain behavior, accounting functionality and the existing AAA 106 infrastructure) with the benefits of Kerberos (support by a number of 107 existing protocols, authorization capabilities, key distribution and 108 protection of messages) a number of advantages can be achieved. 110 Section 3.4.4 of [I-D.iab-research-funding] points to the importance 111 of providing solutions for inter-realm Kerberos deployments: 'The 112 need for scalable inter-domain user authentication is increasingly 113 acute as ad-hoc computing and mobile computing become more widely 114 deployed. Thus, work on scalable mechanisms for mobile, ad-hoc, and 115 non-hierarchical inter-domain authentication would be very helpful.' 117 4. Solution Approach 119 At its abstract level this proposal suggests to start with a regular 120 AAA communication which might inludes the usage of EAP 121 [I-D.ietf-eap-rfc2284bis]. EAP acts as a container for a number of 122 authentication and key agreement mechanisms. The AAA infrastructure 123 is used to route, to transport and to secure AAA messages and their 124 payloads. As a result of the network access authentication the user 125 is authenticated to its home AAA server (in the subscription based 126 scenario) and the AAA protocol is ready to exchange collected 127 accounting records. In addition to this exchange the visited network 128 (to which the user's device is attached) receives the gurantee 129 through the execution of the AAA protocol and the AAA infrastructure 130 (roaming agreements etc.) that the home network can be hold liable 131 for the payment for the consumed resources by the end user. 133 Subsequently to a successful authentication and authorization the AAA 134 protocol does not only transmit a session key to the AAA attendant 135 but also creates a Kerberos Ticket Granting Ticket (TGT). This TGT 136 is only valid for the local network and is sent to the end host. The 137 session key is only sent to the Authenticator and not to the end host 138 whereas the TGT has to be made available to the end host itself. A 139 protocol between the end host and the Authenticator is therefore 140 required to carry the TGT. 142 Using the obtained TGT the user is able to request further service 143 tickets using a standard Kerberos service ticket request. A user 144 might also request service tickets for various applications, to 145 secure infrastructure services (DHCP, SLP, DNS, etc.), to secure QoS 146 signaling protocols (see [RFC3182] for RSVP security based on 147 Kerberos) or might even request a service ticket to subsequently 148 execute KINK [I-D.ietf-kink-kink] for the purpose of establishing 149 IPsec security associations. 151 Figure 1 shows a typical message exchange executed when an end host 152 moves to a new network. First, in step (1) some sort of address 153 configuration procedure takes place. If the network access 154 authentication procedure is executed as part of the link layer 155 protocol as for example in IEEE 802.11 then address configuration is 156 executed after step (2). The network access procedure (2) might 157 require many roundtrips depending on the authentication and key 158 exchange protocol used. Finally, after a sucessful completion of the 159 protocol exchange a TGT is attached to the final message and send to 160 the end host in step (3). This requires an additional Radius/ 161 Diameter attribute to carry the TGT from the local AAA server (if we 162 assume that it is created at the local AAA server), which is assumed 163 to be co-located with the Kerberos Authentication Server (labeled as 164 KDC in Figure 1). Co-locating these two entities is done mainly for 165 simplicity reasons since an additional protocol would be required for 166 commuication rather than an API call. The TGT must, additionally, be 167 sent from the AAA attendant to the end host. Subsequently Kerberos 168 service tickets can be requested using the standard Kerberos message 169 exchange (step (4)). 171 FOR DISCUSSION: Should we create 173 o a Ticket Granting Ticket which is sent to the end host or 175 o bootstrap a security association (and in particular a session key) 176 which is then used by the end host to request the Ticket Granting 177 Ticket. 179 The latter approach would not modify the inital TGT Kerberos 180 exchange. Further issues are discussed in Section 8. 182 EAP acts as a container for a number of authentication and key 183 exchange protocols. As such some observations have to be made 184 concerning the properties of the used mechanisms: Since the Ticket 185 Granting Ticket has to include the AAA distributed session key (key 186 field in the encrypted part of the ticket) this proposal requires an 187 EAP mechanism which provides session key distribution. This session 188 key is then used by the end host to create an Authenticator for a 189 subsequent service ticket requests. 191 +----+ +----------+ +------+ +----+ 192 | | | AAA | |AAAL +| | | 193 |Host| | Attendant| | KDC | |AAAH| 194 +-+--+ +-----+----+ +--+---+ +-+--+ 195 | | | | 196 +-----------------+ | | | 197 | Address | | | | 198 | Configuration | | | | 199 | Procedure (1) | | | | 200 +-----------------+ | | | 201 | | | | 202 +--+-------------------+----------------+----------------+--+ 203 | | Network Access Authentication | | 204 | | and | | 205 | | Session key distribtion based on | | 206 | |<------------- successful authentication (2) ------>| | 207 | | | | 208 | | Ticket Granting Ticket | | 209 | | Delivery (3) | | 210 | |<-----------------------------------+ | | 211 | | | | 212 +--+-------------------+----------------+----------------+--+ 213 | | | | 214 +-------------------+----------------+ | 215 | Standard Kerberos Service Ticket | | 216 | Request/Reply (TGS_REQ/TGS_REP) | (4) | 217 +-------------------+----------------+ | 218 | | | | 220 Figure 1: Message Flow 222 Figure 2 shows a Ticket Granting Ticket with the relevant fields. 223 The ticket consists of two parts - one unencrypted and an encrypted 224 part. The unencrypted part contains only information for the 225 recepient (in our case for the Ticket Granting Server) to be able to 226 recognize a ticket for which a key to decrypt the ticket is 227 available. In the described case these fields contain the ticket 228 version number, the realm name of the visited network and the 229 principal name of the Ticket Granting Server (TGS). The remaining 230 fields of the ticket are encrypted with the key known only to the TGS 231 and the Authentication Server (AS). Note that the AS is co-located 232 with the local AAA server in our scenario. The encrypted part of the 233 ticket contains information about the user's realm and its identity 234 which are obtained from the initial authentication procedure. The 235 flags field contains a flag which provides an indication of this 236 Kerberos bootstrapping procedure to differentiate it to a regular 237 AS_REQ/AS_REP exchange. The key field is important since it contains 238 the session key distributed during the initial authentication 239 procedure as described in Figure 1 in step (2). This session key is 240 subsequently only relevant for the TGS. For service authentication 241 between the end host and application servers and new service ticket 242 has to be requested from the TGS using a standard Kerberos TGS_REQ/ 243 TGS_REP message exchange. 245 Note that a protocol is required to carry the EAP messages and the 246 TGT from the AAA attendant to the end host. Such a protocol is 247 required to exchange the necessary parameters. This document does 248 not mandate a particular protocol. However, PANA 249 [I-D.ietf-pana-pana] is suitable for this purpose since it is a 250 flexbile and extensible protocol and allows the secure exchange of 251 parameters between the end host and the network. 253 +-------------------------------------------------+ 254 Unencrypted | Ticket Version Number | 255 part of | Realm that issued a ticket | 256 the ticket | Server's Principal Name (sname) | 257 +-------------------------------------------------+ 258 | Flags | 259 | Key | 260 | Realm in which the client is registered (crealm)| 261 | Client's principal identifier (cname) | 262 Encrypted | Transited Realms | 263 part of | Time of initial authentication (authtime) | 264 the ticket | Starttime | 265 (with a key known | Endtime | 266 to the TGS) | Renew-till | 267 | Hostaddress(es) (caddr) | 268 | Authorization-data | 269 +-------------------------------------------------+ 271 Figure 2: Ticket Granting Ticket Content 273 It is important to highlight that the proposal described in this 274 document makes an assumption which has to be satisified in order for 275 this bootstrapping mechanism to work: 277 The authentication and key exchange protocol shown in Figure 1 (step 278 2) assumes that a session key is distributed and after a successful 279 protocol execution established between the end host and the AAA 280 attendant. The session key distribution with the help of AAA also 281 allows the local AAA server to learn the session key. Since the 282 Ticket Granting Ticket requires a session key to be placed in the Key 283 field as shown in Figure 2. Hence authentication and key exchange 284 protocol which do not establish a session key between the end host 285 and the local network (AAA attendant/local AAA server) cannot be used 286 for bootstrapping a Kerberos Ticket Granting Ticket. 288 Additionally it should be noted that the proposed bootstrapping 289 protocol does not necessarily require the execution of a EAP 290 protocol. Protocols such as described in [I-D.perkins-aaav6], in 291 [I-D.mun-aaa-dbu-mobileipv6] and in [I-D.le-aaa-diameter-mobileipv6] 292 would also provide the desired functionality without relying on EAP 293 methods for authentication. Instead a custom authenthication and key 294 exchange protocol is defined. Even the protocols developed in the 295 SACRED working group would provide the necessary pre-requisity to 296 return a Ticket Granting Ticket and to use this proposal. To focus 297 on an increasingly common deployment environment we have focused on 298 EAP. 300 5. What are the advantages? 302 The authors think that this proposal has the following advantages: 304 o A large number of protocols support Kerberos as an authentication 305 and key distribution protocol. Enabling Kerberos to be used for 306 these environments would also enable these protocols to be secured 307 with Kerberos. 309 o Initial cross-realm/inter-domain authentication can be done using 310 an arbitrary protocol (in case of EAP). 312 o Kerberos relies on symmetric keys (ignoring PKINIT 313 [I-D.ietf-cat-kerberos-pk-init] and PKCROSS 314 [I-D.ietf-cat-kerberos-pk-cross]) for authentication and key 315 distribution. The usage of symmetric keys is highly efficient and 316 the risk of denial of service attacks often found in public key 317 based protocols is reduced. 319 o Kerberos tickets are designed to allow authorization information 320 to be added to the ticket itself. Authorization information can 321 be added by the KDC and allows services to base their access 322 control policies not only on the identity of the principal. 324 o When passwords are used with Kerberos (without PKINIT or other 325 mechanisms) then there might be a vulnerability to dictionary 326 attacks. Replacing the AS exchange with an EAP authentication 327 this vulnerability can be prevented. Note that this assumes that 328 the chosen EAP method is not vulnerable to dictionary attacks. 330 o Some EAP methods provide user identity confidentiality of the EAP 331 peer against either active or passive adversaries. If a Kerberos 332 Ticket Granting Ticket is created with the help of the EAP derived 333 key and the user identity is not copied to the Ticket Granting 334 Ticket then there is no indication for an eavesdropper about the 335 identity of a user. This approach therefore adds user identity 336 confidentiality to Kerberos. 338 6. What are the disadvanges? 340 Despite the advantages listed in the previous section there are some 341 disadvantages or constraints with the following proposal: 343 o A Kerberos implementation has to be supported by end hosts. 345 o Kerberos heavily relies on timestamps. If the clocks of the end 346 host and the various servers in the access network suffer from a 347 clock-drift then some procedure is required for clock- 348 synchronization. Such procedures are for example described 349 in[I-D.ietf-krb-wg-kerberos-clarifications]. It requires further 350 investigation whether a secure time distribution mechanism should 351 be included in this proposal. 353 7. Security Considerations 355 The security of the proposed mechanism relies on the selected EAP 356 mechanism, on Kerberos and on the AAA key distribution mechanism. A 357 security analysis of different EAP methods is outside the scope of 358 this document. It is assumed that the AAA key distribution 359 mechanism, the selected EAP method and Kerberos is secure. 361 Hence this section can only describe threats related to the proposed 362 distribution of the TGT. 364 Stealing of the TGT: 366 An adversary might eavesdrop on the wireless link between the end 367 host and the AAA attendant to learn the exchanged TGT. Without 368 confidentiality protection of the TGT an adversary might be able 369 to retrieve the TGT. Since the TGT is encrypted with the key of 370 the ticket granting server (TGS). It is assumed that this key has 371 sufficient length.This assures that an adversary is able to learn 372 the encrypted content of the ticket. Hence we can conclude that 373 an adversary might not be able to request further service tickets 374 only based on the knowledge of the ticket granting ticket. This 375 is inline with the basic principles of Kerberos. 377 Modification of the TGT: 379 An adversary might want to modify the content of the TGT. A TGS 380 would immediately detect such a modification because most parts of 381 the ticket are encrypted. The unencrypted parts only contain 382 information about the TGS and its realm and are useless for an 383 adversary. 385 Replay of the TGT: 387 An adverary (malicious end host) might want to reuse a TGT of a 388 previous message exchange. Since the TGT contains a lifetime 389 field it is not possible to use TGTs with an expired lifetime. In 390 order to request a service ticket the end host has to know the 391 session key to build an Authenticator. 393 8. Open Issues 395 This section lists some open issues which have been identified during 396 the work on this approach: 398 o Packet formats (e.g., AAA AVP, PANA AVPs, etc.) are missing. 400 o As an alternative to provide the end host (i.e., user) with a TGT 401 it would be possible to create a tentaive user account at the KDC. 402 This allows the end host to request a TGT and subsequently service 403 tickets. This approach would not require a TGT to be transferred 404 to the end host with the initial AAA exchange. 406 o In order to provide a service ticket to run KINK for achieving 407 secure network access an additional roundtrip is required. 408 Solutions are possible which allow the establishment of an IPsec 409 security association with a fewer number of roundtrips. 411 o Should it be possible to request more than a TGT (for example a 412 service ticket for secure network access) with the help of this 413 proposal? 415 o It might be helpful to have a flag inside the ticket to indicate 416 that the ticket presented to a server was not obtained by a 417 regular AS exchange but rather with this bootstapping mechanism. 419 o It would also be possible to provide the client with a secure 420 network time by protecting the timestamp as part of a PANA 421 exchange. 423 o Should the proposed extension return a full AS_REP instead of only 424 the TGT? This would allow the end host to learn the current time 425 based on the information inside the ticket. The TGT also contains 426 time information but it is not accessible for the end host (i.e. 427 it is included in the encrypted part). 429 o In this proposal the TGT is created at the local AAA server. 430 Therefore the local AAA server needs to wait until a succuessful 431 network access authentication indication is available. The 432 EAP-Success message indicates a succesful EAP method protocol run. 433 Hence, it is necessary for the AAA server to bind the EAP run to 434 the TGT. Furthermore, the local AAA server needs to inspect the 435 session key transferred with the AAA attribute in order to create 436 the TGT. More details need to be provided. It might be possible 437 to create the TGT at the Authenticator itself rather than in the 438 local AAA server. This would, however, cause an increase in the 439 number of entities which need to be trusted by the KDC. 441 o Finally, it might be possible to replace this entire bootstrapping 442 mechanism with a new AS_REQ/AS_REP protocol exchange which uses 443 EAP. This exchange could use EAP and the KDC would act as the 444 Authenticator in the EAP architecture. The main advantage of this 445 approach is achieved by protocol separation. A full EAP roundtrip 446 might not be required since the local AAA server might have stored 447 the session key of the previous protocol run already. 449 o Some discussions with regard to the EAP keying framework should go 450 in Section 7. A future version of this document will contain a 451 formal verification of the proposed approach. 453 o The relationship with the work done in the 3GPP Bootstrapping 454 architecture and the SACRED work needs to be described. 456 9. Acknowledgments 458 We would like to thank Guenther Horn, Dirk Kroeselberg and Wolfgang 459 Buecker for their comments to this draft. 461 Furthermore, Hannes Tschofenig would like to thank Derek Atkins for 462 discussions with an older version of this draft (more than a year 463 ago). 465 Jorge Cuellar encourage us to publish this document. 467 10. References 469 10.1 Normative References 471 [I-D.ietf-eap-rfc2284bis] 472 Blunk, L., Carlson, J. and B. Aboba, "Extensible 473 Authentication Protocol (EAP)", 474 draft-ietf-eap-rfc2284bis-09 (work in progress), February 475 2004, . 477 [I-D.ietf-pana-pana] 478 Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. 479 Yegin, "Protocol for Carrying Authentication for Network 480 Access (PANA)", draft-ietf-pana-pana-04 (work in 481 progress), May 2004, . 483 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 484 Authentication Service (V5)", RFC 1510, September 1993, 485 . 487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", March 1997. 490 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 491 "Remote Authentication Dial In User Service (RADIUS)", RFC 492 2865, June 2000. 494 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 495 Arkko, "Diameter Base Protocol", RFC 3588, September 2003, 496 . 498 10.2 Informative References 500 [I-D.iab-research-funding] 501 Atkinson, R. and S. Floyd, "IAB Concerns & Recommendations 502 Regarding Internet Research & Evolution", 503 draft-iab-research-funding-03 (work in progress), May 504 2004, . 506 [I-D.ietf-cat-kerberos-pk-cross] 507 Tsudik, G., Neuman, C., Sommerfeld, B., Tung, B., Hur, M., 508 Ryutov, T. and A. Medvinsky, "Public Key Cryptography for 509 Cross-Realm Authentication in Kerberos", 510 draft-ietf-cat-kerberos-pk-cross-08 (work in progress), 511 November 2001, 512 . 514 [I-D.ietf-cat-kerberos-pk-init] 515 Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, 516 S., Wray, J. and J. Trostle, "Public Key Cryptography for 517 Initial Authentication in Kerberos", 518 draft-ietf-cat-kerberos-pk-init-19 (work in progress), 519 April 2004, . 521 [I-D.ietf-eap-keying] 522 Aboba, B., "EAP Key Management Framework", 523 draft-ietf-eap-keying-01 (work in progress), October 2003, 524 . 526 [I-D.ietf-kink-kink] 527 Thomas, M. and J. Vilhuber, "Kerberized Internet 528 Negotiation of Keys (KINK)", draft-ietf-kink-kink-05 (work 529 in progress), January 2003, 530 . 532 [I-D.ietf-krb-wg-kerberos-clarifications] 533 Neuman, C., "The Kerberos Network Authentication Service 534 (V5)", draft-ietf-krb-wg-kerberos-clarifications-05 (work 535 in progress), February 2004, 536 . 538 [I-D.le-aaa-diameter-mobileipv6] 539 Faccin, S., "Diameter Mobile IPv6 Application", 540 draft-le-aaa-diameter-mobileipv6-03 (work in progress), 541 April 2003, 542 . 544 [I-D.mun-aaa-dbu-mobileipv6] 545 Kim, M. and Y. Mun, "Dynamic Binding Update using AAA", 546 draft-mun-aaa-dbu-mobileipv6-00 (work in progress), 547 December 2002, . 549 [I-D.perkins-aaav6] 550 Perkins, C., Flykt, P. and T. Eklund, "AAA for IPv6 551 Network Access", draft-perkins-aaav6-06 (work in 552 progress), May 2003, . 554 [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 555 Herzog, S. and R. Hess, "Identity Representation for 556 RSVP", RFC 3182, October 2001, . 558 Authors' Addresses 560 Hannes Tschofenig 561 Siemens 562 Otto-Hahn-Ring 6 563 Munich, Bayern 81739 564 Germany 566 EMail: Hannes.Tschofenig@siemens.com 568 Vishal Sankhla 569 University of Southern California 570 1860N, Fuller Avenue, Apt 117 571 Los Angeles, California 90046 572 USA 574 EMail: sankhla@usc.edu 576 Intellectual Property Statement 578 The IETF takes no position regarding the validity or scope of any 579 Intellectual Property Rights or other rights that might be claimed to 580 pertain to the implementation or use of the technology described in 581 this document or the extent to which any license under such rights 582 might or might not be available; nor does it represent that it has 583 made any independent effort to identify any such rights. Information 584 on the procedures with respect to rights in RFC documents can be 585 found in BCP 78 and BCP 79. 587 Copies of IPR disclosures made to the IETF Secretariat and any 588 assurances of licenses to be made available, or the result of an 589 attempt made to obtain a general license or permission for the use of 590 such proprietary rights by implementers or users of this 591 specification can be obtained from the IETF on-line IPR repository at 592 http://www.ietf.org/ipr. 594 The IETF invites any interested party to bring to its attention any 595 copyrights, patents or patent applications, or other proprietary 596 rights that may cover technology that may be required to implement 597 this standard. Please address the information to the IETF at 598 ietf-ipr@ietf.org. 600 Disclaimer of Validity 602 This document and the information contained herein are provided on an 603 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 604 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 605 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 606 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 607 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 608 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 610 Copyright Statement 612 Copyright (C) The Internet Society (2004). This document is subject 613 to the rights, licenses and restrictions contained in BCP 78, and 614 except as set forth therein, the authors retain all their rights. 616 Acknowledgment 618 Funding for the RFC Editor function is currently provided by the 619 Internet Society.