idnits 2.17.00 (12 Aug 2021) /tmp/idnits864/draft-tschofenig-moonshot-ps-00.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 (July 5, 2010) is 4338 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MOONSHOT H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track July 5, 2010 5 Expires: January 6, 2011 7 Federated Authentication Beyond The Web: Problem Statement and 8 Requirements 9 draft-tschofenig-moonshot-ps-00.txt 11 Abstract 13 It is quite common that application developers and system architects 14 are in a need for authentication and authorization support in a 15 distributed environment. At least three parties need to cooperate, 16 namely the end host, the identity provider, and the relying party. 17 At the end of the exchange the identity provider asserts identity 18 information or certain attributes to the relying party without 19 exposing the user's long-term secret to the relying party. 21 While the problem sounds challenging and interesting but it is not 22 new. In fact, various IETF groups have produced specifications to 23 solve this problem, such as Kerberos, RADIUS, and Diameter. Outside 24 the IETF various Single-Sign-On solution for HTTP-based applications 25 have been developed as well. 27 The reader might therefore wonder why there is need for new work 28 given the existence of readily available solutions. This document 29 tries to answer this question in a compact fashion. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 6, 2011. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3. Assumptions and Requirements . . . . . . . . . . . . . . . . . 7 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 70 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 The typical setup for a three party protocol has the following few 76 entities involved. Figure 1 shows the situation. It might surprise 77 that there are actually four parties; we will address the invisible 78 party in the middle a little bit later. 80 With three party protocols there are a number of different protocol 81 variants possible, as the available crypto-literature shows. We will 82 not discuss the different options in this document. What is relevant 83 is that a real world entity is behind the end host and responsible 84 for establishing some form of contract with the identity provider, 85 even if it is only as weak as completing a web form and to confirm 86 the verification email. The outcome of this initial registration 87 step is that credentials are made available to the identity provider 88 and to the end host (or the user). It is important to highlight that 89 in some scenarios there might indeed be a human behind the device 90 denoted as end host and in other cases there is no human involved in 91 the actual protocol execution. 93 We assume that the identity provider and the relying party belong to 94 different administrative domains. Very often there is some form of 95 relationship between the identity provider and the relying party. 96 This is particularly important when the relying party wants to use 97 information obtained from the identity provider for authorization 98 decisions and when the identity provider does not want to release 99 information to every relying party (or only under certain 100 conditions). While it is possible to have a bilateral agreement 101 between every identity provider and every relying party on an 102 Internet scale this setup does require some intermediary, the "stuff- 103 in-the-middle". Please note that the lack of scalability is not 104 caused by technical limitations but rather by business limitations 105 since the agreements between identity providers and the relying 106 parties are often business contracts, i.e. they are about money. The 107 "stuff-in-the-middle" is a placeholder for technical interoperability 108 as well as business practices and operational arrangements, many 109 aspects are outside the scope of the IETF. 111 ----- 112 /- -\ 113 // \\ 114 / \ 115 ---- | | ---- 116 ///- -\\\ | | ///- -\\\ 117 / \ | Stuff-in- | / \ 118 | |-+ the-Middle +-| | 119 | Identity | | | | Relying | 120 | Provider | | | | Party | 121 | | | | | | 122 \ / \ / \ / 123 \\\- -/// \\ // \\\- -/// 124 ---- \- -/ ---- 125 < ----- > 126 \ / 127 \ / 128 \ / 129 \ / 130 \ / 131 \ / 132 \ +------------+ / 133 \ | | / 134 v| End Host |v 135 | | 136 | | 137 +------------+ 139 Figure 1: Three Party Authentication Framework 141 Designing new three party authentication and authorization protocols 142 is hard and cryptographic flaws common in designs. Achieving 143 widespead deployment is even more difficult. The HTTP-based Web has 144 enjoyed a lot of attention from the industry with respect to this 145 problem and some amount of success can be noticed even though many of 146 the business aspects with the "stuff-in-the-middle" still has to be 147 sorted out. This document does not focus on an HTTP-based 148 environment and instead focuses on those protocols where HTTP is not 149 used. Despite the increased excitement for layering every protocol 150 on top of HTTP there are still a number of protocols available that 151 do not use HTTP-based transports. Many of these protocols are 152 lacking an authentication and authorization framework of the style 153 shown in Figure 1. 155 Interestingly, for network access authentication the usage of the AAA 156 framework with RADIUS and Diameter was quite successful from a 157 deployment point of view. To map the terminology used in Figure 1 to 158 the AAA framework the identity provider corresponds to the AAA 159 server, the relying party corresponds to the AAA client, and the 160 "stuff-in-the-middle" are AAA proxies and relays (particularly if 161 they are operated by third parties, such as AAA brokers and clearing 162 houses). The front-end, i.e. the end host to AAA client 163 communication, is in case of network access authentication offered by 164 link layer protocols that forward authentication protocol exchanges 165 back-and-forth. 167 Is it possible to design a system that builds on top of successful 168 protocols to offer non-Web-based protocols with a solid starting 169 point for authentication and authorization in a distributed system? 171 2. Terminology 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 3. Assumptions and Requirements 179 Some requirements restrict the solution space more than others. In 180 this particular case the main requirement is to re-use an existing 181 infrastructure, namely the AAA framework. Briefly stated: The 182 solution MUST make use of the AAA infrastructure (RADIUS and 183 Diameter). Ideally, modifications at AAA servers SHOULD be kept at a 184 minimum. Modifications to the AAA infrastructure that affect 185 operational aspects MUST NOT be made. 187 The next requirement concerns security: The relying party MUST NOT 188 get in possession of the long-term secret of the entity that is 189 authenticated towards the AAA server. Since there is no single 190 authentication mechanism that will be used everywhere there is 191 another associated requirement: The authentication framework MUST 192 allow for the flexible integration of authentication mechanisms. 194 Those who are familiar with the AAA framework might now think 195 about the Extensible Authentication Protocol (EAP) framework. It 196 is standardized, and deployed. The choices are limited. 198 Assuming that this design decision is taken for granted the remaining 199 work is with the integration of the AAA infrastructure into non-Web- 200 based application protocols. Figure 2 shows it graphically. 202 +--------------+ business 203 |AAA Server | agreements 204 |(Identity | <......+ 205 |Provider) | . 206 | | . 207 +------------+-+ . 208 --^----------|-- . . 209 ///// | | \\\\\ . 210 // | | \\ . 211 | | AAA | |. 212 | | protocol | |. 213 | | | |. 214 \\ | | // . 215 \\\\\ | | ///// . 216 --|----------|-- . . 217 Authentication | | . 218 and Security | v . 219 +-------------+ Layer +-+----------+--+ . 220 | |<---------------->| |<-.....+ 221 | Application | | Server Side | 222 | @ End Host | Application | Application | 223 | |<================>|(Relying Party)| 224 +-------------+ Application +---------------+ 225 Data 227 Figure 2: Front-End Integration 229 The front-end (end-host to relying party) MUST be integrated the 230 authentication framework of the back-end. 232 The changes to the end host and the changes to the relying party 233 SHOULD be kept at a minimum. A mechanism MUST be preferred that can 234 demonstrate deployment benefits (based on easy of update of existing 235 software, smaller implementation effort, etc.). 237 4. Security Considerations 239 This entire document is about security. 241 5. IANA Considerations 243 This document does not require actions by IANA. 245 6. Acknowledgments 247 The author would like to thank Sam Hartman for a discussion about all 248 aspects of the "Federated Authentication Beyond The Web" effort when 249 he was visiting MIT in June 2010. 251 7. Normative References 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, March 1997. 256 Author's Address 258 Hannes Tschofenig 259 Nokia Siemens Networks 260 Linnoitustie 6 261 Espoo 02600 262 Finland 264 Phone: +358 (50) 4871445 265 Email: Hannes.Tschofenig@gmx.net 266 URI: http://www.tschofenig.priv.at