idnits 2.17.1 draft-ietf-abfab-gss-eap-naming-02.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: These names MUST not be used for attributes issued by a party other than one closely associated with the source of credentials unless the source of credentials is re-asserting the attributes. For example, a source of credentials can consult whatever sources of attributes it chooses, but acceptors can assume attributes in the federated context are from the source of credentials. -- The document date (March 12, 2012) is 4421 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 245, but not defined == Unused Reference: 'I-D.ietf-kitten-gssapi-naming-exts' is defined on line 295, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-abfab-gss-eap-05 == Outdated reference: A later version (-15) exists of draft-ietf-kitten-gssapi-naming-exts-13 == Outdated reference: A later version (-13) exists of draft-ietf-radext-radius-extensions-04 == Outdated reference: A later version (-20) exists of draft-ietf-kitten-sasl-saml-ec-01 Summary: 0 errors (**), 0 flaws (~~), 9 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: September 13, 2012 JANET(UK) 6 March 12, 2012 8 Name Attributes for the GSS-API EAP mechanism 9 draft-ietf-abfab-gss-eap-naming-02 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 September 13, 2012. 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 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 The naming extensions [I-D.ietf-kitten-gssapi-naming-exts]to the 78 Generic Security Services Application Programming interface (GSS-API) 79 [RFC2743] provide a mechanism for applications to discover 80 authorization and personalization information associated with GSS-API 81 names. The Extensible Authentication Protocol GSS-API mechanism 82 [I-D.ietf-abfab-gss-eap] allows an Authentication/Authorization/ 83 Accounting peer to provide authorization attributes along side an 84 authentication response. It also provides mechanisms to process 85 Security Assertion Markup Language (SAML) messages provided in the 86 AAA response. Other mechanisms such as SAML EC 87 [I-D.ietf-kitten-sasl-saml-ec] also support SAML assertions and 88 attributes carried in the GSS-API. This document describes the 89 necessary information to use the naming extensions API to access SAML 90 assertions in the federated context and AAA attributes. 92 2. Requirements notation 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. Naming Extensions and SAML 100 SAML assertions can carry attributes describing properties of the 101 subject of the assertion. For example, an assertion might carry an 102 attribute describing the organizational affiliation or e-mail address 103 of a subject. According to Section 8.2 and 2.7.3.1 of [SAMLCORE], 104 the name of an attribute has two parts. The first is a URI 105 describing the format of the name. The second part, whose form 106 depends on the format URI, is the actual name. GSS-API name 107 attributes may take a form starting with a URI describing the form of 108 the name; the rest of the name is specified by that URI. 110 SAML attributes carried in GSS-API names are named with three parts. 111 The first is a URN indicating that the name is a SAML attribute and 112 describing the context (Section 4). This URI is followed by a space, 113 the URI indicating the format of the SAML name, a space and the SAML 114 attribute name. The URI indicating the format of the SAML attribute 115 name is not optional and MUST be present. 117 SAML attribute names may not be globally unique. Many names that are 118 named by URNs or URIs are likely to have semantics independent of the 119 issuer. However other name formats, including unspecified name 120 formats, make it easy for two issuers to choose the same name for 121 attributes with different semantics. Attributes using the federated 122 context Section 4 are issued by the same party performing the 123 authentication. So, based on who is the subject of the name, the 124 semantics of the attribute can be determined. 126 4. Federated Context 128 GSS-API naming extensions have the concept of an authenticated name 129 attribute. The mechanism guarantees that the contents of an 130 authenticated name attribute are an authenticated statement from the 131 trusted source of the peer credential. The fact that an attribute is 132 authenticated does not imply that the trusted source of the peer 133 credential is authorized to assert the attribute. 135 In the federated context, the trusted source of the peer credential 136 is typically some identity provider. In the GSS EAP mechanism, 137 information is combined from AAA and SAML sources. The SAML IDP and 138 home AAA server are assumed to be in the same trust domain. However, 139 this trust domain is not typically the same as the trust domain of 140 the service. With other SAML mechanisms using this specification, 141 the SAML assertion also comes from the party performing 142 authentication. Typically, the IDP is run by another organization in 143 the same federation. The IDP is trusted to make some statements, 144 particularly related to the context of a federation. For example, an 145 academic federation's participants would typically trust an IDP's 146 assertions about whether someone was a student or a professor. 147 However that same IDP would not typically be trusted to make 148 assertions about local entitlements such as group membership. Thus, 149 a service MUST make a policy decision about whether the IDP is 150 permitted to assert a particular attribute and about whether the 151 asserted value is acceptable. 153 In contrast, attributes in an enterprise context are often verified 154 by a central authentication infrastructure that is trusted to assert 155 most or all attributes. For example, in a Kerberos infrastructure, 156 the KDC typically indicates group membership information for clients 157 to a server using KDC-authenticated authorization data. 159 The context of an attribute is an important property of that 160 attribute; trust context is an important part of this overall 161 context. In order for applications to distinguish the context of 162 attributes, attributes with different context need different names. 163 This specification defines attribute names for SAML and AAA 164 attributes in the federated context. 166 These names MUST not be used for attributes issued by a party other 167 than one closely associated with the source of credentials unless the 168 source of credentials is re-asserting the attributes. For example, a 169 source of credentials can consult whatever sources of attributes it 170 chooses, but acceptors can assume attributes in the federated context 171 are from the source of credentials. 173 5. Name Attributes for GSS-EAP 175 This section describes how RADIUS attributes received with the GSS- 176 EAP mechanism are named. 178 The first portion of the name is urn:ietf:params:gss:radius-attr (a 179 URN indicating that this is a GSS-EAP RADIUS AVP). This is followed 180 by a space and a numeric RADIUS name as described by section 2.6 of 181 [I-D.ietf-radext-radius-extensions]. For example the name of the 182 User-Name attribute is "urn:ietf:gss:radius-attr 1". The name of 183 extended type 1 within type 241 would be "urn:ietf:gss:radius-attr 184 241.1". 186 The value of RADIUS attributes is the raw octets of the packet. 187 Integers are in network byte order. The display value SHOULD be a 188 human readable string; an implementation can only produce this string 189 if it knows the type of a given RADIUS attribute. 191 6. Names of SAML Attributes in the Federated Context 193 6.1. Assertions 195 An assertion generated by the credential source is named by 196 "urn:ietf:params:gss:fed-saml-assertion". The value of this 197 attribute is the assertion carried in the AAA protocol or used for 198 authentication in a SAML mechanism. This attribute is absent from a 199 given acceptor name if no such assertion is present or if the 200 assertion fails local policy checks. This attribute is always 201 authentic when present: authentication only succeeds if the AAA 202 exchange is successfully authenticated. However, users of the GSS- 203 API MUST confirm that the attribute is authenticated because some 204 mechanisms MAY permit an initiator to assert an unauthenticated 205 version of this attribute. 207 6.2. SAML Attributes 209 Each attribute carried in the assertion SHOULD also be a GSS name 210 attribute. The name of this attribute has three parts, all separated 211 by an ASCII space character. The first part is 212 urn:ietf:params:gss:fed-saml-attr. The second part is the URI for 213 the element's NameFormat XML attribute. The final 214 part is the element's Name XML attribute. 216 If the content of each element is a simple text 217 node (or nodes), then the raw and "display" values of the GSS name 218 attribute MUST be the text content of the element(s). The raw value 219 MUST be encoded as UTF-8. 221 If the value is not simple, then the raw value(s) of the GSS name 222 attribute MUST be the well-formed serialization of the element(s) encoded as UTF-8. The "display" values 224 are implementation-defined. 226 These attributes SHOULD be marked authenticated if they are contained 227 in SAML assertions that have been successfully validated back to the 228 trusted source of the peer credential. In the GSS-EAP mechanism, a 229 SAML assertion carried in an integrity-protected and authenticated 230 AAA protocol SHALL be sufficiently validated. An implementation MAY 231 apply local policy checks to this assertion and discard it if it is 232 unacceptable according to these checks. 234 6.3. SAML Name Identifiers 236 The carried in the subject of the assertion SHOULD also 237 be a GSS name attribute. The name of this attribute has two parts, 238 separated by an ASCII space character. The first part is 239 urn:ietf:params:gss:fed-saml-nameid. The second part is the URI for 240 the element's Format XML attribute. 242 The raw value of the GSS name attribute MUST be the well-formed 243 serialization of the element encoded as UTF-8. The 244 "display" value is implementation-defined. For formats defined by 245 section 8.3 of [SAMLCORE], missing values of the NameQualifier or 246 SPNameQualifier XML attributes MUST be populated in accordance with 247 the definition of the format prior to serialization. In other words, 248 the defaulting rules specified for the "persistent" and "transient" 249 formats MUST be applied prior to serialization. 251 This attribute SHOULD be marked authenticated if the name identifier 252 is contained in a SAML assertion that has been successfully validated 253 back to the trusted source of the peer credential. In the GSS-EAP 254 mechanism, a SAML assertion carried in an integrity-protected and 255 authenticated AAA protocol SHALL be sufficiently validated. An 256 implementation MAY apply local policy checks to this assertion and 257 discard it if it is unacceptable according to these checks. 259 7. Security Considerations 261 This document describes how to access RADIUS attributes, SAML 262 attributes and SAML assertions from some GSS-API mechanisms. These 263 attributes are typically used for one of two purposes. The least 264 sensitive is personalization: a central service MAY provide 265 information about an authenticated user so they need not enter it 266 with each acceptor they access. A more sensitive use is 267 authorization. 269 The mechanism is responsible for authentication and integrity 270 protection of the attributes. However, the acceptor application is 271 responsible for making a decision about whether the credential source 272 is trusted to assert the attribute and validating the asserted value. 274 8. IANA Considerations 276 First, a new registry needs to be created for GSS URNs. Then, this 277 needs to be registered in the IETF's URN registry. Then this 278 registry needs to be populated with URN items from this spec. 280 9. Acknowledgements 282 Scott Cantor contributed significant text and multiple reviews of 283 this document. 285 10. References 287 10.1. Normative References 289 [I-D.ietf-abfab-gss-eap] 290 Hartman, S. and J. Howlett, "A GSS-API Mechanism for the 291 Extensible Authentication Protocol", 292 draft-ietf-abfab-gss-eap-05 (work in progress), 293 March 2012. 295 [I-D.ietf-kitten-gssapi-naming-exts] 296 Williams, N., Johansson, L., Hartman, S., and S. 297 Josefsson, "GSS-API Naming Extensions", 298 draft-ietf-kitten-gssapi-naming-exts-13 (work in 299 progress), March 2012. 301 [I-D.ietf-radext-radius-extensions] 302 DeKok, A. and A. Lior, "Remote Authentication Dial In User 303 Service (RADIUS) Protocol Extensions", 304 draft-ietf-radext-radius-extensions-04 (work in progress), 305 January 2012. 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, March 1997. 310 [RFC2743] Linn, J., "Generic Security Service Application Program 311 Interface Version 2, Update 1", RFC 2743, January 2000. 313 10.2. Informative References 315 [I-D.ietf-kitten-sasl-saml-ec] 316 Cantor, S. and S. Josefsson, "SAML Enhanced Client SASL 317 and GSS-API Mechanisms", draft-ietf-kitten-sasl-saml-ec-01 318 (work in progress), February 2012. 320 Authors' Addresses 322 Sam Hartman 323 Painless Security 325 Email: hartmans-ietf@mit.edu 327 Josh Howlett 328 JANET(UK) 330 Email: josh.howlett@ja.net