idnits 2.17.1 draft-ietf-abfab-gss-eap-naming-01.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 (October 21, 2011) is 4571 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 101, but not defined == Unused Reference: 'I-D.ietf-kitten-gssapi-naming-exts' is defined on line 251, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-abfab-gss-eap-03 == Outdated reference: A later version (-15) exists of draft-ietf-kitten-gssapi-naming-exts-11 == Outdated reference: A later version (-13) exists of draft-ietf-radext-radius-extensions-01 == Outdated reference: A later version (-20) exists of draft-ietf-kitten-sasl-saml-ec-00 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: April 23, 2012 JANET(UK) 6 October 21, 2011 8 Name Attributes for the GSS-API EAP mechanism 9 draft-ietf-abfab-gss-eap-naming-01 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 April 23, 2012. 41 Copyright Notice 43 Copyright (c) 2011 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 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 The naming extensions [I-D.ietf-kitten-gssapi-naming-exts]to the 76 Generic Security Services Application Programming interface (GSS-API) 77 [RFC2743] provide a mechanism for applications to discover 78 authorization and personalization information associated with GSS-API 79 names. The Extensible Authentication Protocol GSS-API mechanism 80 [I-D.ietf-abfab-gss-eap] allows an Authentication/Authorization/ 81 Accounting peer to provide authorization attributes along side an 82 authentication response. It also provides mechanisms to process 83 Security Assertion Markup Language (SAML) messages provided in the 84 AAA response. Other mechanisms such as SAML EC 85 [I-D.ietf-kitten-sasl-saml-ec] also support SAML assertions and 86 attributes carried in the GSS-API. This document describes the 87 necessary information to use the naming extensions API to access SAML 88 assertions in the federated context and AAA attributes. 90 2. Requirements notation 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 3. Naming Extensions and SAML 98 SAML assertions can carry attributes describing properties of the 99 subject of the assertion. For example, an assertion might carry an 100 attribute describing the organizational affiliation or e-mail address 101 of a subject. According to Section 8.2 and 2.7.3.1 of [SAMLCORE], 102 the name of an attribute has two parts. The first is a URI 103 describing the format of the name. The second part, whose form 104 depends on the format URI, is the actual name. GSS-API name 105 attributes may take a form starting with a URI describing the form of 106 the name; the rest of the name is specified by that URI. 108 SAML attributes carried in GSS-API names are named with three parts. 109 The first is a URN indicating that the name is a SAML attribute and 110 describing the context (Section 4). This URI is followed by a space, 111 the URI indicating the format of the SAML name, a space and the SAML 112 attribute name. The URI indicating the format of the SAML attribute 113 name is not optional and MUST be present. 115 SAML attribute names may not be globally unique. Many names that are 116 named by URNs or URIs are likely to have semantics independent of the 117 issuer. However for other name formats, including unspecified name 118 formats, make it easy for two issuers to choose the same name for 119 attributes with different semantics. Attributes using the federated 120 context Section 4 are issued by the same party performing the 121 authentication. So, based on who is named by the name, the semantics 122 of the attribute can be determined. 124 4. Federated Context 126 GSS-API naming extensions have the concept of an authenticated name 127 attribute. The mechanism guarantees that the contents of an 128 authenticated name attribute are an authenticated statement from the 129 trusted source of the peer credential. The fact that an attribute is 130 authenticated does not imply that the trusted source of the peer 131 credential is authorized to assert the attribute. 133 In the federated context, the trusted source of the peer credential 134 is typically some identity provider. In the GSS EAP mechanism, 135 information is combined from AAA and SAML sources. The SAML IDP and 136 home AAA server are assumed to be in the same trust domain. However, 137 this trust domain is not typically the same as the trust domain of 138 the service. With other SAML mechanisms using this specification, 139 the SAML assertion also comes from the party performing 140 authentication. Typically, the IDP is run by another organization in 141 the same federation. The IDP is trusted to make some statements, 142 particularly related to the context of a federation. For example, an 143 academic federation's participants would typically trust an IDP's 144 assertions about whether someone was a student or a professor. 145 However that same IDP would not typically be trusted to make 146 assertions about local entitlements such as group membership. Thus, 147 a service MUST make a policy decision about whether the IDP is 148 permitted to assert a particular attribute and about whether the 149 asserted value is acceptable. 151 In contrast, attributes in an enterprise context are often verified 152 by a central authentication infrastructure that is trusted to assert 153 most or all attributes. For example, in a Kerberos infrastructure, 154 the KDC typically indicates group membership information for clients 155 to a server using KDC-authenticated authorization data. 157 The context of an attribute is an important property of that 158 attribute; trust context is an important part of the context. In 159 order for applications to distinguish the context of attributes, 160 attributes with different context need different names. This 161 specification defines attribute names for SAML and AA attributes in 162 the federated context. 164 These names MUST not be used for attributes issued by a party other 165 than one closely associated with the source of credentials unless the 166 source of credentials is re-asserting the attributes. For example, a 167 source of credentials can consult whatever sources of attributes it 168 chooses, but acceptors can assume attributes in the federated context 169 are from the source of credentials. 171 5. Name Attributes for GSS-EAP 173 This section describes how RADIUS attributes received with the GSS- 174 EAP mechanism are named. 176 The first portion of the name is TBD1 (a URN indicating that this is 177 a GSS-EAP RADIUS AVP). This is followed by a space and a numeric 178 RADIUS name as described by section 2.6 of 179 [I-D.ietf-radext-radius-extensions]. For example the name of the 180 User-Name attribute is "TBD 1". The name of extended type 1 within 181 type 241 would be "TBD 241.1". 183 The value of RADIUS attributes is the raw octets of the packet. 184 Integers are in network byte order. The display value SHOULD be a 185 human readable string; an implementation can only produce this string 186 if it knows the type of a given RADIUS attribute. 188 6. Names of SAML Attributes in the Federated Context 190 6.1. Assertions 192 An assertion generated by the credential source is named by 193 "urn:ietf:params:gss-eap:saml-aaa-assertion". The value of this 194 attribute is the assertion carried in the AAA protocol or used for 195 authentication in a SAML mechanism. This attribute is absent from a 196 given acceptor name if no such assertion is present or if the 197 assertion fails local policy checks. This attribute is always 198 authentic when present: authentication only succeeds if the AAA 199 exchange is successfully authenticated. However, users of the GSS- 200 API MUST confirm that the attribute is authenticated because some 201 mechanisms MAY permit an initiator to assert an unauthenticated 202 version of this attribute. 204 6.2. SAML Attributes 206 Each attribute carried in the assertion SHOULD also be a GSS name 207 attribute. The name of this attribute has three parts, all separated 208 by an ASCII space character. The first part is 209 urn:ietf:params:gss-eap:saml-attr. The second part is the URI for 210 the SAML attribute name format. The final part is the name of the 211 SAML attribute. 213 These attributes SHOULD be marked authenticated if they are contained 214 in SAML assertions that have been successfully validated back to the 215 trusted source of the peer credential. In the GSS-EAP mechanism, a 216 SAML assertion carried in an integrity-protected and authenticated 217 AAA protocol SHALL be sufficiently validated. An implementation MAY 218 apply local policy checks to this assertion and discard it if it is 219 unacceptable according to these checks. 221 7. Security Considerations 223 This document describes how to access RADIUS attributes, SAML 224 attributes and SAML assertions from some GSS-API mechanisms. These 225 attributes are typically used for one of two purposes. The least 226 sensitive is personalization: a central service MAY provide 227 information about an authenticated user so they need not enter it 228 with each acceptor they access. A more sensitive use is 229 authorization. 231 The mechanism is responsible for authentication and integrity 232 protection of the attributes. However, the acceptor application is 233 responsible for making a decision about whether the credential source 234 is trusted to assert the attribute and validating the asserted value. 236 8. IANA Considerations 238 This section needs to include URN registrations within the IETF 239 namespace for URNs that are used. 241 9. References 243 9.1. Normative References 245 [I-D.ietf-abfab-gss-eap] 246 Hartman, S. and J. Howlett, "A GSS-API Mechanism for the 247 Extensible Authentication Protocol", 248 draft-ietf-abfab-gss-eap-03 (work in progress), 249 October 2011. 251 [I-D.ietf-kitten-gssapi-naming-exts] 252 Williams, N., Johansson, L., Hartman, S., and S. 253 Josefsson, "GSS-API Naming Extensions", 254 draft-ietf-kitten-gssapi-naming-exts-11 (work in 255 progress), May 2011. 257 [I-D.ietf-radext-radius-extensions] 258 DeKok, A. and A. Lior, "Remote Authentication Dial In User 259 Service (RADIUS) Protocol Extensions", 260 draft-ietf-radext-radius-extensions-01 (work in progress), 261 June 2011. 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, March 1997. 266 [RFC2743] Linn, J., "Generic Security Service Application Program 267 Interface Version 2, Update 1", RFC 2743, January 2000. 269 9.2. Informative References 271 [I-D.ietf-kitten-sasl-saml-ec] 272 Cantor, S. and S. Josefsson, "SAML Enhanced Client SASL 273 and GSS-API Mechanisms", draft-ietf-kitten-sasl-saml-ec-00 274 (work in progress), August 2011. 276 Authors' Addresses 278 Sam Hartman 279 Painless Security 281 Email: hartmans-ietf@mit.edu 283 Josh Howlett 284 JANET(UK) 286 Email: josh.howlett@ja.net