idnits 2.17.1 draft-perez-abfab-gss-remote-attr-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 5, 2015) is 3126 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-abfab-aaa-saml-11 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ABFAB A. Perez-Mendez 3 Internet-Draft R. Marin-Lopez 4 Intended status: Informational G. Lopez-Millan 5 Expires: April 7, 2016 University of Murcia 6 October 5, 2015 8 Retrieving remote attributes using GSS-API naming extensions 9 draft-perez-abfab-gss-remote-attr-00 11 Abstract 13 The GSS-API Naming Extensions define new APIs that extend the GSS-API 14 naming model to support name attribute transfer between GSS-API 15 peers. Historically, this set of functions has been used to obtain 16 the authorization information contained in some sort of authorization 17 token provided to the GSS acceptor during the context establishment 18 process, such as a Kerberos ticket, a SAML assertion, or an X.509 19 attribute certificate. However, some scenarios require to allow the 20 GSS acceptor to request additional attributes after context 21 establishment. If these attributes are not locally stored by the GSS 22 mechanism they have to be retrieved from an external source (e.g. 23 SQL database, LDAP directory, external IdP, etc.). This document 24 describes how current GSS-API extensions are able to encompass such 25 functionality without requiring of any change, neither on the 26 existing calls nor on the way applications use the API. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 7, 2016. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. General operation . . . . . . . . . . . . . . . . . . . . . . 3 66 5. Example using draft-ietf-abfab-aaa-saml, GSS-EAP and RFC7056 5 67 6. Considerations on blocking calls . . . . . . . . . . . . . . 6 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 9.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 The Generic Security Service Application Programming Interface (GSS- 78 API) Naming Extensions [RFC6680] define new APIs that extend the GSS- 79 API naming model to support name attribute transfer between GSS-API 80 peers. Historically, this set of functions has been used to obtain 81 the authorization information contained in some sort of authorization 82 token provided to the GSS acceptor during the context establishment 83 process, such as a Kerberos ticket, a SAML assertion, or an X.509 84 attribute certificate. Therefore, after context establishment, the 85 GSS mechanism could provide any of the available name attributes to 86 the application (GSS acceptor) without requiring any further 87 interaction with any external entity. 89 However, some scenarios require to allow the GSS acceptor to request 90 additional attributes after context establishment. In those cases, 91 it is possible that these attributes are not locally stored by the 92 GSS mechanism and, therefore, they have to be retrieved from an 93 external source (e.g. SQL database, LDAP directory, external IdP, 94 etc.). This document describes how current GSS-API extensions are 95 able to encompass such functionality without requiring of any change, 96 neither on the existing calls nor on the way applications use the 97 API. 99 2. Conventions 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 3. Motivation 107 This document is motivated by the work being done in the IETF ABFAB 108 WG. In particular, the ABFAB architecture [I-D.ietf-abfab-arch] 109 defines a way by which a federated end user can authenticate with a 110 particular application by using a new GSS-API mechanism called GSS- 111 EAP [RFC7055]. This mechanism conveys EAP packets between the end 112 user (acting as EAP peer and GSS initiator), the application (acting 113 as EAP authenticator and GSS acceptor), and the RADIUS server (acting 114 as EAP server). Moreover, the ABFAB architecture also defines how a 115 SAML assertion containing information about the end user is delivered 116 to the GSS acceptor after the successful authentication of the end 117 user. This latter process is described in the ABFAB Authentication 118 Profile of [I-D.ietf-abfab-aaa-saml]. 120 To this point, the GSS-EAP mechanism can make the information 121 contained in the SAML assertion available to the application, by 122 using the standard GSS-API Naming Extensions calls [RFC7056]. That 123 is, the GSS_Inquire_Name() call returns the list of attributes 124 available in the SAML assertion, whereas the GSS_Get_Name_Attribute() 125 one returns the value of each specific attribute. 127 However, [I-D.ietf-abfab-aaa-saml] also defines the ABFAB Assertion 128 Query/Request Profile. Using it, the GSS acceptor can send 129 additional SAML Attribute Queries to the IDP after the end user has 130 been authenticated, in order to obtain attributes that were not 131 obtained before (i.e. not listed by GSS_Inquire_Name()). It was not 132 clear for the ABFAB WG whether this behaviour was possible using 133 current GSS-API calls, so this document intends to shed some light on 134 the subject. 136 4. General operation 138 Despite its typical usage, the GSS-API naming extensions document 139 [RFC6680] takes no assumption on how a particular GSS mechanism 140 obtains the attributes associated to a name. Indeed, as any other 141 API, the GSS-API works as a "black box", where only inputs and 142 outputs are specified. Hence, it is irrelevant whether the GSS 143 mechanism has the attributes locally stored, or it has to retrieve 144 this information from an external source. Moreover, [RFC6680] does 145 not forbid the usage of the GSS_Get_Name_Attribute() call to request 146 the value of an attribute that is not listed in the output of the 147 GSS_Inquire_Name() call. 149 Taking the previous considerations into account, the following steps 150 describe a proposal by which any GSS-API mechanism implementation can 151 retrieve remote attributes and provide them to the application in a 152 transparent way: 154 1. The application gets the list of attribute names by invoking 155 GSS_Inquire_Name(). 157 2. The application is interested on a particular attribute (called 158 "ATTR") that is not included in the results from step 1. 160 3. The application requests the value of attribute "ATTR" by 161 invoking GSS_Get_Name_Attribute(). 163 4. The GSS mechanism processes the request and realizes the 164 attribute is not available into its local storage. Instead of 165 generating an GSS_S_UNAVAILABLE error, the mechanism checks its 166 configuration to see whether it can retrieve the attribute from 167 an external source (e.g. SQL database, LDAP directory, SAML 168 IDP...). There are two possible outcomes for this process: 170 a. If the attribute is successfully retrieved from the remote 171 source, the GSS mechanism adds it to the local storage so it 172 will be listed by future invocations of GSS_Inquire_Name(). 173 This process is similar as if the GSS_Set_Name_Attribute() 174 would have been called with the retrieved attribute data. 175 Finally, the attribute value is provided to the application 176 as if the attribute would have been located into the local 177 storage. Note that the application is unaware of this whole 178 process. 180 b. If the attribute cannot be retrieved, the GSS mechanism 181 returns the GSS_S_UNAVAILABLE error major code. The minor 182 code might provide additional information (e.g. connection 183 refused, timeout, invalid SAML attribute format...) if 184 desired. 186 5. The application makes use of the obtained attribute, or take the 187 associated countermeasures if the attribute was not provided. 189 5. Example using draft-ietf-abfab-aaa-saml, GSS-EAP and RFC7056 191 The following example follows the steps described in the previous 192 section, with actual examples using draft-ietf-abfab-aaa-saml, GSS- 193 EAP and [RFC7056]. 195 1. The application gets the list of attribute names by invoking 196 GSS_Inquire_Name(). The list returns the following attribute 197 names: 199 * urn:ietf:params:gss:radius-attribute 79 (RADIUS EAP-Message) 201 * urn:ietf:params:gss:radius-attribute 80 (RADIUS Message- 202 Authenticator attribute) 204 * urn:ietf:params:gss:radius-attribute 1 (RADIUS User-Name 205 attribute) 207 * urn:ietf:params:gss:radius-attribute 24 (RADIUS State 208 attribute) 210 * urn:ietf:params:gss:federated-saml-assertion (Complete SAML 211 assertion) 213 * urn:ietf:params:gss:federated-saml-attribute 214 urn:oasis:names:tc:SAML:2.0:attrname-format:uri 215 urn:oid:1.3.6.1.4.1.5923.1.1.1.7 (SAML eduPersonAffiliation 216 attribute) 218 These attribute names follow the format described in [RFC7056]. 220 2. The application is interested on getting the value of a standard 221 federated SAML attribute called eduPersonAffiliation. The format 222 of the attribute name following [RFC7056] is 223 "urn:ietf:params:gss:federated-saml-attribute 224 urn:oasis:names:tc:SAML:2.0:attrname-format:uri 225 urn:oid:1.3.6.1.4.1.5923.1.1.1.1". 227 3. The application requests the value of the attribute by invoking 228 GSS_Get_Name_Attribute(). 230 4. The GSS-EAP mechanism implementation processes the request, and 231 realizes the attribute is not available into its local storage. 232 Then, it generates a new SAML Attribute Query for that attribute, 233 sending it to the IdP using the ABFAB Assertion Query/Request 234 Profile described in section 8 of [I-D.ietf-abfab-aaa-saml]. As 235 a result, it obtains a SAML Response with a SAML Attribute 236 Statement for the requested attribute. Finally, the GSS-EAP 237 mechanism implementation stores the attribute into its local 238 storage, and provides the output of the GSS_Get_Name_Attribute() 239 call with the value of the attribute. 241 5. The application uses the attribute to perform authorization 242 tasks. 244 6. If the application invokes GSS_Inquire_Name() again, the result 245 would contain the following attribute names: 247 * urn:ietf:params:gss:radius-attribute 79 (RADIUS EAP-Message) 249 * urn:ietf:params:gss:radius-attribute 80 (RADIUS Message- 250 Authenticator attribute) 252 * urn:ietf:params:gss:radius-attribute 1 (RADIUS User-Name 253 attribute) 255 * urn:ietf:params:gss:radius-attribute 24 (RADIUS State 256 attribute) 258 * urn:ietf:params:gss:federated-saml-assertion (Complete SAML 259 assertion) 261 * urn:ietf:params:gss:federated-saml-attribute 262 urn:oasis:names:tc:SAML:2.0:attrname-format:uri 263 urn:oid:1.3.6.1.4.1.5923.1.1.1.7 (SAML eduPersonAffiliation 264 attribute) 266 * urn:ietf:params:gss:federated-saml-attribute 267 urn:oasis:names:tc:SAML:2.0:attrname-format:uri 268 urn:oid:1.3.6.1.4.1.5923.1.1.1.1 (SAML eduPersonEntitlement 269 attribute) 271 6. Considerations on blocking calls 273 The fact of performing network interactions within the implementation 274 of an API call may lead to blocking situations, where the GSS 275 mechanism needs to wait for a third entity to provide a result. This 276 behaviour is allowed by current specification [RFC6680], although it 277 may not be foreseen by some applications that (wrongly) assume GSS- 278 API calls will return immediately. 280 After a discussion on the Kitten WG mailing list [KITTENDIS], it was 281 concluded that it would be reasonable for an application to assume 282 that the calls to GSS_Inquire_Name() and to GSS_Get_Name_Attribute() 283 for attributes listed by the former will be faster (i.e. non- 284 blocking) than the calls to GSS_Get_Name_Attribute() for non-listed 285 attributes (i.e. require network interaction). 287 Furthermore, it would be desirable that new definitions of GSS naming 288 attributes explicitly declare whether a network interaction is 289 possible to be triggered, so applications are aware that the results 290 may take some time to be returned. 292 Finally, this document recommends GSS mechanism to implement timers 293 to prevent a call to GSS_Get_Name_Attribute() keeps blocked if the 294 external entity does not reply in a reasonable amount of time. If 295 the timer expires, GSS_Get_Name_Attribute() returns with the 296 GSS_S_UNAVAILABLE code, as if the attribute was not available at all. 297 The returned minor code might provide some information about the 298 actual cause of the error (i.e. timeout). 300 7. IANA Considerations 302 There are no IANA Considerations. 304 8. Acknowledgements 306 Authors thank JISC for their support. 308 9. References 310 9.1. Normative References 312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP 14, RFC 2119, 314 DOI 10.17487/RFC2119, March 1997, 315 . 317 [RFC6680] Williams, N., Johansson, L., Hartman, S., and S. 318 Josefsson, "Generic Security Service Application 319 Programming Interface (GSS-API) Naming Extensions", 320 RFC 6680, DOI 10.17487/RFC6680, August 2012, 321 . 323 9.2. Informative References 325 [RFC7055] Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism for 326 the Extensible Authentication Protocol", RFC 7055, 327 DOI 10.17487/RFC7055, December 2013, 328 . 330 [RFC7056] Hartman, S. and J. Howlett, "Name Attributes for the GSS- 331 API Extensible Authentication Protocol (EAP) Mechanism", 332 RFC 7056, DOI 10.17487/RFC7056, December 2013, 333 . 335 [KITTENDIS] 336 Perez-Mendez, A., "Use of GSS_Get_name_attribute() to 337 obtain further attributes. https://www.ietf.org/mail- 338 archive/web/kitten/current/msg05550.html", April 2015. 340 [I-D.ietf-abfab-arch] 341 Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. 342 Schaad, "Application Bridging for Federated Access Beyond 343 Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work 344 in progress), July 2014. 346 [I-D.ietf-abfab-aaa-saml] 347 Howlett, J., Hartman, S., and A. Perez-Mendez, "A RADIUS 348 Attribute, Binding, Profiles, Name Identifier Format, and 349 Confirmation Methods for SAML", draft-ietf-abfab-aaa- 350 saml-11 (work in progress), August 2015. 352 Authors' Addresses 354 Alejandro Perez-Mendez 355 University of Murcia 356 Campus de Espinardo S/N, Faculty of Computer Science 357 Murcia 30100 358 Spain 360 Phone: +34 868 88 46 44 361 EMail: alex@um.es 363 Rafa Marin-Lopez 364 University of Murcia 365 Campus de Espinardo S/N, Faculty of Computer Science 366 Murcia 30100 367 Spain 369 Phone: +34 868 88 85 01 370 EMail: rafa@um.es 371 Gabriel Lopez-Millan 372 University of Murcia 373 Campus de Espinardo S/N, Faculty of Computer Science 374 Murcia 30100 375 Spain 377 Phone: +34 868 88 85 04 378 EMail: gabilm@um.es