idnits 2.17.1 draft-ietf-abfab-gss-eap-naming-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 19, 2012) is 4230 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) == Unused Reference: 'I-D.ietf-kitten-gssapi-naming-exts' is defined on line 402, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-radext-radius-extensions-06 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-14) exists of draft-ietf-abfab-aaa-saml-03 == Outdated reference: A later version (-20) exists of draft-ietf-kitten-sasl-saml-ec-03 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hartman 3 Internet-Draft Painless Security 4 Intended status: Standards Track J. Howlett 5 Expires: March 23, 2013 JANET(UK) 6 September 19, 2012 8 Name Attributes for the GSS-API EAP mechanism 9 draft-ietf-abfab-gss-eap-naming-05 11 Abstract 13 The naming extensions to the Generic Security Services Application 14 Programming interface provide a mechanism for applications to 15 discover authorization and personalization information associated 16 with GSS-API names. The Extensible Authentication Protocol GSS-API 17 mechanism allows an Authentication/Authorization/Accounting peer to 18 provide authorization attributes along side an authentication 19 response. It also provides mechanisms to process Security Assertion 20 Markup Language (SAML) messages provided in the AAA response. This 21 document describes the necessary information to use the naming 22 extensions API to access that information. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 23, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 60 3. Naming Extensions and SAML . . . . . . . . . . . . . . . . . . 5 61 4. Federated Context . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Name Attributes for GSS-EAP . . . . . . . . . . . . . . . . . 8 63 6. Names of SAML Attributes in the Federated Context . . . . . . 9 64 6.1. Assertions . . . . . . . . . . . . . . . . . . . . . . . . 9 65 6.2. SAML Attributes . . . . . . . . . . . . . . . . . . . . . 9 66 6.3. SAML Name Identifiers . . . . . . . . . . . . . . . . . . 10 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 8.1. Registration of the GSS URN Namespace . . . . . . . . . . 12 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 The naming extensions [I-D.ietf-kitten-gssapi-naming-exts]to the 79 Generic Security Services Application Programming interface (GSS-API) 80 [RFC2743] provide a mechanism for applications to discover 81 authorization and personalization information associated with GSS-API 82 names. The Extensible Authentication Protocol GSS-API mechanism 83 [I-D.ietf-abfab-gss-eap] allows an Authentication/Authorization/ 84 Accounting peer to provide authorization attributes along side an 85 authentication response. It also provides mechanisms to process 86 Security Assertion Markup Language (SAML) messages provided in the 87 AAA response. Other mechanisms such as SAML EC 88 [I-D.ietf-kitten-sasl-saml-ec] also support SAML assertions and 89 attributes carried in the GSS-API. This document describes the 90 necessary information to use the naming extensions API to access SAML 91 assertions in the federated context and AAA attributes. 93 The semantics of setting attributes defined in this specification are 94 undefined and left to future work. 96 2. Requirements notation 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. Naming Extensions and SAML 104 SAML assertions can carry attributes describing properties of the 105 subject of the assertion. For example, an assertion might carry an 106 attribute describing the organizational affiliation or e-mail address 107 of a subject. According to Section 8.2 and 2.7.3.1 of 108 [OASIS.saml-core-2.0-os], the name of an attribute has two parts. 109 The first is a URI describing the format of the name. The second 110 part, whose form depends on the format URI, is the actual name. GSS- 111 API name attributes may take a form starting with a URI describing 112 the form of the name; the rest of the name is specified by that URI. 114 SAML attributes carried in GSS-API names are named with three parts. 115 The first is a URN indicating that the name is a SAML attribute and 116 describing the context (Section 4). This URN is followed by a space, 117 the URI indicating the format of the SAML name, a space and the SAML 118 attribute name. The URI indicating the format of the SAML attribute 119 name is not optional and MUST be present. 121 SAML attribute names may not be globally unique. Many names that are 122 named by URNs or URIs are likely to have semantics independent of the 123 issuer. However other name formats, including unspecified name 124 formats, make it easy for two issuers to choose the same name for 125 attributes with different semantics. Attributes using the federated 126 context Section 4 are issued by the same party performing the 127 authentication. So, based on who is the subject of the name, the 128 semantics of the attribute can be determined. 130 4. Federated Context 132 GSS-API naming extensions have the concept of an authenticated name 133 attribute. The mechanism guarantees that the contents of an 134 authenticated name attribute are an authenticated statement from the 135 trusted source of the peer credential. The fact that an attribute is 136 authenticated does not imply that the trusted source of the peer 137 credential is authorized to assert the attribute. 139 In the federated context, the trusted source of the peer credential 140 is typically some identity provider. In the GSS EAP mechanism, 141 information is combined from AAA and SAML sources. The SAML IDP and 142 home AAA server are assumed to be in the same trust domain. However, 143 this trust domain is not typically the same as the trust domain of 144 the service. With other SAML mechanisms using this specification, 145 the SAML assertion also comes from the party performing 146 authentication. Typically, the IDP is run by another organization in 147 the same federation. The IDP is trusted to make some statements, 148 particularly related to the context of a federation. For example, an 149 academic federation's participants would typically trust an IDP's 150 assertions about whether someone was a student or a professor. 151 However that same IDP would not typically be trusted to make 152 assertions about local entitlements such as group membership. Thus, 153 a service MUST make a policy decision about whether the IDP is 154 permitted to assert a particular attribute and about whether the 155 asserted value is acceptable. This policy can be implemented as 156 local configuration on the service, as rules in AAA proxies, or 157 through other deployment-specific mechanisms. 159 In contrast, attributes in an enterprise context are often verified 160 by a central authentication infrastructure that is trusted to assert 161 most or all attributes. For example, in a Kerberos infrastructure, 162 the KDC typically indicates group membership information for clients 163 to a server using KDC-authenticated authorization data. 165 The context of an attribute is an important property of that 166 attribute; trust context is an important part of this overall 167 context. In order for applications to distinguish the context of 168 attributes, attributes with different context need different names. 169 This specification defines attribute names for SAML and AAA 170 attributes in the federated context. 172 These names MUST NOT be used for attributes issued by a party other 173 than one closely associated with the source of credentials unless the 174 source of credentials is re-asserting the attributes. For example, a 175 source of credentials can consult whatever sources of attributes it 176 chooses, but acceptors can assume attributes in the federated context 177 are from the source of credentials. This requirement is typically 178 enforced in mechanism specifications. For example 179 [I-D.ietf-abfab-aaa-saml] provides enough information thatwe know the 180 attributes it carries today are in the federated context. Similarly, 181 we know that the requirements of this paragraph are met by SAML 182 mechanisms where the assertion is the means of authentication. 184 5. Name Attributes for GSS-EAP 186 This section describes how RADIUS attributes received in an access- 187 accept message by the GSS-EAP [I-D.ietf-abfab-gss-eap] mechanism are 188 named. The use of attributes defined in this section for other 189 RADIUS messages or prior to the access-accept message is undefined at 190 this time. Future specifations can explore these areas giving 191 adequate weight to backward compatibility. In particular, this 192 specification defines the meaning of these attributes for the 193 src_name output of GSS_Accept_sec_context after that function returns 194 GSS_S_COMPLETE. Attributes MAy be absent or values MAY change in 195 other circumstances; future specifications MAY define this behavior. 197 The first portion of the name is urn:ietf:params:gss:radius-attribute 198 (a URN indicating that this is a GSS-EAP RADIUS AVP). This is 199 followed by a space and a numeric RADIUS name as described by section 200 2.6 of [I-D.ietf-radext-radius-extensions]. For example the name of 201 the User-Name attribute is "urn:ietf:params:gss:radius-attribute 1". 202 The name of extended type 1 within type 241 would be 203 "urn:ietf:params:gss:radius-attribute 241.1". 205 Consider a case where the RADIUS access-accept response includes the 206 RADIUS username attribute. An application wishing to retrieve the 207 value of this attribute would first wait until GSS- 208 _Accept_sec_Context returned GSS_S_COMPLETE. Then the application 209 would take the src_name output from GSS_Accept_Sec_context and call 210 GSS_Get_Name_attribute passing this name and an attribute of 211 "urn:ietf:params:gss:radius-attribute 1" as inputs. After confirming 212 that the authenticated boolean output is true, the application can 213 find the username in the values output. 215 The value of RADIUS attributes is the raw octets of the packet. 216 Integers are in network byte order. The display value SHOULD be a 217 human readable string; an implementation can only produce this string 218 if it knows the type of a given RADIUS attribute. If multiple 219 attributes are present with a given name in the RADIUS message, then 220 a multi-valued GSS-API attribute SHOULD be returned. As an 221 exception, implementations SHOULD concatenate RADIUS attributes such 222 as EAP-Message or large attributes defined in 223 [I-D.ietf-radext-radius-extensions] that use multiple attributes to 224 carry more than 253 octets of information. 226 6. Names of SAML Attributes in the Federated Context 228 6.1. Assertions 230 An assertion generated by the credential source is named by 231 "urn:ietf:params:gss:federated-saml-assertion". The value of this 232 attribute is the assertion carried in the AAA protocol or used for 233 authentication in a SAML mechanism. This attribute is absent from a 234 given acceptor name if no such assertion is present or if the 235 assertion fails local policy checks. 237 This attribute is returned with the authenticatedoutput of 238 GSS_Get_name_attribute true only when the mechanism can successfully 239 authenticated the SAML statement. For the GSS-EAP mechanism this is 240 true if the AAA exchange has successfully authenticated. However, 241 uses of the GSS-API MUST confirm that the attribute is marked 242 authenticated as other mechanisms MAY permit an initiator to provide 243 an unauthenticated SAML statement. 245 Mechanisms MAY perform additional local policy checks and MAY remove 246 the attribute corresponding to assertions that fail these checks. 248 6.2. SAML Attributes 250 Each attribute carried in the assertion SHOULD also be a GSS name 251 attribute. The name of this attribute has three parts, all separated 252 by an ASCII space character. The first part is 253 urn:ietf:params:gss:federated-saml-attribute. The second part is the 254 URI for the element's NameFormat XML attribute. The 255 final part is the element's Name XML attribute. The 256 SAML attribute name may itself contain spaces. As required by the 257 URI specification, spaces within a URI are encoded as "%20". Spaces 258 within a URI, including either the first or second part of the name, 259 encoding as "%20" do not separate parts of the GSS-API attribute 260 name; they are simply part of the URI. 262 As an example, if the eduPersonEntitlement attribute is present in an 263 assertion, then An attribute with the name 264 "urn:ietf:params:gss:federated-saml-attribute 265 urn:oasis:names:tc:SAML:2.0:attrname-format:uri 266 urn:oid:1.3.6.1.4.1.5923.1.1.1.7 " could be returned from 267 GSS_Inquire_Name. If an application calls GSS_Get_Name_attribute 268 with this attribute in the attr parameter then the values output 269 would include one or more URIs of entitlements that were associated 270 with the authenticated user. 272 If the content of each element is a simple text 273 node (or nodes), then the raw and "display" values of the GSS name 274 attribute MUST be the text content of the element(s). The raw value 275 MUST be encoded as UTF-8. 277 If the value is not simple or is empty, then the raw value(s) of the 278 GSS name attribute MUST be the well-formed serialization of the 279 element(s) encoded as UTF-8. The "display" 280 values are implementation-defined. 282 These attributes SHOULD be marked authenticated if they are contained 283 in SAML assertions that have been successfully validated back to the 284 trusted source of the peer credential. In the GSS-EAP mechanism, a 285 SAML assertion carried in an integrity-protected and authenticated 286 AAA protocol SHALL be successfully validated; attributes from that 287 assertion SHALL be returned from GSS_Get_Name_attribute with the 288 authenticated output set to true. An implementation MAY apply local 289 policy checks to each attribute in this assertion and discard the 290 attribute if it is unacceptable according to these checks. 292 6.3. SAML Name Identifiers 294 The carried in the subject of the assertion SHOULD also 295 be a GSS name attribute. The name of this attribute has two parts, 296 separated by an ASCII space character. The first part is 297 urn:ietf:params:gss:federated-saml-nameid. The second part is the 298 URI for the element's Format XML attribute. 300 The raw value of the GSS name attribute MUST be the well-formed 301 serialization of the element encoded as UTF-8. The 302 "display" value is implementation-defined. For formats defined by 303 section 8.3 of [OASIS.saml-core-2.0-os], missing values of the 304 NameQualifier or SPNameQualifier XML attributes MUST be populated in 305 accordance with the definition of the format prior to serialization. 306 In other words, the defaulting rules specified for the "persistent" 307 and "transient" formats MUST be applied prior to serialization. 309 This attribute SHOULD be marked authenticated if the name identifier 310 is contained in a SAML assertion that has been successfully validated 311 back to the trusted source of the peer credential. In the GSS-EAP 312 mechanism, a SAML assertion carried in an integrity-protected and 313 authenticated AAA protocol SHALL be sufficiently validated. An 314 implementation MAY apply local policy checks to this assertion and 315 discard it if it is unacceptable according to these checks. 317 7. Security Considerations 319 This document describes how to access RADIUS attributes, SAML 320 attributes and SAML assertions from some GSS-API mechanisms. These 321 attributes are typically used for one of two purposes. The least 322 sensitive is personalization: a central service MAY provide 323 information about an authenticated user so they need not enter it 324 with each acceptor they access. A more sensitive use is 325 authorization. 327 The mechanism is responsible for authentication and integrity 328 protection of the attributes. However, the acceptor application is 329 responsible for making a decision about whether the credential source 330 is trusted to assert the attribute and validating the asserted value. 332 mechanisms are permitted to perform local policy checks on SAML 333 assertions, attributes and name identifiers exposed through name 334 attributes defined in this document. If there is another way to get 335 access to the SAML assertion, for example the mechanism described in 336 [I-D.ietf-abfab-aaa-saml], then an application MAY get different 337 results depending on how the SAML is accessed. This is intended 338 behavior; applications who choose to bypass local policy checks 339 SHOULD perform their own evaluation before relying on information. 341 8. IANA Considerations 343 A new top-level registry is created titled "Generic Security Service 344 Application Program Interface Parameters". 346 In this top-level registry, a sub-registry titled "GSS-API URN 347 Parameters" is created. Registration in this registry is by the IETF 348 review or expert review procedures [RFC5226]. Registrations in this 349 registry are generally only expected as part of protocols published 350 as RFCs on the IETF stream; other URIs are expected to be better 351 choices for non-IETf work. Expert review is permitted mainly to 352 permit early registration related to specifications under development 353 when the community believes they have reach sufficient maturity. 355 If the "paramname" parameter is registered in this registry then its 356 URN will be "urn:ietf:params:gss:paramname". The initial 357 registrations are as follows: 359 +--------------------------+-------------+ 360 | Parameter | Reference | 361 +--------------------------+-------------+ 362 | radius-attribute | Section 5 | 363 | | | 364 | federated-saml-assertion | Section 6.1 | 365 | | | 366 | federated-saml-attribute | Section 6.2 | 367 | | | 368 | federated-saml-nameid | Section 6.3 | 369 +--------------------------+-------------+ 371 8.1. Registration of the GSS URN Namespace 373 IANA is requested to register the "gss" URN sub-namespace in the IETF 374 URN sub-namespace for protocol parameters defined in [RFC3553]. 376 Registry Name: gss 378 Specification: draft-ietf-abfab-gss-eap-naming 380 Repository: GSS-API URN Parameters (Section 8) 382 Index Value: Sub-parameters MUST be specified in UTF-8 using standard 383 URI encoding where necessary. 385 9. Acknowledgements 387 Scott Cantor contributed significant text and multiple reviews of 388 this document. 390 Sam hartman's work on this specification has been funded by Janet. 392 10. References 394 10.1. Normative References 396 [I-D.ietf-abfab-gss-eap] 397 Hartman, S. and J. Howlett, "A GSS-API Mechanism for the 398 Extensible Authentication Protocol", 399 draft-ietf-abfab-gss-eap-09 (work in progress), 400 August 2012. 402 [I-D.ietf-kitten-gssapi-naming-exts] 403 Williams, N., Johansson, L., Hartman, S., and S. 404 Josefsson, "GSS-API Naming Extensions", 405 draft-ietf-kitten-gssapi-naming-exts-15 (work in 406 progress), May 2012. 408 [I-D.ietf-radext-radius-extensions] 409 DeKok, A. and A. Lior, "Remote Authentication Dial In User 410 Service (RADIUS) Protocol Extensions", 411 draft-ietf-radext-radius-extensions-06 (work in progress), 412 June 2012. 414 [OASIS.saml-core-2.0-os] 415 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 416 "Assertions and Protocol for the OASIS Security Assertion 417 Markup Language (SAML) V2.0", OASIS Standard saml-core- 418 2.0-os, March 2005. 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, March 1997. 423 [RFC2743] Linn, J., "Generic Security Service Application Program 424 Interface Version 2, Update 1", RFC 2743, January 2000. 426 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 427 IETF URN Sub-namespace for Registered Protocol 428 Parameters", BCP 73, RFC 3553, June 2003. 430 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 431 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 432 May 2008. 434 10.2. Informative References 436 [I-D.ietf-abfab-aaa-saml] 437 Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding 438 and Profiles for SAML", draft-ietf-abfab-aaa-saml-03 (work 439 in progress), March 2012. 441 [I-D.ietf-kitten-sasl-saml-ec] 442 Cantor, S. and S. Josefsson, "SAML Enhanced Client SASL 443 and GSS-API Mechanisms", draft-ietf-kitten-sasl-saml-ec-03 444 (work in progress), September 2012. 446 Authors' Addresses 448 Sam Hartman 449 Painless Security 451 Email: hartmans-ietf@mit.edu 453 Josh Howlett 454 JANET(UK) 456 Email: josh.howlett@ja.net