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