idnits 2.17.1 draft-ietf-aaa-roamops-auth-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 63: '... MAY include additional authorizatio...' RFC 2119 keyword, line 224: '...ounting messages MUST flow through the...' RFC 2119 keyword, line 231: '...ntication server MAY use the AAA proto...' RFC 2119 keyword, line 251: '... AAA protocol MUST allow for a sing...' RFC 2119 keyword, line 254: '...The AAA protocol MUST be "proxyable", ...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 186 has weird spacing: '... Reply w/ a...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2284 (ref. '1') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2486 (ref. '2') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 2222 (ref. '3') (Obsoleted by RFC 4422, RFC 4752) Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Standards Track Sun Microsystems, Inc. 4 Title: draft-ietf-aaa-roamops-auth-req-00.txt Glen Zorn 5 Date: March 1999 Microsoft Corporation 7 Roamops Authentication/Authorization Requirements 9 Status of this Memo 11 This document is a submission by the AAA Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the aaa-wg@merit.edu mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at: 34 http://www.ietf.org/shadow.html. 36 Abstract 38 The AAA Working Group is currently looking at defining the 39 requirements for Authentication and Authorization. This document 40 contains the requirements for Roaming Operations. 42 1.0 Introduction 43 In non-roamops environments, a typical AAA deployment would consist 44 of a Policy Enforcement Point (PEP), and a Policy Decision Point 45 (PDP). The PEP receives a request for service from a user or device, 46 and in turn issues an Authentication/Authorization request to the 47 PDP. 49 +------+ +-----+ +-----+ 50 | user | | PEP | | PDP | 51 +------+ +-----+ +-----+ 52 --------> 53 Request for service 54 ---------------------> 55 Authentication/Authorization (AA) 56 <--------------------- 57 Reply w/ authorization info 58 <-------- 59 Service is offered 61 The PDP authenticates the user, makes some authorization decisions 62 based on the user or device's profile, and issues a reply. The reply 63 MAY include additional authorization information, which the PEP uses 64 to perform additional authorization decisions before offering the 65 service to the user/device. 67 Much of the work in progress within ROAMOPS allows the AAA server to 68 take a much more active role in the authentication phase. This is 69 intended to increase the security, especially in roaming 70 environments, where replay of previous authentication sessions is 71 very easy. The unfortunate side-effect of this feature is that it 72 requires more exchanges between the PEP and the PDP, as shown below. 74 +------+ +-----+ +-----+ 75 | user | | PEP | | PDP | 76 +------+ +-----+ +-----+ 77 --------> 78 Request for service 79 ---------------------> 80 AA Req w/ identity 81 <--------------------- 82 AA Reply w/ Challenge 83 <-------- 84 Challenge 85 --------> 86 Response 87 ---------------------> 88 AA Req w/ Response 89 <--------------------- 90 Reply w/ authorization info 91 <-------- 92 Service is offered 94 In the above example, when the PEP issues the initial AA request to 95 the PDP, it includes the user's identity (ideally in the format 96 defined by the Network Access Identifier (NAI) specification [1]). 97 The PDP issues some challenge to the PEP, which is then forwarded to 98 the user/device. This challenge could in fact be encapsulated within 99 an EAP [2] or SASL [3] envelope, which would allow for user/device to 100 PDP authentication using existing authentication frameworks. Once the 101 PDP determines that the user/device has satisfactorily authenticated 102 itself, access is granted which includes authorization information. 104 There have been some discussions in the AAA working group to 105 logically split the authentication and authorization phase, possibly 106 into two different protocols. The resulting protocol would look like 107 the following figure: 109 +------+ +-----+ +-----+ 110 | user | | PEP | | PDP | 111 +------+ +-----+ +-----+ 112 --------> 113 Request for service 114 ---------------------> 115 Authen. Req w/ identity 116 <--------------------- 117 Authen. Reply w/ Challenge 118 <-------- 119 Challenge 120 --------> 121 Response 122 ---------------------> 123 Authen. Req w/ Response 124 <--------------------- 125 Authen. Reply w/ token 126 ---------------------> 127 Authorization Req w/ token 128 <--------------------- 129 Reply w/ authorization info 130 <-------- 131 Service is offered 133 In this instance, the PEP initially sends the authentication request 134 to the PDP. Upon successful authentication, the PDP returns some form 135 of signed token back in the reply. The PEP would then issue the 136 authorization request to the PDP, which would look at the token (to 137 ensure that authentication had already occured), authorize the 138 user/device, and return a reply that contains the additional 139 authorization information. 141 Since it is very possible for the authentication and authorization to 142 be performed by two different PDPs, each specializing in their own 143 area, the above example does allow for such a logical split in 144 functionality. The Authentication PDP could support a specific 145 manufacturer's token card, or biometric authentication. 147 In the roamops model, it is assumed that the user/device cannot be 148 authenticated and authorized locally. This means that the user/device 149 requests service from a provider that is not its "home" provider. 150 Therefore, the visited domain must forward the request to the user's 151 home domain in order to perform the Authentication and Authorization. 152 A reply from the home domain may be construed as "willingness to pay" 153 for the service provided to the requesting user/device. 155 Visited Home 156 +------+ +-----+ +-----+ +-----+ 157 | user | | PEP | | PDP | | PDP | 158 +------+ +-----+ +-----+ +-----+ 159 --------> 160 Request for service 161 ---------------------> 162 Authen. Req Req (includes identity) 163 -------------> 164 Authen. Req w/ identity 165 <------------- 166 Authen. Rep. w/ Challenge 167 <--------------------- 168 Authen. Reply w/ Challenge 169 <-------- 170 Challenge 171 --------> 172 Response 173 ---------------------> 174 Authen. Req w/ Response 175 -------------> 176 Authen. Req w/ Response 177 <------------- 178 Authen. Reply w/ token 179 <--------------------- 180 Authen. Reply w/ token 181 ---------------------> 182 Autho. Req w/ token 183 -------------> 184 Autho. Req w/ token 185 <------------- 186 Reply w/ authorization 187 info 188 <--------------------- 189 Reply w/ authorization info 190 <-------- 191 Service is offered 193 In the above diagram, the Visited PDP forwards the request to the 194 home PDP. The Home PDP is known using the identity, which is some 195 cases is the NAI. It is equally possible for the visited PDP to 196 simply forward the request to a broker, which it shares a trust 197 relationship with, which in turn forwards the request to the home 198 PDP. 200 Visited Broker Home 201 +------+ +-----+ +-----+ +-----+ +-----+ 202 | user | | PEP | | PDP | | PDP | | PDP | 203 +------+ +-----+ +-----+ +-----+ +-----+ 205 Here each message will traverse the internet, possibly twice for each 206 message if a broker is involved. Many of the services which will be 207 using AAA stated that one of their requirement was to be able to use 208 AAA and not impose an additional long latency. Therefore, it is 209 paramount that we attempt to limit the number of messages required 210 for the authentication and authorization phase. Ideally, the 211 authentication request *should* include a request for authorization. 212 This also has the advantange of reducing the Inter-Domain trust 213 relationships to one (instead of one for authentication and one for 214 authorization). 216 When brokers are involved, it is necessary that a end-to-end (Visited 217 to Home PDP) trust relationship be established in order to prevent 218 from fraudulent broker activity. Otherwise, it would be possible for 219 the broker to modify authorization information that was returned by 220 the home domain's PDP. It should therefore be possible for the broker 221 to return a forwarding address to the visited network's PDP, and 222 allow the local PDP to contact the "home" PDP directly, using the 223 end-to-end trust relationship for authentication and authorization. 224 However, accounting messages MUST flow through the broker. This 225 decision is up to the broker's policy on whether a forwarding address 226 is returned, or the request is proxied to the home domain. 228 Note that the PDP can still interface with a specialized 229 authentication server for support of token cards or biometrics, as 230 shown below. In this case, the interface between the PDP and the 231 specialized Authentication server MAY use the AAA protocol, or may 232 use a proprietary protocol. However, this is clearly outside this 233 scope of this document. If the Authentication server is required, 234 this should exist within the home domain, and should not be exposed 235 to the visited domain, especially if the interface to the 236 authentiation server is proprietary. 238 +------+ +-----+ +-----+ +------+ 239 | user | | PEP | | PDP | | Auth | 240 +------+ +-----+ +-----+ +------+ 242 3.0 Conclusion 244 The ROAMOPS working group has the following requirements: 246 - Allow existing Authentication Frameworks (EAP, SASL) to be 247 transported over the AAA protocol for user/device 248 authentication. 250 - Allow for separate authorization when necessary, but the 251 AAA protocol MUST allow for a single message to request both 252 authentication and authorization. 254 - The AAA protocol MUST be "proxyable", meaning that a PDP 255 MUST be able to forward the request to another PDP, which 256 may or may not be within the same administrative domain. 258 - The AAA protocol MUST allow for intermediate brokers to 259 add their own local Authorization information to a request 260 or response. 262 - When a broker is involved, the protocol MUST provide end to 263 end security. 265 - The broker MUST be able to return a forwarding address to 266 a requestor, allowing two nodes to communicate together. 268 Furthermore, the protocol MUST provide the following features (per 269 user session): 271 - One Authentication, One Authorization 273 - One Authentication, Multiple Authorization 275 - Multiple Authentication, Multiple Authorization 277 4.0 References 279 [1] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication 280 Protocol (EAP)", RFC 2284, March 1998. 281 [2] B. Aboba, M. Beadles, "The Network Access Identifier", 282 RFC 2486, January 1999. 283 [3] J. Myers, "Simple Authentication and Security Layer 284 (SASL)", RFC 2222, October 1997. 286 5.0 Author's Address 288 Questions about this memo can be directed to: 290 Pat R. Calhoun 291 Network and Security Research Center 292 Sun Microsystems, Inc. 293 15 Network Circle 294 Menlo Park, California, 94025 295 USA 297 Phone: 1-650-786-7733 298 Fax: 1-650-786-6445 299 E-mail: pat.calhoun@eng.sun.com 301 Glen Zorn 302 Microsoft Corporation 303 One Microsoft Way 304 Redmond, Washington 98052 306 Phone: +1 425 703 1559 307 E-Mail: glennz@microsoft.com