idnits 2.17.1 draft-perez-abfab-kerberos-preauth-options-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4428 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-abfab-usecases-01 == Outdated reference: A later version (-09) exists of draft-ietf-abfab-gss-eap-04 == Outdated reference: A later version (-03) exists of draft-perez-krb-wg-gss-preauth-01 -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ABFAB A. Perez 3 Internet-Draft University of Murcia 4 Intended status: Informational J. Howlett 5 Expires: September 13, 2012 Janet 6 March 12, 2012 8 Options for Abfab-based Kerberos pre-authentication 9 draft-perez-abfab-kerberos-preauth-options-01 11 Abstract 13 Kerberos is widely used for authentication within organisations. It 14 is not, however, commonly used for authentication between domains or 15 realms ("cross-realm operation"). Abfab is a new architecture, based 16 on the AAA framework, that provides a mechanism for federating 17 authentication between realms. 19 AAA protocols are already widely used for federating authentication 20 for network access scenarios today. It has been proposed that Abfab 21 could be used to provide a mechanism yielding cross-realm 22 functionality for Kerberos. This document discusses two alternative 23 models with the aim of informing and facilitating discussion. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 13, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Use of Abfab . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Proposed Models . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. The Kerberos client is the Abfab initiator . . . . . . . . 3 63 3.2. The Kerberos Client is the Abfab acceptor . . . . . . . . . 4 64 3.3. Commonalities . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.4. Differences . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. EAP-based pre-authentication approaches . . . . . . . . . . . . 5 67 4.1. EAP pre-authentication . . . . . . . . . . . . . . . . . . 5 68 4.2. GSS-API pre-authentication . . . . . . . . . . . . . . . . 6 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 70 6. Informative References . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 Kerberos [RFC4120] is a widely deployed system for authentication, 75 being integrated in multiple operating systems and network 76 applications. However, Kerberos is typically only used to manage 77 authentication within the scope of a single realm (typically 78 corresponding to a single organisation). While often supported by 79 implementations, Kerberos cross-realm operation is used relatively 80 infrequently. 82 The Abfab architecture [I-D.lear-abfab-arch] describes an access 83 management model that enables the application of federated identity 84 within a broad range of use cases. This is achieved by building on 85 proven technologies and widely deployed infrastructures. Some of 86 these use cases are described in [I-D.ietf-abfab-usecases]. 88 This draft considers two alternative models to typical Kerberos 89 cross-realm operation that build on the Abfab architecture. The goal 90 of this document is to describe these approaches in the expectation 91 that this will facilitate and inform further discussion. 93 2. Use of Abfab 95 The Extensible Authentication Protocol (EAP) [RFC3748] was originally 96 defined as an authentication framework for data links (such as PPP 97 [RFC1661]), building on the AAA frameworks provided by RADIUS 98 [RFC2865] and Diameter [RFC3588]. 100 Abfab is the application of the EAP and AAA frameworks for 101 authentication of application-level protocols, through the use of a 102 Generic Security Services (GSS) mechanism that acts as an EAP lower- 103 layer: the GSS EAP mechanism [I-D.ietf-abfab-gss-eap]. 105 In the GSS EAP mechanism, the GSS initiator is the EAP peer and the 106 GSS acceptor is the EAP authenticator. In the canonical case the GSS 107 acceptor will act as an EAP pass-through, using an AAA protocol to 108 federate authenticate to a remote AAA/EAP server. 110 3. Proposed Models 112 Two models involving the application of Abfab within Kerberos have 113 been proposed. 115 3.1. The Kerberos client is the Abfab initiator 117 In this model a Kerberos client, co-located with the User Agent and 118 acting as an EAP peer, obtains a Kerberos ticket by using an EAP 119 credential to authenticate against a foreign realm's KDC that is 120 acting as an Abfab relying party. A detailed description of this 121 model can be found in [I-D.perez-abfab-eap-gss-preauth]. 123 The EAP credential is authenticated by the EAP server associated with 124 the user principal wielding the User Agent. If this ticket is a TGT, 125 the Kerberos client can subsequently obtain service tickets from the 126 foreign KDC in the usual way. 128 In either case, the Kerberos client is able to subsequently request a 129 Kerberos service ticket from the foreign KDC and authenticate to 130 Kerberos services within that realm. 132 The following figure illustrates this model: 134 User Kerberos EAP 135 Agent <----------------> KDC <----------------> Server 137 (EAP over (EAP over AAA) 138 K5 REQ/REP) 140 Figure 1 142 This model can be understood as the application of Abfab to the 143 Kerberos authentication message exchange. 145 3.2. The Kerberos Client is the Abfab acceptor 147 In this model a User Agent, acting as an EAP peer, initiates a 148 standard Abfab authentication exchange with an Abfab relying party. 149 A Kerberos client, co-located on the Abfab relying party, obtains a 150 Kerberos ticket (naming the principal wielding the User Agent) by 151 using the EAP tokens to authenticate against its KDC. 153 As in the previous model the EAP credential is authenticated by the 154 EAP server associated with the user principal wielding the User 155 Agent. 157 The following figure illustrates this model: 159 User Abfab Kerberos EAP 160 Agent <-------> RP <----------> KDC--------> Server 162 (Abfab) (EAP over (EAP over AAA) 163 K5 REQ/REP) 165 Figure 2 167 Having an additional actor, this model is more complex than the first 168 model. However, the relying party and KDC can be understood as a 169 single EAP authenticator that is split across two entities. Hence, 170 both entities must share access to the EAP authenticator context 171 (i.e. authenticator name, MSK, RADIUS keys...). 173 3.3. Commonalities 175 These model share the following in common: 177 o EAP is used to authenticate the user principal. 179 o The KDC is able to act as a point of authorisation for relying 180 parties within its realm. 182 3.4. Differences 184 These models are different in the following ways: 186 o In the first model, the KDC must (in the general case) be exposed 187 to KDC requests from any network location. In the second model, 188 the KDC only needs to be exposed to trusted Kerberos services. 190 o In the first model, the Kerberos client must be happy to use the 191 Kerberos discovery mechanism. 193 o In the first model, the User Agent must be happy to always use 194 Kerberos if it is available. 196 o In the first model, the Kerberos client and KDC must be modified, 197 but the already deployed relying parties reamain unmodified. In 198 the second model, the relying parties and the KDC must be 199 modified. 201 4. EAP-based pre-authentication approaches 203 The models described above require of a Kerberos pre-authentication 204 based on EAP. However, this pre-authentication can be provided by 205 one of the following two approaches. 207 4.1. EAP pre-authentication 209 In this approach, Kerberos itself becomes an EAP lower-layer. The 210 most straightforward way to approach this is to define a new EAP- 211 based FAST factor. This FAST factor transports EAP packets between 212 the EU and the KDC, following the multi round-trip procedure 213 described in [RFC6113] (i.e. returning MORE_PREAUTH_DATA_REQUIRED 214 error code). 216 This alternative is very simple, as EAP interfaces directly with 217 Kerberos, making the architecture more straightforward. It requires 218 the definition of the FAST factor in such a way that implements 219 [RFC4137], which defines the interface between EAP and the EAP lower- 220 layer. 222 This approach is applicable to any of the models. 224 4.2. GSS-API pre-authentication 226 In this alternative GSS-API is used by the Kerberos client and the 227 KDC to perform pre-authentication. Hence, a pre-authentication 228 mechanism based on the transport of GSS-API tokens is required, such 229 as that proposed by [I-D.perez-krb-wg-gss-preauth]. Such a pre- 230 authentication mechanism provides a generic framework where any GSS- 231 API mechanism can be executed, without further modification to the 232 Kerberos infrastructure. 234 This alternative introduces an additional layer, the GSS-API, between 235 EAP and Kerberos. The addition of this layer implies a higher 236 complexity of the model, but it also comes with several advantages. 237 The first one is the flexibility it provides. Defining a generic 238 GSS-preauth not only allows performing EAP pre-authentication, but it 239 can be used for any other existing GSS mechanism, and for those to be 240 defined in the future. This implies that using this alternative 241 would serve to integrate Kerberos into any existing federation, not 242 only those based on AAA, just by using a different GSS mechanism 243 instead of GSS-EAP. 245 Besides, from an design point of view, this alternative takes 246 advantage of the definition and implementation efforts put on the 247 GSS-EAP mechanism of the ABFAB WG and the Moonshot project. That 248 mechanism has already carefully implemented the interfaces defined 249 for an EAP lower-layer. 251 Finally, as discussed in [I-D.perez-krb-wg-gss-preauth], using this 252 proposal may simplify the generation of the PA-PX-COOKIE, as instead 253 of serializing the whole EAP state machine on each round-trip, it 254 could be possible to exchange GSS-API context handlers. 256 This approach is applicable to the first model. However, due the 257 specific particularities of the second model, this approach is not 258 easily applicable to it. 260 5. Security Considerations 262 To do 264 6. Informative References 266 [I-D.lear-abfab-arch] Howlett, J., Hartman, S., 267 Tschofenig, H., and E. Lear, 268 "Application Bridging for 269 Federated Access Beyond Web 270 (ABFAB) Architecture", 271 draft-lear-abfab-arch-02 (work in 272 progress), March 2011. 274 [I-D.ietf-abfab-usecases] Smith, R., "Application Bridging 275 for Federated Access Beyond web 276 (ABFAB) Use Cases", 277 draft-ietf-abfab-usecases-01 (work 278 in progress), July 2011. 280 [I-D.ietf-abfab-gss-eap] Howlett, J. and S. Hartman, "A 281 GSS-API Mechanism for the 282 Extensible Authentication 283 Protocol", 284 draft-ietf-abfab-gss-eap-04 (work 285 in progress), October 2011. 287 [I-D.perez-krb-wg-gss-preauth] Perez-Mendez, A., Pereniguez- 288 Garcia, F., Lopez-Millan, G., and 289 R. Lopez, "GSS-API pre- 290 authentication for Kerberos", 291 draft-perez-krb-wg-gss-preauth-01 292 (work in progress), January 2012. 294 [I-D.perez-abfab-eap-gss-preauth] Perez-Mendez, A., Lopez, R., 295 Pereniguez-Garcia, F., and G. 296 Lopez-Millan, "GSS-EAP pre- 297 authentication for Kerberos", draf 298 t-perez-abfab-eap-gss-preauth-01 299 (work in progress), March 2012. 301 [RFC1661] Simpson, W., "The Point-to-Point 302 Protocol (PPP)", STD 51, RFC 1661, 303 July 1994. 305 [RFC2865] Rigney, C., Willens, S., Rubens, 306 A., and W. Simpson, "Remote 307 Authentication Dial In User 308 Service (RADIUS)", RFC 2865, 309 June 2000. 311 [RFC3588] Calhoun, P., Loughney, J., 312 Guttman, E., Zorn, G., and J. 313 Arkko, "Diameter Base Protocol", 314 RFC 3588, September 2003. 316 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, 317 J., Carlson, J., and H. Levkowetz, 318 "Extensible Authentication 319 Protocol (EAP)", RFC 3748, 320 June 2004. 322 [RFC4120] Neuman, C., Yu, T., Hartman, S., 323 and K. Raeburn, "The Kerberos 324 Network Authentication Service 325 (V5)", RFC 4120, July 2005. 327 [RFC4137] Vollbrecht, J., Eronen, P., 328 Petroni, N., and Y. Ohba, "State 329 Machines for Extensible 330 Authentication Protocol (EAP) Peer 331 and Authenticator", RFC 4137, 332 August 2005. 334 [RFC6113] Hartman, S. and L. Zhu, "A 335 Generalized Framework for Kerberos 336 Pre-Authentication", RFC 6113, 337 April 2011. 339 Authors' Addresses 341 Alejandro Perez Mendez 342 University of Murcia 344 EMail: alex@um.es 346 Josh Howlett 347 Janet 349 EMail: josh.howlett@ja.net