idnits 2.17.1 draft-ietf-abfab-gss-eap-naming-07.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 (November 14, 2012) is 4174 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: 'XMLNS' is defined on line 445, 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLNS' == Outdated reference: A later version (-14) exists of draft-ietf-abfab-aaa-saml-04 == Outdated reference: A later version (-20) exists of draft-ietf-kitten-sasl-saml-ec-04 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). 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: May 18, 2013 JANET(UK) 6 November 14, 2012 8 Name Attributes for the GSS-API EAP mechanism 9 draft-ietf-abfab-gss-eap-naming-07 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 May 18, 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 . . . . . . . . . . . . . . . . . . . . . . . 14 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 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 (AAA) peer to provide authorization attributes along side 85 an 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 Universal Resource Identifier (URI) describing the 110 format of the name. The second part, whose form depends on the 111 format URI, is the actual name. GSS-API name attributes may take a 112 form starting with a URI describing the form of the name; the rest of 113 the name is specified by that URI. 115 SAML attributes carried in GSS-API names are named with three parts. 116 The first is a Universal Resource Name (URN) indicating that the name 117 is a SAML attribute and describing the context (Section 4). This URN 118 is followed by a space, the URI indicating the format of the SAML 119 name, a space and the SAML attribute name. The URI indicating the 120 format of the SAML attribute name is not optional and MUST be 121 present. 123 SAML attribute names may not be globally unique. Many names that are 124 named by URNs or URIs are likely to have semantics independent of the 125 issuer. However other name formats, including unspecified name 126 formats, make it easy for two issuers to choose the same name for 127 attributes with different semantics. Attributes using the federated 128 context Section 4 are issued by the same party performing the 129 authentication. So, based on who is the subject of the name, the 130 semantics of the attribute can be determined. 132 4. Federated Context 134 GSS-API naming extensions have the concept of an authenticated name 135 attribute. The mechanism guarantees that the contents of an 136 authenticated name attribute are an authenticated statement from the 137 trusted source of the peer credential. The fact that an attribute is 138 authenticated does not imply that the trusted source of the peer 139 credential is authorized to assert the attribute. 141 In the federated context, the trusted source of the peer credential 142 is typically some identity provider. In the GSS EAP mechanism, 143 information is combined from AAA and SAML sources. The SAML IDP and 144 home AAA server are assumed to be in the same trust domain. However, 145 this trust domain is not typically the same as the trust domain of 146 the service. With other SAML mechanisms using this specification, 147 the SAML assertion also comes from the party performing 148 authentication. Typically, the IDP is run by another organization in 149 the same federation. The IDP is trusted to make some statements, 150 particularly related to the context of a federation. For example, an 151 academic federation's participants would typically trust an IDP's 152 assertions about whether someone was a student or a professor. 153 However that same IDP would not typically be trusted to make 154 assertions about local entitlements such as group membership. Thus, 155 a service MUST make a policy decision about whether the IDP is 156 permitted to assert a particular attribute and about whether the 157 asserted value is acceptable. This policy can be implemented as 158 local configuration on the service, as rules in AAA proxies, or 159 through other deployment-specific mechanisms. 161 In contrast, attributes in an enterprise context are often verified 162 by a central authentication infrastructure that is trusted to assert 163 most or all attributes. For example, in a Kerberos infrastructure, 164 the KDC typically indicates group membership information for clients 165 to a server using KDC-authenticated authorization data. 167 The context of an attribute is an important property of that 168 attribute; trust context is an important part of this overall 169 context. In order for applications to distinguish the context of 170 attributes, attributes with different context need different names. 171 This specification defines attribute names for SAML and AAA 172 attributes in the federated context. 174 These names MUST NOT be used for attributes issued by a party other 175 than one closely associated with the source of credentials unless the 176 source of credentials is re-asserting the attributes. For example, a 177 source of credentials can consult whatever sources of attributes it 178 chooses, but acceptors can assume attributes in the federated context 179 are from the source of credentials. This requirement is typically 180 enforced in mechanism specifications. For example 181 [I-D.ietf-abfab-aaa-saml] provides enough information thatwe know the 182 attributes it carries today are in the federated context. Similarly, 183 we know that the requirements of this paragraph are met by SAML 184 mechanisms where the assertion is the means of authentication. 186 5. Name Attributes for GSS-EAP 188 This section describes how RADIUS attributes received in an access- 189 accept message by the GSS-EAP [I-D.ietf-abfab-gss-eap] mechanism are 190 named. The use of attributes defined in this section for other 191 RADIUS messages or prior to the access-accept message is undefined at 192 this time. Future specifations can explore these areas giving 193 adequate weight to backward compatibility. In particular, this 194 specification defines the meaning of these attributes for the 195 src_name output of GSS_Accept_sec_context after that function returns 196 GSS_S_COMPLETE. Attributes MAY be absent or values MAY change in 197 other circumstances; future specifications MAY define this behavior. 199 The first portion of the name is urn:ietf:params:gss:radius-attribute 200 (a URN indicating that this is a GSS-EAP RADIUS AVP). This is 201 followed by a space and a numeric RADIUS name as described by section 202 2.6 of [I-D.ietf-radext-radius-extensions]. For example the name of 203 the User-Name attribute is "urn:ietf:params:gss:radius-attribute 1". 204 The name of extended type 1 within type 241 would be 205 "urn:ietf:params:gss:radius-attribute 241.1". 207 Consider a case where the RADIUS access-accept response includes the 208 RADIUS username attribute. An application wishing to retrieve the 209 value of this attribute would first wait until GSS- 210 _Accept_sec_Context returned GSS_S_COMPLETE. Then the application 211 would take the src_name output from GSS_Accept_sec_context and call 212 GSS_Get_name_attribute passing this name and an attribute of 213 "urn:ietf:params:gss:radius-attribute 1" as inputs. After confirming 214 that the authenticated boolean output is true, the application can 215 find the username in the values output. 217 The value of RADIUS attributes is the raw octets of the packet. 218 Integers are in network byte order. The display value SHOULD be a 219 human readable string; an implementation can only produce this string 220 if it knows the type of a given RADIUS attribute. If multiple 221 attributes are present with a given name in the RADIUS message, then 222 a multi-valued GSS-API attribute SHOULD be returned. As an 223 exception, implementations SHOULD concatenate RADIUS attributes such 224 as EAP-Message or large attributes defined in 225 [I-D.ietf-radext-radius-extensions] that use multiple attributes to 226 carry more than 253 octets of information. 228 6. Names of SAML Attributes in the Federated Context 230 6.1. Assertions 232 An assertion generated by the credential source is named by 233 "urn:ietf:params:gss:federated-saml-assertion". The value of this 234 attribute is the assertion carried in the AAA protocol or used for 235 authentication in a SAML mechanism. This attribute is absent from a 236 given acceptor name if no such assertion is present or if the 237 assertion fails local policy checks. 239 When GSS_Get_name_attribute is called, This attribute will be 240 returned with the authenticated output set to true only if the 241 mechanism can successfully authenticate the SAML statement. For the 242 GSS-EAP mechanism this is true if the AAA exchange has successfully 243 authenticated. However, uses of the GSS-API MUST confirm that the 244 attribute is marked authenticated as other mechanisms MAY permit an 245 initiator to provide an unauthenticated SAML statement. 247 Mechanisms MAY perform additional local policy checks and MAY remove 248 the attribute corresponding to assertions that fail these checks. 250 6.2. SAML Attributes 252 Each attribute carried in the assertion SHOULD also be a GSS name 253 attribute. The name of this attribute has three parts, all separated 254 by an ASCII space character. The first part is 255 urn:ietf:params:gss:federated-saml-attribute. The second part is the 256 URI for the element's NameFormat XML attribute. The 257 final part is the element's Name XML attribute. The 258 SAML attribute name may itself contain spaces. As required by the 259 URI specification, spaces within a URI are encoded as "%20". Spaces 260 within a URI, including either the first or second part of the name, 261 encoded as "%20" do not separate parts of the GSS-API attribute name; 262 they are simply part of the URI. 264 As an example, if the eduPersonEntitlement attribute is present in an 265 assertion, then an attribute with the name 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.7" could be returned from 269 GSS_Inquire_Name. If an application calls GSS_Get_name_attribute 270 with this attribute in the attr parameter then the values output 271 would include one or more URIs of entitlements that were associated 272 with the authenticated user. 274 If the content of each element is a simple text 275 node (or nodes), then the raw and "display" values of the GSS name 276 attribute MUST be the text content of the element(s). The raw value 277 MUST be encoded as UTF-8. 279 If the value is not simple or is empty, then the raw value(s) of the 280 GSS name attribute MUST be a namespace well-formed serialization 281 [XMLNS]of the element(s) encoded as UTF-8. The 282 "display" values are implementation-defined. 284 These attributes SHOULD be marked authenticated if they are contained 285 in SAML assertions that have been successfully validated back to the 286 trusted source of the peer credential. In the GSS-EAP mechanism, a 287 SAML assertion carried in an integrity-protected and authenticated 288 AAA protocol SHALL be successfully validated; attributes from that 289 assertion SHALL be returned from GSS_Get_name_attribute with the 290 authenticated output set to true. An implementation MAY apply local 291 policy checks to each attribute in this assertion and discard the 292 attribute if it is unacceptable according to these checks. 294 6.3. SAML Name Identifiers 296 The carried in the subject of the assertion SHOULD also 297 be a GSS name attribute. The name of this attribute has two parts, 298 separated by an ASCII space character. The first part is 299 urn:ietf:params:gss:federated-saml-nameid. The second part is the 300 URI for the element's Format XML attribute. 302 The raw value of the GSS name attribute MUST be the well-formed 303 serialization of the element encoded as UTF-8. The 304 "display" value is implementation-defined. For formats defined by 305 section 8.3 of [OASIS.saml-core-2.0-os], missing values of the 306 NameQualifier or SPNameQualifier XML attributes MUST be populated in 307 accordance with the definition of the format prior to serialization. 308 In other words, the defaulting rules specified for the "persistent" 309 and "transient" formats MUST be applied prior to serialization. 311 This attribute SHOULD be marked authenticated if the name identifier 312 is contained in a SAML assertion that has been successfully validated 313 back to the trusted source of the peer credential. In the GSS-EAP 314 mechanism, a SAML assertion carried in an integrity-protected and 315 authenticated AAA protocol SHALL be sufficiently validated. An 316 implementation MAY apply local policy checks to this assertion and 317 discard it if it is unacceptable according to these checks. 319 7. Security Considerations 321 This document describes how to access RADIUS attributes, SAML 322 attributes and SAML assertions from some GSS-API mechanisms. These 323 attributes are typically used for one of two purposes. The least 324 sensitive is personalization: a central service MAY provide 325 information about an authenticated user so they need not enter it 326 with each acceptor they access. A more sensitive use is 327 authorization. 329 The mechanism is responsible for authentication and integrity 330 protection of the attributes. However, the acceptor application is 331 responsible for making a decision about whether the credential source 332 is trusted to assert the attribute and validating the asserted value. 334 Mechanisms are permitted to perform local policy checks on SAML 335 assertions, attributes and name identifiers exposed through name 336 attributes defined in this document. If there is another way to get 337 access to the SAML assertion, for example the mechanism described in 338 [I-D.ietf-abfab-aaa-saml], then an application MAY get different 339 results depending on how the SAML is accessed. This is intended 340 behavior; applications who choose to bypass local policy checks 341 SHOULD perform their own evaluation before relying on information. 343 8. IANA Considerations 345 A new top-level registry is created titled "Generic Security Service 346 Application Program Interface Parameters". 348 In this top-level registry, a sub-registry titled "GSS-API URN 349 Parameters" is created. Registration in this registry is by the IETF 350 review or expert review procedures [RFC5226]. 352 This paragraph gives guidance to designated experts. Registrations 353 in this registry are generally only expected as part of protocols 354 published as RFCs on the IETF stream; other URIs are expected to be 355 better choices for non-IETf work. Expert review is permitted mainly 356 to permit early registration related to specifications under 357 development when the community believes they have reach sufficient 358 maturity. The expert SHOULD evaluate the maturity and stability of 359 such an IETF-stream specification. Experts SHOULD review anything 360 not from the IETF stream for consistency and consensus with current 361 practice. Today such requests would not typically be approved. 363 If the "paramname" parameter is registered in this registry then its 364 URN will be "urn:ietf:params:gss:paramname". The initial 365 registrations are as follows: 367 +--------------------------+-------------+ 368 | Parameter | Reference | 369 +--------------------------+-------------+ 370 | radius-attribute | Section 5 | 371 | | | 372 | federated-saml-assertion | Section 6.1 | 373 | | | 374 | federated-saml-attribute | Section 6.2 | 375 | | | 376 | federated-saml-nameid | Section 6.3 | 377 +--------------------------+-------------+ 379 8.1. Registration of the GSS URN Namespace 381 IANA is requested to register the "gss" URN sub-namespace in the IETF 382 URN sub-namespace for protocol parameters defined in [RFC3553]. 384 Registry Name: gss 386 Specification: draft-ietf-abfab-gss-eap-naming 388 Repository: GSS-API URN Parameters (Section 8) 390 Index Value: Sub-parameters MUST be specified in UTF-8 using standard 391 URI encoding where necessary. 393 9. Acknowledgements 395 Scott Cantor contributed significant text and multiple reviews of 396 this document. 398 The authors would like to thank Stephen Farrell, Luke Howard, and Jim 399 Schaad 401 Sam hartman's work on this specification has been funded by Janet. 403 10. References 405 10.1. Normative References 407 [I-D.ietf-abfab-gss-eap] 408 Hartman, S. and J. Howlett, "A GSS-API Mechanism for the 409 Extensible Authentication Protocol", 410 draft-ietf-abfab-gss-eap-09 (work in progress), 411 August 2012. 413 [I-D.ietf-kitten-gssapi-naming-exts] 414 Williams, N., Johansson, L., Hartman, S., and S. 415 Josefsson, "GSS-API Naming Extensions", 416 draft-ietf-kitten-gssapi-naming-exts-15 (work in 417 progress), May 2012. 419 [I-D.ietf-radext-radius-extensions] 420 DeKok, A. and A. Lior, "Remote Authentication Dial In User 421 Service (RADIUS) Protocol Extensions", 422 draft-ietf-radext-radius-extensions-06 (work in progress), 423 June 2012. 425 [OASIS.saml-core-2.0-os] 426 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 427 "Assertions and Protocol for the OASIS Security Assertion 428 Markup Language (SAML) V2.0", OASIS Standard saml-core- 429 2.0-os, March 2005. 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, March 1997. 434 [RFC2743] Linn, J., "Generic Security Service Application Program 435 Interface Version 2, Update 1", RFC 2743, January 2000. 437 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 438 IETF URN Sub-namespace for Registered Protocol 439 Parameters", BCP 73, RFC 3553, June 2003. 441 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 442 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 443 May 2008. 445 [XMLNS] W3C, "XML Namespaces Conformance", 2009, . 448 10.2. Informative References 450 [I-D.ietf-abfab-aaa-saml] 451 Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding 452 and Profiles for SAML", draft-ietf-abfab-aaa-saml-04 (work 453 in progress), October 2012. 455 [I-D.ietf-kitten-sasl-saml-ec] 456 Cantor, S. and S. Josefsson, "SAML Enhanced Client SASL 457 and GSS-API Mechanisms", draft-ietf-kitten-sasl-saml-ec-04 458 (work in progress), October 2012. 460 Authors' Addresses 462 Sam Hartman 463 Painless Security 465 Email: hartmans-ietf@mit.edu 467 Josh Howlett 468 JANET(UK) 470 Email: josh.howlett@ja.net