idnits 2.17.00 (12 Aug 2021) /tmp/idnits34695/draft-tschofenig-enroll-bootstrapping-saml-01.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 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 975. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 952. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 959. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 965. ** 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. 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 18, 2005) is 6150 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-pana-pana has been published as RFC 5191 -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: draft-ietf-eap-rfc2284bis has been published as RFC 3748 ** Obsolete normative reference: RFC 3588 (ref. '6') (Obsoleted by RFC 6733) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' == Outdated reference: draft-ietf-mip6-bootstrap-ps has been published as RFC 4640 == Outdated reference: A later version (-01) exists of draft-jee-mip6-bootstrap-pana-00 == Outdated reference: A later version (-04) exists of draft-giaretta-mip6-authorization-eap-02 == Outdated reference: draft-ietf-mip6-auth-protocol has been published as RFC 4285 == Outdated reference: A later version (-03) exists of draft-yegin-eap-boot-rfc3118-01 == Outdated reference: A later version (-01) exists of draft-mahy-eap-enrollment-00 == Outdated reference: draft-cam-winget-eap-fast-provisioning has been published as RFC 5422 == Outdated reference: draft-ietf-eap-keying has been published as RFC 5247 -- Obsolete informational reference (is this intentional?): RFC 3281 (ref. '26') (Obsoleted by RFC 5755) == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 == Outdated reference: A later version (-01) exists of draft-bournelle-pana-mip6-00 == Outdated reference: draft-ietf-sipping-trait-authz has been published as RFC 4484 == Outdated reference: A later version (-05) exists of draft-alfano-aaa-qosprot-02 == Outdated reference: draft-ietf-nsis-qos-nslp has been published as RFC 5974 == Outdated reference: A later version (-05) exists of draft-tschofenig-sip-saml-03 == Outdated reference: draft-ietf-aaa-diameter-cc has been published as RFC 4006 == Outdated reference: draft-bersani-eap-psk has been published as RFC 4764 == Outdated reference: draft-tschofenig-eap-ikev2 has been published as RFC 5106 -- Obsolete informational reference (is this intentional?): RFC 2716 (ref. '38') (Obsoleted by RFC 5216) == Outdated reference: draft-ietf-aaa-eap has been published as RFC 4072 Summary: 5 errors (**), 0 flaws (~~), 23 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Credential and Provisioning H. Tschofenig 3 (Enroll) Siemens 4 Internet-Draft G. Giaretta 5 Expires: January 19, 2006 TILab 6 A. Gomez-Skarmeta 7 University of Murcia 8 J. Polk 9 Cisco 10 July 18, 2005 12 Enriching Bootstrapping with Authorization Information 13 draft-tschofenig-enroll-bootstrapping-saml-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 19, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 Bootstrapping refers to the process of creating state (typically 47 security associations) between two or more entities based on a trust 48 relationship between these two or more parties AND a trusted third 49 party. Some work has been done in the area of bootstrapping in the 50 IETF recently. So far, the focus was on creating security 51 associations. This document aims to attach authorization information 52 to the bootstrapping process. 54 Table of Contents 56 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 4.1 Authorization in QoS signaling protocols . . . . . . . . . 9 61 4.2 SIP Service Bootstrapping . . . . . . . . . . . . . . . . 11 62 5. Obtaining a SAML Artifact/Assertion . . . . . . . . . . . . . 13 63 5.1 SAML Artifact transport in EAP methods . . . . . . . . . . 13 64 5.2 SAML Artifact transport in PANA . . . . . . . . . . . . . 13 65 6. Binding Authorization Information to Credentials . . . . . . . 16 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 67 7.1 Stolen Assertion . . . . . . . . . . . . . . . . . . . . . 18 68 7.2 MitM Attack . . . . . . . . . . . . . . . . . . . . . . . 18 69 7.3 Forged Assertion . . . . . . . . . . . . . . . . . . . . . 19 70 7.4 Replay Attack . . . . . . . . . . . . . . . . . . . . . . 19 71 7.5 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 19 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 74 9.1 Normative References . . . . . . . . . . . . . . . . . . . 22 75 9.2 Informative References . . . . . . . . . . . . . . . . . . 22 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 77 Intellectual Property and Copyright Statements . . . . . . . . 26 79 1. Introduction and Problem Statement 81 Some work has been done in the area of bootstrapping in the IETF 82 recently. The goal of bootstrapping is to create state (typically 83 security related information such as security associations) between 84 two or more entities. We focus on the two party case and call them 85 Alice and Bob. To securely establish state is simple if (a) Alice and 86 Bob share some information to protect the signaling exchange (e.g., 87 shared secret or the ability to verify a digital signature) and (b) 88 if they are able to authorize the other party. The following 89 statements describe (a) the problem of key management and (b) 90 addresses an important aspect in real world deployments - 91 authorization. 93 Hence, to develop a satisfactory bootstrapping solution it is 94 necessary to solve these two aspects: 96 o In order to solve the key management problem, a number of 97 mechanisms have been introduced including bootstrapping 98 mechanisms. For example, [9] and [10] give an overview of 99 bootstrapping (and imprinting) and describe protocol and 100 architectural considerations. Moreover, the problem of 101 bootstrapping is a hot topic in MIP6 WG: for a Mobile IPv6 102 bootstrapping problem statement see [11]. Several solutions have 103 also been proposed so far: some of them, such as [12] and [13], 104 exploit the authentication and protocol exchanges performed by the 105 mobile node for network access (e.g., PANA, EAP) in order to 106 bootstrap a Mobile IPv6 security association with the HA: in this 107 way, to bootstrap a MIPv6 SA no other authentication phase is 108 needed. Other solutions are completely independent from network 109 access authentication: for example, [14] proposes to use IKEv2, 110 while with [15] a MIPv6 security association for [16] is created 111 using PANA [1]. Finally, a solution for bootstrapping a DHCP RFC 112 3118 [17] security association using EAP/PANA was specified in 113 [18] and in [19] and a proposal to bootstrap a Kerberos Ticket 114 Granting Ticket based on a successful EAP protocol exchange is 115 provided in [20]. Recently, two further contributions [21] and 116 [22] were published that aim to reuse EAP for the purpose of 117 bootstrapping information. 119 o The aspect of authorization has received little attention in the 120 existing literature. Its importance has been discovered during 121 the work on the EAP keying framework [23] document but does not go 122 beyond investigating information carried by AAA protocols. 123 Actually, the authentication and the implicit authorization 124 performed through a pre-shared key or a key management protocol 125 may not be sufficient to conclude that a node (a user) is 126 authorized for a particular service. Considering the case of 127 Mobile IPv6 service as an example, the fact that the MN shares a 128 pre-shared key with the Home Agent and is able to setup an IPsec 129 Security Association to protect Mobile IPv6 signaling does not 130 imply that it is authorized to provide the Mobile IPv6 service. 131 For example, the Mobility Service Provider (MSP) might want to 132 prevent the usage of MIPv6 if the credit of the MN is going to 133 exhaust or based on the time of the day. This implies that 134 solving the key management problem is not enough to bootstrap a 135 service: a mechanism to explicitly authorize the user is needed to 136 design a bootstrapping solution. 138 This document describes a "single sign-on" framework that addresses 139 these issues through the usage of EAP and the AAA infrastructure of 140 the involved service providers (i.e., the home and the visited 141 service providers). This framework does not depend on a particular 142 EAP method, the EAP lower layer, the AAA protocol used. Several 143 mechanisms can be used to carry authorization data, such as Diameter, 144 PANA or EAP. 146 This document addresses authorization by utilizing capabilities of 147 the Security Assertion Markup Language (SAML). For details about 148 SAML see [2], [3] and [24]. Please note that it would be possible to 149 use other languages for describing authorization capabilities as 150 well, such as SPKI [25] or X.509 Authorization Certificates [26]. 152 Based on the previously published solution, it can be seen that the 153 Extensible Authentication Protocol (EAP) [4] plays an important role 154 in a bootstrapping solution since 156 o it provides support for multiple authentication and key exchange 157 protocols. 159 o allows three entities to be involved (EAP peer, EAP server and the 160 Authenticator). 162 o extensively deployed in the context of operational environments. 164 As a protocol between the Authenticator and the EAP server RADIUS [5] 165 and DIAMETER [6] are important to complete the architecture. 167 The manage of the authorization process related to the bootstrapping 168 is being considered as an important aspect of the services deployment 169 within the next generation networks. In this context, this document 170 aims to describe how the SAML could be used to provide the user 171 consumer of a service of the material needed to access in a secure 172 way the services and to link it with the permission and grants 173 associated to the user. 175 2. Terminology 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in [7]. 181 3. Framework 183 This section illustrates the bootstrapping framework and the involved 184 entities. The framework is based on a single sign-on paradigm: a 185 first authentication and authorization protocol exchange is exploited 186 to exchange general authorization data and to bootstrap subsequent 187 security associations and services. The framework is independent 188 from the container used to carry the needed authorization data; 189 however, in this draft the usage of SAML has been taken into account, 190 since it offers several advantages such as extensility, flexibilty 191 etc., 193 Figure 1 shows the entities typically involved in bootstrapping. 195 +---------------+ +---------------+ 196 | | (A) | | 197 | Bootstrapping |<-------------------> | Bootstrapping | 198 | Client (BC) | Protocol or | Agent (BA) | 199 | | API | | 200 +---------------+ +---------------+ 201 ^ 202 | 203 Protocol or |(B) 204 API | 205 v 206 +---------------+ 207 | | 208 | Bootstrapping | 209 | Target (BT) | 210 | | 211 +---------------+ 213 Figure 1: Bootstrapping Framework 215 Existing bootstrapping proposals nicely fit into this architecture. 216 Below, we provide an attempt for classification based on the 217 following distinguishing properties: 219 o Which protocol is used between the BC and the BA? 221 o Which protocol is used between the BA and the BT? 223 o What information is bootstrapped? 225 Ideally, a generic bootstrapping protocol would provide enough 226 flexibility for bootstrapping a variety of (bootstrapping) data 227 items. 229 As an example, we list a few proposals and show their properties in 230 the subsequent table below: 232 +---------------+----------+----------+-------------------+ 233 | Proposal | BC<->BA | BA<->BT | Bootstrapped Info | 234 +---------------+----------+----------+-------------------+ 235 |IKEv2 (1) | IKEv2 | API | IPsec SAs | 236 |...............|..........|..........|...................| 237 |Jee et al. (2) | PANA + |DIAMETER | IKE SA | 238 | | DIAMETER | | | 239 |...............|..........|..........|...................| 240 |Tschofenig et | | | | 241 | al (3) | PANA | API | SA for MIP6 Auth. | 242 |...............|..........|..........|...................| 243 |MIP6 Auth.(4) | MIP6 Ext.| API | SA for MIP6 Auth. | 244 |...............|..........|..........|...................| 245 |Giaretta et al.| EAP | Not | IKE SA | 246 | (5) | | specified| | 247 |...............|..........|..........|...................| 248 |Bournelle et | PANA | Not | IKE SA | 249 | al (6) | | specified| | 250 +---------------+----------+----------+-------------------+ 252 where (1) refers to [27], [14] and also to , (2) refers to [12], (3) 253 refers to [15], (4) refers to [16], (5) refers to [13] and (6) refers 254 to [28]. It is a matter of taste to call [27] or [16] a 255 bootstrapping protocol. 257 The bootstrapping framework, shown in Figure 1, can nicely be mapped 258 to the Authorization Framework shown in Figure 3. The Bootstrapping 259 client corresponds to the entity that is used to request the 260 assertion/artifact, the Bootstrapping Agent can be related to the 261 Assertion Granting Entity and the Assertion Verifying Entity 262 corresponds to the Bootstrapping Target. 264 +----------------+ Trust Relationship +----------------+ 265 | +------------+ |<.......................>| +------------+ | 266 | | Protocol | | | | Assertion | | 267 | | requesting | | Request | | Granting | | 268 | | authz | |------------------------>| | Entity | | 269 | | assertions | |<------------------------| +------------+ | 270 | +------------+ | Artifact/Assertion | Entity Cecil | 271 | ^ | +----------------+ 272 | | | ^ ^| 273 | | | . || HTTP or 274 | | | Trust . || DIAMETER 275 | API Access | Relationship. || 276 | | | . || 277 | | | . || 278 | | | v |v 279 | v | +----------------+ 280 | +------------+ | | +------------+ | 281 | | Protocol | | Service Request + | | Assertion | | 282 | | using authz| | Assertion/Artifact | | Verifying | | 283 | | assertion | | ----------------------- | | Entity | | 284 | +------------+ | | +------------+ | 285 | Entity Alice | <---------------------- | Entity Bob | 286 +----------------+ Response/Error +----------------+ 288 Figure 3: Authorization Framework 290 When Alice is successfully authenticated and authorized by Bob, he 291 receives the Artifact either via PANA, IKEv2 or any other protected 292 channel established via certain EAP methods. Alice might want to 293 make the Artifact available to other protocols. When Alice wants to 294 make a service request with Bob then the Artifact is attached. Bob 295 will need to interact with Cecil in order to fetch the Assertion. 296 Bob might want to use DIAMETER to fetch the Assertion and to execute 297 functions such as accounting and credit control. DIAMETER is 298 particularly attractive if keying material needs to be distribtued to 299 create a security association between Alice and Bob to secure 300 subsequent communication. If the establishment of keying material is 301 not important then other mechanisms (such as HTTP) could be used. 303 4. Scenarios 305 The content of this section is partially based on [29] which 306 addresses trait-based authorization in SIP. This document has a 307 strong relationship with [29] but aims to be more generic (instead of 308 focusing on SIP). Furthermore, Section 4.1 borrows also from [30] 309 and from [31]. 311 Two scenarios are meant to illustrate the functionality of SAML for 312 authorization in combination with bootstrapping. First, we describe 313 how authorization in a QoS signaling environment can be used and then 314 we illustrate a SIP service authorization example. 316 4.1 Authorization in QoS signaling protocols 318 Cryptographic computations are expensive and computing authorization 319 decisions might require a lot of time and also requires multiple 320 messages between the entity enforcing the decisions and the entity 321 computing the authorization decision. Particularly, in a mobile 322 environment these entities are physically separated - or not even in 323 the same administrative domain. Accordingly, the notion of "single 324 sign-on" is another potential application of authorization 325 assertions, and trait-based authorization - a user is authenticated 326 and authorized through one protocol, and can reuse the resulting 327 authorization assertion in other, unrelated protocol exchanges. 329 For example, in some environments it is useful to make the 330 authorization decision for a "high-level" service (such a voice 331 call). The authorization for the "voice call" itself might include 332 authorization for SIP signaling and also for lower level network 333 functions, for example a quality-of-service (QoS) reservation to 334 improve the performance of real-time media sessions established by 335 SIP. Since the SIP signaling protocol and the QoS reservation 336 protocol are totally separate, it is necessary to link the 337 authorization decisions of the two protocols. The authorization 338 decision might be valid for a number of different protocol exchanges, 339 for different protocols and for a certain duration or some other 340 attributes. 342 To enable this mechanism as part of the initial authorization step, 343 an authorization assertion is returned to the end host of the SIP UAC 344 (cryptographically protected). If QoS is necessary, the end host 345 might reuse the returned assertion in the QoS signaling protocol. 346 Any domains in the federation that would honor the assertion 347 generated to authorize the SIP signaling would similarly honor the 348 use of the assertion in the context of QoS. Upon the initial 349 generation of the assertion by an authorization server, traits could 350 be added that specify the desire level of quality that should be 351 granted to the media associated with a SIP session. 353 The message flow shown in Figure 4 illustrates such an exchange where 354 a client (such as a SIP user agent) uses some signaling exchange 355 which allows the end host to obtain an Artifact. This is Artifact is 356 later used as an input for a QoS signaling protocol and provides 357 client authorization. The QoS aware router can either process the 358 request locally or use the Diameter QoS application for verifying the 359 authorization decision at the entity which created the Artifact. In 360 order to perform the processing locally, it is required to obtain an 361 Assertion rather than an Artifact (which is not further illustrated 362 in Figure 4). The DIAMETER QoS application contacts the Application 363 Server to obtain the Assertion, to authorize the request and to start 364 accounting. 366 Diameter QoS 367 Application 368 Enabled Router Application 369 Enforcement Pt Server 370 Application + 371 Client Domain 1 + Domain 2 372 | | + | 373 | Service Request (QoS) | 374 +------------+------------+-------------> 375 | | + | 376 | | + | 377 | Service Response (QoS',Artifact) | 378 <------------+------------+-------------+ 379 | | + | 380 | | + | 381 |NSIS(Artifact)| + | 382 +------------> + | 383 | | + | 384 | | -+-- | 385 | |QAR(Art.) - + -QAR(Art.) | 386 | +--------/> + --\--------> 387 | | / + \ | 388 | | / + \ | 389 | | | + | | 390 | | QAA(QoS) + QAA(QoS) | 391 | <------+--- + <---+------+ 392 | | | + | | 393 | | | Diameter | | 394 | | \ Network / | 395 | | \ + / | 396 | | \ + / | 397 | Authorization \- + -/ | 398 | Enforcement -+-- | 399 | Decision + | 400 | | + | 401 | | + | 402 | Allow or Terminate Flow | 403 <-----------+*+-------------------------> 404 | | + | 406 Figure 4: Message flow with NSIS and Diameter QoS Application 408 4.2 SIP Service Bootstrapping 410 This scenario exploits the inclusion of SAML for SIP which has been 411 introduced with [32]. 413 In Figure 5, user Alice runs a protocol with an Authentication Server 414 whereby authentication and authorization is provided. This protocol 415 exchange might be based on a number of protocols, such as EAP, PANA, 416 HTTP or something similar. It is not required that the 417 authentication and key exchange protocol terminates at this entity 418 but the Artifact is created and returned the user (based on a 419 successful protocol execution). When a SIP message (e.g., an INVITE) 420 is sent towards a SIP Server or even to another SIP UA then the 421 Artifact is attached to the SIP message. As shown in Figure 5 the 422 SIP service contacts the Authentication Server (for example via 423 DIAMETER) to request the Assertion. This message exchange also 424 allows the SIP service to obtain keying material. 426 +--------+ +--------------+ +--------+ 427 |User | |Authentication| |SIP | 428 |Alice | |Server | |Service | 429 +---+----+ +------+-------+ +---+----+ 430 | | | 431 | EAP, PANA, HTTP | | 432 |<--------------------->| | 433 | | | 434 | Artifact | | 435 |<----------------------| | 436 | | | 437 | INVITE + SAML Artifact | 438 |-----------------------+--------------------->| 439 | | | 440 | | Fetch Assertion | 441 | |<---------------------| 442 | | | 443 | | Assertion | 444 | |--------------------->| 445 | | | 446 | 200 OK | | 447 |<----------------------+----------------------| 448 | | | 450 Figure 5: Message flow for SIP service authorization 452 5. Obtaining a SAML Artifact/Assertion 454 This section describes how an end host obtains an Artifact via PANA 455 or EAP which subsequently be used for service authorization. 456 Depending on whether the home network or the visited network should 457 create an Assertion/Artifact EAP and/or PANA will be used. If for 458 example, services in the visited network should be authorized then an 459 entity in the visited network should create the Assertion/Artifact 460 and it will be returned via PANA to the end host. 462 It is not suggested to exchange a SAML Assertion either via EAP or 463 via PANA. An Assertion is an XML document which is, for security 464 reasons, digitally signed. Both PANA and EAP/EAP methods suffer from 465 size limitations. EAP and most EAP methods do not support 466 fragmentation. PANA should avoid IP layer fragmentation. 468 A number of mechanisms exist to fetch an Assertion with the help of 469 an Artifact. HTTP is the most common mechanisms. This document also 470 suggests to use DIAMETER to assist in this step since it additionally 471 allows to distribute previously created keying material, to benefit 472 from accounting extensions [33] and other DIAMETER applications such 473 as Credit Control [34]. 475 EDITOR's Note: A "notification" mechanism might be useful to indicate 476 that the user wants to obtain an Artifact (or that the server does 477 not provide this extension). 479 5.1 SAML Artifact transport in EAP methods 481 Currently, there are a number of EAP authentication methods that have 482 the capability to convey generic information items (e.g., PEAPv2 483 [35], EAP-PSK [36] or EAP-IKEv2 [37]). In fact they are being used 484 to send additional information during authentication process inside a 485 protected channel between an EAP peer and the authenticator or 486 between the EAP peer and the EAP server in the case authenticator is 487 acting as a pass-through. This capability is, for example, being 488 considered to transport MIPv6 authorization data [13]. Following 489 this approach, a SAML artifact could be conveyed within an EAP method 490 (by creating another payload/AVP that carries this information). 492 5.2 SAML Artifact transport in PANA 494 Another alternative, that would allow to use EAP methods that are not 495 able to transport generic information (e.g., EAP-TLS [38]), is to use 496 PANA protocol to convey authorization information (SAML artifact) 497 from the PANA Authentication Agent (PAA) to the PANA Authentication 498 Client (PaC). The usage of PANA provides more flexibility with 499 respect to the entity creating the artifact and the bootstrapped 500 service. This circumstance is shown in Figure 6. The PANA protocol 501 is used between the PAA and PaC. It might be necessary that a AAA 502 server is contacted. EAP is carried inside PANA and might then again 503 be encapsulated into a AAA protocol such as RADIUS or DIAMETER (see 504 [39] and [40]). AAA interaction with EAP is typically the case if a 505 user roams to a visited network and the EAP method runs between the 506 EAP peer and the EAP server (whereby the EAP server is at the user's 507 home network). The service which will be later used might be at a 508 different administrative domain. The service could be at the visited 509 network, at the home network or at any other network. To allow 510 bootstrapping to work, it is necessary to have an existing trust 511 relationship between the entity that created the SAML assertion and 512 the service which will later use it. DIAMETER might be used between 513 these two entities to transfer keying material (and other 514 information). 516 If PANA terminates at the first hop router, as proposed in [1], then 517 PANA allows to create the SAML artifact in the visited network (by 518 some entity) and to subsequently use services either in the visited 519 network itself (as shown in Figure 4 or in networks which have some 520 trust relationship with the visited network with regard to the later 521 service usage. 523 +----------------+ 524 | Authentication | 525 | Authorization | 526 | Accounting | 527 | Server | 528 +----------------+ 529 ^ 530 |API/ 531 |AAA/EAP 532 | 533 v 534 +----------------+ +----------------+ 535 | PANA | PANA/EAP | PANA | 536 | Authentication |<---------------->| Authentication | 537 | Client | | Agent | 538 +----------------+ +----------------+ 539 ^ 540 | 541 |API/AAA 542 v 543 +----------------+ 544 | Entity | 545 | Running the | 546 | bootstrapped | 547 | Service | 548 +----------------+ 550 Figure 6: SAML Artifact transport in PANA 552 To create a feasible solution, it is necessary that the SAML artifact 553 can be carried in a AAA protocol (e.g., DIAMETER or RADIUS) between 554 the AAA server and the PAA and is then finally delivered from the PAA 555 to the PaC by using PANA. According to the PANA specification [1] 556 the PANA-FirstAuth-End-Request (PFER) (if both NAP and ISP 557 authentication is carried out) and/or Pana-Binding-Request (PBR) 558 message can transport new AVPs. Confidentiality protection must be 559 provided for this purpose. Authorization information could be 560 carried by defining new AVPs to be transported inside these messages. 561 Note that the new attributes or AVPs to carry SAML in DIAMETER (or 562 RADIUS) also need to be defined. 564 6. Binding Authorization Information to Credentials 566 SAML introduces the concept of a holder-of-the-key assertion to bind 567 the assertions (authorization information) to a cryptographic key. 568 See Section 5.1 of [2] 570 A number of credentials can be used with the KeyInfo element of the 571 Holder-of-the-Key assertion as described in Section 4.4 of [8], such 572 as: 574 o KeyName element, which is a string containing an identifier to a 575 key. 577 o KeyValue element, which contains the public key 579 o RetrievalMethod element, which is a reference to a key 581 o The X509Data element even contains one or more identifiers of 582 keys, X.509 certificates, certificate identifiers or a revocation 583 list. 585 o PGPData element that is used to convey information related to PGP 586 public key pairs 588 o SPKIData element carries information related to SPKI public key 589 pairs, certificates and other SPKI data. 591 o MgmtData element can contain a string value used to convey in-band 592 key distribution or agreement data 594 These concept allows the SAML assertion to be associated with the 595 bootstrapped credentials. For example, binding a public key to a 596 SAML assertion might also be a helpful when the public / private key 597 pair is also bootstrapped based using EAP and uses a pseudonym to 598 allow user identity confidentiality. In this case, this approach 599 would provide credential based authorization. This would then allow 600 subsequent application layer protocols interactions to be secured 601 while authorization information can be attached and provided via 602 SAML. 604 Binding a Kerberos Granting Ticket or a Kerberos Service Ticket to a 605 SAML assertion is also possible but a Kerberos ticket does not have a 606 unique identifier, such as a SerialNumber provided by X.509 607 certificates. One possible approach is to attach the same unique and 608 randomly chosen identifier to both, the KeyName element and to the 609 authorization-data field of the encrypted part of the Kerberos 610 ticket. 612 Furthermore, it is possible to bind the SAML assertion to the AAA- 613 key. This binding, therefore, associates the network authentication 614 and authorization protocol run to the assertion. Each time the user 615 needs to re-authenticate, the assertion can be presented to grant 616 access to the network (and also allowing the both entities to 617 generate a new AAA-key). Such a procedure might be helpful when 618 handovers within different access routers in the access network is 619 desired (intra-domain mobility) or even with inter-domain mobility. 621 7. Security Considerations 623 The security of the proposed mechanism relies on the selected EAP 624 method, on SAML and on the bootstrapping mechanism. A security 625 analysis of different EAP methods is outside the scope of this 626 document. It is assumed that the bootstrapping mechanism (possibly 627 involving AAA key distribution mechanisms) and the selected EAP 628 method is secure. 630 This section discusses a number of selected security threats and 631 their countermeasures. 633 7.1 Stolen Assertion 635 Threat: 637 If an eavesdropper can eavesdrop the SAML Assertion and construct 638 a service request, then the eavesdropper could be able to 639 impersonate the user at other entities. 641 Countermeasures: 643 By providing adequate confidentiality, eavesdropping of a SAML 644 assertion can be avoided. 646 7.2 MitM Attack 648 Threat: 650 Since the SAML assertion is presented to a service when 651 authorization is desired, a malicious service provider could 652 impersonate the user at some other entities. These entities would 653 believe that the adversary has the rights indicated in the 654 assertion. 656 Countermeasures: 658 If the adversary is a not-participating in the SIP signaling 659 itself (i.e., it is not a SIP proxy or a SIP UA), this threat can 660 be eliminated by employing inherent SIP security mechanisms , such 661 as TLS. However, if this entity is part of the communication 662 itself then reference integrity needs to be provided. Assertions 663 with tight restrictions (e.g., validity of the assertion) can also 664 limit the possible damage. 666 7.3 Forged Assertion 668 Threat: 670 A malicious user could forge or alter a SAML assertion in order to 671 communicate with other entities. 673 Countermeasures: 675 To avoid this kind of attack, the entities must assure that proper 676 mechanisms for protecting the SAML assertion needs to be in place. 677 It is recommended to protect the assertion using a digital 678 signature. Note that the current proposal uses Artifacts in most 679 places (EAP methods or PANA) and makes it therefore difficult for 680 an adversary to be able to mount such an attack. 682 7.4 Replay Attack 684 Threat: 686 An adversary who is able to gain access to an Assertion or an 687 Artifcat might be able to attach this token to a resource request 688 to gain special privileges. 690 Countermeasures: 692 The Artifact must be encrypted when the user obtains it. It also 693 needs to be transmitted encrypted when it is used for 694 authorization. To make it even more difficult for an adversary to 695 reuse the Artifact it is possible to associate credentials (either 696 symmetric or asymmetric keying material) with the Assertion. An 697 adversary can then only impersonate the legitimate user if he 698 knows the Artifact or Assertion and the corresponding credentials. 700 7.5 Privacy 702 Threat: 704 An adversary might be able to eavesdrop both the EAP communication 705 and the usage of SAML Artifacts and Assertions. This information 706 might reveal user identities and usage patterns. 708 Countermeasures: 710 EAP methods provide mechanisms to hide the true user identity. 711 This is, however, useless if a SAML Assertion again reveals the 712 true user identity. Since the Assertion is possibly only 713 exchanged using DIAMETER an adversary needs to be located at a AAA 714 client or server. The Artifcat itself does not reveal user 715 specific information since it is only a pointer to the Assertion. 716 Only legitimate entities are allowed to fetch the Assertion using 717 an Artifact. Furthermore, SAML does not mandate the inclusion of 718 a user identity in the Assertion. 720 8. Acknowledgments 722 We would like to thank Goeman Stefan and Rainer Falk for sharing 723 their thoughts with us. Furthermore, we would like to thank the 724 authors of [29] on trait-based authorization for SIP (namely Jon 725 Peterson, James Polk, Douglas Sicker and Marcus Tegnander) for their 726 discussions on the usage of SAML for IETF protocols. 728 The authors are working in two EU funded projects, namely Ambient 729 Networks and DAIDALOS. 731 Parts of this document are a byproduct of the Ambient Networks 732 Project, partially funded by the European Commission under its Sixth 733 Framework Programme. It is provided "as is" and without any express 734 or implied warranties, including, without limitation, the implied 735 warranties of fitness for a particular purpose. The views and 736 conclusions contained herein are those of the authors and should not 737 be interpreted as necessarily representing the official policies or 738 endorsements, either expressed or implied, of the Ambient Networks 739 Project or the European Commission. 741 The work described in this document is partially based on results of 742 IST FP6 Integrated Project DAIDALOS. DAIDALOS receives research 743 funding from the European Community's Sixth Framework Programme. 744 Apart from this, the European Commission has no responsibility for 745 the content of this paper. The information in this document is 746 provided as is and no guarantee or warranty is given that the 747 information is fit for any particular purpose. The user thereof uses 748 the information at its sole risk and liability. The views and 749 conclusions contained herein are those of the authors and should not 750 be interpreted as necessarily representing the official policies or 751 endorsements, either expressed or implied, of Daidalos Project or the 752 European Commission. 754 9. References 756 9.1 Normative References 758 [1] Forsberg, D., "Protocol for Carrying Authentication for Network 759 Access (PANA)", draft-ietf-pana-pana-09 (work in progress), 760 July 2005. 762 [2] Maler, E., Philpott, R., and P. Mishra, "Bindings and Profiles 763 for the OASIS Security Assertion Markup Language (SAML) V1.1", 764 September 2003. 766 [3] Maler, E., Philpott, R., and P. Mishra, "Assertions and Protocol 767 for the OASIS Security Assertion Markup Language (SAML) V1.1", 768 September 2003. 770 [4] Blunk, L., "Extensible Authentication Protocol (EAP)", 771 draft-ietf-eap-rfc2284bis-09 (work in progress), February 2004. 773 [5] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 774 Authentication Dial In User Service (RADIUS)", RFC 2865, 775 June 2000. 777 [6] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 778 "Diameter Base Protocol", RFC 3588, September 2003. 780 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 781 Levels", March 1997. 783 [8] Eastlake, D., Reagle, J., and D. Solo, "XML-Signature Syntax and 784 Processing, W3C Recommendation (available at 785 http://www.w3.org/TR/xmldsig-core/)", February 2002. 787 9.2 Informative References 789 [9] Tschofenig, H. and D. Kroeselberg, "Next Steps for ENROLL", 790 draft-tschofenig-enroll-next-steps-00 (work in progress), 791 October 2004. 793 [10] Pritikin, M., "Trusted Transitive Introduction Model", 794 draft-pritikin-ttimodel-01 (work in progress), July 2004. 796 [11] Patel, A., "Problem Statement for bootstrapping Mobile IPv6", 797 draft-ietf-mip6-bootstrap-ps-03 (work in progress), July 2005. 799 [12] Jee, J., "Diameter Mobile IPv6 Bootstrapping Application using 800 PANA", draft-jee-mip6-bootstrap-pana-00 (work in progress), 801 October 2004. 803 [13] Giaretta, G., "MIPv6 Authorization and Configuration based on 804 EAP", draft-giaretta-mip6-authorization-eap-02 (work in 805 progress), October 2004. 807 [14] Kempf, J., "Bootstrapping Mobile IPv6", 808 draft-chakrabarti-mip6-bmip-01 (work in progress), 809 February 2005. 811 [15] Tschofenig, H., Bournelle, J., and S. Thiruvengadam, 812 "Bootstrapping Mobile IPv6 using PANA", 813 draft-tschofenig-mip6-bootstrapping-pana-00 (work in progress), 814 October 2004. 816 [16] Leung, K., "Authentication Protocol for Mobile IPv6", 817 draft-ietf-mip6-auth-protocol-04 (work in progress), 818 February 2005. 820 [17] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 821 RFC 3118, June 2001. 823 [18] Yegin, A., Tschofenig, H., and D. Forsberg, "Bootstrapping 824 RFC3118 Delayed DHCP Authentication Using EAP-based Network 825 Access Authentication", draft-yegin-eap-boot-rfc3118-01 (work 826 in progress), January 2005. 828 [19] Tschofenig, H., "Bootstrapping RFC3118 Delayed authentication 829 using PANA", draft-tschofenig-pana-bootstrap-rfc3118-01 (work 830 in progress), October 2003. 832 [20] Tschofenig, H., "Bootstrapping Kerberos", 833 draft-tschofenig-pana-bootstrap-kerberos-00 (work in progress), 834 July 2004. 836 [21] Mahy, R., "An Extensible Authentication Protocol (EAP) 837 Enrollment Method", draft-mahy-eap-enrollment-00 (work in 838 progress), July 2005. 840 [22] Cam-Winget, N., "Dynamic Provisioning using EAP-FAST", 841 draft-cam-winget-eap-fast-provisioning-00 (work in progress), 842 July 2005. 844 [23] Aboba, B., "Extensible Authentication Protocol (EAP) Key 845 Management Framework", draft-ietf-eap-keying-06 (work in 846 progress), April 2005. 848 [24] Maler, E. and J. Hughes, "Technical Overview of the OASIS 849 Security Assertion Markup Language (SAML) V1.1", March 2004. 851 [25] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., 852 and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 853 September 1999. 855 [26] Farrell, S. and R. Housley, "An Internet Attribute Certificate 856 Profile for Authorization", RFC 3281, April 2002. 858 [27] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 859 draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. 861 [28] Bournelle, J., "Bootstrapping Mobile IPv6 using PANA", 862 draft-bournelle-pana-mip6-00 (work in progress), December 2004. 864 [29] Peterson, J., "Trait-based Authorization Requirements for the 865 Session Initiation Protocol (SIP)", 866 draft-ietf-sipping-trait-authz-01 (work in progress), 867 February 2005. 869 [30] Alfano, F., "Diameter Quality of Service Application", 870 draft-alfano-aaa-qosprot-02 (work in progress), February 2005. 872 [31] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality- 873 of-Service signaling", draft-ietf-nsis-qos-nslp-06 (work in 874 progress), February 2005. 876 [32] Tschofenig, H., "Using SAML for SIP", 877 draft-tschofenig-sip-saml-03 (work in progress), July 2005. 879 [33] Aboba, B. and J. Wood, "Authentication, Authorization and 880 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 882 [34] Mattila, L., Koskinen, J., Stura, M., Loughney, J., and H. 883 Hakala, "Diameter Credit-control Application", 884 draft-ietf-aaa-diameter-cc-06 (work in progress), August 2004. 886 [35] Josefsson, S., Palekar, A., Simon, D., and G. Zorn, "Protected 887 EAP Protocol (PEAP) Version 2", 888 draft-josefsson-pppext-eap-tls-eap-10 (work in progress), 889 October 2004. 891 [36] Bersani, F., "The EAP-PSK Protocol: a Pre-Shared Key EAP 892 Method", draft-bersani-eap-psk-07 (work in progress), 893 February 2005. 895 [37] Tschofenig, H., "EAP IKEv2 Method (EAP-IKEv2)", 896 draft-tschofenig-eap-ikev2-06 (work in progress), May 2005. 898 [38] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", 899 RFC 2716, October 1999. 901 [39] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 902 In User Service) Support For Extensible Authentication Protocol 903 (EAP)", RFC 3579, September 2003. 905 [40] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 906 Authentication Protocol (EAP) Application", 907 draft-ietf-aaa-eap-10 (work in progress), November 2004. 909 Authors' Addresses 911 Hannes Tschofenig 912 Siemens 913 Otto-Hahn-Ring 6 914 Munich, Bavaria 81739 915 Germany 917 Email: Hannes.Tschofenig@siemens.com 919 Gerardo Giaretta 920 Telecom Italia Lab 921 via G. Reiss Romoli, 274 922 TORINO, 10148 923 Italy 925 Email: gerardo.giaretta@tilab.com 927 Antonio F. Gomez-Skarmeta 928 University of Murcia 929 Campus de Espinardo s/n 930 Murcia, E-30100 931 Spain 933 Email: skarmeta@dif.um.es 935 James Polk 936 Cisco 937 2200 East President George Bush Turnpike 938 Richardson, Texas 75082 939 US 941 Email: jmpolk@cisco.com 943 Intellectual Property Statement 945 The IETF takes no position regarding the validity or scope of any 946 Intellectual Property Rights or other rights that might be claimed to 947 pertain to the implementation or use of the technology described in 948 this document or the extent to which any license under such rights 949 might or might not be available; nor does it represent that it has 950 made any independent effort to identify any such rights. Information 951 on the procedures with respect to rights in RFC documents can be 952 found in BCP 78 and BCP 79. 954 Copies of IPR disclosures made to the IETF Secretariat and any 955 assurances of licenses to be made available, or the result of an 956 attempt made to obtain a general license or permission for the use of 957 such proprietary rights by implementers or users of this 958 specification can be obtained from the IETF on-line IPR repository at 959 http://www.ietf.org/ipr. 961 The IETF invites any interested party to bring to its attention any 962 copyrights, patents or patent applications, or other proprietary 963 rights that may cover technology that may be required to implement 964 this standard. Please address the information to the IETF at 965 ietf-ipr@ietf.org. 967 Disclaimer of Validity 969 This document and the information contained herein are provided on an 970 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 971 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 972 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 973 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 974 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 975 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 977 Copyright Statement 979 Copyright (C) The Internet Society (2005). This document is subject 980 to the rights, licenses and restrictions contained in BCP 78, and 981 except as set forth therein, the authors retain all their rights. 983 Acknowledgment 985 Funding for the RFC Editor function is currently provided by the 986 Internet Society.