idnits 2.17.1 draft-perez-abfab-eap-gss-preauth-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (Mar 2012) is 4423 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Assertion' is mentioned on line 349, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-abfab-aaa-saml-02 == 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 == Outdated reference: A later version (-06) exists of draft-perez-radext-radius-fragmentation-01 == Outdated reference: A later version (-18) exists of draft-sakane-dhc-dhcpv6-kdc-option-13 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ABFAB A. Perez-Mendez 3 Internet-Draft R. Marin-Lopez 4 Intended status: Experimental F. Pereniguez-Garcia 5 Expires: September 2, 2012 G. Lopez-Millan 6 University of Murcia 7 Mar 2012 9 GSS-EAP pre-authentication for Kerberos 10 draft-perez-abfab-eap-gss-preauth-01 12 Abstract 14 This draft defines an alternative to the standard cross-realm 15 operation in Kerberos, to allow users from an organization can obtain 16 a TGT from the KDC of a different one, both belonging to the same 17 AAA-based federation. This proposal makes use of the GSS-API pre- 18 authentication for Kerberos and the GSS-API Mechanism for the 19 Extensible Authentication Protocol to carry out the required 20 functionality. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 2, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Elements of the architecture . . . . . . . . . . . . . . . . . 3 59 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Discovery of the KDC . . . . . . . . . . . . . . . . . . . 4 61 3.2. Pre-authentication with the KDC . . . . . . . . . . . . . 4 62 3.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 8 63 3.4. Access to the Application Service . . . . . . . . . . . . 10 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 4.1. AAA/EAP key management in Kerberos . . . . . . . . . . . . 10 66 4.2. Trust relationships . . . . . . . . . . . . . . . . . . . 11 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 6. Normative References . . . . . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 71 1. Introduction 73 Kerberos [RFC4120] is becoming one of the most widely deployed 74 protocols for authentication and key distribution, as it is 75 integrated in different operating systems and network applications 76 (FTP, SSH, HTTP...). However, Kerberos usage is typically used to 77 control the access of the subscribers of a single organization, since 78 Kerberos multi-domain (cross-realm) infrastructures are not usually 79 deployed. This draft aims to provide an alternative to the typical 80 cross-realm operation in Kerberos by making use of existing 81 Authentication, Authorization and Accounting (AAA) infrastructures, 82 the Extensible Authentication Protocol (EAP) [RFC3748] for 83 authentication and the SAML [OASIS.saml-core-2.0-os] and XACML 84 [OASIS.xacml-2.0-core-spec-os] for authorization. 86 Since organizations typically deploy AAA infrastructures for 87 controlling the access to services (especially network access 88 service) in federated networks, the lack of a correct integration 89 between Kerberos and AAA infrastructures limits the service access 90 based on Kerberos only to service provider's subscribers, defeating 91 the purpose of the network federations: to allow any end user in the 92 federation to access any service deployed within it. In this 93 document, we define a unified architecture to integrate existing AAA 94 infrastructures with the service access control based on Kerberos. 95 Specifically, we propose the user to perform a pre-authentication 96 process with the visited KDC based on EAP, combining the use of the 97 the GSS-API pre-authentication for Kerberos 98 [I-D.perez-krb-wg-gss-preauth] and the GSS-API Mechanism for the 99 Extensible Authentication Protocol [I-D.ietf-abfab-gss-eap]. 100 Additionally, this solution also introduces authorization management 101 based on the SAML and XACML standards. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 2. Elements of the architecture 111 Brief description of the elements in the proposed architecture. 113 o End User. Integrates the functionality of Kerberos client, GSS 114 initiator and EAP peer. 116 o KDC. Integrates the functionality of Kerberos KDC, GSS acceptor 117 and EAP authenticator. 119 o AAA server. Integrates the functionality of the EAP server. 121 o Identity Provider. Generates authentication statements upon a 122 request from the AAA server and attribute statements upon a 123 request from the KDC. 125 o Policy Decision Point (PDP). Manages the set of access control 126 policies for the domain of the KDC and takes authorization 127 decisions based on the provided information. 129 o MetaData Service (MDS). Maintains a database of every service 130 metadata within the federation. The MDS can be queried by any 131 member of the federation to obtain information about other 132 member's public service [OASIS.saml-metadata-2.0-os]. 134 o Application Server. Provides a service valuable to the End User, 135 whose access is controlled by means of the Kerberos protocol. 137 3. Operation 139 3.1. Discovery of the KDC 141 In federated environments, where users move between different 142 organizations, the specific location of the KDC in any visited domain 143 should by dynamically discovered by the End User. This may be 144 achieved by the use of DNS SRV RR queries as defined in [RFC4120] or 145 the DHCPv6 protocol as defined in [I-D.sakane-dhc-dhcpv6-kdc-option]. 147 3.2. Pre-authentication with the KDC 149 Once the KDC location is known by the End User, the pre- 150 authentication process is performed as depicted (in a very simplified 151 way) in Figure 1. A detailed description of these steps is provided 152 following. 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Visited | | Home | 156 | Organization | | Organization | 157 | +-+-+-+ +-+-+-+ | | +-+-+-+ +-+-+-+ | 158 | | EU | | KDC | | | | AAA | | IdP | | 159 | +-+-+-+ +-+-+-+ | | +-+-+-+ +-+-+-+ | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | | | | 162 |AS_REQ(PA-GSS-TOK(EAP-Res))) | | 163 |------------------->| | | 164 | |Access-Request(EAP-Req) | 165 | |----------------->| | 166 | | | | 167 | Acess-Challenge(EAP-Req) | 168 | |<-----------------| | 169 | | | | 170 | KRB_ERROR(MORE_PRAUTH_NEEDED, | | 171 | PA-FX-COOKIE, | | 172 | PA-GSS-TOK(EAP-Req)) | | 173 |<-------------------| | | 174 | | | | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 176 | REPEAT N-TIMES UNTIL EAP METHOD IS COMPLETED | | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 178 | | | | 179 |AS_REQ(PA-GSS-TOK(EAP-Res), | | 180 | PA-FX-COOKIE) | | 181 |------------------->| | | 182 | |Access-Request(EAP-Res) | 183 | |----------------->| | 184 | | |AuthnReq(username) 185 | | |---------------->| 186 | | | | 187 | | | SAML Assertion| 188 | | |<----------------| 189 | | Access-Accept | | 190 | |(EAP-Succ,Assertion,MSK) | 191 | |<-----------------| | 192 | | | | 193 | +-+-+-+-+-+-+-+-+-+-+ | | 194 | | Derive reply-key | | | 195 | | based on MSK | | | 196 | +-+-+-+-+-+-+-+-+-+-+ | | 197 | | | | 198 |AS_REP(PA-GSS-TOK(EAP-Succ), | | 199 | enc-part, | | 200 | TGT[Assertion]) | | 201 |<-------------------| | | 202 Figure 1: EAP-GSS pre-authentication with the KDC 204 1. Kerberos client calls to GSS_Init_sec_ctx() to obtain the a GSS 205 token to be sent to the KDC. Details on this process are 206 described in [I-D.perez-krb-wg-gss-preauth]. The selected GSS 207 mechanism is GSS-EAP, defined in [I-D.ietf-abfab-gss-eap]. 209 2. The GSS_Init_sec_ctx() call is treated by the GSS-EAP mechanism, 210 which generates the actual GSS token following the 211 specifications provided in [I-D.ietf-abfab-gss-eap]. Usually, 212 this GSS token will contain an EAP response message. At this 213 level, the GSS-EAP mechanism will use the EAP identity of the 214 End User. 216 3. Once the Kerberos client has obtained the GSS token, it is 217 encapsulated into a PA-GSS-TOKEN pre-authentication data element 218 and included into the KRB_AS_REQ message (as specified in 219 [I-D.perez-krb-wg-gss-preauth]). The user may belong to a 220 different organization than the KDC and, therefore, its client 221 name may not be found in the KDC's local database. To avoid the 222 generation of an error of type KDC_ERR_C_PRINCIPAL_UNKNOWN, the 223 Kerberos client sets the cname field of the KRB_AS_REQ message 224 to a new fixed value, WELLKNOWN:FEDERATED, following the model 225 proposed in [RFC6111]. In this manner, the KDC is warned that 226 the End User belongs to the federation and not local 227 verification of credentials should be done. 229 4. On the reception of the KRB_AS_REQ message, the KDC omits the 230 local database lookup of the client name, since WELLKNOWN: 231 FEDERATED is indicated. Then, the KDC calls the 232 GSS_Accept_sec_ctx() function, as described in 233 [I-D.perez-krb-wg-gss-preauth], to process the GSS token 234 received in the PA-GSS-TOKEN pre-authentication data element. 236 5. The GSS_Accept_sec_ctx() call is treated by the GSS-EAP 237 mechanism, which extracts EAP packet contained on it, determines 238 the AAA server where it should be forwarded and encapsulates it 239 into the proper AAA protocol (i.e. RADIUS or Diameter), as 240 described in [I-D.ietf-abfab-gss-eap]. 242 6. The AAA server processes the EAP packet and generates a new EAP 243 Request for the End User. If the response is an EAP Success, 244 the process continues in step 10. Otherwise, the AAA server 245 encapsulates the EAP packet into a AAA message and sends it to 246 the KDC. Note: For simplicity, AAA proxies are not considered. 247 More details are provided in [I-D.ietf-abfab-gss-eap]. 249 7. The GSS-EAP mechanism in the KDC processes the AAA message and 250 generates a new GSS token with the obtained EAP request. 252 8. As a result of the call to the GSS_Accept_sec_ctx() function, 253 the KDC obtains the GSS token, which is encapsulated into a new 254 PA-GSS-TOKEN element and sent to the Kerberos client into a 255 KRB_ERR message with code MORE_PREAUTH_DATA_REQUIRED as 256 specified in [I-D.perez-krb-wg-gss-preauth]. This KRB_ERR 257 message also contains a PA-FX-COOKIE element where the KDC 258 introduces the value of the context handle obtained after the 259 call. 261 9. The Kerberos client processes the KRB_ERR message, obtains the 262 GSS token and calls to the GSS_Init_sec_ctx() function. The 263 process continues as defined in step 1. 265 10. If the AAA server determines that the authentication has been 266 completed, before sending the proper message to the KDC it 267 contacts with its local IdP to obtain an SAML Authentication 268 Statement. This is accomplished by sending a SAML AuthnRequest 269 message to the IdP, indicating the EAP identity as the value of 270 the Subject. This message is generated following the SOAP-based 271 authentication profile described in 272 [LIBERTY.idwsf-authn-svc-v2.0]. Alternatively, the IdP could be 273 collocated with the AAA server. In this case, this and the next 274 step would be omitted as the AAA server could issue the SAML 275 Assertion by itself. Another option would be that the KDC 276 generates the SAML AuthnRequest instead of the AAA server, since 277 it will be the ultimate consumer of the produced Assertion. 279 11. The IdP authenticates the user based on the trust established in 280 the organization between the AAA server (acting as the attester) 281 and the IdP, and generates a SAML Assertion in response. This 282 Assertion, which contains an Authentication Statement, will be 283 used to refer to this authentication process in the future (e.g. 284 to request attributes). 286 12. The AAA server verifies the Authentication Statement and 287 encapsulates the Assertion into an SAML-AAA attribute, following 288 schema described in [I-D.ietf-abfab-aaa-saml]. Then it sends 289 the AAA response message to the KDC including this attribute 290 along with the EAP Success packet and the derived MSK. If the 291 assertion length is big enough to make the RADIUS packet exceed 292 the 4 KB limit, the RADIUS packet fragmentation solution 293 described in [I-D.perez-radext-radius-fragmentation] would be 294 applied. 296 13. The GSS-EAP mechanism processes the AAA response as described in 297 [I-D.ietf-abfab-gss-eap]. The EAP identity is exported as 298 initiator name. This name will also include the received 299 Assertion as an attribute, following the specifications in GSS- 300 naming [I-D.ietf-kitten-gssapi-naming-exts]. The MSK is used to 301 derive the GMSK. 303 14. The KDC obtains, as a result of the last call to the 304 GSS_Accept_sec_ctx(), the final GSS token, and the initiator 305 name. As described in [I-D.perez-krb-wg-gss-preauth], the token 306 is encapsulated into a PA-GSS-TOKEN, while the initiator name is 307 used as the cname field in both, the KRB_AS_REP message and the 308 TGT. Furthermore, the KDC obtains, using the 309 GSS_Get_name_attribute(), the SAML Assertion. This Assertion is 310 included in a new authorization data element (ADE) into the 311 authorization_data field of the TGT. By this way, the TGS will 312 receive the Assertion in the KRB_TGS_REQ. Following the 313 specifications in [I-D.perez-krb-wg-gss-preauth], the KDC uses 314 the GSS_Pseudo_random() call to generate the reply key with 315 which encrypting the enc-part of the KRB_AS_REP message 316 (Replacing-reply-key facility) 318 15. Finally, the Kerberos client processes the KRB_AS_REP message. 319 As a first step, the PA-GSS-TOKEN is processed as specified in 320 [I-D.perez-krb-wg-gss-preauth]. The GSS-EAP mechanism extracts 321 the EAP packet from the token and derives the MSK and the GMSK. 322 The Kerberos client uses the GSS_Pseudo_random() call to 323 generate the reply key, and decrypts the enc-part of the 324 KRB_AS_REP message. After that, the Kerberos client stores the 325 TGT into the credentials cache associated to the identity 326 indicated in the cname field. 328 3.3. Authorization 330 With the TGT, the End User can request Service Tickets (ST) for the 331 different services in the domain by means of a TGS exchange. In this 332 process, the TGS can take an authorization decision based on the 333 identity information of the End User, thanks to the authorization 334 information (i.e. Assertion) the AS included in the TGT. Both the 335 service and the client are completely agnostic of this authorization 336 process, thus they do not require changes. A simplification of the 337 process is outlined in Figure 2. A detailed description is provided 338 below. 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ 341 | Visited | | Home | 342 | Organization | Federation | Organizat | 343 | | | | 344 | +-+-+-+ +-+-+-+ +-+-+-+ | +-+-+-+ | +-+-+-+ | 345 | | EU | | KDC | | PDP | | | MDS | | | IdP | | 346 | +-+-+-+ +-+-+-+ +-+-+-+ | +-+-+-+ | +-+-+-+ | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+ 348 | TGS_REQ | | | | 349 |(sname,TGT[Assertion]) | | | 350 |---------------->| | | | 351 | | MDS Query (user's home)| | 352 | |----------------------->| | 353 | | | | | 354 | | MDS Response (IdP) | | 355 | |<-----------------------| | 356 | | | | | 357 | |Attribute Query(pseudonym) | 358 | |------------------------------------>| 359 | | | | | 360 | |Response(attributes) | | 361 | |<------------------------------------| 362 | | | | | 363 | |Authz Decision Query | | 364 | |(sname, attributes) | | 365 | |------------>| | | 366 | | | | | 367 | |Authz Decision Resp | | 368 | | (decision) | | | 369 | |<------------| | | 370 | TGS_REP (ST) | | | | 371 |<----------------| | | | 372 | | | | | 374 Figure 2: Authorization process 376 1. The Kerberos client creates a new KRB_TGS_REQ message, following 377 what is specified in [RFC4120]. This message transports the TGT 378 obtained during the authentication phase. 380 2. The TGS (KDC) processes the KRB_TGS_REQ message as usual. When 381 the TGS processes the authorization data element (ADE) containing 382 the Assertion, it contacts with the federation's MDS to obtain 383 the location of the End User's home IdP. This information is 384 required in order to contact with the End User's IdP to request 385 some user attributes to perform the authorization decision. 387 3. With the metadata information the TGS is able to contact with the 388 End User's IdP directly. This contact is performed by means of a 389 SAML Attribute Query message [OASIS.saml-core-2.0-os], indicating 390 the pseudonym of the user included in the assertion as the 391 Subject. 393 4. The IdP recognises the pseudonym and provides the requested 394 attributes in a SAML Response containing one or more SAML 395 Attribute Statements. 397 5. The TGS provides the gathered attributes to the local PDP, along 398 with information about the resource (sname) and the action to be 399 performed, using an XACML AuthzDecision Query message. With this 400 information the PDP queries its local policy database and takes 401 an authorization decision. This decision is provided to the TGS 402 using a XACML AuthzDecision Response message. 404 6. If the decision is PERMIT, the TGS issues the ticket for the 405 requested service. Otherwise, if the decision is DENY, the 406 client is provided with a Kerberos error message and the ST is 407 not delivered. 409 There is one way of simplifying the authorization work-flow by 410 allowing IdPs to return SAML Attribute Statements during the first 411 step of the authorization phase. In this case, the AAA server will 412 receive a SAML Attribute Statement holding the end user attributes 413 along with the Authentication Statement in the Assertion. This way 414 the MDS Query and the Attribute Query exchanges could be omitted, 415 since the Assertion already contains the required information. 416 However, this approach does not allow the IdP to discriminate what 417 attributes should be returned based on the preferred services, 418 because they are known in the KRB_TGS exchange. 420 3.4. Access to the Application Service 422 With the ST, the user can access the Application Service using 423 standard Kerberos, as described in [RFC4120] 425 4. Security Considerations 427 4.1. AAA/EAP key management in Kerberos 429 The use of EAP for Kerberos pre-authentication has security 430 implications, specially in key distribution and management. The 431 security analysis described in [RFC4962] and [RFC5247] are applicable 432 here. Indeed, intermediate AAA proxies placed between the KDC and 433 the home AAA server can observe the distributed MSK that will be used 434 to derive the Kerberos secret key. 436 However, the trust model in federated environments assumes that 437 intermediate AAA proxies are trusted entities. Moreover, as 438 [RFC4962] explains, some key wrapping techniques can be applied to 439 provide confidentiality, integrity and replay protection to the 440 distributed key material between each pair of AAA entities (e.g. AAA 441 proxies). 443 4.2. Trust relationships 445 This work assumes the existence of a transitive trust relationship 446 for authentication between the involved domains thanks to the 447 deployed AAA infrastructure. Besides, regarding the authorization 448 process, it is generally assumed the use of a direct trust 449 relationship, allowing the protection of SAML messages directly 450 between domains (step 2 and 3). Usually PKI architecture are used to 451 deploy this trust. Following this approach IdPs and KDCs should be 452 fed with cryptographic material. 454 Nevertheless, other approach can be followed to avoid the deployment 455 of an additional infrastructure (e.g. PKI). We could leverage the 456 transitive trust relationship defined by the deployed AAA 457 infrastructure to perform safely the attribute recovery process by 458 means of the AAA protocol. In this case, it is necessary to define 459 new extensions to standard AAA protocols. 461 5. IANA Considerations 463 This document has no actions for IANA. 465 6. Normative References 467 [I-D.ietf-abfab-aaa-saml] 468 Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding 469 and Profiles for SAML", draft-ietf-abfab-aaa-saml-02 (work 470 in progress), October 2011. 472 [I-D.ietf-abfab-gss-eap] 473 Howlett, J. and S. Hartman, "A GSS-API Mechanism for the 474 Extensible Authentication Protocol", 475 draft-ietf-abfab-gss-eap-04 (work in progress), 476 October 2011. 478 [I-D.ietf-kitten-gssapi-naming-exts] 479 Johansson, L., Williams, N., Hartman, S., and S. 481 Josefsson, "GSS-API Naming Extensions", 482 draft-ietf-kitten-gssapi-naming-exts-12 (work in 483 progress), December 2011. 485 [I-D.perez-krb-wg-gss-preauth] 486 Perez-Mendez, A., Pereniguez-Garcia, F., Lopez-Millan, G., 487 and R. Lopez, "GSS-API pre-authentication for Kerberos", 488 draft-perez-krb-wg-gss-preauth-01 (work in progress), 489 January 2012. 491 [I-D.perez-radext-radius-fragmentation] 492 Perez-Mendez, A., Lopez, R., Pereniguez-Garcia, F., Lopez- 493 Millan, G., Lopez, D., and A. DeKok, "Support of 494 fragmentation of RADIUS packets", 495 draft-perez-radext-radius-fragmentation-01 (work in 496 progress), February 2012. 498 [I-D.sakane-dhc-dhcpv6-kdc-option] 499 Sakane, S. and M. Ishiyama, "Kerberos Options for DHCPv6", 500 draft-sakane-dhc-dhcpv6-kdc-option-13 (work in progress), 501 December 2011. 503 [LIBERTY.idwsf-authn-svc-v2.0] 504 Hodges, J., Aarts, R., Madsen, P., and S. Cantor, "Liberty 505 ID-WSF Authentication, Single Sign-On, and Identity 506 Mapping Services Specification", Liberty Alliance liberty- 507 idwsf-authn-svc-v2.0, 2006. 509 [OASIS.saml-core-2.0-os] 510 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 511 "Assertions and Protocol for the OASIS Security Assertion 512 Markup Language (SAML) V2.0", OASIS Standard saml-core- 513 2.0-os, March 2005. 515 [OASIS.saml-metadata-2.0-os] 516 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 517 "Metadata for the Assertions and Protocol for the OASIS 518 Security Assertion Markup Language (SAML) V2.0", OASIS 519 Standard saml-metadata-2.0-os, March 2005. 521 [OASIS.xacml-2.0-core-spec-os] 522 Moses, T., "eXtensible Access Control Markup Language 523 (XACML) Version 2.0", OASIS 524 Standard xacml-2.0-core-spec-os, February 2005. 526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, March 1997. 529 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 530 Levkowetz, "Extensible Authentication Protocol (EAP)", 531 RFC 3748, June 2004. 533 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 534 Kerberos Network Authentication Service (V5)", RFC 4120, 535 July 2005. 537 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 538 Authorization, and Accounting (AAA) Key Management", 539 BCP 132, RFC 4962, July 2007. 541 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 542 Authentication Protocol (EAP) Key Management Framework", 543 RFC 5247, August 2008. 545 [RFC6111] Zhu, L., "Additional Kerberos Naming Constraints", 546 RFC 6111, April 2011. 548 Authors' Addresses 550 Alejandro Perez-Mendez (Ed.) 551 University of Murcia 552 Campus de Espinardo S/N, Faculty of Computer Science 553 Murcia, 30100 554 Spain 556 Phone: +34 868 88 46 44 557 Email: alex@um.es 559 Rafa Marin-Lopez 560 University of Murcia 561 Campus de Espinardo S/N, Faculty of Computer Science 562 Murcia, 30100 563 Spain 565 Phone: +34 868 88 85 01 566 Email: rafa@um.es 567 Fernando Pereniguez-Garcia 568 University of Murcia 569 Campus de Espinardo S/N, Faculty of Computer Science 570 Murcia, 30100 571 Spain 573 Phone: +34 868 88 78 82 574 Email: pereniguez@um.es 576 Gabriel Lopez-Millan 577 University of Murcia 578 Campus de Espinardo S/N, Faculty of Computer Science 579 Murcia, 30100 580 Spain 582 Phone: +34 868 88 85 04 583 Email: gabilm@um.es