idnits 2.17.1 draft-ietf-abfab-usecases-05.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 (September 25, 2012) is 4230 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2911 (Obsoleted by RFC 8011) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) == Outdated reference: A later version (-11) exists of draft-freeman-plasma-requirements-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ABFAB R. Smith, Ed. 3 Internet-Draft Cardiff University 4 Intended status: Informational September 25, 2012 5 Expires: March 29, 2013 7 Application Bridging for Federated Access Beyond web (ABFAB) Use Cases 8 draft-ietf-abfab-usecases-05 10 Abstract 12 Federated identity is typically associated with Web-based services at 13 present, but there is growing interest in its application in non Web- 14 based contexts. The goal of this document is to document a selection 15 of the wide variety of these contexts whose user experience could be 16 improved through the use of technologies based on the ABFAB 17 architecture and specifications. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 29, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Context of Use Cases . . . . . . . . . . . . . . . . . . . . . 3 55 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Cloud Services . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1.1. Cloud-based Application Services . . . . . . . . . . . 4 58 3.1.2. Cloud-based Infrastructure Services . . . . . . . . . 5 59 3.2. High Performance Computing . . . . . . . . . . . . . . . . 6 60 3.3. Grid Infrastructure . . . . . . . . . . . . . . . . . . . 7 61 3.4. Databases and Directories . . . . . . . . . . . . . . . . 8 62 3.5. Media Streaming . . . . . . . . . . . . . . . . . . . . . 8 63 3.6. Printing . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.7. Accessing Applications from Devices on a Telecoms 65 Infrastructure . . . . . . . . . . . . . . . . . . . . . . 9 66 3.8. Enhanced Security Services for S/MIME . . . . . . . . . . 10 67 3.9. Smart Objects . . . . . . . . . . . . . . . . . . . . . . 11 68 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 74 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 Federated identity facilitates the controlled sharing of information 79 about people (a.k.a. 'principals'), commonly across organisational 80 boundaries. This avoids redundant registration of principals who 81 operate in and across multiple domains; both reducing the 82 administrative overhead for the organizations involved and improving 83 the usability of systems for the principal. Simultaneously, it can 84 also help address privacy-related concerns, along with the regulatory 85 and statutory requirements of some jurisdictions. 87 The information that is passed between organizations may include 88 authentication state and identity information that can be used for 89 many purposes, including making access management decisions. A 90 number of mechanisms support the transmission of this information for 91 Web-based scenarios in particular (e.g. SAML 92 [OASIS.saml-profiles-2.0-os]), but there is significant interest in 93 the more general application of federated identity to include non-Web 94 use cases. This document enumerates some of these use cases, 95 describing how technologies based on the the ABFAB architecture 96 [I-D.lear-abfab-arch] and specifications could be used. 98 2. Context of Use Cases 100 The use cases described in this document are a result of work led by 101 Janet, the operator of the United Kingdom's education and research 102 network, responding to requirements from its community, and augmented 103 by various inputs from the IETF community. 105 The ABFAB architecture and specifications enables authentication and 106 authorization to occur across organizational boundaries. For many 107 applications, principals need not have pre-instantiated accounts that 108 their federated identity maps to before their first visit to that 109 application; the application can perform this process on the fly. In 110 cases where such accounts are required for particular applications, 111 the pre-provisioning process is out of scope of ABFAB technologies, 112 which assumes any such requirements have already been fulfilled. 113 Standards-based work of note that would assist with this pre- 114 provisioning of accounts includes the standards and specifications 115 produced by the IETF SCIM working group. 117 3. Use Cases 119 This section describes some of the variety of potential use cases 120 where technologies based on the ABFAB architecture and specifications 121 could help improve the user experience; each includes a brief 122 description of how current technologies attempt to solve the use 123 cases and how this could improved upon by ABFAB implementations. 125 3.1. Cloud Services 127 Cloud computing is emerging as a common way of provisioning 128 infrastructure services in an on-demand manner. These services are 129 typically offered as one of three models: 131 o General infrastructure services such as computing power, network, 132 storage, and utility ("Infrastructure as a Service", or IaaS); 134 o Software stacks or platforms such as database servers, web 135 servers, application runtime environments, etc. ("Platform as a 136 Service", or PaaS); 138 o Common application software such as email, shared storage, 139 business applications such as Customer Relationship Management 140 (CRM) or scientific applications ("Software as a Service", or 141 SaaS). 143 In many cases the provisioned cloud infrastructures and applications 144 need to be integrated with existing infrastructure of the 145 organisation, and it is of course desirable if this could be achieved 146 in a way that allows business or scientific workflows to act across 147 infrastructure both across the cloud and in the local infrastructure 148 in as seamless a manner as possible. 150 There are two main areas where federated access fits in cloud 151 computing: using federation to help mediate access to cloud based 152 application services (e.g. cloud provided email or CRM systems); and 153 using federation to help mediate access to the management of cloud 154 based infrastructure services. 156 3.1.1. Cloud-based Application Services 158 Many organizations are seeking to deliver services to their users 159 through the use of providers based in the 'cloud'. This is typically 160 motivated by a desire to avoid management and operation of commodity 161 services which, through economies of scale and so-forth, can often be 162 delivered more efficiently by such providers. 164 Many providers already provide web-based access using conventional 165 federated authentication mechanisms; for example, outsourced email 166 provision where federated access is enabled using 'webmail' 167 applications where access is mediated through the use of SAML 168 [OASIS.saml-profiles-2.0-os]. This use of federated authentication 169 enables organizations that consume cloud services to more efficiently 170 orchestrate the delivery of these services to their users, and 171 enables Single Sign On to the services for these users. 173 Frequently, however, users will prefer to use desktop applications 174 that do not use web (i.e. HTTP [RFC2616] based) protocols. For 175 example, a desktop email client may use a variety of non-web 176 protocols including SMTP [RFC5321], IMAP [RFC3501] and POP [RFC1939]. 177 Some cloud providers support access to their services using non-web 178 protocols, however, the authentication mechanisms used by these 179 protocols will typically require that the provider has access to the 180 user's credentials - i.e. non federated. Consequently, the provider 181 will require that users' credentials are regularly synchronised from 182 the user organisation to the provider, with the obvious overhead this 183 imparts on the organisation along with the obvious implications for 184 security and privacy; or else be provisioned directly by the provider 185 to the user. 187 The latter approach of directly provisioning accounts may be 188 acceptable in the case where an organisation has relationships with 189 only a small number of providers, but may become untenable if an 190 organisation obtains services from many providers. Consequently any 191 organisation with a requirement to use non-web protocols would prefer 192 to make use of the credentials that they have already provisioned 193 their users with, and to utilise federated authentication with non- 194 web protocols to obtain access to cloud-based providers. 196 ABFAB could help in this context as its specifications would enable 197 federated authentication for a variety of non-web protocols, thus 198 gaining the benefits of federated authentication without any of the 199 drawbacks that are currently experienced. 201 3.1.2. Cloud-based Infrastructure Services 203 Typical IaaS or PaaS cloud use cases deal with provisioning on-demand 204 cloud based infrastructure services that may include infrastructure 205 components such as computing and storage resources, network 206 infrastructure, and other utilities. Cloud based virtualised 207 applications should ideally operate in the same way as regular non- 208 virtualised applications whilst allowing management of the virtual 209 computing resources (scaling, migration, reconfiguration) without 210 changing the management applications. 212 In many cases, moving applications or platforms to the Cloud may 213 require their re-designing/re-factoring to support dynamic deployment 214 and configuration, including their security and authentication and 215 authorisation services. These will typically today be extensively 216 based on manual setup and configuration of such components and 217 features as trusted certificates and trust anchors, authorities and 218 trusted services (both their location and certificates), attribute 219 namespaces, policies, etc. 221 ABFAB could help in this context as a way of moving from the model of 222 manually configured authentication and authorisation towards a more 223 easily managed system involved federated trust and identity, and will 224 be applicable for a wide range of existing features (e.g. connecting 225 to a newly provisioned Virtual Machine through ABFAB enabled secure 226 shell (SSH) [RFC4251] instead of having to manually manage an 227 administrative login to that machine). 229 3.2. High Performance Computing 231 High-performance computing (HPC) is a discipline that uses 232 supercomputers and computer clusters to solve complex computation 233 problems; it most commonly associated with scientific research or 234 computational science. 236 Access to HPC resources, often mediated through technologies such as 237 secure shell, is typically managed through the use of user digital 238 certificates [RFC5280] or through manually provisioned credentials 239 and accounts. This requires HPC operators to issue certificates or 240 accounts to users using a registration process that often duplicates 241 identity management processes that already exist within most user 242 organizations. The HPC community would like to utilise federated 243 identity to perform both the user registration and authentication 244 functions required to use HPC resources, and so reduce costs by 245 avoiding this duplication of effort. 247 The HPC community also have following additional requirements: 249 o Improved Business Continuity: In the event of operational issues 250 at an HPC system at one organisation (for example, a power 251 failure), users and jobs could be transparently moved to other HPC 252 systems without the overhead of having to manage user credentials 253 for multiple organizations; 255 o Establish HPC-as-a-service: Many organizations who have invested 256 in HPC systems want to make their systems easily available to 257 external customers. Federated authentication facilitates this by 258 enabling these customers to use their existing identity 259 management, user credentialing and support processes; 261 o Improve the user experience: Authentication to HPC systems is 262 normally performed using user digital certificates, which some 263 users find difficult to use. Federated authentication can provide 264 a better user experience by allowing the use of other types of 265 credentials, without requiring technical modifications to the HPC 266 system to support these. 268 ABFAB could help in this context as it could enable federated 269 authentication for the many of the protocols and technologies 270 currently in use by HPC providers, such as secure shell. 272 3.3. Grid Infrastructure 274 Grids are large-scale distributed infrastructures, consisting of many 275 loosely coupled, independently managed, and geographically 276 distributed resources managed by organisationally independent 277 providers. Users of grids utilise these resources using grid 278 middleware that allows them to submit and control computing jobs, 279 manipulate datasets, communicate with other users, etc. These users 280 are organised into Virtual Organisations (VOs); each VO represents a 281 group of people working collaboratively on a common project. VOs 282 facilitate both the management of its users and the meditation of 283 agreements between its users and resource providers. 285 Authentication and authorisation within most grids is performed using 286 a Public Key Infrastructure, requiring each user to have an X.509 287 public-key certificate [RFC5280]. Authentication is performed 288 through ownership of a particular certificate, while authorisation 289 decisions are made based on the user's identity (derived from their 290 X.509 certificate), membership of a particular VO, or additional 291 information assigned to a user by a VO. While efficient and 292 scalable, this approach has been found wanting in terms of usability 293 - many users find certificates difficult to manage, for various 294 reasons. 296 One approach to ameliorating this issue, adopted to some extent by 297 some grid communities already, is to abstract away direct access to 298 certificates from users, instead using alternative authentication 299 mechanisms and then converting the credential provided by these into 300 standard grid certificates. Some implementations of this idea use 301 existing federated authentication techniques. However, current 302 implementations of this approach suffer from a number of problems, 303 not the least of which is the inability to use the federated 304 credentials used to authenticate to a credential-conversion portal to 305 also directly authenticate to non-web resources such as secure shell 306 daemons. 308 The ability to use federated authentication directly through ABFAB, 309 without the use of a credential conversion service, would allow users 310 to authenticate to a grid and its associated services, allowing them 311 to directly launch and control computing jobs, all without having to 312 manage, or even see, an X.509 public-key certificate at any point in 313 the process. Authorisation within the grid would still be performed 314 using VO membership asserted issued by the user's identity provider 315 through the federated transport. 317 3.4. Databases and Directories 319 Databases (e.g. MySQL, PostgreSQL, Oracle, etc.) and directory 320 technologies (e.g. OpenLDAP, Microsoft Active Directory, Novell 321 eDirectory, etc.) are very commonly used within many organsiations 322 for a variety of purposes. This can include core administrative 323 functions, such as hosting identity information for its users, as 324 well as business functions (e.g. student records systems at 325 educational organizations). 327 Access to such database and directory systems is usually provided for 328 internal users only, however, users external to the organizations 329 sometimes require access to these systems directly: for example, 330 external examiners in educational organizations requiring access to 331 student records systems, members of cross-organisational project 332 teams who store information in a particular organisation's systems, 333 external auditors, etc. 335 Credentials for users both internal or external to the organisation 336 that allow access these databases and directories are usually 337 provisioned manually within an organisation, either using Identity 338 Management technologies or through more manual processes. For the 339 internal users, this situation is fine - this is one of the mainstays 340 of Identity Management. However, for external users who require 341 access, this represents more of a problem for organisational 342 processes. The organisation either has to add these external users 343 to its internal Identity Management systems, or else provision these 344 credentials directly within the database/directory systems and 345 continue to manage them, including appropriate access controls 346 associated with each credential, for the lifetime of that credential. 348 Federated authentication to databases or directories, via ABFAB 349 technologies, would improve upon this situation as it would remove 350 the need to provision and de-provision credentials to access these 351 systems. Organisations may still wish to manually manage access 352 control of federated identities; however, even this could be provided 353 through federated means, if the trust relationship between 354 organizations was strong enough for the organisation providing the 355 service to rely upon it for this purpose. 357 3.5. Media Streaming 359 Media streaming services (audio or audio/video) are often provided 360 publicly to anonymous users, but authentication is important for a 361 protected subset of streams where rights management and access 362 control must be applied. 364 Streams can be delivered via protocols such as RTSP [RFC3226] / RTP 366 [RFC3550] which already include authentication, or can be published 367 in an encrypted form with keys only being distributed to trusted 368 users. Federated authentication is applicable to both of these 369 cases. 371 Alternative mechanisms to managing access exist; for example, an 372 approach where a unique stream URI is minted for each user. However, 373 this relies on preserving the secrecy of the stream URI, and also 374 requires a communication channel between the web page used for 375 authentication and the streaming service itself. Federated 376 authentication would be a better fit for this kind of access control. 377 Thus, AFAB technologies that allow federated authentication directly 378 within (inherently non-web) media streaming protocols would represent 379 an enhancement to this area. 381 3.6. Printing 383 A visitor from one organisation to the premises of another often 384 requires the use of print services. Their home organisation may of 385 course offer printing, but the output could be a long way away so the 386 home service is not useful. The user will typically want to print 387 from within a desktop or mobile application. 389 Where this service is currently offered it would usually be achieved 390 through the use of 'open' printers (i.e. printers that allow 391 anonymous print requests), where printer availability is advertised 392 through the use of Bonjour or other similar protocols. If the 393 organisation requires authenticated print requests (usually for 394 accounting purposes), the the visitor would usually have to be given 395 credentials that allow this, often supplemented with pay-as-you-go 396 style payment systems. 398 Adding federated authentication to IPP [RFC2911] (and other relevant 399 protocols) would enable this kind of remote printing service without 400 the administrative overhead of credentialing these visitors (who, of 401 course, may well one time visitors to the organisation). This would 402 be immediately applicable to higher education, where this use case is 403 increasingly important thanks to the success of federated network 404 authentication systems such as eduroam but could also be used in 405 other contexts such as commercial print kiosks, or in large, 406 heterogeneous organizations. 408 3.7. Accessing Applications from Devices on a Telecoms Infrastructure 410 Telecom operators typically have the following properties: 412 o A large collection of registered users, many of whom may have 413 identities registered to a fairly high level of assurance (often 414 for payment purposes). However, not all users will have this 415 property - for example, non-contract customers on mobile telecoms 416 infrastructures in countries with low levels of identity 417 registration requirements. 419 o An existing network infrastructure capable of authenticating a 420 device (e.g. a cellphone or an ADSL router), and by inference, its 421 owner. 423 o A large collection of applications (both web-based and non web- 424 based) that its users wish to access using their device. These 425 applications could be hosted by the telecoms operator directly, or 426 could be any application or system on the internet - for example, 427 network messaging services, VoIP, email, etc. 429 At present, authentication to these applications will be typically 430 configured manually by the user on the device (or on a different 431 device connected to that device) but inputting their (usually pre- 432 provisioned out-of-band) credentials for that application - one per 433 application. 435 The use of ABFAB technologies in this case, via a mechanism dubbed 436 "federated cross-layer access" (see [I-D.wei-abfab-fcla]) would 437 enhance the user experience of using these applications through 438 devices greatly. Federated cross-layer access would make use of the 439 initial mutual authentication between device and network to enable 440 subsequent authentication and authorisation to happen in a seamless 441 manner for the user of that device authenticating to applications. 443 3.8. Enhanced Security Services for S/MIME 445 There are many situations where organizations want to protect 446 information with robust access control, either for implementation of 447 intellectual property right protections, enforcement of contractual 448 confidentiality agreements or because of legal regulations. The 449 Enhanced Security Services (ESS) for S/MIME defines an access control 450 mechanism which is enforced by the recipient's client after 451 decryption of the message (see [I-D.freeman-plasma-requirements]). 452 The data model used makes use of Policy decision points (PDP) which 453 make the policy decisions, policy enforcement points (PEP) which make 454 decision requests to the PDP, and policy information points (PIP) 455 which issue attributes about subjects. The decisions themselves are 456 based on the policies and on the subject attributes. 458 The use of ABFAB technologies in this case would enable both the 459 front or back end attribute exchange required to provide subject 460 attributes. When the PEP contacts the PDP, it would initiate an 461 ABFAB authentication in order to authenticate to the PDP and allow it 462 to obtain these required subject attributes. Once authenticated, the 463 PDP would return a token to the subject PEP which can be used for 464 subsequent authentications to the PDP. 466 3.9. Smart Objects 468 Many smart device deployments involve multiple organizations that do 469 not directly share security infrastructure. For example, in smart 470 power deployments, devices including appliances and infrastructure 471 such as electric car chargers will wish to connect to an energy 472 management system. The energy management system is provided by a 473 utility company in some deployments. The utility company may wish to 474 grant access only to authorized devices; for example, a consortium of 475 utility companies and device manufacturers may certify devices to 476 connect to power networks. 478 In another example, consumer devices may be used to access cloud 479 services. For example, a camera could be bound to a photo processing 480 site. Authentication and authorization for uploading pictures or 481 ordering prints is required. Sensors could be used to provide data 482 to services run by organizations other than the sensor manufacturer. 483 Authorization and authentication can become very tricky when sensors 484 have no user interface. Cellular devices may want to access services 485 provided by a third party regardless of whether the cellular network 486 or wi-fi is used. This becomes difficult when authorization and 487 billing is coordinated by the cellular provider. 489 The use of ABFAB technologies in this case would provide 490 authentication between one entity, such as a smart device, and its 491 identity provider. Only two parties are involved in this exchange; 492 this means that the smart device need not participate in any 493 complicated public-key infrastructure even if it is authenticating 494 against many cloud services. Instead, the device can delegate the 495 process of authenticating the service and even deciding whether the 496 device should be permitted to access the service to the identity 497 provider. This has several advantages. A wide variety of revenue 498 sharing models are enabled. Because device authentication is only 499 with a single identity provider, phishing of device credentials can 500 be avoided. Authorization and decisions about what personal 501 information to release are made by the identity provider. The device 502 owner can use a rich interface such as a website to configure 503 authorization and privacy policy even if the device has no user 504 interface. This model works well with pre-provisioning of device 505 credentials. 507 4. Contributors 509 The following individuals made important contributions to the text of 510 this document: Tim Bannister (Manchester University), Simon Cooper 511 (Janet), Josh Howlett (Janet), and Mark Tysom (Janet). 513 5. Acknowledgements 515 These use-cases have been developed and documented using significant 516 input from Jens Jensen (STFC Rutherford Appleton Laboratory), Daniel 517 Kouril (CESNET), Michal Prochazka (CESNET), Ian Stewart (University 518 of Edinburgh), Stephen Booth (Edinburgh Parallel Computing Centre), 519 Eefje van der Harst (SURFnet), Joost van Dijk (SURFnet), Robin 520 Breathe (Oxford Brookes University), Yinxing Wei (ZTE Corporation), 521 Trevor Freeman (Microsoft Corp.), Sam Hartman (Painless Security, 522 LLC), and Yuri Demchenko (University of Amsterdam). 524 6. Security Considerations 526 This document contains only use cases and defines no protocol 527 operations for ABFAB. Security considerations for the ABFAB 528 architecture are documented in the ABFAB architecture specification, 529 and security considerations for ABFAB technologies and protocols that 530 are discussed in these use cases are documented in the corresponding 531 protocol specifications. 533 7. IANA Considerations 535 This document does not require actions by IANA. 537 8. References 539 8.1. Normative References 541 [I-D.lear-abfab-arch] Howlett, J., Hartman, S., 542 Tschofenig, H., and E. Lear, 543 "Application Bridging for 544 Federated Access Beyond Web 545 (ABFAB) Architecture", 546 draft-lear-abfab-arch-02 (work in 547 progress), March 2011. 549 8.2. Informative References 551 [RFC1939] Myers, J. and M. Rose, "Post 552 Office Protocol - Version 3", 553 STD 53, RFC 1939, May 1996. 555 [RFC2616] Fielding, R., Gettys, J., Mogul, 556 J., Frystyk, H., Masinter, L., 557 Leach, P., and T. Berners-Lee, 558 "Hypertext Transfer Protocol -- 559 HTTP/1.1", RFC 2616, June 1999. 561 [RFC2911] Hastings, T., Herriot, R., deBry, 562 R., Isaacson, S., and P. Powell, 563 "Internet Printing Protocol/1.1: 564 Model and Semantics", RFC 2911, 565 September 2000. 567 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 568 A6 aware server/resolver message 569 size requirements", RFC 3226, 570 December 2001. 572 [RFC3501] Crispin, M., "INTERNET MESSAGE 573 ACCESS PROTOCOL - VERSION 4rev1", 574 RFC 3501, March 2003. 576 [RFC3550] Schulzrinne, H., Casner, S., 577 Frederick, R., and V. Jacobson, 578 "RTP: A Transport Protocol for 579 Real-Time Applications", STD 64, 580 RFC 3550, July 2003. 582 [RFC4251] Ylonen, T. and C. Lonvick, "The 583 Secure Shell (SSH) Protocol 584 Architecture", RFC 4251, 585 January 2006. 587 [RFC5280] Cooper, D., Santesson, S., 588 Farrell, S., Boeyen, S., Housley, 589 R., and W. Polk, "Internet X.509 590 Public Key Infrastructure 591 Certificate and Certificate 592 Revocation List (CRL) Profile", 593 RFC 5280, May 2008. 595 [RFC5321] Klensin, J., "Simple Mail Transfer 596 Protocol", RFC 5321, October 2008. 598 [OASIS.saml-profiles-2.0-os] Hughes, J., Cantor, S., Hodges, 599 J., Hirsch, F., Mishra, P., 600 Philpott, R., and E. Maler, 601 "Profiles for the OASIS Security 602 Assertion Markup Language (SAML) 603 V2.0", OASIS Standard OASIS.saml- 604 profiles-2.0-os, March 2005. 606 [I-D.wei-abfab-fcla] Wei, Y., "Federated Cross-Layer 607 Access", draft-wei-abfab-fcla-02 608 (work in progress), March 2012. 610 [I-D.freeman-plasma-requirements] Freeman, T., Schaad, J., and P. 611 Patterson, "Requirements for 612 Message Access Control", draft- 613 freeman-plasma-requirements-03 614 (work in progress), August 2012. 616 Author's Address 618 Dr. Rhys Smith (editor) 619 Cardiff University 620 39-41 Park Place 621 Cardiff CF10 3BB 622 United Kingdom 624 Phone: +44 29 2087 0126 625 EMail: smith@cardiff.ac.uk