idnits 2.17.1 draft-hartman-gss-eap-naming-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 5, 2010) is 5044 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 256, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-kitten-gssapi-naming-exts-08 Summary: 1 error (**), 0 flaws (~~), 5 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 6, 2011 JANET(UK) 6 July 5, 2010 8 Name Attributes for the GSS-API EAP mechanism 9 draft-hartman-gss-eap-naming-00 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 to IETF 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), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 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 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on January 6, 2011. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 65 3. Naming Extensions and SAML . . . . . . . . . . . . . . . . . . 5 66 4. RADIUS and Authenticated Attributes . . . . . . . . . . . . . 6 67 5. Name Attributes for GSS-EAP . . . . . . . . . . . . . . . . . 8 68 5.1. Assertions . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.2. SAML Attributes . . . . . . . . . . . . . . . . . . . . . 8 70 5.3. RADIUS Attributes . . . . . . . . . . . . . . . . . . . . 8 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 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.howlett-eap-gss] 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. This document describes the necessary information to 88 use the naming extensions API to access that information. 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. As of June 2010, GSS- 105 API name attributes take the form of a single URI. 107 Administrators may need to type SAML attribute names into 108 configuration files or otherwise tell applications how to find 109 attributes. It is desirable to support accessing these attributes 110 from applications that have no awareness of SAML. So, the GSS-API 111 attribute name should be something that an administrator can 112 reasonably easily construct from a SAML attribute name. In 113 particular, adding or removing URI escapes, base64 encoding or 114 similar transformations would significantly decrease usability. 116 Instead, it seems desirable to extend GSS-API naming extensions to 117 support concepts such as SAML names where the format is specified 118 separately. The format of GSS-API attribute names should be changed. 119 If no space character is found in the name, then the name is 120 interpreted as a URI describing the attribute. Otherwise, the 121 portion from the beginning of the buffer to the first space is 122 interpreted as a URI describing the form and interpretation of the 123 rest of the buffer; this portion is known as the attribute type URI. 125 4. RADIUS and Authenticated Attributes 127 GSS-API naming extensions have the concept of an authenticated name 128 attribute. The mechanism guarantees that the contents of an 129 authenticated name attribute are an authenticated statement from the 130 trusted source of the peer credential. The fact that an attribute is 131 authenticated does not imply that the trusted source of the peer 132 credential is authorized to assert the attribute. 134 In the federated context, the trusted source of the peer credential 135 is typically some identity provider. In the GSS EAP mechanism, 136 information is combined from AAA and SAML sources. The SAML IDP and 137 home AAA server are assumed to be in the same trust domain. However, 138 this trust domain is not typically the same as the trust domain of 139 the service. Typically, the IDP is run by another organization in 140 the same federation. The IDP is trusted to make some statements, 141 particularly related to the context of a federation. For example, an 142 academic federation's participants would typically trust an IDP's 143 assertions about whether someone was a student or a professor. 144 However that same IDP would not typically be trusted to make 145 assertions about local entitlements such as group membership. Thus, 146 a service MUST make a policy decision about whether the IDP is 147 permitted to assert a particular attribute and about whether the 148 asserted value is acceptable. 150 In contrast, attributes in an enterprise context are often verified 151 by a central authentication infrastructure that is trusted to assert 152 most or all attributes. For example, in a Kerberos infrastructure, 153 the KDC typically indicates group membership information for clients 154 to a server using KDC-authenticated authorization data. 156 The context of an attribute is an important property of that 157 attribute; trust context is an important part of the context. 158 Applications will often want to treat an attribute in a federated 159 context the same as an attribute in an enterprise context. In order 160 for applications to distinguish the context of attributes, attributes 161 with different context need different names. For example, the name 162 of an attribute containing the initiator's e-mail address in a 163 federated context needs to be different from the name containing the 164 initiator's e-mail address in a different context. The determination 165 of trust from this context information can never be exact: Kerberos 166 typically is used in environments where the KDC is fairly trusted, 167 but an application could have a key in a realm that it does not fully 168 trust. Similarly, SAML is typically in a federated context, but an 169 organization could use SAML for internal authentication as well. 171 It would be convenient to use the same GSS-API attribute names for 172 the same information regardless of context. However, when 173 considering attribute names it is critical to consider the 174 appropriate interpretation of that name and the distinctions an 175 application will need to make about the name. As a result, it is 176 often the case that attributes from two different mechanisms will 177 have different names. 179 However, the local implementation of the mechanism and layers in the 180 GSS-API implementation above the mechanism can make the job of the 181 application easier. If local policy permits an attribute to be 182 trusted, then the attribute can be copied to a name whose context 183 indicates that local policy has been applied. For example, an 184 implementation could have an attribute for e-mail address that 185 received the value both of a SAML mechanism and Kerberos mechanism's 186 e-mail address attributes after local policy is applied. Such 187 mechanism-level attributes can also be used to normalize the format 188 of attribute values. 190 In the case of GSS-EAP, the attribute names need to be specific to 191 SAML attributes obtained via AAA transport. 193 5. Name Attributes for GSS-EAP 195 This section describes how SAML assertions, SAML attributes and 196 RADIUS attributes received with the GSS-EAP mechanism are named. 198 5.1. Assertions 200 Implementations of GSS-EAP MUST support an attribute with the name 201 "urn:ietf:params:gss-eap:saml-aaa-assertion". The value of this 202 attribute is the assertion carried in the AAA protocol. This 203 attribute is absent from a given acceptor name if no such assertion 204 is present or if the assertion fails local policy checks. This 205 attribute is always authentic when present: authentication only 206 succeeds if the AAA exchange is successfully authenticated. However, 207 users of the GSS-API MUST confirm that the attribute is authenticated 208 because some mechanisms MAY permit an initiator to assert an 209 unauthenticated version of this attribute. 211 5.2. SAML Attributes 213 Each attribute carried in the assertion SHOULD also be a GSS name 214 attribute. The name of this attribute has three parts, all separated 215 by an ASCII space character. The first part is 216 urn:ietf:params:gss-eap:saml-attr. The second part is the URI for 217 the SAML attribute name format. The final part is the name of the 218 SAML attribute. If the mechanism performs an additional attribute 219 query, the retrieved attributes SHOULD be GSS-API name attributes 220 using the same name syntax. 222 These attributes SHOULD be marked authenticated if they are contained 223 in SAML assertions that have been successfully validated back to the 224 trusted source of the peer credential. In the GSS-EAP mechanism, a 225 SAML assertion carried in an integrity-protected and authenticated 226 AAA protocol SHALL be sufficiently validated. An implementation MAY 227 apply local policy checks to this assertion and discard it if it is 228 unacceptable according to these checks. 230 Attribute query results made based on this assertion also count as 231 originating with the source of the peer credential. The 232 implementation MUST validate the authenticity of these results before 233 they are processed. 235 5.3. RADIUS Attributes 237 A mechanism needs to be created to give applications access to AAA 238 AVPs carried along with an access-accept message. 240 6. Security Considerations 242 This needs to be written. 244 7. IANA Considerations 246 This section needs to include URN registrations within the IETF 247 namespace for URNs that are used. 249 8. Normative References 251 [I-D.howlett-eap-gss] 252 Hartman, S. and J. Howlett, "A GSS-API Mechanism for the 253 Extensible Authentication Protocol", 254 draft-howlett-eap-gss-00 (work in progress), March 2010. 256 [I-D.ietf-kitten-gssapi-naming-exts] 257 Williams, N. and L. Johansson, "GSS-API Naming 258 Extensions", draft-ietf-kitten-gssapi-naming-exts-08 (work 259 in progress), June 2010. 261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 262 Requirement Levels", BCP 14, RFC 2119, March 1997. 264 [RFC2743] Linn, J., "Generic Security Service Application Program 265 Interface Version 2, Update 1", RFC 2743, January 2000. 267 Authors' Addresses 269 Sam Hartman 270 Painless Security 272 Email: hartmans-ietf@mit.edu 274 Josh Howlett 275 JANET(UK) 277 Email: josh.howlett@ja.net