idnits 2.17.00 (12 Aug 2021) /tmp/idnits48362/draft-ietf-abfab-arch-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1181: '...A infrastructure MAY hide the peer's i...' RFC 2119 keyword, line 1545: '... by an IdP, care MUST be taken in the ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 3497 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'X' is mentioned on line 1275, but not defined == Unused Reference: 'RFC2903' is defined on line 1612, but no explicit reference was found in the text == Unused Reference: 'RFC4017' is defined on line 1634, but no explicit reference was found in the text == Unused Reference: 'RFC5106' is defined on line 1638, but no explicit reference was found in the text == Unused Reference: 'RFC2138' is defined on line 1654, but no explicit reference was found in the text == Unused Reference: 'RFC2904' is defined on line 1683, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) == Outdated reference: draft-ietf-abfab-gss-eap has been published as RFC 7055 == Outdated reference: draft-ietf-abfab-aaa-saml has been published as RFC 7833 == Outdated reference: draft-ietf-oauth-v2 has been published as RFC 6749 == Outdated reference: draft-iab-privacy-considerations has been published as RFC 6973 -- Obsolete informational reference (is this intentional?): RFC 2138 (Obsoleted by RFC 2865) -- Obsolete informational reference (is this intentional?): RFC 5849 (Obsoleted by RFC 6749) -- No information found for draft-ietf-emu-eap-tunnel-method - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ABFAB J. Howlett 3 Internet-Draft JANET(UK) 4 Intended status: Informational S. Hartman 5 Expires: April 25, 2013 Painless Security 6 H. Tschofenig 7 Nokia Siemens Networks 8 E. Lear 9 Cisco Systems GmbH 10 J. Schaad 11 Soaring Hawk Consulting 12 October 22, 2012 14 Application Bridging for Federated Access Beyond Web (ABFAB) 15 Architecture 16 draft-ietf-abfab-arch-04.txt 18 Abstract 20 Over the last decade a substantial amount of work has occurred in the 21 space of federated access management. Most of this effort has 22 focused on two use-cases: network and web-based access. However, the 23 solutions to these use-cases that have been proposed and deployed 24 tend to have few common building blocks in common. 26 This memo describes an architecture that makes use of extensions to 27 the commonly used security mechanisms for both federated and non- 28 federated access management, including the Remote Authentication Dial 29 In User Service (RADIUS) and the Diameter protocol, the Generic 30 Security Service (GSS), the GS2 family, the Extensible Authentication 31 Protocol (EAP) and the Security Assertion Markup Language (SAML). 32 The architecture addresses the problem of federated access management 33 to primarily non-web-based services, in a manner that will scale to 34 large numbers of identity providers, relying parties, and 35 federations. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 25, 2013. 54 Copyright Notice 56 Copyright (c) 2012 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.2. An Overview of Federation . . . . . . . . . . . . . . . . 6 74 1.3. Challenges for Contemporary Federation . . . . . . . . . . 9 75 1.4. An Overview of ABFAB-based Federation . . . . . . . . . . 10 76 1.5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . 13 77 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 2.1. Relying Party to Identity Provider . . . . . . . . . . . . 15 79 2.1.1. AAA, RADIUS and Diameter . . . . . . . . . . . . . . . 16 80 2.1.2. Discovery and Rules Determination . . . . . . . . . . 17 81 2.1.3. Routing and Technical Trust . . . . . . . . . . . . . 18 82 2.1.4. SAML Assertions . . . . . . . . . . . . . . . . . . . 20 83 2.2. Client To Identity Provider . . . . . . . . . . . . . . . 21 84 2.2.1. Extensible Authentication Protocol (EAP) . . . . . . . 21 85 2.2.2. EAP Channel Binding . . . . . . . . . . . . . . . . . 23 86 2.3. Client to Relying Party . . . . . . . . . . . . . . . . . 23 87 2.3.1. GSS-API . . . . . . . . . . . . . . . . . . . . . . . 23 88 2.3.2. Protocol Transport . . . . . . . . . . . . . . . . . . 25 89 3. Application Security Services . . . . . . . . . . . . . . . . 26 90 3.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 26 91 3.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 27 92 3.3. Host-Based Service Names . . . . . . . . . . . . . . . . . 28 93 3.4. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 29 94 4. Future Work: Attribute Providers . . . . . . . . . . . . . . . 30 95 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 31 96 5.1. Entities and their roles . . . . . . . . . . . . . . . . . 31 97 5.2. Relationship between user and entities . . . . . . . . . . 32 98 5.3. Data and Identifiers in use . . . . . . . . . . . . . . . 32 99 5.3.1. NAI . . . . . . . . . . . . . . . . . . . . . . . . . 32 100 5.3.2. Identity Information . . . . . . . . . . . . . . . . . 33 101 5.3.3. Accounting Information . . . . . . . . . . . . . . . . 33 102 5.3.4. Collection and retention of data and identifiers . . . 33 103 5.4. User Participation . . . . . . . . . . . . . . . . . . . . 34 104 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 35 105 6.1. EAP Channel Binding . . . . . . . . . . . . . . . . . . . 35 106 6.2. AAA Proxy Behavior . . . . . . . . . . . . . . . . . . . . 35 107 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 108 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 109 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 110 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 111 10.1. Normative References . . . . . . . . . . . . . . . . . . . 40 112 10.2. Informative References . . . . . . . . . . . . . . . . . . 40 113 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 116 1. Introduction 118 The Internet uses numerous security mechanisms to manage access to 119 various resources. These mechanisms have been generalized and scaled 120 over the last decade through mechanisms such as Simple Authentication 121 and Security Layer (SASL) with the Generic Security Server 122 Application Program Interface (GSS-API) (known as the GS2 family) 123 [RFC5801], Security Assertion Markup Language (SAML) 124 [OASIS.saml-core-2.0-os], and the Authentication, Authorization, and 125 Accounting (AAA) architecture as embodied in RADIUS [RFC2865] and 126 Diameter [RFC3588]. 128 A Relying Party (RP) is the entity that manages access to some 129 resource. The actor that is requesting access to that resource is 130 often described as the Client. Many security mechanisms are 131 manifested as an exchange of information between these actors. The 132 RP is therefore able to decide whether the Client is authorized, or 133 not. 135 Some security mechanisms allow the RP to delegate aspects of the 136 access management decision to an actor called the Identity Provider 137 (IdP). This delegation requires technical signaling, trust and a 138 common understanding of semantics between the RP and IdP. These 139 aspects are generally managed within a relationship known as a 140 'federation'. This style of access management is accordingly 141 described as 'federated access management'. 143 Federated access management has evolved over the last decade through 144 specifications like SAML [OASIS.saml-core-2.0-os], OpenID [1], OAuth 145 [RFC5849], [I-D.ietf-oauth-v2] and WS-Trust [WS-TRUST]. The benefits 146 of federated access management include: 148 Single or Simplified sign-on: 150 An Internet service can delegate access management, and the 151 associated responsibilities such as identity management and 152 credentialing, to an organisation that already has a long-term 153 relationship with the Subject. This is often attractive for 154 Relying Parties who frequently do not want these responsibilities. 155 The Subject also requires fewer credentials, which is also 156 desirable. 158 Data Minimization and User Participation: 160 Often a Relying Party does not need to know the identity of a 161 Subject to reach an access management decision. It is frequently 162 only necessary for the Relying Party know specific attributes 163 about the subject, for example, that the Subject is affiliated 164 with a particular organisation or has a certain role or 165 entitlement. Sometimes the RP only needs to know a pseudonym of 166 the Subject. 168 Prior to the release of attributes to the IdP from the IdP, the 169 IdP will check configuration and policy to determine if the 170 attributes are to be released. There is currently no direct 171 client participation in this decision. 173 Provisioning 175 Sometimes a Relying Party needs, or would like, to know more about 176 a subject than an affiliation or a pseudonym. For example, a 177 Relying Party may want the Subject's email address or name. Some 178 federated access management technologies provide the ability for 179 the IdP to supply this information, either on request by the RP or 180 unsolicited. 182 This memo describes the Application Bridging for Federated Access 183 Beyond the Web (ABFAB) architecture. This architecture makes use of 184 extensions to the commonly used security mechanisms for both 185 federated and non-federated access management, including the RADIUS 186 and the Diameter protocols, the Generic Security Service (GSS), the 187 GS2 family, the Extensible Authentication Protocol (EAP) and SAML. 188 The architecture addresses the problem of federated access management 189 primarily for non-web-based services. It does so in a manner that 190 will scale to large numbers of identity providers, relying parties, 191 and federations. 193 1.1. Terminology 195 This document uses identity management and privacy terminology from 196 [I-D.iab-privacy-considerations]. In particular, this document uses 197 the terms identity provider, relying party, (data) subject, 198 identifier, pseudonymity, unlinkability, and anonymity. 200 In this architecture the IdP consists of the following components: an 201 EAP server, a RADIUS or a Diameter server, and optionally a SAML 202 Assertion service. 204 This document uses the term Network Access Identifier (NAI), as 205 defined in [RFC4282]. An NAI consists of a realm identifier, which 206 is associated with an IdP and a username which is associated with a 207 specific client of the IdP. 209 One of the problems people will find with reading this document is 210 that the terminology sometimes appears to be inconsistent. This is 211 due the fact that the terms used by the different standards we are 212 picking up don't use the same terms. In general the document uses 213 either a consistent term or the term associated with the standard 214 under discussion as appropriate. For reference we include this table 215 which maps the different terms into a single table. 217 +----------+-----------+--------------------+-----------------------+ 218 | Protocol | Subject | Relying Party | Identity Provider | 219 +----------+-----------+--------------------+-----------------------+ 220 | ABFAB | Client | Relying Party (RP) | Identity Provider | 221 | | | | (IdP) | 222 | | | | | 223 | | Initiator | Acceptor | | 224 | | | | | 225 | SAML | Subject | Service Provider | Issuer | 226 | | | | | 227 | GSS-API | Initiator | Acceptor | | 228 | | | | | 229 | EAP | EAP peer | | EAP server | 230 | | | | | 231 | AAA | | AAA Client | AAA server | 232 | | | | | 233 | RADIUS | user | NAS | RADIUS server | 234 | | | | | 235 | | | RADIUS client | | 236 +----------+-----------+--------------------+-----------------------+ 238 Note that in some cases a cell has been left empty, in these cases 239 there is no direct name that represents this concept. 241 Note to reviewers - I have most likely missed some entries in the 242 table. Please provide me with both correct names from the protocol 243 and missing names that are used in the text below. 245 1.2. An Overview of Federation 247 In the previous section we introduced the following actors: 249 o the Client, 251 o the Identity Provider, and 253 o the Relying Party. 255 One additional actor in can be an Individual. An individual is a 256 human being that is using a client. Individuals may or may not exist 257 in any given deployment. The client may be either a front end on an 258 individual or an independent automated entity. 260 These entities and their relationships are illustrated graphically in 261 Figure 1. 263 ,----------\ ,---------\ 264 | Identity | Federation | Relying | 265 | Provider + <-------------------> + Party | 266 `----------' '---------' 267 < 268 \ 269 \ Authentication 270 \ 271 \ 272 \ 273 \ 274 \ +---------+ 275 \ | | O 276 v| Client | \|/ Individual 277 | | | 278 +---------+ / \ 280 Figure 1: Entities and their Relationships 282 The relationships between the entities in Figure 1 are: 284 Federation 286 The Identity Provider and the Relying Parties are part of a 287 Federation. The relationship may be direct (they have an explicit 288 trust relationship) or transitive (the trust releationship is 289 mediated by one or more entities). The federation relationship is 290 governed by a federation agreement. Within a single federation, 291 there may be multiple Identity Providers as well as multiple 292 Relying Parties. A federation is governed by a federation 293 agreement. 295 Authentication 297 There is a direct relationship between the Client and the Identity 298 Provider by which the entities trust and can securely authenticate 299 each other. 301 A federation agreement typically encompasses operational 302 specifications and legal rules: 304 Operational Specifications: 306 These includes the technical specifications (e.g. protocols used 307 to communicate between the three parties), process standards, 308 policies, identity proofing, credential and authentication 309 algorithm requirements, performance requirements, assessment and 310 audit criteria, etc. The goal of operational specifications is to 311 provide enough definition that the system works and 312 interoperability is possible. 314 Legal Rules: 316 The legal rules take the legal framework into consideration and 317 provides contractual obligations for each entity. The rules 318 define the responsibilities of each party and provide further 319 clarification of the operational specifications. These legal 320 rules regulate the operational specifications, make operational 321 specifications legally binding to the participants, define and 322 govern the rights and responsibilities of the participants. The 323 legal rules may, for example, describe liability for losses, 324 termination rights, enforcement mechanisms, measures of damage, 325 dispute resolution, warranties, etc. 327 The Operational Specifications can demand the usage of a 328 sophisticated technical infrastructure, including requirements on the 329 message routing intermediaries, to offer the required technical 330 functionality. In other environments, the Operational Specifications 331 require fewer technical components in order to meet the required 332 technical functionality. 334 The Legal Rules include many non-technical aspects of federation, 335 such as business practices and legal arrangements, which are outside 336 the scope of the IETF. The Legal Rules can still have an impact the 337 architectural setup or on how to ensure the dynamic establishment of 338 trust. 340 While a federation agreement is often discussed within the context of 341 formal relationships, such as between an enterprise and an employee 342 or a government and a citizen, a federation agreement does not have 343 to require any particular level of formality. For an IdP and a 344 Client, it is sufficient for a relationship to be established by 345 something as simple as using a web form and confirmation email. For 346 an IdP and an RP, it is sufficient for the IdP to publish contact 347 information along with a public key and for the RP to use that data. 348 With in the framework of ABFAB, it will generally be required that a 349 mechanism exists for the IdP to be able to trust the identity of the 350 RP, if this is not present then the IdP cannot provide the assurances 351 to the client that the identity of the RP has been established. 353 The nature of federation dictates that there is some form of 354 relationship between the identity provider and the relying party. 355 This is particularly important when the relying party wants to use 356 information obtained from the identity provider for access management 357 decisions and when the identity provider does not want to release 358 information to every relying party (or only under certain 359 conditions). 361 While it is possible to have a bilateral agreement between every IdP 362 and every RP; on an Internet scale this setup requires the 363 introduction of the multi-lateral federation concept, as the 364 management of such pair-wise relationships would otherwise prove 365 burdensome. 367 The IdP will typically have a long-term relationship with the Client. 368 This relationship typically involves the IdP positively identifying 369 and credentialing the Client (for example, at time of employment 370 within an organization). The relationship will often be instantiated 371 within an agreement between the IdP and the Client (for example, 372 within an employment contract or terms of use that stipulates the 373 appropriate use of credentials and so forth). 375 The nature and quality of the relationship between the Subject and 376 the IdP is an important contributor to the level of trust that an RP 377 may attribute to an assertion describing a Client made by an IdP. 378 This is sometimes described as the Level of Assurance. 380 Federation does not require an a priori relationship or a long-term 381 relationship between the RP and the Client; it is this property of 382 federation that yields many of its benefits. However, federation 383 does not preclude the possibility of a pre-existing relationship 384 between the RP and the Client, nor that they may use the introduction 385 to create a new long-term relationship independent of the federation. 387 Finally, it is important to reiterate that in some scenarios there 388 might indeed be an Individual behind the Client and in other cases 389 the Client may be autonomous. 391 1.3. Challenges for Contemporary Federation 393 As the number of federated services has proliferated, the role of the 394 individual can become ambiguous in certain circumstances. For 395 example, a school might provide online access for a student's grades 396 to their parents for review, and to the student's teacher for 397 modification. A teacher who is also a parent must clearly 398 distinguish her role upon access. 400 Similarly, as the number of federations proliferates, it becomes 401 increasingly difficult to discover which identity provider(s) a user 402 is associated with. This is true for both the web and non-web case, 403 but is particularly acute for the latter as many non-web 404 authentication systems are not semantically rich enough on their own 405 to allow for such ambiguities. For instance, in the case of an email 406 provider, the use of SMTP and IMAP protocols do not have the ability 407 for the server to get additional information, beyond the clients NAI, 408 in order to provide additional input to decide between multiple 409 federations it may be associated with. However, the building blocks 410 do exist to add this functionality. 412 1.4. An Overview of ABFAB-based Federation 414 The previous section described the general model of federation, and 415 its the application of federated access management. This section 416 provides a brief overview of ABFAB in the context of this model. 418 In this example, a client is attempting to connect to a server in 419 order to either get access to some data or perform some type of 420 transaction. In order for the client to mutually authenticate with 421 the server, the following steps are taken in an ABFAB federated 422 architecture: 424 1. Client Configuration: The Client Application is configured with 425 an NAI assigned by the IdP. It is also configured with any 426 keys, certificates, passwords or other secret and public 427 information needed to run the EAP protocols between it and the 428 IdP. 430 2. Authentication mechanism selection: The GSS-EAP GSS-API 431 mechanism is selected for authentication/authorization. 433 3. Client provides an NAI to RP: The client application sets up a 434 transport to the RP and begins the GSS-EAP authentication. In 435 response, the RP sends an EAP request message (nested in the 436 GSS-EAP protocol) asking for the Client's name. The Client 437 sends an EAP response with an NAI name form that at a minimum, 438 contains the realm portion of it's full NAI. 440 4. Discovery of federated IdP: The RP uses pre-configured 441 information or a federation proxy to determine what IdP to use 442 based on policy and the realm portion of the provided Client 443 NAI. This is discussed in detail below (Section 2.1.2). 445 5. Request from Relying Party to IdP: Once the RP knows who the IdP 446 is, it (or its agent) will send a RADIUS/Diameter request to the 447 IdP. The RADIUS/Diameter access request encapsulates the EAP 448 response. At this stage, the RP will likely have no idea who 449 the client is. The RP sends its identity to the IdP in AAA 450 attributes, and it may send a SAML Attribute Requests in a AAA 451 attribute. The AAA network checks that the identity claimed by 452 the RP is valid. 454 6. IdP begins EAP with the client: The IdP sends an EAP message to 455 the client with an EAP method to be run. The IdP may re-request 456 the clients name in this message, but this is unexpected 457 behavior. The available and appropriate methods are discussed 458 below in this memo (Section 2.2.1). 460 7. The EAP protocol is run: A bunch of EAP messages are passed 461 between the client (EAP peer) and the IdP (EAP server), until 462 the result of the authentication protocol is determined. The 463 number and content of those messages depends on the EAP method 464 selected. If the IdP is unable to authenticate the client, the 465 IdP sends a EAP failure message to the RP. As part of the EAP 466 protocol, the client sends a channel bindings EAP message to the 467 IdP (Section 2.2.2). In the channel binding message the client 468 identifies, among other things, the RP to which it is attempting 469 to authenticate. The IdP checks the channel binding data from 470 the client with that provided by the RP via the AAA protocol. 471 If the bindings do not match the IdP sends an EAP failure 472 message to the RP. 474 8. Successful EAP Authentication: At this point, the IdP (EAP 475 server) and client (EAP peer) have mutually authenticated each 476 other. As a result, the subject and the IdP hold two 477 cryptographic keys: a Master Session Key (MSK), and an Extended 478 MSK (EMSK). At this point the client has a level of assurance 479 about the identity of the RP based on the name checking the IdP 480 has done using the RP naming information from the AAA framework 481 and from the client (by the channel binding data). 483 9. Local IdP Policy Check: At this stage, the IdP checks local 484 policy to determine whether the RP and client are authorized for 485 a given transaction/service, and if so, what if any, attributes 486 will be released to the RP. If the IdP gets a policy failure, 487 it sends an EAP failure message to the RP.[anchor4] (The RP will 488 have done its policy checks during the discovery process.) 490 10. IdP provide the RP with the MSK: The IdP sends a positive result 491 EAP to the RP, along with an optional set of AAA attributes 492 associated with the client (usually as one or more SAML 493 assertions). In addition, the EAP MSK is returned to the RP. 495 11. RP Processes Results: When the RP receives the result from the 496 IdP, it should have enough information to either grant or refuse 497 a resource access request. It may have information that 498 associates the client with specific authorization identities. 499 If additional attributes are needed from the IdP the RP may make 500 a new SAML Request to the IdP. It will apply these results in 501 an application-specific way. 503 12. RP returns results to client: Once the RP has a response it must 504 inform the client application of the result. If all has gone 505 well, all are authenticated, and the application proceeds with 506 appropriate authorization levels. The client can now complete 507 the authentication of the RP by the use of the EAP MSK value. 509 An example communication flow is given below: 511 Relying Client Identity 512 Party App Provider 514 | (1) | Client Configuration 515 | | | 516 |<-----(2)----->| | Mechanism Selection 517 | | | 518 |<-----(3)-----<| | NAI transmitted to RP 519 | | | 520 |<=====(4)====================>| Discovery 521 | | | 522 |>=====(5)====================>| Access request from RP to IdP 523 | | | 524 | |< - - (6) - -<| EAP method to Client 525 | | | 526 | |< - - (7) - ->| EAP Exchange to authenticate 527 | | | Client 528 | | | 529 | | (8 & 9) Local Policy Check 530 | | | 531 |<====(10)====================<| IdP Assertion to RP 532 | | | 533 (11) | | RP processes results 534 | | | 535 |>----(12)----->| | Results to client app. 537 ----- = Between Client App and RP 538 ===== = Between RP and IdP 539 - - - = Between Client App and IdP 541 1.5. Design Goals 543 Our key design goals are as follows: 545 o Each party of a transaction will be authenticated, although 546 perhaps not identified, and the client will be authorized for 547 access to a specific resource. 549 o Means of authentication is decoupled so as to allow for multiple 550 authentication methods. 552 o Hence, the architecture requires no sharing of long term private 553 keys between clients and servers. 555 o The system will scale to large numbers of identity providers, 556 relying parties, and users. 558 o The system will be designed primarily for non-Web-based 559 authentication. 561 o The system will build upon existing standards, components, and 562 operational practices. 564 Designing new three party authentication and authorization protocols 565 is hard and fraught with risk of cryptographic flaws. Achieving 566 widespead deployment is even more difficult. A lot of attention on 567 federated access has been devoted to the Web. This document instead 568 focuses on a non-Web-based environment and focuses on those protocols 569 where HTTP is not used. Despite the increased excitement for 570 layering every protocol on top of HTTP there are still a number of 571 protocols available that do not use HTTP-based transports. Many of 572 these protocols are lacking a native authentication and authorization 573 framework of the style shown in Figure 1. 575 2. Architecture 577 We have already introduced the federated access architecture, with 578 the illustration of the different actors that need to interact, but 579 did not expand on the specifics of providing support for non-Web 580 based applications. This section details this aspect and motivates 581 design decisions. The main theme of the work described in this 582 document is focused on re-using existing building blocks that have 583 been deployed already and to re-arrange them in a novel way. 585 Although this architecture assumes updates to the relying party, the 586 client application, and the Identity Provider, those changes are kept 587 at a minimum. A mechanism that can demonstrate deployment benefits 588 (based on ease of update of existing software, low implementation 589 effort, etc.) is preferred and there may be a need to specify 590 multiple mechanisms to support the range of different deployment 591 scenarios. 593 There are a number of ways for encapsulating EAP into an application 594 protocol. For ease of integration with a wide range of non-Web based 595 application protocols the usage of the GSS-API was chosen. A 596 description of the technical specification can be found in 597 [I-D.ietf-abfab-gss-eap]. Other alternatives exist as well and may 598 be considered later, such as "TLS using EAP Authentication" 599 [I-D.nir-tls-eap].[anchor7] 601 The architecture consists of several building blocks, which is shown 602 graphically in Figure 2. In the following sections, we discuss the 603 data flow between each of the entities, the protocols used for that 604 data flow and some of the trade-offs made in choosing the protocols. 606 +--------------+ 607 | Identity | 608 | Provider | 609 | (IdP) | 610 +-^----------^-+ 611 * EAP o RADIUS/ 612 * o Diameter 613 --v----------v-- 614 /// \\\ 615 // \\ 616 | Federation | 617 | Substrate | 618 \\ // 619 \\\ /// 620 --^----------^-- 621 * EAP o RADIUS/ 622 * o Diameter 623 +-------------+ +-v----------v--+ 624 | |<---------------->| | 625 | Client | EAP/EAP Method | Relying Party | 626 | Application |<****************>| (RP) | 627 | | GSS-API | | 628 | |<---------------->| | 629 | | Application | | 630 | | Protocol | | 631 | |<================>| | 632 +-------------+ +---------------+ 634 Legend: 636 <****>: Client-to-IdP Exchange 637 <---->: Client-to-RP Exchange 638 : RP-to-IdP Exchange 639 <====>: Protocol through which GSS-API/GS2 exchanges are tunneled 641 Figure 2: ABFAB Protocol Instantiation 643 2.1. Relying Party to Identity Provider 645 Communications between the Relying Party and the Identity Provider is 646 done by the federation substrate. This communication channel is 647 responsible for: 649 o Establishing the trust relationship between the RP and the IdP. 651 o Determining the rules governing the relationship. 653 o Conveying EAP packets between the RP and IdP. 655 The ABFAB working group has chosen the AAA framework for the messages 656 transported between the RP and IdP. This allows for the current AAA 657 protocols to be used to establish the trust relationship between the 658 RP and the IdP. Future protocols that support the same framework but 659 do different routing may be used in the future. There is currently 660 an effort to setup a framework that creates a trusted point-to-point 661 channel on the fly. The ABFAB protocol itself details the method of 662 establishing the trust relationship between the RP and the client. 664 2.1.1. AAA, RADIUS and Diameter 666 Interestingly, for network access authentication the usage of the AAA 667 framework with RADIUS [RFC2865] and Diameter [RFC3588] was quite 668 successful from a deployment point of view. To map the terminology 669 used in Figure 1 to the AAA framework the IdP corresponds to the AAA 670 server, the RP corresponds to the AAA client, and the technical 671 building blocks of a federation are AAA proxies, relays and redirect 672 agents (particularly if they are operated by third parties, such as 673 AAA brokers and clearing houses). The front-end, i.e. the end host 674 to AAA client communication, is in case of network access 675 authentication offered by link layer protocols that forward 676 authentication protocol exchanges back-and-forth. An example of a 677 large scale RADIUS-based federation is EDUROAM [2]. 679 By using the AAA framework, ABFAB gets a lot of mileage as many of 680 the federation agreements already exist and merely need to be 681 expanded to cover the ABFAB additions. The AAA framework has already 682 addressed some of the problems outlined above. For example, 684 o It already has a method for routing requests based on a domain. 686 o It already has an extensible architecture allowing for new 687 attributes to be defined and transported. 689 o Pre-existing relationships can be re-used. 691 The astute reader will notice that RADIUS and Diameter have 692 substantially similar characteristics. Why not pick one? RADIUS and 693 Diameter are deployed in different environments. RADIUS can often be 694 found in enterprise and university networks, and is also in use by 695 fixed network operators. Diameter, on the other hand, is deployed by 696 mobile operators. Another key difference is that today RADIUS is 697 largely transported upon UDP. We leave as a deployment decision, 698 which protocol will be appropriate. The protocol defines all the 699 necessary new AAA attributes as RADIUS attributes. A future document 700 would defined the same AAA attributes for a Diameter environment. We 701 also note that there exist proxies which convert from RADIUS to 702 Diameter and back. This makes it possible for both to be deployed in 703 a single federation substrate. 705 Through the integrity protection mechanisms in the AAA framework, the 706 identity provider can establish technical trust that messages are 707 being sent by the appropriate relying party. Any given interaction 708 will be associated with one federation at the policy level. The 709 legal or business relationship defines what statements the identity 710 provider is trusted to make and how these statements are interpreted 711 by the relying party. The AAA framework also permits the relying 712 party or elements between the relying party and identity provider to 713 make statements about the relying party. 715 The AAA framework provides transport for attributes. Statements made 716 about the subject by the identity provider, statements made about the 717 relying party and other information are transported as attributes. 719 One demand that the AAA substrate makes of the upper layers is that 720 they must properly identify the end points of the communication. It 721 must be possible for the AAA client at the RP to determine where to 722 send each RADIUS or Diameter message. Without this requirement, it 723 would be the RP's responsibility to determine the identity of the 724 client on its own, without the assistance of an IdP. This 725 architecture makes use of the Network Access Identifier (NAI), where 726 the IdP is indicated by the realm component [RFC4282]. The NAI is 727 represented and consumed by the GSS-API layer as GSS_C_NT_USER_NAME 728 as specified in [RFC2743]. The GSS-API EAP mechanism includes the 729 NAI in the EAP Response/Identity message. 731 2.1.2. Discovery and Rules Determination 733 While we are using the AAA protocols to communicate with the IdP, the 734 RP may have multiple federation substrates to select from. The RP 735 has a number of criteria that it will use in selecting which of the 736 different federations to use: 738 o The federation selected must be able to communicate with the IdP. 740 o The federation selected must match the business rules and 741 technical policies required for the RP security requirements. 743 The RP needs to discover which federation will be used to contact the 744 IdP. The first selection criteria in discovery is going to be the 745 name of the IdP to be contacted. The second selection criteria in 746 discovery is going to be the set of business rules and technical 747 policies governing the relationship; this is called rules 748 determination. The RP also needs to establish technical trust in the 749 communications with the IdP. 751 Rules determination covers a broad range of decisions about the 752 exchange. One of these is whether the given RP is permitted to talk 753 to the IdP using a given federation at all, so rules determination 754 encompasses the basic authorization decision. Other factors are 755 included, such as what policies govern release of information about 756 the principal to the RP and what policies govern the RP's use of this 757 information. While rules determination is ultimately a business 758 function, it has significant impact on the technical exchanges. The 759 protocols need to communicate the result of authorization. When 760 multiple sets of rules are possible, the protocol must disambiguate 761 which set of rules are in play. Some rules have technical 762 enforcement mechanisms; for example in some federations 763 intermediaries validate information that is being communicated within 764 the federation. 766 ABFAB has not formally defined any part of discovery at this point. 767 The process of specifying and evaluating the business rules and 768 technical policies is too complex to provide a simple framework. 769 There is not currently a way to know if a AAA proxy is able to 770 communicate with a specific IdP, although this may change with some 771 of the routing protocols that are being considered. At the present 772 time, the discovery process is going to be a manual configuration 773 process. 775 2.1.3. Routing and Technical Trust 777 Several approaches to having messages routed through the federation 778 substrate are possible. These routing methods can most easily be 779 classified based on the mechanism for technical trust that is used. 780 The choice of technical trust mechanism constrains how rules 781 determination is implemented. Regardless of what deployment strategy 782 is chosen, it is important that the technical trust mechanism be able 783 to validate the names of both parties to the exchange. The trust 784 mechanism must to ensure that the entity acting as IdP for a given 785 NAI is permitted to be the IdP for that realm, and that any service 786 name claimed by the RP is permitted to be claimed by that entity. 787 Here are the categories of technical trust determination: 789 AAA Proxy: 790 The simplest model is that an RP supports a request directly to an 791 AAA proxy. The hop-by-hop integrity protection of the AAA fabric 792 provides technical trust. An RP can submit a request directly to 793 a federation. Alternatively, a federation disambiguation fabric 794 can be used. Such a fabric takes information about what 795 federations the RP is part of and what federations the IdP is part 796 of and routes a message to the appropriate federation. The 797 routing of messages across the fabric plus attributes added to 798 requests and responses provides rules determination. For example, 799 when a disambiguation fabric routes a message to a given 800 federation, that federation's rules are chosen. Name validation 801 is enforced as messages travel across the fabric. The entities 802 near the RP confirm its identity and validate names it claims. 803 The fabric routes the message towards the appropriate IdP, 804 validating the IdP's name in the process. The routing can be 805 statically configured. Alternatively a routing protocol could be 806 developed to exchange reachability information about given IdPs 807 and to apply policy across the AAA fabric. Such a routing 808 protocol could flood naming constraints to the appropriate points 809 in the fabric. 811 Trust Broker: 812 Instead of routing messages through AAA proxies, some trust broker 813 could establish keys between entities near the RP and entities 814 near the IdP. The advantage of this approach is efficiency of 815 message handling. Fewer entities are needed to be involved for 816 each message. Security may be improved by sending individual 817 messages over fewer hops. Rules determination involves decisions 818 made by trust brokers about what keys to grant. Also, associated 819 with each credential is context about rules and about other 820 aspects of technical trust including names that may be claimed. A 821 routing protocol similar to the one for AAA proxies is likely to 822 be useful to trust brokers in flooding rules and naming 823 constraints. 825 Global Credential: 826 A global credential such as a public key and certificate in a 827 public key infrastructure can be used to establish technical 828 trust. A directory or distributed database such as the Domain 829 Name System is used by the RP to discover the endpoint to contact 830 for a given NAI. Either the database or certificates can provide 831 a place to store information about rules determination and naming 832 constraints. Provided that no intermediates are required (or 833 appear to be required) and that the RP and IdP are sufficient to 834 enforce and determine rules, rules determination is reasonably 835 simple. However applying certain rules is likely to be quite 836 complex. For example if multiple sets of rules are possible 837 between an IdP and RP, confirming the correct set is used may be 838 difficult. This is particularly true if intermediates are 839 involved in making the decision. Also, to the extent that 840 directory information needs to be trusted, rules determination may 841 be more complex. 843 Real-world deployments are likely to be mixtures of these basic 844 approaches. For example, it will be quite common for an RP to route 845 traffic to a AAA proxy within an organization. That proxy could then 846 use any of the three methods to get closer to the IdP. It is also 847 likely that rather than being directly reachable, the IdP may have a 848 proxy on the edge of its organization. Federations will likely 849 provide a traditional AAA proxy interface even if they also provide 850 another mechanism for increased efficiency or security. 852 2.1.4. SAML Assertions 854 For the traditional use of AAA frameworks, network access, the only 855 requirement that was necessary to grant access was an affirmative 856 response from the IdP. In the ABFAB world, the RP may need to get 857 additional information about the client before granting access. 858 ABFAB therefore has a requirement that it can transport an arbitrary 859 set of attributes about the client from the IdP to the RP. 861 Security Assertions Markup Language (SAML) [OASIS.saml-core-2.0-os] 862 was designed in order to carry an extensible set of attributes about 863 a subject. Since SAML is extensible in the attribute space, ABFAB 864 has no immediate needs to update the core SAML specifications for our 865 work. It will be necessary to update IdPs that need to return SAML 866 assertions to IdPs and for both the IdP and the RP to implement a new 867 SAML profile designed to carry SAML assertions in AAA. The new 868 profile can be found in RFCXXXX [I-D.ietf-abfab-aaa-saml]. 870 There are two issues that need to be highlighted: 872 o The security of SAML assertions. 874 o Namespaces and mapping of SAML attributes. 876 SAML assertions have an optional signature that can be used to 877 protect and provide origination of the assertion. These signatures 878 are normally based on asymmetric key operations and require that the 879 verifier be able to check not only the cryptographic operation, but 880 also the binding of the originators name and the public key. In a 881 federated environment it will not always be possible for the RP to 882 validate the binding, for this reason the technical trust established 883 in the federation is used as an alternate method of validating the 884 origination and integrity of the SAML Assertion. 886 Attributes placed in SAML assertions can have different namespaces 887 assigned to the same name. In many, but not all, cases the 888 federation agreements will determine what attributes can be used in a 889 SAML statement. This means that the RP needs to map from the 890 federation names, types and semantics into the ones that the policies 891 of the RP are written in. In other cases the federation substrate 892 may modify the SAML assertions in transit to do the necessary 893 namespace, naming and semantic mappings as the assertion crosses the 894 different boundaries in the federation. If the proxies are modifying 895 the SAML Assertion, then will obviously remove any signatures on the 896 SAML assertions as they would no longer validate. In this case the 897 technical trust is the required mechanism for validating the 898 integrity of the assertion. Finally, the attributes may still be in 899 the namespace of the originating IdP. When this occurs the RP will 900 need to get the required mapping operations from the federation 901 agreements and do the appropriate mappings itself. 903 2.2. Client To Identity Provider 905 Looking at the communications between the client and the IdP, the 906 following items need to be dealt with: 908 o The client and the IdP need to mutually authenticate each other. 910 o The client and the IdP need to mutually agree on the identity of 911 the RP. 913 ABFAB selected EAP for the purposes of mutual authentication and 914 assisted in creating some new EAP channel binding documents for 915 dealing with determining the identity of the RP. A framework for the 916 channel binding mechanism has been defined in RFC 6677 [RFC6677] that 917 allows the IdP to check the identity of the RP provided by the AAA 918 framework with that provided by the client. 920 2.2.1. Extensible Authentication Protocol (EAP) 922 Traditional web federation does not describe how a subject interacts 923 with an identity provider for authentication. As a result, this 924 communication is not standardized. There are several disadvantages 925 to this approach. Since the communication is not standardized, it is 926 difficult for machines to correctly enter their credentials with 927 different authentications, where Individuals can correctly identify 928 the entyr mechanism on the fly. The use of browsers for 929 authentication restricts the deployment of more secure forms of 930 authentication beyond plaintext username and password known by the 931 server. In a number of cases the authentication interface may be 932 presented before the subject has adequately validated they are 933 talking to the intended server. By giving control of the 934 authentication interface to a potential attacker, then the security 935 of the system may be reduced and phishing opportunities introduced. 937 As a result, it is desirable to choose some standardized approach for 938 communication between the subject's end-host and the identity 939 provider. There are a number of requirements this approach must 940 meet. 942 Experience has taught us one key security and scalability 943 requirement: it is important that the relying party not get 944 possession of the long-term secret of the client. Aside from a 945 valuable secret being exposed, a synchronization problem can develop 946 when the client changes keys with the IdP. 948 Since there is no single authentication mechanism that will be used 949 everywhere there is another associated requirement: The 950 authentication framework must allow for the flexible integration of 951 authentication mechanisms. For instance, some IdPs require hardware 952 tokens while others use passwords. A service provider wants to 953 provide support for both authentication methods, and other methods 954 from IdPs not yet seen. 956 Fortunately, these requirements can be met by utilizing standardized 957 and successfully deployed technology, namely by the Extensible 958 Authentication Protocol (EAP) framework [RFC3748]. Figure 2 959 illustrates the integration graphically. 961 EAP is an end-to-end framework; it provides for two-way communication 962 between a peer (i.e,service client or principal) through the 963 authenticator (i.e., service provider) to the back-end (i.e., 964 identity provider). Conveniently, this is precisely the 965 communication path that is needed for federated identity. Although 966 EAP support is already integrated in AAA systems (see [RFC3579] and 967 [RFC4072]) several challenges remain: 969 o The first is how to carry EAP payloads from the end host to the 970 relying party. 972 o Another is to verify statements the relying party has made to the 973 subject, confirm these statements are consistent with statements 974 made to the identity provider and confirm all the above are 975 consistent with the federation and any federation-specific policy 976 or configuration. 978 o Another challenge is choosing which identity provider to use for 979 which service. 981 The EAP method used for ABFAB needs to meet the following 982 requirements: 984 o It needs to provide mutual authentication of the client and IdP. 986 o It needs to support channel binding. 988 As of this writing, the only EAP method that meets these criteria is 989 TEAP [I-D.ietf-emu-eap-tunnel-method] either alone (if client 990 certificates are used) or with an inner EAP method that does mutual 991 authentication. 993 2.2.2. EAP Channel Binding 995 EAP channel binding is easily confused with a facility in GSS-API 996 also called channel binding. GSS-API channel binding provides 997 protection against man-in-the-middle attacks when GSS-API is used as 998 authentication inside some tunnel; it is similar to a facility called 999 cryptographic binding in EAP. See [RFC5056] for a discussion of the 1000 differences between these two facilities and Section 6.1 for how GSS- 1001 API channel binding is handled in this mechanism. 1003 The client knows, in theory, the name of the RP that it attempted to 1004 connect to, however in the event that an attacker has intercepted the 1005 protocol, the client and the IdP need to be able to detect this 1006 situation. A general overview of the problem along with a 1007 recommended way to deal with the channel binding issues can be found 1008 in RFC 6677 [RFC6677]. 1010 Since that document was published, a number of possible attacks were 1011 found and methods to address these attacks have been outlined in 1012 [I-D.hartman-emu-mutual-crypto-bind]. 1014 2.3. Client to Relying Party 1016 The final set of interactions between parties to consider are those 1017 between the client and the RP. In some ways this is the most complex 1018 set since at least part of it is outside the scope of the ABFAB work. 1019 The interactions between these parties include: 1021 o Running the protocol that implements the service that is provided 1022 by the RP and desired by the client. 1024 o Authenticating the client to the RP and the RP to the client. 1026 o Providing the necessary security services to the service protocol 1027 that it needs beyond authentication. 1029 2.3.1. GSS-API 1031 One of the remaining layers is responsible for integration of 1032 federated authentication into the application. There are a number of 1033 approaches that applications have adopted for security. So, there 1034 may need to be multiple strategies for integration of federated 1035 authentication into applications. However, we have started with a 1036 strategy that provides integration to a large number of application 1037 protocols. 1039 Many applications such as SSH [RFC4462], NFS [RFC2203], DNS [RFC3645] 1040 and several non-IETF applications support the Generic Security 1041 Services Application Programming Interface [RFC2743]. Many 1042 applications such as IMAP, SMTP, XMPP and LDAP support the Simple 1043 Authentication and Security Layer (SASL) [RFC4422] framework. These 1044 two approaches work together nicely: by creating a GSS-API mechanism, 1045 SASL integration is also addressed. In effect, using a GSS-API 1046 mechanism with SASL simply requires placing some headers on the front 1047 of the mechanism and constraining certain GSS-API options. 1049 GSS-API is specified in terms of an abstract set of operations which 1050 can be mapped into a programming language to form an API. When 1051 people are first introduced to GSS-API, they focus on it as an API. 1052 However, from the prospective of authentication for non-web 1053 applications, GSS-API should be thought of as a protocol not an API. 1054 It consists of some abstract operations such as the initial context 1055 exchange, which includes two sub-operations (gss_init_sec_context and 1056 gss_accept_sec_context). An application defines which abstract 1057 operations it is going to use and where messages produced by these 1058 operations fit into the application architecture. A GSS-API 1059 mechanism will define what actual protocol messages result from that 1060 abstract message for a given abstract operation. So, since this work 1061 is focusing on a particular GSS-API mechanism, we generally focus on 1062 protocol elements rather than the API view of GSS-API. 1064 The API view has significant value. Since the abstract operations 1065 are well defined, the set of information that a mechanism gets from 1066 the application is well defined. Also, the set of assumptions the 1067 application is permitted to make is generally well defined. As a 1068 result, an application protocol that supports GSS-API or SASL is very 1069 likely to be usable with a new approach to authentication including 1070 this one with no required modifications. In some cases, support for 1071 a new authentication mechanism has been added using plugin interfaces 1072 to applications without the application being modified at all. Even 1073 when modifications are required, they can often be limited to 1074 supporting a new naming and authorization model. For example, this 1075 work focuses on privacy; an application that assumes it will always 1076 obtain an identifier for the principal will need to be modified to 1077 support anonymity, unlinkability or pseudonymity. 1079 So, we use GSS-API and SASL because a number of the application 1080 protocols we wish to federate support these strategies for security 1081 integration. What does this mean from a protocol standpoint and how 1082 does this relate to other layers? This means we need to design a 1083 concrete GSS-API mechanism. We have chosen to use a GSS-API 1084 mechanism that encapsulates EAP authentication. So, GSS-API (and 1085 SASL) encapsulate EAP between the end-host and the service. The AAA 1086 framework encapsulates EAP between the relying party and the identity 1087 provider. The GSS-API mechanism includes rules about how principals 1088 and services are named as well as per-message security and other 1089 facilities required by the applications we wish to support. 1091 2.3.2. Protocol Transport 1093 The transport of data between the client and the relying party is not 1094 provided by GSS-API. GSS-API creates and consumes messages, but it 1095 does not provide the transport itself, instead the protocol using 1096 GSS-API needs to provide the transport. In many cases HTTP or HTTPS 1097 is used for this transport, but other transports are perfectly 1098 acceptable. The core GSS-API document [RFC2743] provides some 1099 details on what requirements exist. 1101 In addition we highlight the following: 1103 o The transport does not need to provide either privacy or 1104 integrity. After GSS-EAP has finished negotiation, GSS-API can be 1105 used to provide both services. If the negotiation process itself 1106 needs protection from eavesdroppers then the transport would need 1107 to provide the necessary services. 1109 o The transport needs to provide reliable transport of the messages. 1111 o The transport needs to ensure that tokens are delivered in order 1112 during the negotiation process. 1114 o GSS-API messages need to be delivered atomically. If the 1115 transport breaks up a message it must also reassemble the message 1116 before delivery. 1118 3. Application Security Services 1120 One of the key goals is to integrate federated authentication into 1121 existing application protocols and where possible, existing 1122 implementations of these protocols. Another goal is to perform this 1123 integration while meeting the best security practices of the 1124 technologies used to perform the integration. This section describes 1125 security services and properties required by the EAP GSS-API 1126 mechanism in order to meet these goals. This information could be 1127 viewed as specific to that mechanism. However, other future 1128 application integration strategies are very likely to need similar 1129 services. So, it is likely that these services will be expanded 1130 across application integration strategies if new application 1131 integration strategies are adopted. 1133 3.1. Authentication 1135 GSS-API provides an optional security service called mutual 1136 authentication. This service means that in addition to the initiator 1137 providing (potentially anonymous or pseudonymous) identity to the 1138 acceptor, the acceptor confirms its identity to the initiator. 1139 Especially for the ABFAB context, this service is confusingly named. 1140 We still say that mutual authentication is provided when the identity 1141 of an acceptor is strongly authenticated to an anonymous initiator. 1143 RFC 2743, unfortunately, does not explicitly talk about what mutual 1144 authentication means. Within this document we therefore define it 1145 as: 1147 o If a target name is supplied to the initiator, then the initiator 1148 trusts that the supplied target name describes the acceptor. This 1149 implies both that appropriate cryptographic exchanges took place 1150 for the initiator to make such a trust decision, and that after 1151 evaluating the results of these exchanges, the initiator's policy 1152 trusts that the target name is accurate. 1154 o If no target name is supplied to the initiator, then the initiator 1155 trusts that the acceptor name, supplied by the acceptor, correctly 1156 names the entity it is communicating with. 1158 o Both the initiator and acceptor have the same key material for 1159 per-message keys and both parties have confirmed they actually 1160 have the key material. In EAP terms, there is a protected 1161 indication of success. 1163 Mutual authentication is an important defense against certain aspects 1164 of phishing. Intuitively, users would like to assume that if some 1165 party asks for their credentials as part of authentication, 1166 successfully gaining access to the resource means that they are 1167 talking to the expected party. Without mutual authentication, the 1168 acceptor could "grant access" regardless of what credentials are 1169 supplied. Mutual authentication better matches this user intuition. 1171 It is important, therefore, that the GSS-EAP mechanism implement 1172 mutual authentication. That is, an initiator needs to be able to 1173 request mutual authentication. When mutual authentication is 1174 requested, only EAP methods capabale of providing the necessary 1175 service can be used, and appropriate steps need to be taken to 1176 provide mutual authentication. A broader set of EAP methods could be 1177 supported when a particular application does not request mutual 1178 authentication. It is an open question whether the mechanism will 1179 permit this. 1181 The AAA infrastructure MAY hide the peer's identity from the GSS-API 1182 acceptor, providing anonymity between the peer and initiator. At 1183 this time, whether the identity is disclosed is determined by EAP 1184 server policy rather than by an indication from the peer. Also, 1185 peers are unlikely to be able to determine whether anonymous 1186 communication will be provided. For this reason, peers are unlikely 1187 to set the anonymous return flag from GSS_Init_Sec_context. 1189 3.2. GSS-API Channel Binding 1191 [RFC5056] defines a concept of channel binding to prevent man-in-the- 1192 middle attacks. It is common to provide SASL and GSS-API with 1193 another layer to provide transport security; Transport Layer Security 1194 (TLS) is the most common such layer. TLS provides its own server 1195 authentication. However there are a variety of situations where this 1196 authentication is not checked for policy or usability reasons. Even 1197 when it is checked, if the trust infrastructure behind the TLS 1198 authentication is different from the trust infrastructure behind the 1199 GSS-API mutual authentication then confirming the end-points using 1200 both trust infrastructures is likely to enhance security. If the 1201 endpoints of the GSS-API authentication are different than the 1202 endpoints of the lower layer, this is a strong indication of a 1203 problem such as a man-in-the-middle attack. Channel binding provides 1204 a facility to determine whether these endpoints are the same. 1206 The GSS-EAP mechanism needs to support channel binding. When an 1207 application provides channel binding data, the mechanism needs to 1208 confirm this is the same on both sides consistent with the GSS-API 1209 specification. 1211 Typically when considering channel binding, people think of channel 1212 binding in combination with mutual authentication. This is 1213 sufficiently common that without additional qualification channel 1214 binding should be assumed to imply mutual authentication. Without 1215 mutual authentication, only one party knows that the endpoints are 1216 correct. That's sometimes useful. Consider for example a user who 1217 wishes to access a protected resource from a shared whiteboard in a 1218 conference room. The whiteboard is the initiator; it does not need 1219 to actually authenticate that it is talking to the correct resource 1220 because the user will be able to recognize whether the displayed 1221 content is correct. If channel binding were used without mutual 1222 authentication, it would in effect be a request to only disclose the 1223 resource in the context of a particular channel. Such an 1224 authentication would be similar in concept to a holder-of-key SAML 1225 assertion. However, also note that while it is not happening in the 1226 protocol, mutual authentication is happening in the overall system: 1227 the user is able to visually authenticate the content. This is 1228 consistent with all uses of channel binding without protocol level 1229 mutual authentication found so far. 1231 RFC 5056 channel binding (also called GSS-API channel binding when 1232 GSS-API is involved) is not the same thing as EAP channel binding. 1233 EAP channel binding is also used in the ABFAB context in order to 1234 implement acceptor naming and mutual authentication. Details are 1235 discussed in the mechanisms specification [I-D.ietf-abfab-gss-eap]. 1237 3.3. Host-Based Service Names 1239 IETF security mechanisms typically take the name of a service entered 1240 by a user and make some trust decision about whether the remote party 1241 in an interaction is the intended party. GSS-API has a relatively 1242 flexible naming architecture. However most of the IETF applications 1243 that use GSS-API, including SSH, NFS, IMAP, LDAP and XMPP, have 1244 chosen to use host-based service names when they use GSS-API. In 1245 this model, the initiator names an acceptor based on a service such 1246 as "imap" or "host" (for login services such as SSH) and a host name. 1248 Using host-based service names leads to a challenging trust 1249 delegation problem. Who is allowed to decide whether a particular 1250 hostname maps to an entity. The public-key infrastructure (PKI) used 1251 by the web has chosen to have a number of trust anchors (root 1252 certificate authorities) each of which can map any name to a public 1253 key. A number of GSS-API mechanisms, such as Kerberos [RFC1964], 1254 split the problem into two parts. A new concept called a realm is 1255 introduced. Then the mechanism decides what realm is responsible for 1256 a given name. That realm is responsible for deciding if the acceptor 1257 entity is allowed to claim the name. ABFAB needs to adopt this 1258 approach. 1260 Host-based service names do not work ideally when different instances 1261 of a service are running on different ports. Also, these do not work 1262 ideally when SRV record or other insecure referrals are used. 1264 The GSS-EAP mechanism needs to support host-based service names in 1265 order to work with existing IETF protocols. 1267 3.4. Per-Message Tokens 1269 GSS-API provides per-message security services that can provide 1270 confidentiality and integrity. Some IETF protocols such as NFS and 1271 SSH take advantage of these services. As a result GSS-EAP needs to 1272 support these services. As with mutual authentication, per-message 1273 services will limit the set of EAP methods that are available. Any 1274 EAP method that produces a Master Session Key (MSK) is able to 1275 support per-message security services described in [X]. 1277 GSS-API provides a pseudo-random function. While the pseudo-random 1278 function does not involve sending data over the wire, it provides an 1279 algorithm that both the initiator and acceptor can run in order to 1280 arrive at the same key value. This is useful for designs where a 1281 successful authentication is used to key some other function. This 1282 is similar in concept to the TLS extractor. No current IETF 1283 protocols require this. However GSS-EAP supports this service 1284 because it is valuable for the future and easy to do given per- 1285 message services. Non-IETF protocols are expected to take advantage 1286 of this in the near future. 1288 4. Future Work: Attribute Providers 1290 This architecture provides for a federated authentication and 1291 authorization framework between IdPs, RPs, principals, and subjects. 1292 It does not at this time provide for a means to retrieve attributes 1293 from 3rd parties. However, it envisions such a possibility. We note 1294 that in any extension to the model, an attribute provider must be 1295 authorized to release specific attributes to a specific RP for a 1296 specific principal. In addition, we note that it is an open question 1297 beyond this architecture as to how the RP should know to trust a 1298 particular attribute provider. 1300 There are a number of possible technical means to provide attribute 1301 provider capabilities. One possible approach is for the IdP to 1302 provide a signed attribute request to RP that it in turn will provide 1303 to the attribute authority. Another approach would be for the IdP to 1304 provide a URI to the RP that contains a token of some form. The form 1305 of communications between the IdP and attribute provider as well as 1306 other considerations are left for the future. One thing we can say 1307 now is that the IdP would merely be asserting who the attribute 1308 authority is, and not the contents of what the attribute authority 1309 would return. (Otherwise, the IdP might as well make the query to 1310 the attribute authority and then resign it.) 1312 5. Privacy Considerations 1314 ABFAB, as an architecture designed to enable federated authentication 1315 and allow for the secure transmission of identity information between 1316 entities, obviously requires careful consideration around privacy and 1317 the potential for privacy violations. 1319 This section examines the privacy related information presented in 1320 this document, summarising the entities that are involved in ABFAB 1321 communications and what exposure they have to identity information. 1322 In discussing these privacy considerations in this section, we use 1323 terminology and ideas from [I-D.iab-privacy-considerations]. 1325 Note that the ABFAB architecture uses at its core several existing 1326 technologies and protocols; detailed privacy discussion around these 1327 is not examined. This section instead focuses on privacy 1328 considerations specifically related to overall architecture and usage 1329 of ABFAB. 1331 5.1. Entities and their roles 1333 In an ABFAB environment, there are four distinct types of entities 1334 involved in communication paths. Figure 2 shows the ABFAB 1335 architecture with these entity types. We have: 1337 o The client application: usually a piece of software running on a 1338 user's device. This communicates with a service (the Relying 1339 Party) that the user wishes to interact with. 1341 o The Identity Provider: The home AAA server for the user. 1343 o The Relying Party: The service the user wishes to connect to. 1345 o The federation substrate: A set of entities through which messages 1346 pass on their path between RP and AAA server. 1348 As described in detail earlier in this document, when a user wishes 1349 to access a Relying Party, a secure tunnel is set up between their 1350 client application and their Identity Provider (via the Relying Party 1351 and the federation substrate) through which credentials are 1352 exchanged. An indication of success or failure, alongside a set of 1353 AAA attributes about a principal is then passed from the Identity 1354 Provider to the Relying Party (usually in the form of a SAML 1355 assertion). 1357 5.2. Relationship between user and entities 1359 o Between User and Identity Provider - the identity Provider is an 1360 entity the user will have a direct relationship with, created when 1361 the organisation that operates the entity provisioned and 1362 exchanged the user's credentials. Privacy and data protection 1363 guarantees may form a part of this relationship. 1365 o Between User and Relying Party - the Relying Party is an entity 1366 the user may or may not have a direct relationship with, depending 1367 on the service in question. Some services may only be offered to 1368 those users where such a direct relationship exists (for 1369 particularly sensitive services, for example), while some may not 1370 require this and would instead be satisfied with basic federation 1371 trust guarantees between themselves and the Identity Provider). 1372 This may well include the option that the user stays anonymous 1373 with respect to the Relying Party (though obviously not to the 1374 Identity Provider). If attempting to preserve privacy through the 1375 mitigation of data minimisation, then the only attribute 1376 information about individuals exposed to the Relying Party should 1377 be that which is strictly necessary for the operation of the 1378 service. 1380 o Between User and Federation substrate - the user is highly likely 1381 to have no knowledge of, or relationship with, any entities 1382 involved with the federation substrate (not that the Identity 1383 Provider and/or Relying Party may, however). Knowledge of 1384 attribute information about individuals for these entities is not 1385 necessary, and thus such information should be protected in such a 1386 way as to prevent access to this information from being possible. 1388 5.3. Data and Identifiers in use 1390 In the ABFAB architecture, there are a few different types of data 1391 and identifiers in use. 1393 5.3.1. NAI 1395 In order for the Relying Party to be able to route messages to enable 1396 an EAP transaction to occur between client application and the 1397 correct identity Provider, it is necessary for the client application 1398 to provide enough information to the Relying Party to enable the 1399 identification of the correct Identity Provider. This takes the form 1400 of an Network Access Identifier (NAI) (as specified in [RFC4282]). 1401 Note that an NAI can have inner and outer forms in a AAA 1402 architecture. 1404 o The outer part of NAI is exposed to the Relying Party; this can 1405 simply contain realm information. Doing so (i.e. not including 1406 user identification details such as a username) minimises the data 1407 given to the Relying Part to that which is purely necessary to 1408 support the necessary routing decision. 1410 o The inner part of NAI is sent through the secure tunnel as 1411 established by the EAP protocol; this form of the NAI will contain 1412 credentials for the user suitable for authenticating them 1413 successfully (e.g. a username and password). Since the entire 1414 purpose of the secure tunnel is to protect communications between 1415 client application (EAP client) and Identity Provider (EAP 1416 server), then it is considered secure from eavesdroppers or 1417 malicious intermediaries and no further privacy discussion is 1418 necessary. 1420 5.3.2. Identity Information 1422 As a part of the ABFAB process, after a successful authentication has 1423 occurred between client application and Identity Provider, an 1424 indication of this success is sent to the Relying Party. Alongside 1425 this message, information about the user may be returned through AAA 1426 attributes, usually in form of a SAML assertion. This information is 1427 arbitrary and may include either only attributes that prevent an 1428 individual from being identified by the Relying Party (thus enabling 1429 anonymous or pseudonymous access) or attributes that contain 1430 personally identifiable information. 1432 Depending on the method used, this information carried through AAA 1433 attributes may or may not be accessible to intermediaries involved in 1434 communications - e.g. in the case of RADIUS and unencrypted SAML, 1435 these headers are plain text and could be seen by any observer, 1436 whereas if using RADSEC or encrypted SAML, these headers are 1437 protected from observers. Obviously, where the protection of the 1438 privacy of an individual is required then this information needs to 1439 be protected by some appropriate means. 1441 5.3.3. Accounting Information 1443 Alongside the core authentication and authorization that occurs in 1444 AAA communications, accounting information about resource consumption 1445 may be delivered as part of the accounting exchange during the 1446 lifetime of the granted application session. 1448 5.3.4. Collection and retention of data and identifiers 1450 In cases where Relying Parties do not require to identify a 1451 particular individual when an individual wishes to make use of their 1452 service, the ABFAB architecture enable anonymous or pseudonymous 1453 access. Thus data and identifiers other than pseudonyms and 1454 unlinkable attribute information need not be stored and retained. 1456 However, in cases where Relying Parties require the ability to 1457 identify a particular individual (e.g. so they can link this identity 1458 information to a particular account in their service, or where 1459 identity information is required for audit purposes), the service 1460 will need to collect and store such information, and to retain it for 1461 as long as they require. Deprovisioning of such accounts and 1462 information is out of scope for ABFAB, but obviously for privacy 1463 protection any identifiers collected should be deleted when they are 1464 no longer needed. 1466 5.4. User Participation 1468 In the ABFAB architecture, by its very nature users are active 1469 participants in the sharing of their identifiers as they initiate the 1470 communications exchange every time they wish to access a server. 1471 They are, however, not involved in control of the set of information 1472 related to them that transmitted from Identity Provider to Relying 1473 Party for authorisation purposes. 1475 6. Deployment Considerations 1477 6.1. EAP Channel Binding 1479 Discuss the implications of needing EAP channel binding. 1481 6.2. AAA Proxy Behavior 1483 Discuss deployment implications of our proxy requirements. 1485 7. Security Considerations 1487 This document describes the architecture for Application Bridging for 1488 Federated Access Beyond Web (ABFAB) and security is therefore the 1489 main focus. This section highlights the main communication channels 1490 and their security properties: 1492 Client-to-RP Channel: 1494 The channel binding material is provided by any certificates and 1495 the final message (i.e., a cryptographic token for the channel). 1496 Authentication may be provided by the RP to the client but a 1497 deployment without authentication at the TLS layer is possible as 1498 well. In addition, there is a channel between the GSS requestor 1499 and the GSS acceptor, but the keying material is provided by a 1500 "third party" to both entities. The client can derive keying 1501 material locally, but the RP gets the material from the IdP. In 1502 the absence of a transport that provides encryption and/or 1503 integrity, the channel between the client and the RP has no 1504 ability to have any cryptographic protection until the EAP 1505 authentication has been completed and the MSK is transfered from 1506 the IdP to the RP. 1508 RP-to-IdP Channel: 1510 The security of this communication channel is mainly provided by 1511 the functionality offered via RADIUS and Diameter. At the time of 1512 writing there are no end-to-end security mechanisms standardized 1513 and thereby the architecture has to rely on hop-by-hop security 1514 with trusted AAA entities or, as an alternative but possible 1515 deployment variant, direct communication between the AAA client to 1516 the AAA server. Note that the authorization result the IdP 1517 provides to the RP in the form of a SAML assertion may, however, 1518 be protected such that the SAML related components are secured 1519 end-to-end. 1521 The MSK is transported from the IdP to the RP over this channel. 1522 As no end-to-end security is provided by AAA, all AAA entities on 1523 the path between the RP and IdP have the ability to eavesdrop if 1524 no additional security measures are taken. One such measure is to 1525 use a transport between the client and the IdP that provides 1526 confidentiality. 1528 Client-to-IdP Channel: 1530 This communication interaction is accomplished with the help of 1531 EAP and EAP methods. The offered security protection will depend 1532 on the EAP method that is chosen but a minimum requirement is to 1533 offer mutual authentication, and key derivation. The IdP is 1534 responsible during this process to determine that the RP that is 1535 communication to the client over the RP-to-IdP channel is the same 1536 one talking to the IdP. This is accomplished via the EAP channel 1537 binding. 1539 Partial list of issues to be addressed in this section: Privacy, 1540 SAML, Trust Anchors, EAP Algorithm Selection, Diameter/RADIUS/AAA 1541 Issues, Naming of Entities, Protection of passwords, Channel Binding, 1542 End-point-connections (TLS), Proxy problems 1544 When a psuedonym is generated as a unique long term identifier for a 1545 Subject by an IdP, care MUST be taken in the algorithm that it cannot 1546 easily be reverse engineered by the service provider. If it can be 1547 reversed then the service provider can consult an oracle to determine 1548 if a given unique long term identifier is associated with a different 1549 known identifier. 1551 8. IANA Considerations 1553 This document does not require actions by IANA. 1555 9. Acknowledgments 1557 We would like to thank Mayutan Arumaithurai and Klaas Wierenga for 1558 their feedback. Additionally, we would like to thank Eve Maler, 1559 Nicolas Williams, Bob Morgan, Scott Cantor, Jim Fenton, Paul Leach, 1560 and Luke Howard for their feedback on the federation terminology 1561 question. 1563 Furthermore, we would like to thank Klaas Wierenga for his review of 1564 the pre-00 draft version. 1566 10. References 1568 10.1. Normative References 1570 [RFC2743] Linn, J., "Generic Security Service Application Program 1571 Interface Version 2, Update 1", RFC 2743, January 2000. 1573 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1574 "Remote Authentication Dial In User Service (RADIUS)", 1575 RFC 2865, June 2000. 1577 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1578 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1580 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1581 Levkowetz, "Extensible Authentication Protocol (EAP)", 1582 RFC 3748, June 2004. 1584 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1585 Dial In User Service) Support For Extensible 1586 Authentication Protocol (EAP)", RFC 3579, September 2003. 1588 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1589 Authentication Protocol (EAP) Application", RFC 4072, 1590 August 2005. 1592 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1593 Network Access Identifier", RFC 4282, December 2005. 1595 [I-D.ietf-abfab-gss-eap] 1596 Hartman, S. and J. Howlett, "A GSS-API Mechanism for the 1597 Extensible Authentication Protocol", 1598 draft-ietf-abfab-gss-eap-09 (work in progress), 1599 August 2012. 1601 [I-D.ietf-abfab-aaa-saml] 1602 Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding 1603 and Profiles for SAML", draft-ietf-abfab-aaa-saml-04 (work 1604 in progress), October 2012. 1606 [RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding 1607 Support for Extensible Authentication Protocol (EAP) 1608 Methods", RFC 6677, July 2012. 1610 10.2. Informative References 1612 [RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J., and 1613 D. Spence, "Generic AAA Architecture", RFC 2903, 1614 August 2000. 1616 [I-D.nir-tls-eap] 1617 Nir, Y., Sheffer, Y., Tschofenig, H., and P. Gutmann, "A 1618 Flexible Authentication Framework for the Transport Layer 1619 Security (TLS) Protocol using the Extensible 1620 Authentication Protocol (EAP)", draft-nir-tls-eap-13 (work 1621 in progress), December 2011. 1623 [I-D.ietf-oauth-v2] 1624 Hardt, D., "The OAuth 2.0 Authorization Framework", 1625 draft-ietf-oauth-v2-31 (work in progress), August 2012. 1627 [I-D.iab-privacy-considerations] 1628 Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1629 Morris, J., Hansen, M., and R. Smith, "Privacy 1630 Considerations for Internet Protocols", 1631 draft-iab-privacy-considerations-03 (work in progress), 1632 July 2012. 1634 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1635 Authentication Protocol (EAP) Method Requirements for 1636 Wireless LANs", RFC 4017, March 2005. 1638 [RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., 1639 and F. Bersani, "The Extensible Authentication Protocol- 1640 Internet Key Exchange Protocol version 2 (EAP-IKEv2) 1641 Method", RFC 5106, February 2008. 1643 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 1644 RFC 1964, June 1996. 1646 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 1647 Specification", RFC 2203, September 1997. 1649 [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., 1650 and R. Hall, "Generic Security Service Algorithm for 1651 Secret Key Transaction Authentication for DNS (GSS-TSIG)", 1652 RFC 3645, October 2003. 1654 [RFC2138] Rigney, C., Rigney, C., Rubens, A., Simpson, W., and S. 1655 Willens, "Remote Authentication Dial In User Service 1656 (RADIUS)", RFC 2138, April 1997. 1658 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 1659 "Generic Security Service Application Program Interface 1660 (GSS-API) Authentication and Key Exchange for the Secure 1661 Shell (SSH) Protocol", RFC 4462, May 2006. 1663 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1664 Security Layer (SASL)", RFC 4422, June 2006. 1666 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1667 Channels", RFC 5056, November 2007. 1669 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 1670 Service Application Program Interface (GSS-API) Mechanisms 1671 in Simple Authentication and Security Layer (SASL): The 1672 GS2 Mechanism Family", RFC 5801, July 2010. 1674 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 1675 April 2010. 1677 [OASIS.saml-core-2.0-os] 1678 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1679 "Assertions and Protocol for the OASIS Security Assertion 1680 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1681 2.0-os, March 2005. 1683 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 1684 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 1685 D. Spence, "AAA Authorization Framework", RFC 2904, 1686 August 2000. 1688 [I-D.hartman-emu-mutual-crypto-bind] 1689 Hartman, S., Wasserman, M., and D. Zhang, "EAP Mutual 1690 Cryptographic Binding", 1691 draft-hartman-emu-mutual-crypto-bind-00 (work in 1692 progress), March 2012. 1694 [I-D.ietf-emu-eap-tunnel-method] 1695 Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1696 "Tunnel EAP Method (TEAP) Version 1", 1697 draft-ietf-emu-eap-tunnel-method-04 (work in progress), 1698 October 2012. 1700 [WS-TRUST] 1701 Lawrence, K., Kaler, C., Nadalin, A., Goodner, M., Gudgin, 1702 M., Barbir, A., and H. Granqvist, "WS-Trust 1.4", OASIS 1703 Standard ws-trust-200902, February 2009, . 1706 URIs 1708 [1] 1710 [2] 1712 Editorial Comments 1714 [anchor4] JLS: Should this be an EAP failure to the client as well? 1716 [anchor7] JLS: I don't believe this is a true statement - check it 1717 with Josh and Sam. 1719 Authors' Addresses 1721 Josh Howlett 1722 JANET(UK) 1723 Lumen House, Library Avenue, Harwell 1724 Oxford OX11 0SG 1725 UK 1727 Phone: +44 1235 822363 1728 Email: Josh.Howlett@ja.net 1730 Sam Hartman 1731 Painless Security 1733 Phone: 1734 Email: hartmans-ietf@mit.edu 1736 Hannes Tschofenig 1737 Nokia Siemens Networks 1738 Linnoitustie 6 1739 Espoo 02600 1740 Finland 1742 Phone: +358 (50) 4871445 1743 Email: Hannes.Tschofenig@gmx.net 1744 URI: http://www.tschofenig.priv.at 1746 Eliot Lear 1747 Cisco Systems GmbH 1748 Richtistrasse 7 1749 Wallisellen, ZH CH-8304 1750 Switzerland 1752 Phone: +41 44 878 9200 1753 Email: lear@cisco.com 1755 Jim Schaad 1756 Soaring Hawk Consulting 1758 Email: ietf@augustcellars.com