idnits 2.17.1 draft-ietf-abfab-gss-eap-naming-03.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 (July 11, 2012) is 4304 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) == Missing Reference: 'SAMLCORE' is mentioned on line 255, but not defined == Unused Reference: 'I-D.ietf-kitten-gssapi-naming-exts' is defined on line 348, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-abfab-gss-eap-08 == 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 (-20) exists of draft-ietf-kitten-sasl-saml-ec-01 Summary: 1 error (**), 0 flaws (~~), 7 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: January 12, 2013 JANET(UK) 6 July 11, 2012 8 Name Attributes for the GSS-API EAP mechanism 9 draft-ietf-abfab-gss-eap-naming-03 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 January 12, 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 . . . . . . . . . . . . . . . . . . . . . . . . 14 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 definied in this specification 94 are 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 [SAMLCORE], 108 the name of an attribute has two parts. The first is a URI 109 describing the format of the name. The second part, whose form 110 depends on the format URI, is the actual name. GSS-API name 111 attributes may take a form starting with a URI describing the form of 112 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 URI 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 mechanism are named. 182 The first portion of the name is urn:ietf:params:gss:radius-attribute 183 (a URN indicating that this is a GSS-EAP RADIUS AVP). This is 184 followed by a space and a numeric RADIUS name as described by section 185 2.6 of [I-D.ietf-radext-radius-extensions]. For example the name of 186 the User-Name attribute is "urn:ietf:gss:radius-attribute 1". The 187 name of extended type 1 within type 241 would be 188 "urn:ietf:gss:radius-attribute 241.1". 190 The value of RADIUS attributes is the raw octets of the packet. 191 Integers are in network byte order. The display value SHOULD be a 192 human readable string; an implementation can only produce this string 193 if it knows the type of a given RADIUS attribute. If multiple 194 attributes are present with a given name in the RADIUS message, then 195 a multi-valued GSS-API attribute SHOULD be returned. As an 196 exception, implementations SHOULD concatenate RADIUS attributes such 197 as EAP-Message or large attributes defined in 198 [I-D.ietf-radext-radius-extensions] that use multiple attributes to 199 carry more than 253 octets of information. 201 6. Names of SAML Attributes in the Federated Context 203 6.1. Assertions 205 An assertion generated by the credential source is named by 206 "urn:ietf:params:gss:federated-saml-assertion". The value of this 207 attribute is the assertion carried in the AAA protocol or used for 208 authentication in a SAML mechanism. This attribute is absent from a 209 given acceptor name if no such assertion is present or if the 210 assertion fails local policy checks. This attribute is always 211 authentic when present: authentication only succeeds if the AAA 212 exchange is successfully authenticated. However, users of the GSS- 213 API MUST confirm that the attribute is authenticated because some 214 mechanisms MAY permit an initiator to assert an unauthenticated 215 version of this attribute. 217 6.2. SAML Attributes 219 Each attribute carried in the assertion SHOULD also be a GSS name 220 attribute. The name of this attribute has three parts, all separated 221 by an ASCII space character. The first part is 222 urn:ietf:params:gss:federated-saml-attribute. The second part is the 223 URI for the element's NameFormat XML attribute. The 224 final part is the element's Name XML attribute. 226 If the content of each element is a simple text 227 node (or nodes), then the raw and "display" values of the GSS name 228 attribute MUST be the text content of the element(s). The raw value 229 MUST be encoded as UTF-8. 231 If the value is not simple or is empty, then the raw value(s) of the 232 GSS name attribute MUST be the well-formed serialization of the 233 element(s) encoded as UTF-8. The "display" 234 values are implementation-defined. 236 These attributes SHOULD be marked authenticated if they are contained 237 in SAML assertions that have been successfully validated back to the 238 trusted source of the peer credential. In the GSS-EAP mechanism, a 239 SAML assertion carried in an integrity-protected and authenticated 240 AAA protocol SHALL be sufficiently validated. An implementation MAY 241 apply local policy checks to this assertion and discard it if it is 242 unacceptable according to these checks. 244 6.3. SAML Name Identifiers 246 The carried in the subject of the assertion SHOULD also 247 be a GSS name attribute. The name of this attribute has two parts, 248 separated by an ASCII space character. The first part is 249 urn:ietf:params:gss:federated-saml-nameid. The second part is the 250 URI for the element's Format XML attribute. 252 The raw value of the GSS name attribute MUST be the well-formed 253 serialization of the element encoded as UTF-8. The 254 "display" value is implementation-defined. For formats defined by 255 section 8.3 of [SAMLCORE], missing values of the NameQualifier or 256 SPNameQualifier XML attributes MUST be populated in accordance with 257 the definition of the format prior to serialization. In other words, 258 the defaulting rules specified for the "persistent" and "transient" 259 formats MUST be applied prior to serialization. 261 This attribute SHOULD be marked authenticated if the name identifier 262 is contained in a SAML assertion that has been successfully validated 263 back to the trusted source of the peer credential. In the GSS-EAP 264 mechanism, a SAML assertion carried in an integrity-protected and 265 authenticated AAA protocol SHALL be sufficiently validated. An 266 implementation MAY apply local policy checks to this assertion and 267 discard it if it is unacceptable according to these checks. 269 7. Security Considerations 271 This document describes how to access RADIUS attributes, SAML 272 attributes and SAML assertions from some GSS-API mechanisms. These 273 attributes are typically used for one of two purposes. The least 274 sensitive is personalization: a central service MAY provide 275 information about an authenticated user so they need not enter it 276 with each acceptor they access. A more sensitive use is 277 authorization. 279 The mechanism is responsible for authentication and integrity 280 protection of the attributes. However, the acceptor application is 281 responsible for making a decision about whether the credential source 282 is trusted to assert the attribute and validating the asserted value. 284 8. IANA Considerations 286 A new top-level registry is created titled "Generic Security Service 287 Application Program Interface Parameters". There doesn't seem to be 288 an existing top-level registry that can be used. There are 289 Parameters for the Kerberos V mechanism; parameters for the GSS-API 290 EAP mechanism; and GSS-API/SASL/Kerberos service names. However none 291 of these are the right place. 293 In this top-level registry, a sub-registry titled "GSS-API URN 294 Parameters" is created. Registration in this registry is by the IETF 295 review or expert review procedures [RFC5226]. Registrations in this 296 registry are generally only expected as part of protocols published 297 as RFCs on the IETF stream; other URIs are expected to be better 298 choices for non-IETf work. Expert review is permitted mainly to 299 permit early registration related to specifications under development 300 when the community believes they have reach sufficient maturity. 302 If the "paramname" parameter is registered in this registry then its 303 URN will be "urn:ietf:gss:paramname". The initial registrations are 304 as follows: 306 +--------------------------+-------------+ 307 | Parameter | Reference | 308 +--------------------------+-------------+ 309 | radius-attribute | Section 5 | 310 | | | 311 | federated-saml-assertion | Section 6.1 | 312 | | | 313 | federated-saml-attribute | Section 6.2 | 314 | | | 315 | federated-saml-nameid | Section 6.3 | 316 +--------------------------+-------------+ 318 8.1. Registration of the GSS URN Namespace 320 IANA is requested to register the "gss" URN sub-namespace in the IETF 321 URN sub-namespace for protocol parameters defined in [RFC3553]. 323 Registry Name: gss 325 Specification: draft-ietf-abfab-gss-eap-naming 327 Repository: GSS-API URN Parameters (Section 8) 329 Index Value: Sub-parameters MUST be specified in UTF-8 using standard 330 URI encoding where necessary. 332 9. Acknowledgements 334 Scott Cantor contributed significant text and multiple reviews of 335 this document. 337 Sam hartman's work on this specification has been funded by Janet. 339 10. References 341 10.1. Normative References 343 [I-D.ietf-abfab-gss-eap] 344 Hartman, S. and J. Howlett, "A GSS-API Mechanism for the 345 Extensible Authentication Protocol", 346 draft-ietf-abfab-gss-eap-08 (work in progress), June 2012. 348 [I-D.ietf-kitten-gssapi-naming-exts] 349 Williams, N., Johansson, L., Hartman, S., and S. 350 Josefsson, "GSS-API Naming Extensions", 351 draft-ietf-kitten-gssapi-naming-exts-15 (work in 352 progress), May 2012. 354 [I-D.ietf-radext-radius-extensions] 355 DeKok, A. and A. Lior, "Remote Authentication Dial In User 356 Service (RADIUS) Protocol Extensions", 357 draft-ietf-radext-radius-extensions-06 (work in progress), 358 June 2012. 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, March 1997. 363 [RFC2743] Linn, J., "Generic Security Service Application Program 364 Interface Version 2, Update 1", RFC 2743, January 2000. 366 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 367 IETF URN Sub-namespace for Registered Protocol 368 Parameters", BCP 73, RFC 3553, June 2003. 370 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 371 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 372 May 2008. 374 10.2. Informative References 376 [I-D.ietf-kitten-sasl-saml-ec] 377 Cantor, S. and S. Josefsson, "SAML Enhanced Client SASL 378 and GSS-API Mechanisms", draft-ietf-kitten-sasl-saml-ec-01 379 (work in progress), February 2012. 381 Authors' Addresses 383 Sam Hartman 384 Painless Security 386 Email: hartmans-ietf@mit.edu 388 Josh Howlett 389 JANET(UK) 391 Email: josh.howlett@ja.net