idnits 2.17.00 (12 Aug 2021) /tmp/idnits27879/draft-tschofenig-enroll-bootstrapping-saml-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 960. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 937. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 944. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 950. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (February 12, 2005) is 6306 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: A later version (-01) exists of draft-chakrabarti-mip6-bmip-00 == 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: 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-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-01 == 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-02 == 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. '36') (Obsoleted by RFC 5216) == Outdated reference: draft-ietf-aaa-eap has been published as RFC 4072 Summary: 7 errors (**), 0 flaws (~~), 22 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: August 16, 2005 TILab 6 A. Gomez-Skarmeta 7 University of Murcia 8 February 12, 2005 10 Enriching Bootstrapping with Authorization Information 11 draft-tschofenig-enroll-bootstrapping-saml-00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 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 25 Internet-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 August 16, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 Some work has been done in the area of bootstrapping in the IETF 47 recently. Bootstrapping refers to the process of creating state 48 (typically security associations) between two or more entities based 49 on a trust relationship between these two or more parties and a 50 trusted third party. So far work has mostly focused on creating 51 security associations. This document aims to attach authorization 52 information 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 86 and Bob share some information to protect the signaling exchange 87 (e.g., share secret or the ability to verify a digital signature) and 88 (b) if they are able to authorize the other party. (a) is the 89 problem of key management problem and (b) addresses an important 90 aspect in real world deployments - authorization. 92 Hence, to develop a satisfactory bootstrapping solution it is 93 necessary to solve these two aspects: 95 o In order to solve the key management problem a number of 96 mechanisms have been introduced including bootstrapping 97 mechanisms. For example, [9] and [10] give an overview of 98 bootstrapping (and imprinting) and give protocol and architectural 99 considerations. Moreover, the problem of bootstrapping is a hot 100 topic in MIP6 WG: for a Mobile IPv6 bootstrapping problem 101 statement see [11]. Several solutions have also been proposed so 102 far: some of them, such as [12] and [13], exploit the 103 authentication and protocol exchanges performed by the mobile node 104 for network access (e.g. PANA, EAP) in order to bootstrap a 105 Mobile IPv6 security association with the HA: in this way, to 106 bootstrap a MIPv6 SA no other authentication phase is needed. 107 Other solutions are completely independent from network access 108 authentication: for example, [14] proposes to use IKEv2, while 109 with [15] a MIPv6 security association for [16] is created using 110 PANA [1]. Finally, a solution for bootstrapping a DHCP RFC 3118 111 [17] security association using EAP/PANA was specified in [18] and 112 in [19] and a proposal to bootstrap a Kerberos Ticket Granting 113 Ticket based on a successful EAP protocol exchange is provided in 114 [20]. 116 o The aspect of authorization has received little attention in the 117 existing literature. Its importance has been discovered during 118 the work on the EAP keying framework [21] document but does not go 119 beyond investigating information carried by AAA protocols. 120 Actually the authentication and the implicit authorization 121 performed through a pre-shared key or a key management protocol 122 may not be sufficient to conclude that a node (a user) is 123 authorized for a particular service. Considering the case of 124 Mobile IPv6 service as an example, the fact that the MN shares a 125 pre-shared key with the Home Agent and is able to setup an IPsec 126 Security Association to protect Mobile IPv6 signaling does not 127 imply that it is authorized to provide the Mobile IPv6 service. 128 For example the Mobility Service Provider (MSP) might want to 129 prevent the usage of MIPv6 if the credit of the MN is going to 130 exhaust or based on the time of the day. This implies that 131 solving the key management problem is not enough to bootstrap a 132 service: a mechanism to explicitely authorize th user is needed to 133 design a bootstrapping solution. 135 This document describes a "single sign-on" framework that addresses 136 these issues through the usage of EAP and the AAA infrastracture of 137 the involved service providers (i.e. the home and the visited 138 service providers). This framework does not depend on the EAP 139 method, the EAP lower layer, the AAA protocol used even if some EAP 140 method (e.g. PEAPv2, which creates a secure channel between the 141 client and the server) and some EAP lower layer (e.g. PANA) could 142 bring some (more) benefits. Several mechanisms can be used to carry 143 authorization data, such as Diameter, PANA or EAP. 145 This document addresses authorization by utilizing capabilities of 146 the Security Assertion Markup Language (SAML). For details about 147 SAML see [2], [3] and [22]. Please note that it would be possible to 148 use other languages for describing authorization capabilities as 149 well, such as SPKI [23] or X.509 Authorization Certificates [24]. 151 Based on the previously published solution it can be seen that the 152 Extensible Authentication Protocol (EAP) [4] plays an important role 153 in a bootstrapping solution since 155 o it provides support for multiple authentication and key exchange 156 protocols; 158 o allows three entities to be involved (EAP peer, EAP server and the 159 Authenicator); 161 o extensively deployed in the context of operational environments. 163 As a protocol between the Authenticator and the EAP server RADIUS [5] 164 and DIAMETER [6] are important to complete the architecture. 166 The manage of the authorization process related to the bootstrapping 167 is being considered as an important aspect of the services deployment 168 within the next generation networks. In this context the proposal of 169 this document is to describe how the use of SAML could provide the 170 user consumer of a service of the material needed to access in a 171 secure way the services and to link it with the permission and grants 172 associated to the user. 174 2. Terminology 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [7]. 180 3. Framework 182 This section illustrates the bootstrapping framework and the involved 183 entities. The framework is based on a single sign-on paradigm: a 184 first authentication and authorization protocol exchange is exploited 185 to exchange general authorization data and to bootstrap subsequent 186 security associations and services. The framework is independent 187 from the container used to carry the needed authorization data; 188 however in this draft the usage of SAML is described, since it seems 189 to offer several advantages. 191 Figure 1 shows the entities typically involved in bootstrapping. 193 +---------------+ +---------------+ 194 | | (A) | | 195 | Bootstrapping |<-------------------> | Bootstrapping | 196 | Client (BC) | Protocol or | Agent (BA) | 197 | | API | | 198 +---------------+ +---------------+ 199 ^ 200 | 201 Protocol or |(B) 202 API | 203 v 204 +---------------+ 205 | | 206 | Bootstrapping | 207 | Target (BT) | 208 | | 209 +---------------+ 211 Figure 1: Bootstrapping Framework 213 Existing bootstrapping proposals nicely fit into this architecture. 214 Below we provide an attempt for classification based on the following 215 distinguishing properties: 217 o Which protocol is used between the BC and the BA? 219 o Which protocol is used between the BA and the BT? 221 o What information is bootstrapped? 223 The authors argue that the first two bullets are the most important 224 once. Ideally a generic bootstrapping protocol would provide enough 225 flexility for bootstrapping a variety of bootstrapping data items. 227 As an example we classify a few proposals: 229 +---------------+----------+----------+-------------------+ 230 | Protocol | BC<->BA | BA<->BT | Bootstrapped Info | 231 +---------------+----------+----------+-------------------+ 232 |IKEv2 (1) | IKEv2 | API | IPsec SAs | 233 |...............|..........|..........|...................| 234 |Jee et al. (2) | PANA + |DIAMETER | IKE SA | 235 | | DIAMETER | | | 236 |...............|..........|..........|...................| 237 |Tschofenig et | | | | 238 | al (3) | PANA | API | SA for MIP6 Auth. | 239 |...............|..........|..........|...................| 240 |MIP6 Auth.(4) | MIP6 Ext.| API | SA for MIP6 Auth. | 241 |...............|..........|..........|...................| 242 |Giaretta et al.| EAP | Not | IKE SA | 243 | (5) | | specified| | 244 |...............|..........|..........|...................| 245 |Bournelle et | PANA | Not | IKE SA | 246 | al (6) | | specified| | 247 +---------------+----------+----------+-------------------+ 249 where (1) refers to [25], [14] and also to , (2) refers to [12], (3) 250 refers to [15], (4) refers to [16], (5) refers to [13] and (6) refers 251 to [26]. It is a matter of taste to call [25] or [16] a 252 bootstrapping protocol. 254 The bootstrapping framework, shown in Figure 1, can nicely be mapped 255 to the Authorization Framework Figure 3. The Bootstrapping client 256 corresponds to the entity that is used to request the 257 assertion/artifact, the Bootstrapping Agent can be related to the 258 Assertion Granting Entity and the Assertion Verifying Entity 259 corresponds to the Bootstrapping Target. 261 When Alice is successfully authorized it receives the Artifact either 262 via PANA, IKEv2 or any other protected channel established via 263 certain EAP methods. Alice might want to make the Artifact available 264 to other protocols. When Alice wants to make a service request with 265 Bob then the Artifact is attached. Bob will need to interact with 266 Cecil in order to fetch the Assertion. Bob might want to use 267 DIAMETER to fetch the Assertion and to execute functions such as 268 accounting and credit control. DIAMETER is particularly attractive 269 if keying material needs to be distribued to create a security 270 association between Alice and Bob to secure subsequent communication. 271 If the establishment of keying material is not important then other 272 mechanisms (such as HTTP) could be used. 274 +----------------+ Trust Relationship +----------------+ 275 | +------------+ |<.......................>| +------------+ | 276 | | Protocol | | | | Assertion | | 277 | | requesting | | Request | | Granting | | 278 | | authz | |------------------------>| | Entity | | 279 | | assertions | |<------------------------| +------------+ | 280 | +------------+ | Artifact/Assertion | Entity Cecil | 281 | ^ | +----------------+ 282 | | | ^ ^| 283 | | | . || HTTP or 284 | | | Trust . || DIAMETER 285 | API Access | Relationship. || 286 | | | . || 287 | | | . || 288 | | | v |v 289 | v | +----------------+ 290 | +------------+ | | +------------+ | 291 | | Protocol | | Service Request + | | Assertion | | 292 | | using authz| | Assertion/Artifact | | Verifying | | 293 | | assertion | | ----------------------- | | Entity | | 294 | +------------+ | | +------------+ | 295 | Entity Alice | <---------------------- | Entity Bob | 296 +----------------+ Response/Error +----------------+ 298 Figure 3: Authorization Framework 300 4. Scenarios 302 The content of this section is partially based on [27] which 303 addresses trait-based authorization in SIP. This document has a 304 strong relationship with [27] but aims to be more generic (instead of 305 focusing on SIP). Furthermore, Section 4.1 borrows also from [28] 306 and from [29]. 308 Two scenarios are meant to illustrate the functionality of SAML for 309 authorization in combination with bootstrapping. First, we describe 310 how authorization in a QoS signaling environment can be used and then 311 we illustrate a SIP service authorization example. 313 4.1 Authorization in QoS signaling protocols 315 Cryptographic computations are expensive and computing authorization 316 decisions might require a lot of time and multiple messages between 317 the entity enforcing the decisions and the entity computing the 318 authorization decision. Particularly in a mobile environment these 319 entities are physically separated - or not even in the same 320 administrative domain. Accordingly, the notion of "single sign-on" 321 is another potential application of authorization assertions, and 322 trait-based authorization - a user is authenticated and authorized 323 through one protocol, and can reuse the resulting authorization 324 assertion in other, potential unrelated protocol exchanges. 326 For example, in some environments it is useful to make the 327 authorization decision for a "high-level" service (such a voice 328 call). The authorization for the "voice call" itself might include 329 authorization for SIP signaling and also for lower level network 330 functions, for example a quality-of-service (QoS) reservation to 331 improve the performance of real-time media sessions established by 332 SIP. Since the SIP signaling protocol and the QoS reservation 333 protocol are totally separate, it is necessary to link the 334 authorization decisions of the two protocols. The authorization 335 decision might be valid for a number of different protocol exchanges, 336 for different protocols and for a certain duration or some other 337 attributes. 339 To enable this mechanism as part of the initial authorization step an 340 authorization assertion is returned to the end host of the SIP UAC 341 (cryptographically protected). If QoS is necessary, the end host 342 might reuse the returned assertion in the QoS signaling protocol. 343 Any domains in the federation that would honor the assertion 344 generated to authorize the SIP signaling would similar honor the use 345 of the assertion in the context of QoS. Upon the initial generation 346 of the assertion by an authorization server, traits could be added 347 that specify the desire level of quality that should be granted to 348 the media associated with a SIP session. 350 The message flow shown in Figure 4 illustrates such an exchange where 351 a client (such as a SIP user agent) uses some signaling exchange 352 which allows the end host to obtain an Artifact. This is Artifact is 353 later used as input for a QoS signaling protocol and provides client 354 authorization. The QoS aware router can either process the request 355 locally or use the Diameter QoS application for verifying the 356 authorization decision at the entity which created the Artifact. In 357 order to perform the processing local it is required to obtain an 358 Assertion rather than an Artifact (which is not further illustrated 359 in Figure 4). The DIAMETER QoS application contacts the Application 360 Server to obtain the Assertion, to authorize the request and to start 361 accounting. 363 Diameter QoS 364 Application 365 Enabled Router Application 366 Enforcement Pt Server 367 Application + 368 Client Domain 1 + Domain 2 369 | | + | 370 | Service Request (QoS) | 371 +------------+------------+-------------> 372 | | + | 373 | | + | 374 | Service Response (QoS',Artifact) | 375 <------------+------------+-------------+ 376 | | + | 377 | | + | 378 |NSIS(Artifact)| + | 379 +------------> + | 380 | | + | 381 | | -+-- | 382 | |QAR(Art.) - + -QAR(Art.) | 383 | +--------/> + --\--------> 384 | | / + \ | 385 | | / + \ | 386 | | | + | | 387 | | QAA(QoS) + QAA(QoS) | 388 | <------+--- + <---+------+ 389 | | | + | | 390 | | | Diameter | | 391 | | \ Network / | 392 | | \ + / | 393 | | \ + / | 394 | Authorization \- + -/ | 395 | Enforcement -+-- | 396 | Decision + | 397 | | + | 398 | | + | 399 | Allow or Terminate Flow | 400 <-----------+*+-------------------------> 401 | | + | 403 Figure 4: Message flow with NSIS and Diameter QoS Application 405 4.2 SIP Service Bootstrapping 407 This scenario exploits the inclusion of SAML for SIP which has been 408 introduced with [30]. 410 In Figure 5 user Alice runs a protocol with an Authentication Server 411 whereby authentication and authorization is provided. This protocol 412 exchange might be based on a number of protocols, such as EAP, PANA, 413 HTTP or something similar. It is not required that the 414 authentication and key exchange protocol terminates at this entity 415 but the Artificat is created and returned the the user (based on a 416 successful protocol execution). When a SIP message (e.g., an INVITE) 417 is sent towards a SIP Server or even to another SIP UA then the 418 Artifact is attached to the SIP message. As shown in Figure 5 the 419 SIP service contacts the Authentication Server (for example via 420 DIAMETER) to request the Assertion. This message exchange also 421 allows the SIP service to obtain keying material. 423 +--------+ +--------------+ +--------+ 424 |User | |Authentication| |SIP | 425 |Alice | |Server | |Service | 426 +---+----+ +------+-------+ +---+----+ 427 | | | 428 | EAP, PANA, HTTP | | 429 |<--------------------->| | 430 | | | 431 | Artifact | | 432 |<----------------------| | 433 | | | 434 | INVITE + SAML Artifact | 435 |-----------------------+--------------------->| 436 | | | 437 | | Fetch Assertion | 438 | |<---------------------| 439 | | | 440 | | Assertion | 441 | |--------------------->| 442 | | | 443 | 200 OK | | 444 |<----------------------+----------------------| 445 | | | 447 Figure 5: Message flow for SIP service authorization 449 5. Obtaining a SAML Artifact/Assertion 451 This section describes how an end host obtains an Artifact via PANA 452 or EAP which subsequently be used for service authorization. 453 Depending on whether the home network or the visited network should 454 create an Assertion/Artifact EAP and/or PANA will be used. If for 455 example, services in the visited network should be authorized then an 456 entity in the visited network should create the Assertion/Artifact 457 and it will be returned via PANA to the end host. 459 It is not suggested to exchange a SAML Assertion either via EAP or 460 via PANA. An Assertion is an XML document which is, for security 461 reasons, digitally signed. Both PANA and EAP/EAP methods suffer from 462 size limitations. EAP and most EAP methods do not support 463 fragmentation. PANA should avoid IP layer fragmentation. 465 A number of mechanisms exist to fetch an Assertion with the help of 466 an Artifact. HTTP is the most common mechanisms. This document also 467 suggests to use DIAMETER to assist in this step since it additionally 468 allows to distribute previously created keying material, to benefit 469 from accounting extensions [31] and other DIAMETER applications such 470 as Credit Control [32]. 472 EDITOR's Note: A "notification" mechanism might be useful to indicate 473 that the user wants to obtain an Artifact (or that the server does 474 not provide this extension). 476 5.1 SAML Artifact transport in EAP methods 478 Currently there are a number of EAP authentication methods that have 479 the capability to convey generic information items (e.g., PEAPv2 480 [33], EAP-PSK [34] or EAP-IKEv2 [35]). In fact they are being used 481 send additional information during authentication proccess inside a 482 protected channel between an EAP peer and the authenticator or 483 between the EAP peer and the EAP server in the case authenticator is 484 acting as a pass-through. This capability is, for example, being 485 considered to transport MIPv6 authorization data [13]. Following 486 this approach SAML information (i.e., the SAML artifact) could be 487 conveyed in this kinds of EAP methods too by creating another payload 488 or AVP that carries this information. 490 5.2 SAML Artifact transport in PANA 492 Another alternative, that would allow to use EAP methods that are not 493 able to transport generic information (e.g., EAP-TLS [36]), is to use 494 PANA protocol to convey authorization information (SAML artifact) 495 from the PANA Authentication Agent (PAA) to the PANA Authentication 496 Client (PaC). The usage of PANA provides more flexibility with 497 respect to the entity creating the artifact and the bootstrapped 498 service. This circumstance is shown in Figure 6. The PANA protocol 499 is used between the PAA and PaC. It might be necessary that a AAA 500 server is contacted. EAP is carried inside PANA and might then again 501 be encapsulated into a AAA protocol such as RADIUS or DIAMETER (see 502 [37] and [38]). AAA interaction with EAP is typically the case if a 503 user roams to a visited network and the EAP method runs between the 504 EAP peer and the EAP server (whereby the EAP server is at the user's 505 home network). The service which will be later used might be at a 506 different administrative domain. The service could be at the visited 507 network, at the home network or at any other network. To allow 508 bootstrapping to work it is necessary to have an existing trust 509 relationship between the entity that created the SAML assertion and 510 the service which will later use it. DIAMETER might be used between 511 these two entities to transfer keying material (and other 512 information). 514 If PANA terminates at the first hop router, as proposed in [1], then 515 PANA allows to create the SAML artifact in the visited network (by 516 some entity) and to subsequently use services either in the visited 517 network itself (as shown in Figure 4 or in networks which have some 518 trust relationship with the visited network with regard to the later 519 service usage. 521 +----------------+ 522 | Authentication | 523 | Authorization | 524 | Accounting | 525 | Server | 526 +----------------+ 527 ^ 528 |API/ 529 |AAA/EAP 530 | 531 v 532 +----------------+ +----------------+ 533 | PANA | PANA/EAP | PANA | 534 | Authentication |<---------------->| Authentication | 535 | Client | | Agent | 536 +----------------+ +----------------+ 537 ^ 538 | 539 |API/AAA 540 v 541 +----------------+ 542 | Entity | 543 | Running the | 544 | bootstrapped | 545 | Service | 546 +----------------+ 548 Figure 6: SAML Artifact transport in PANA 550 To create a working solution it is necessary that the SAML artifact 551 can be carried in a AAA protocol (e.g., DIAMETER or RADIUS) between 552 the AAA server and the PAA and is then finally delivered from the PAA 553 to the PaC by using PANA. According to the PANA specification [1] 554 the PANA-FirstAuth-End-Request (PFER) (if both NAP and ISP 555 authentication is carried out) and/or Pana-Binding-Request (PBR) 556 message can transport new AVPs. Confidentiality protection must be 557 provided for this purpose. Authorization information could be 558 carried by defining new AVPs to be transported inside these messages. 559 Note that new attributes or AVPs to carry SAML in DIAMETER (or 560 RADIUS) also need to be defined. 562 6. Binding Authorization Information to Credentials 564 SAML introduces the concept of a holder-of-the-key assertion to bind 565 the assertions (authorization information) to a cryptographic key. 566 See Section 5.1 of [2] 568 A number of credentials can be used with the KeyInfo element of the 569 Holder-of-the-Key assertion as described in Section 4.4 of [8], such 570 as: 572 o KeyName element, which is a string containing an identifier to a 573 key. 575 o KeyValue element, which contains the public key 577 o RetrievalMethod element, which is a reference to a key 579 o The X509Data element even contains one or more identifiers of 580 keys, X.509 certificates, certificate identifiers or a revocation 581 list. 583 o PGPData element that is used to convey information related to PGP 584 public key pairs 586 o SPKIData element carries information related to SPKI public key 587 pairs, certificates and other SPKI data. 589 o MgmtData element can contain a string value used to convey in-band 590 key distribution or agreement data 592 These concept allows the SAML assertion to be associated with the 593 bootstrapped credentials. For example, binding a public key to a 594 SAML assertion might also be a helpful when the public / private key 595 pair is also bootstrapped based using EAP and uses a pseudonym to 596 allow user identity confidentiality. In this case this approach 597 would provide credential based authorization. This would then allow 598 subsequent application layer protocols interactions to be secured 599 while authorization information can be attached and provided via 600 SAML. 602 Binding a Kerberos Ticket Granting Ticket or a Kerberos Service 603 Ticket to a SAML assertion is also possible but a Kerberos ticket 604 does not have a unique identifier, such as a SerialNumber provided by 605 X.509 certificates. One possible approach to attach the same unique 606 and randomly chosen identifier to both, the KeyName element and to 607 the authorization-data field of the encrypted part of the Kerberos 608 ticket. 610 Furthermore, it is possible to binding the SAML assertion to the 611 AAA-key. This binding therefore associates the network 612 authentication and authorization protocol run to the assertion. Each 613 time the user needs to re-authenticate, the assertion can be 614 presented to grant access to the network (and also allowing the both 615 entities to generate a new AAA-key). Such a procedure might be 616 helpful when handovers within different access routers in the access 617 network is desired (intra-domain mobility) or even with inter-domain 618 mobility. 620 7. Security Considerations 622 The security of the proposed mechanism relies on the selected EAP 623 method, on SAML and on the bootstrapping mechanism. A security 624 analysis of different EAP methods is outside the scope of this 625 document. It is assumed that the bootstrapping mechanism (possibly 626 involving AAA key distribution mechanisms) and the selected EAP 627 method is secure. 629 This section discusses a number of selected security threats and 630 their countermeasures. 632 7.1 Stolen Assertion 634 Threat: 636 If an eavesdropper can eavesdrop the SAML Assertion and construct 637 a service request, then the eavesdropper could be able to 638 impersonate the user at other entities. 640 Countermeasures: 642 By providing adequate confidentiality, eavesdropping of a SAML 643 assertion can be avoided. 645 7.2 MitM Attack 647 Threat: 649 Since the SAML assertion is presented to a service when 650 authorization is desired, a malicious service provider could 651 impersonate the user at some other entities. These entities would 652 believe that the adversary has the rights indicated in the 653 assertion. 655 Countermeasures: 657 If the adversary is a not-participating in the SIP signaling 658 itself (i.e., it is not a SIP proxy or a SIP UA), this threat can 659 be eliminated by employing inherent SIP security mechanisms , such 660 as TLS. However, if this entity is part of the communication 661 itself then reference integrity needs to be provided. Assertions 662 with tight restrictions (e.g., validity of the assertion) can also 663 limit the possible damage. 665 7.3 Forged Assertion 667 Threat: 669 A malicious user could forge or alter a SAML assertion in order to 670 communicate with other entities. 672 Countermeasures: 674 To avoid this kind of attack, the entities must assure that proper 675 mechanisms for protecting the SAML assertion needs to be in place. 676 It is recommended to protect the assertion using a digital 677 signature. Note that the current proposal uses Artifacts in most 678 places (EAP methods or PANA) and makes it therefore difficult for 679 an adversary to be able to mount such an attack. 681 7.4 Replay Attack 683 Threat: 685 An adversary who is able to gain access to an Assertion or an 686 Artificat might be able to attach this token to a resource request 687 to gain special priviliges. 689 Countermeasures: 691 The Artificat must be encrypted when the user obtains it. It also 692 needs to be transmitted encrypted when it is used for 693 authorization. To make it even more difficult for an adversary to 694 reuse the Artificat it is possible to associate credentials 695 (either symmetric or asymmetric keying material) with the 696 Assertion. An adversary can then only impersonate the legitimate 697 user if he knows the Artificat or Assertion and the corresponding 698 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. 712 This is, however, useless if a SAML Assertion again reveals the 713 true user identity. Since the Assertion is possibly only 714 exchanged using DIAMETER an adversary needs to be located at a AAA 715 client or server. The Artifcat itself does not reveal user 716 specific information since it is only a pointer to the Assertion. 717 Only legimiate entities are allowed to fetch the Assertion using 718 an Artifact. Furthermore, SAML does not mandate the inclusion of 719 a user identity in the Assertion. 721 8. Acknowledgments 723 We would like to thank Goeman Stefan and Rainer Falk for sharing 724 their thoughts with us. Furthermore, we would like to thank the 725 authors of [27] on trait-based authorization for SIP (namely Jon 726 Peterson, James Polk, Douglas Sicker and Marcus Tegnander) for their 727 discussions on the usage of SAML for IETF protocols. 729 The authors are working in two EU funded projects, namely Ambient 730 Networks and DAIDALOS. 732 Parts of this document are a byproduct of the Ambient Networks 733 Project, partially funded by the European Commission under its Sixth 734 Framework Programme. It is provided "as is" and without any express 735 or implied warranties, including, without limitation, the implied 736 warranties of fitness for a particular purpose. The views and 737 conclusions contained herein are those of the authors and should not 738 be interpreted as necessarily representing the official policies or 739 endorsements, either expressed or implied, of the Ambient Networks 740 Project or the European Commission. 742 The work described in this document is partiarly based on results of 743 IST FP6 Integrated Project DAIDALOS. DAIDALOS receives research 744 funding from the European Community's Sixth Framework Programme. 745 Apart from this, the European Commission has no responsibility for 746 the content of this paper. The information in this document is 747 provided as is and no guarantee or warranty is given that the 748 information is fit for any particular purpose. The user thereof uses 749 the information at its sole risk and liability. The views and 750 conclusions contained herein are those of the authors and should not 751 be interpreted as necessarily representing the official policies or 752 endorsements, either expressed or implied, of Daidalos Project or the 753 European Commission. 755 9. References 757 9.1 Normative References 759 [1] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin, 760 "Protocol for Carrying Authentication for Network Access 761 (PANA)", Internet-Draft draft-ietf-pana-pana-07, December 2004. 763 [2] Maler, E., Philpott, R. and P. Mishra, "Bindings and Profiles 764 for the OASIS Security Assertion Markup Language (SAML) V1.1", 765 September 2003. 767 [3] Maler, E., Philpott, R. and P. Mishra, "Assertions and Protocol 768 for the OASIS Security Assertion Markup Language (SAML) V1.1", 769 September 2003. 771 [4] Blunk, L., "Extensible Authentication Protocol (EAP)", 772 Internet-Draft draft-ietf-eap-rfc2284bis-09, February 2004. 774 [5] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 775 Authentication Dial In User Service (RADIUS)", RFC 2865, June 776 2000. 778 [6] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, 779 "Diameter Base Protocol", RFC 3588, September 2003. 781 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 782 Levels", March 1997. 784 [8] Eastlake, D., Reagle, J. and D. Solo, "XML-Signature Syntax and 785 Processing, W3C Recommendation (available at 786 http://www.w3.org/TR/xmldsig-core/)", February 2002. 788 9.2 Informative References 790 [9] Tschofenig, H. and D. Kroeselberg, "Next Steps for ENROLL", 791 Internet-Draft draft-tschofenig-enroll-next-steps-00, October 792 2004. 794 [10] Pritikin, M., "Trusted Transitive Introduction Model", 795 Internet-Draft draft-pritikin-ttimodel-01, July 2004. 797 [11] Patel, A., "Problem Statement for bootstrapping Mobile IPv6", 798 Internet-Draft draft-ietf-mip6-bootstrap-ps-01, October 2004. 800 [12] Jee, J., "Diameter Mobile IPv6 Bootstrapping Application using 801 PANA", Internet-Draft draft-jee-mip6-bootstrap-pana-00, October 802 2004. 804 [13] Giaretta, G., "MIPv6 Authorization and Configuration based on 805 EAP", Internet-Draft draft-giaretta-mip6-authorization-eap-02, 806 October 2004. 808 [14] Kempf, J., "Bootstrapping Mobile IPv6", 809 Internet-Draft draft-chakrabarti-mip6-bmip-00, December 2004. 811 [15] Tschofenig, H., Bournelle, J. and S. Thiruvengadam, 812 "Bootstrapping Mobile IPv6 using PANA", 813 Internet-Draft draft-tschofenig-mip6-bootstrapping-pana-00, 814 October 2004. 816 [16] Leung, K., "Authentication Protocol for Mobile IPv6", 817 Internet-Draft draft-ietf-mip6-auth-protocol-04, February 2005. 819 [17] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 820 RFC 3118, June 2001. 822 [18] Yegin, A., Tschofenig, H. and D. Forsberg, "Bootstrapping 823 RFC3118 Delayed DHCP Authentication Using EAP-based Network 824 Access Authentication", 825 Internet-Draft draft-yegin-eap-boot-rfc3118-01, January 2005. 827 [19] Tschofenig, H., "Bootstrapping RFC3118 Delayed authentication 828 using PANA", 829 Internet-Draft draft-tschofenig-pana-bootstrap-rfc3118-01, 830 October 2003. 832 [20] Tschofenig, H., "Bootstrapping Kerberos", 833 Internet-Draft draft-tschofenig-pana-bootstrap-kerberos-00, 834 July 2004. 836 [21] Aboba, B., "Extensible Authentication Protocol (EAP) Key 837 Management Framework", Internet-Draft draft-ietf-eap-keying-04, 838 November 2004. 840 [22] Maler, E. and J. Hughes, "Technical Overview of the OASIS 841 Security Assertion Markup Language (SAML) V1.1", March 2004. 843 [23] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B. 844 and T. Ylonen, "SPKI Certificate Theory", RFC 2693, September 845 1999. 847 [24] Farrell, S. and R. Housley, "An Internet Attribute Certificate 848 Profile for Authorization", RFC 3281, April 2002. 850 [25] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 851 Internet-Draft draft-ietf-ipsec-ikev2-17, October 2004. 853 [26] Bournelle, J., "Bootstrapping Mobile IPv6 using PANA", 854 Internet-Draft draft-bournelle-pana-mip6-00, December 2004. 856 [27] Peterson, J., "Trait-based Authorization Requirements for the 857 Session Initiation Protocol (SIP)", 858 Internet-Draft draft-ietf-sipping-trait-authz-00, February 859 2004. 861 [28] Alfano, F., "Diameter Quality of Service Application", 862 Internet-Draft draft-alfano-aaa-qosprot-01, October 2004. 864 [29] Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for 865 Quality-of-Service signaling", 866 Internet-Draft draft-ietf-nsis-qos-nslp-05, October 2004. 868 [30] Tschofenig, H., "Using SAML for SIP", 869 Internet-Draft draft-tschofenig-sip-saml-02, December 2004. 871 [31] Aboba, B. and J. Wood, "Authentication, Authorization and 872 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 874 [32] Mattila, L., Koskinen, J., Stura, M., Loughney, J. and H. 875 Hakala, "Diameter Credit-control Application", 876 Internet-Draft draft-ietf-aaa-diameter-cc-06, August 2004. 878 [33] Josefsson, S., Palekar, A., Simon, D. and G. Zorn, "Protected 879 EAP Protocol (PEAP) Version 2", 880 Internet-Draft draft-josefsson-pppext-eap-tls-eap-10, October 881 2004. 883 [34] Bersani, F., "The EAP-PSK Protocol: a Pre-Shared Key EAP 884 Method", Internet-Draft draft-bersani-eap-psk-06, November 885 2004. 887 [35] Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method 888 (EAP-IKEv2)", Internet-Draft draft-tschofenig-eap-ikev2-05, 889 October 2004. 891 [36] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", 892 RFC 2716, October 1999. 894 [37] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 895 In User Service) Support For Extensible Authentication Protocol 896 (EAP)", RFC 3579, September 2003. 898 [38] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 899 Authentication Protocol (EAP) Application", 900 Internet-Draft draft-ietf-aaa-eap-10, November 2004. 902 Authors' Addresses 904 Hannes Tschofenig 905 Siemens 906 Otto-Hahn-Ring 6 907 Munich, Bavaria 81739 908 Germany 910 Email: Hannes.Tschofenig@siemens.com 912 Gerardo Giaretta 913 Telecom Italia Lab 914 via G. Reiss Romoli, 274 915 TORINO, 10148 916 Italy 918 Email: gerardo.giaretta@tilab.com 920 Antonio F. Gomez-Skarmeta 921 University of Murcia 922 Campus de Espinardo s/n 923 Murcia, E-30100 924 Spain 926 Email: skarmeta@dif.um.es 928 Intellectual Property Statement 930 The IETF takes no position regarding the validity or scope of any 931 Intellectual Property Rights or other rights that might be claimed to 932 pertain to the implementation or use of the technology described in 933 this document or the extent to which any license under such rights 934 might or might not be available; nor does it represent that it has 935 made any independent effort to identify any such rights. Information 936 on the procedures with respect to rights in RFC documents can be 937 found in BCP 78 and BCP 79. 939 Copies of IPR disclosures made to the IETF Secretariat and any 940 assurances of licenses to be made available, or the result of an 941 attempt made to obtain a general license or permission for the use of 942 such proprietary rights by implementers or users of this 943 specification can be obtained from the IETF on-line IPR repository at 944 http://www.ietf.org/ipr. 946 The IETF invites any interested party to bring to its attention any 947 copyrights, patents or patent applications, or other proprietary 948 rights that may cover technology that may be required to implement 949 this standard. Please address the information to the IETF at 950 ietf-ipr@ietf.org. 952 Disclaimer of Validity 954 This document and the information contained herein are provided on an 955 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 956 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 957 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 958 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 959 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 960 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 962 Copyright Statement 964 Copyright (C) The Internet Society (2005). This document is subject 965 to the rights, licenses and restrictions contained in BCP 78, and 966 except as set forth therein, the authors retain all their rights. 968 Acknowledgment 970 Funding for the RFC Editor function is currently provided by the 971 Internet Society.