idnits 2.17.1 draft-jones-diameter-abfab-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4426 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) == Outdated reference: A later version (-28) exists of draft-ietf-dime-app-design-guide-13 == Outdated reference: A later version (-13) exists of draft-ietf-abfab-arch-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ABFAB M. Jones 3 Internet-Draft Bridgewater Systems 4 Intended status: Informational H. Tschofenig 5 Expires: September 13, 2012 Nokia Siemens Networks 6 March 12, 2012 8 The Diameter 'Application Bridging for Federated Access Beyond Web 9 (ABFAB)' Application 10 draft-jones-diameter-abfab-01.txt 12 Abstract 14 The Application Bridging for Federated Access Beyond Web (ABFAB) 15 architecture provides cross-domain authentication, authorization and 16 accounting functionality by utilizing well-established technologies, 17 such as Diameter, the Extensible Authentication Protocol (EAP), and 18 the Generic Security Services API (GSS-API). 20 This document defines a Diameter application for usage with the ABFAB 21 architecture to convey authentication information, and authorization 22 decisions from the Diameter server (acting as the identity provider) 23 to the Diameter client (acting as a relying party) encoded in a 24 Security Assertion Markup Language (SAML) encoding. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 13, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3. Application Identifiers . . . . . . . . . . . . . . . . . . . 7 63 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 64 4.1. Session Management . . . . . . . . . . . . . . . . . . . . 8 65 4.1.1. Session-Termination-Request . . . . . . . . . . . . . 9 66 4.1.2. Session-Termination-Answer . . . . . . . . . . . . . . 9 67 4.1.3. Abort-Session-Request . . . . . . . . . . . . . . . . 9 68 4.1.4. Abort-Session-Answer . . . . . . . . . . . . . . . . . 9 69 4.2. Accounting for ABFAB services . . . . . . . . . . . . . . 9 70 4.2.1. Accounting-Request . . . . . . . . . . . . . . . . . . 10 71 4.2.2. Accounting-Answer . . . . . . . . . . . . . . . . . . 10 72 5. Command Codes . . . . . . . . . . . . . . . . . . . . . . . . 11 73 5.1. Diameter-EAP-Request . . . . . . . . . . . . . . . . . . . 11 74 5.2. Diameter-EAP-Answer . . . . . . . . . . . . . . . . . . . 12 75 6. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 7. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 14 77 8. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 15 78 8.1. DER, DEA AVP/Command-Code Table . . . . . . . . . . . . . 15 79 8.2. Coupled Accounting Model AVP Table . . . . . . . . . . . . 15 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 17 82 9.2. Application Identifier . . . . . . . . . . . . . . . . . . 17 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 84 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 85 12. Normative References . . . . . . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 88 1. Introduction 90 The Application Bridging for Federated Access Beyond Web (ABFAB) 91 architecture [I-D.ietf-abfab-arch] provides cross-domain 92 authentication, authorization and accounting functionality by 93 utilizing well-established technologies, such as Diameter, the 94 Extensible Authentication Protocol (EAP), and the Generic Security 95 Services API (GSS-API). 97 The steps taken generally in an ABFAB federated authentication/ 98 authorization exchange are as follows: 100 1. Principal provides NAI to Application: Somehow the client is 101 configured with at least the realm portion of an NAI, which 102 represents the IdP to be discovered. 104 2. Authentication mechanism selection: this is the step necessary 105 to indicate that the GSS-EAP SASL/GS2 mechanism will be used for 106 authentication/authorization. 108 3. Client Application provides NAI to RP: At the conclusion of 109 mechanism selection the NAI must be provided to the RP for 110 discovery. 112 4. Discovery of federated IdP: This is discussed in detail below. 113 Either the RP is configured with authorized IdPs, or it makes 114 use of a federation proxy. 116 5. Request from Relying Party to IdP: Once the RP knows who the IdP 117 is, it or its agent will forward RADIUS request that 118 encapsulates a GSS/EAP access request to an IdP. This may or 119 may not contain a SAML request as a series of attributes. At 120 this stage, the RP will likely have no idea who the principal 121 is. The RP claims its identity to the IdP in AAA attributes, 122 and it makes whatever SAML Attribute Requests through a AAA 123 attribute. 125 6. IdP informs the principal of which EAP method to use: The 126 available and appropriate methods are discussed below in this 127 memo. 129 7. A bunch of EAP messages happen between the endpoints: Messages 130 are exchanged between the principal and the IdP until a result 131 is determined. The number and content of those messages will 132 depend on the EAP method. If the IdP is unable to authenticate 133 the principal, the process concludes here. As part of this 134 process, the principal will, under protection of EAP, assert the 135 identity of the RP to which it intends to authenticate. 137 8. Successful Authentication: At the very least the IdP (its EAP 138 server) and EAP peer / subject have authenticated one another. 139 As a result of this step, the subject and the IdP hold two 140 cryptographic keys- a Master Session Key (MSK), and an Extended 141 MSK (EMSK). If the asserted identity of the RP by the principal 142 matches the identity the RP itself asserted, there is some 143 confidence that the RP is now authenticated to the IdP. 145 9. Local IdP Policy Check: At this stage, the IdP checks local 146 policy to determine whether the RP and subject are authorized 147 for a given transaction/service, and if so, what if any, 148 attributes will be released to the RP. Additional policy checks 149 will likely have been made earlier just through the process of 150 discovery. 152 10. Response from the IdP to the Relying Party: Once the IdP has 153 made a determination of whether and how to authenticate or 154 authorize the principal to the RP, it returns either a negative 155 AAA result to the RP, or it returns a positive result to the RP, 156 along with an optional set of AAA attributes associated with the 157 principal that could include one or more SAML assertions. In 158 addition, an EAP MSK is returned to the subject. 160 11. RP Processes Results. When the RP receives the result from the 161 IdP, it should have enough information to either grant or refuse 162 a resource access request. It may have information that leads 163 it to make additional attribute queries. It may have 164 information that associates the principal with specific 165 authorization identies. It will apply these results in an 166 application-specific way. 168 12. RP returns results to principal: Once the RP has a response it 169 must inform the client application of the result. If all has 170 gone well, all are authenticated, and the application proceeds 171 with appropriate authorization levels. 173 The involved entities are shown in Figure 1. 175 +--------------+ 176 | AAA Server | 177 | (Identity | 178 | Provider) | 179 +-^----------^-+ 180 * EAP | RADIUS/ 181 * | Diameter 182 --v----------v-- 183 /// \\\ 184 // \\ *** 185 | Federation | back- 186 | | end 187 \\ // *** 188 \\\ /// 189 --^----------^-- 190 * EAP | RADIUS/ 191 Application * | Diameter 192 +-------------+ Data +-v----------v--+ 193 | |<---------------->| | 194 | Client | EAP/EAP Method | Server Side | 195 | Application |<****************>| Application | 196 | @ End Host | GSS-API |(Relying Party)| 197 | |<---------------->| | 198 | | Application | | 199 | | Protocol | | 200 | |<================>| | 201 +-------------+ +---------------+ 202 *** front-end *** 204 Legend: 206 <****>: End-to-end exchange 207 <---->: Hop-by-hop exchange 208 <====>: Protocol through which GSS-API/GS2 exchanges are tunnelled 210 Figure 1: Architecture for Federated Access of non-Web based 211 Applications 213 2. Terminology 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 217 document are to be interpreted as described in RFC 2119 [RFC2119]. 219 This document uses terminology defined [I-D.ietf-abfab-arch]. 221 3. Application Identifiers 223 This specification defines a new Diameter application and the 224 respective Application Identifier: 226 Diameter ABFAB (ABFAB) [[TBD by IANA]] 228 The Diameter ABFAB related accounting information generated by the 229 Diameter client uses the ABFAB Application Identifier in the case of 230 coupled accounting model. The Diameter Base Accounting Application 231 Identifier (value of 3) is used in case of the split accounting 232 model. Refer to Section 4.2 for more information regarding the 233 accounting models. 235 4. Protocol Description 237 Relying Party Client App IdP 239 | (1) | Client App gets NAI (somehow) 240 | | | 241 |<-----(2)----->| | Mechanism Selection 242 | | | 243 |<-----(3)-----<| | NAI transmitted to RP 244 | | | 245 |<=====(4)====================>| Discovery 246 | | | 247 |>=====(5)====================>| Access request from RP to IdP 248 | | | 249 | |< - - (6) - -<| EAP method to Principal 250 | | | 251 | |< - - (7) - ->| EAP Exchange to authenticate 252 | | | Principal 253 | | | 254 | | (8 & 9) Local Policy Check 255 | | | 256 |<====(10)====================<| IdP Assertion to RP 257 | | | 258 | | | (11) RP Processes results. 259 | | | 260 |>----(12)----->| | Results to client app. 262 ----- = Between Client App and RP 263 ===== = Between RP and IdP 264 - - - = Between Client App and IdP 266 Figure 2: Message Interaction Sequence 268 4.1. Session Management 270 The Diameter server may maintain state or may be stateless. This is 271 indicated in the Auth-Session-State AVP (or its absence). The 272 Diameter client MUST support the Authorization Session State Machine 273 defined in [RFC3588]. 275 4.1.1. Session-Termination-Request 277 The Session-Termination-Request (STR) message [RFC3588] is sent by 278 the Diameter client to inform the Diameter server that an authorized 279 session is being terminated. 281 4.1.2. Session-Termination-Answer 283 The Session-Termination-Answer (STA) message [RFC3588] is sent by the 284 Diameter server to acknowledge the notification that the session has 285 been terminated. 287 4.1.3. Abort-Session-Request 289 The Abort-Session-Request (ASR) message [RFC3588] is sent by the 290 Diameter server to the Diameter client to terminate the authorized 291 session. When the Diameter client receives the ASR message, it MUST 292 take further actions to terminate the established application 293 context. 295 4.1.4. Abort-Session-Answer 297 The Abort-Session-Answer (ASA) message [RFC3588] is sent by the Home 298 Agent in response to an ASR message. 300 4.2. Accounting for ABFAB services 302 The Diameter client collects accounting records needed for service 303 control and charging MUST support the accounting procedures and the 304 Accounting Session State Machine as defined in [RFC3588]. 306 The Diameter application design guideline 307 [I-D.ietf-dime-app-design-guide] defines two separate models for 308 accounting: 310 Split accounting model: 312 According to this model, the accounting messages use the Diameter 313 Base Accounting Application Identifier (value of 3). Since 314 accounting is treated as an independent application, accounting 315 commands may be routed separately from the rest of application 316 messages and thus the accounting messages generally end up in a 317 central accounting server. Since the Diameter ABFAB application 318 does not define its own unique accounting commands, this is the 319 preferred choice, since it permits use of centralized accounting 320 for several applications. 322 Coupled accounting model: 324 In this model, the accounting messages will use the ABFAB 325 Application Identifiers. This means that accounting messages will 326 be routed like any other Diameter ABFAB application messages. 327 This requires the Diameter server in charge of the Diameter ABFAB 328 application to handle the accounting records (e.g., sends them to 329 a proper accounting server). 331 As mentioned above, the preferred choice is to use the split 332 accounting model and thus to choose Diameter Base Accounting 333 Application Identifier (value of 3) for accounting messages. 335 4.2.1. Accounting-Request 337 The Accounting-Request command [RFC3588] is sent by the Diameter 338 client to the Diameter server to exchange accounting information. 340 4.2.2. Accounting-Answer 342 The Accounting-Answer command [RFC3588] is sent by the Diameter 343 server to the Diameter client to acknowledge an Accounting-Request. 345 5. Command Codes 347 The Diameter ABFAB application defined in this document reuses the 348 Diameter EAP application [RFC4072] commands: Diameter-EAP-Request 349 (DER) and Diameter-EAP-Answer (DEA). This specification extends the 350 existing DER and DEA command ABNFs to offer the necessary ABFAB 351 functionality. Other than new additional AVPs and the corresponding 352 additions to the command ABNFs, the Diameter EAP application command 353 ABNFs remain unchanged. The ABNF language is defined in [RFC3588]. 355 Command-Name Abbrev. Code Reference 356 --------------------------------------------- 357 Diameter-EAP-Request DER 268 RFC 4072 358 Diameter-EAP-Answer DEA 268 RFC 4072 360 Figure 3: Command Codes 362 5.1. Diameter-EAP-Request 364 The Diameter-EAP-Request (DER) message, indicated by the Command-Code 365 field set to 268 and the 'R' bit set in the Command Flags field, is 366 sent by the Diameter client to the Diameter server to initiate a 367 Diameter ABFAB authentication and authorization procedure. The 368 Application-ID field of the Diameter Header MUST be set to the 369 Diameter ABFAB Application ID (value of TDB). 371 ::= < Diameter Header: 268, REQ, PXY > 372 < Session-Id > 373 { Auth-Application-Id } 374 { Origin-Host } 375 { Origin-Realm } 376 { Destination-Realm } 377 { Auth-Request-Type } 378 [ Destination-Host ] 379 [ NAS-Identifier ] 380 [ NAS-IP-Address ] 381 [ NAS-IPv6-Address ] 382 [ NAS-Port-Type ] 383 [ User-Name ] 384 ... 385 { EAP-Payload } 386 ... 387 [ SAML-AuthnRequest ] 388 ... 389 * [ AVP ] 391 The SAML-AuthnRequest AVP is only included in the first DER message 392 send by the Diameter client. The user is both authenticated and 393 during the EAP method authentication. Authorization happens 394 immediately after the authentication procedure has been completed. 395 Thus, the Auth-Request-Type AVP MUST be set to the value 396 AUTHORIZE_AUTHENTICATE. 398 5.2. Diameter-EAP-Answer 400 The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code 401 field set to 268 and 'R' bit cleared in the Command Flags field, is 402 sent in response to the Diameter-EAP-Request message (DER). The 403 Application-Id field in the Diameter message header MUST be set to 404 the Diameter ABFAB Application-Id (value of TBD). 406 ::= < Diameter Header: 268, PXY > 407 < Session-Id > 408 { Auth-Application-Id } 409 { Auth-Request-Type } 410 { Result-Code } 411 { Origin-Host } 412 { Origin-Realm } 413 [ User-Name ] 414 [ EAP-Payload ] 415 [ EAP-Reissued-Payload ] 416 [ EAP-Master-Session-Key ] 417 [ EAP-Key-Name ] 418 [ Multi-Round-Time ] 419 ... 420 [ SAML-AuthnResponse ] 421 [ SAML-Assertion ] 422 ... 423 * [ AVP ] 425 SAML related attributes are only included in the final message 426 exchange. Either the SAML-AuthnResponse AVP is included in the 427 response or a SAML-Assertion but not both. 429 6. AVPs 431 +--------------------+ 432 | AVP Flag rules | 433 +----+---+------+----+----+ 434 AVP | | |SHOULD|MUST|MAY | 435 Attribute Name Code Value Type |MUST|MAY| NOT | NOT|Encr| 436 +-------------------------------------+----+---+------+----+----+ 437 |SAML-Assertion TBD UTF8String | | P | | V | Y | 438 +-------------------------------------+----+---+------+----+----+ 439 |SAML-AuthnRequest TBD UTF8String | | P | | V | Y | 440 +-------------------------------------+----+---+------+----+----+ 441 |SAML-AuthnResponse TBD UTF8String | | P | | V | Y | 442 +-------------------------------------+----+---+------+----+----+ 444 AVPs for the Diameter ABFAB Application 446 [Editor's Note: SAML encryption requirements are FFS. The "MAY Encr" 447 column in the above table refers to XML-Enc rather than the defunct 448 Diameter AVP encryption.] 450 The SAML-Assertion AVP contains the UTF8String encoded SAML 451 assertion. 453 The SAML-AuthnRequest AVP contains the UTF8String encoded SAML 454 AuthnRequest message. 456 The SAML-AuthnResponse AVP contains the UTF8String encoded SAML 457 AuthnResponse message. 459 7. Result-Code AVP Values 461 This section defines new Result-Code [RFC3588] values that MUST be 462 supported by all Diameter implementations that conform to this 463 specification. 465 [Editor's Note: ABFAB specific error values may need to be added 466 here.] 468 8. AVP Occurrence Tables 470 The following tables present the AVPs defined in this document and 471 their occurrences in Diameter messages. 473 The table uses the following symbols: 475 0: 477 The AVP MUST NOT be present in the message. 479 0+: 481 Zero or more instances of the AVP MAY be present in the message. 483 0-1: 485 Zero or one instance of the AVP MAY be present in the message. 487 1: 489 One instance of the AVP MUST be present in the message. 491 8.1. DER, DEA AVP/Command-Code Table 493 +------------+ 494 |Command-Code| 495 |-----+------+ 496 AVP Name | DER | DEA | 497 -------------------------------|-----+------+ 498 SAML-Assertion | 0 | 1 | 499 SAML-AuthnRequest | 1 | 0 | 500 SAML-AuthnResponse | 0 | 1 | 501 +-----+------+ 503 [Editor's Note: Is it possible to return more than one SAML- 504 Assertion?] 506 8.2. Coupled Accounting Model AVP Table 508 The table in this section is used to represent which AVPs defined in 509 this document are to be present in the Accounting messages, as 510 defined in [RFC3588]. 512 +-------------+ 513 | Command-Code| 514 |------+------+ 515 Attribute Name | ACR | ACA | 516 -------------------------------------|------+------+ 517 Accounting-Input-Octets | 0-1 | 0-1 | 518 Accounting-Input-Packets | 0-1 | 0-1 | 519 Accounting-Output-Octets | 0-1 | 0-1 | 520 Accounting-Output-Packets | 0-1 | 0-1 | 521 Acct-Multi-Session-Id | 0-1 | 0-1 | 522 Acct-Session-Time | 0-1 | 0-1 | 523 -------------------------------------|------+------+ 525 [Editor's Note: Do we need any application specific accounting 526 messages for ABFAB?] 528 9. IANA Considerations 530 This section contains the namespaces that have either been created in 531 this specification or had their values assigned to existing 532 namespaces managed by IANA. 534 9.1. AVP Codes 536 This specification requires IANA to register the following new AVPs 537 from the AVP Code namespace defined in [RFC3588]. 539 o SAML-Assertion 541 o SAML-AuthnRequest 543 o SAML-AuthnResponse 545 The AVPs are defined in Section 8. 547 9.2. Application Identifier 549 This specification requires IANA to allocate a new application ID 550 from the Application Identifier namespace defined in [RFC3588]. 552 Application Identifier | Value 553 -----------------------------------+------ 554 Diameter ABFAB (ABFAB) | TBD 556 10. Security Considerations 557 11. Acknowledgments 558 12. Normative References 560 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 561 Requirement Levels", BCP 14, RFC 2119, March 1997. 563 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 564 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 566 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 567 Authentication Protocol (EAP) Application", RFC 4072, 568 August 2005. 570 [I-D.ietf-dime-app-design-guide] 571 Fajardo, V., Tschofenig, H., and L. Morand, "Diameter 572 Applications Design Guidelines", 573 draft-ietf-dime-app-design-guide-13 (work in progress), 574 January 2012. 576 [I-D.ietf-abfab-arch] 577 Howlett, J., Hartman, S., Tschofenig, H., and E. Lear, 578 "Application Bridging for Federated Access Beyond Web 579 (ABFAB) Architecture", draft-ietf-abfab-arch-01 (work in 580 progress), March 2012. 582 Authors' Addresses 584 Mark Jones 585 Bridgewater Systems 587 Email: mark@azu.ca 589 Hannes Tschofenig 590 Nokia Siemens Networks 591 Linnoitustie 6 592 Espoo 02600 593 Finland 595 Phone: +358 (50) 4871445 596 Email: Hannes.Tschofenig@gmx.net 597 URI: http://www.tschofenig.priv.at