idnits 2.17.1 draft-ietf-abfab-gss-eap-naming-04.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 (August 14, 2012) is 4273 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 363, 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-02 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: February 15, 2013 JANET(UK) 6 August 14, 2012 8 Name Attributes for the GSS-API EAP mechanism 9 draft-ietf-abfab-gss-eap-naming-04 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 February 15, 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 . . . . . . . . . . . . . . . . . 7 63 6. Names of SAML Attributes in the Federated Context . . . . . . 8 64 6.1. Assertions . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6.2. SAML Attributes . . . . . . . . . . . . . . . . . . . . . 8 66 6.3. SAML Name Identifiers . . . . . . . . . . . . . . . . . . 8 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 8.1. Registration of the GSS URN Namespace . . . . . . . . . . 11 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 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. 157 In contrast, attributes in an enterprise context are often verified 158 by a central authentication infrastructure that is trusted to assert 159 most or all attributes. For example, in a Kerberos infrastructure, 160 the KDC typically indicates group membership information for clients 161 to a server using KDC-authenticated authorization data. 163 The context of an attribute is an important property of that 164 attribute; trust context is an important part of this overall 165 context. In order for applications to distinguish the context of 166 attributes, attributes with different context need different names. 167 This specification defines attribute names for SAML and AAA 168 attributes in the federated context. 170 These names MUST NOT be used for attributes issued by a party other 171 than one closely associated with the source of credentials unless the 172 source of credentials is re-asserting the attributes. For example, a 173 source of credentials can consult whatever sources of attributes it 174 chooses, but acceptors can assume attributes in the federated context 175 are from the source of credentials. 177 5. Name Attributes for GSS-EAP 179 This section describes how RADIUS attributes received in an access- 180 accept message by the GSS-EAP [I-D.ietf-abfab-gss-eap] mechanism are 181 named. The use of attributes defined in this section for other 182 RADIUS messages or prior to the access-accept message is undefined at 183 this time. Future specifations can explore these areas giving 184 adequate weight to backward compatibility. 186 The first portion of the name is urn:ietf:params:gss:radius-attribute 187 (a URN indicating that this is a GSS-EAP RADIUS AVP). This is 188 followed by a space and a numeric RADIUS name as described by section 189 2.6 of [I-D.ietf-radext-radius-extensions]. For example the name of 190 the User-Name attribute is "urn:ietf:gss:radius-attribute 1". The 191 name of extended type 1 within type 241 would be 192 "urn:ietf:gss:radius-attribute 241.1". 194 The value of RADIUS attributes is the raw octets of the packet. 195 Integers are in network byte order. The display value SHOULD be a 196 human readable string; an implementation can only produce this string 197 if it knows the type of a given RADIUS attribute. If multiple 198 attributes are present with a given name in the RADIUS message, then 199 a multi-valued GSS-API attribute SHOULD be returned. As an 200 exception, implementations SHOULD concatenate RADIUS attributes such 201 as EAP-Message or large attributes defined in 202 [I-D.ietf-radext-radius-extensions] that use multiple attributes to 203 carry more than 253 octets of information. 205 6. Names of SAML Attributes in the Federated Context 207 6.1. Assertions 209 An assertion generated by the credential source is named by 210 "urn:ietf:params:gss:federated-saml-assertion". The value of this 211 attribute is the assertion carried in the AAA protocol or used for 212 authentication in a SAML mechanism. This attribute is absent from a 213 given acceptor name if no such assertion is present or if the 214 assertion fails local policy checks. This attribute is always 215 authenticated when present in mechanism names for mechanisms 216 complying with this specification: authentication only succeeds if 217 the SAML or AAA exchange is successfully authenticated. However, 218 users of the GSS-API MUST confirm that the attribute is authenticated 219 because some other mechanisms MAY permit an initiator to assert an 220 unauthenticated version of this attribute. 222 6.2. SAML Attributes 224 Each attribute carried in the assertion SHOULD also be a GSS name 225 attribute. The name of this attribute has three parts, all separated 226 by an ASCII space character. The first part is 227 urn:ietf:params:gss:federated-saml-attribute. The second part is the 228 URI for the element's NameFormat XML attribute. The 229 final part is the element's Name XML attribute. 231 If the content of each element is a simple text 232 node (or nodes), then the raw and "display" values of the GSS name 233 attribute MUST be the text content of the element(s). The raw value 234 MUST be encoded as UTF-8. 236 If the value is not simple or is empty, then the raw value(s) of the 237 GSS name attribute MUST be the well-formed serialization of the 238 element(s) encoded as UTF-8. The "display" 239 values are implementation-defined. 241 These attributes SHOULD be marked authenticated if they are contained 242 in SAML assertions that have been successfully validated back to the 243 trusted source of the peer credential. In the GSS-EAP mechanism, a 244 SAML assertion carried in an integrity-protected and authenticated 245 AAA protocol SHALL be sufficiently validated. An implementation MAY 246 apply local policy checks to this assertion and discard it if it is 247 unacceptable according to these checks. 249 6.3. SAML Name Identifiers 251 The carried in the subject of the assertion SHOULD also 252 be a GSS name attribute. The name of this attribute has two parts, 253 separated by an ASCII space character. The first part is 254 urn:ietf:params:gss:federated-saml-nameid. The second part is the 255 URI for the element's Format XML attribute. 257 The raw value of the GSS name attribute MUST be the well-formed 258 serialization of the element encoded as UTF-8. The 259 "display" value is implementation-defined. For formats defined by 260 section 8.3 of [OASIS.saml-core-2.0-os], missing values of the 261 NameQualifier or SPNameQualifier XML attributes MUST be populated in 262 accordance with the definition of the format prior to serialization. 263 In other words, the defaulting rules specified for the "persistent" 264 and "transient" formats MUST be applied prior to serialization. 266 This attribute SHOULD be marked authenticated if the name identifier 267 is contained in a SAML assertion that has been successfully validated 268 back to the trusted source of the peer credential. In the GSS-EAP 269 mechanism, a SAML assertion carried in an integrity-protected and 270 authenticated AAA protocol SHALL be sufficiently validated. An 271 implementation MAY apply local policy checks to this assertion and 272 discard it if it is unacceptable according to these checks. 274 7. Security Considerations 276 This document describes how to access RADIUS attributes, SAML 277 attributes and SAML assertions from some GSS-API mechanisms. These 278 attributes are typically used for one of two purposes. The least 279 sensitive is personalization: a central service MAY provide 280 information about an authenticated user so they need not enter it 281 with each acceptor they access. A more sensitive use is 282 authorization. 284 The mechanism is responsible for authentication and integrity 285 protection of the attributes. However, the acceptor application is 286 responsible for making a decision about whether the credential source 287 is trusted to assert the attribute and validating the asserted value. 289 mechanisms are permitted to perform local policy checks on SAML 290 assertions, attributes and name identifiers exposed through name 291 attributes defined in this document. If there is another way to get 292 access to the SAML assertion, for example the mechanism described in 293 [I-D.ietf-abfab-aaa-saml], then an application MAY get different 294 results depending on how the SAML is accessed. This is intended 295 behavior; applications who choose to bypass local policy checks 296 SHOULD perform their own evaluation before relying on information. 298 8. IANA Considerations 300 A new top-level registry is created titled "Generic Security Service 301 Application Program Interface Parameters". There doesn't seem to be 302 an existing top-level registry that can be used. There are 303 Parameters for the Kerberos V mechanism; parameters for the GSS-API 304 EAP mechanism; and GSS-API/SASL/Kerberos service names. However none 305 of these are the right place. 307 In this top-level registry, a sub-registry titled "GSS-API URN 308 Parameters" is created. Registration in this registry is by the IETF 309 review or expert review procedures [RFC5226]. Registrations in this 310 registry are generally only expected as part of protocols published 311 as RFCs on the IETF stream; other URIs are expected to be better 312 choices for non-IETf work. Expert review is permitted mainly to 313 permit early registration related to specifications under development 314 when the community believes they have reach sufficient maturity. 316 If the "paramname" parameter is registered in this registry then its 317 URN will be "urn:ietf:gss:paramname". The initial registrations are 318 as follows: 320 +--------------------------+-------------+ 321 | Parameter | Reference | 322 +--------------------------+-------------+ 323 | radius-attribute | Section 5 | 324 | | | 325 | federated-saml-assertion | Section 6.1 | 326 | | | 327 | federated-saml-attribute | Section 6.2 | 328 | | | 329 | federated-saml-nameid | Section 6.3 | 330 +--------------------------+-------------+ 332 8.1. Registration of the GSS URN Namespace 334 IANA is requested to register the "gss" URN sub-namespace in the IETF 335 URN sub-namespace for protocol parameters defined in [RFC3553]. 337 Registry Name: gss 339 Specification: draft-ietf-abfab-gss-eap-naming 341 Repository: GSS-API URN Parameters (Section 8) 343 Index Value: Sub-parameters MUST be specified in UTF-8 using standard 344 URI encoding where necessary. 346 9. Acknowledgements 348 Scott Cantor contributed significant text and multiple reviews of 349 this document. 351 Sam hartman's work on this specification has been funded by Janet. 353 10. References 355 10.1. Normative References 357 [I-D.ietf-abfab-gss-eap] 358 Hartman, S. and J. Howlett, "A GSS-API Mechanism for the 359 Extensible Authentication Protocol", 360 draft-ietf-abfab-gss-eap-09 (work in progress), 361 August 2012. 363 [I-D.ietf-kitten-gssapi-naming-exts] 364 Williams, N., Johansson, L., Hartman, S., and S. 365 Josefsson, "GSS-API Naming Extensions", 366 draft-ietf-kitten-gssapi-naming-exts-15 (work in 367 progress), May 2012. 369 [I-D.ietf-radext-radius-extensions] 370 DeKok, A. and A. Lior, "Remote Authentication Dial In User 371 Service (RADIUS) Protocol Extensions", 372 draft-ietf-radext-radius-extensions-06 (work in progress), 373 June 2012. 375 [OASIS.saml-core-2.0-os] 376 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 377 "Assertions and Protocol for the OASIS Security Assertion 378 Markup Language (SAML) V2.0", OASIS Standard saml-core- 379 2.0-os, March 2005. 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, March 1997. 384 [RFC2743] Linn, J., "Generic Security Service Application Program 385 Interface Version 2, Update 1", RFC 2743, January 2000. 387 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 388 IETF URN Sub-namespace for Registered Protocol 389 Parameters", BCP 73, RFC 3553, June 2003. 391 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 392 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 393 May 2008. 395 10.2. Informative References 397 [I-D.ietf-abfab-aaa-saml] 398 Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding 399 and Profiles for SAML", draft-ietf-abfab-aaa-saml-03 (work 400 in progress), March 2012. 402 [I-D.ietf-kitten-sasl-saml-ec] 403 Cantor, S. and S. Josefsson, "SAML Enhanced Client SASL 404 and GSS-API Mechanisms", draft-ietf-kitten-sasl-saml-ec-02 405 (work in progress), August 2012. 407 Authors' Addresses 409 Sam Hartman 410 Painless Security 412 Email: hartmans-ietf@mit.edu 414 Josh Howlett 415 JANET(UK) 417 Email: josh.howlett@ja.net