idnits 2.17.1 draft-howlett-radsec-knp-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 : ---------------------------------------------------------------------------- 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 date (October 21, 2011) is 4571 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-09) exists of draft-ietf-abfab-gss-eap-03 == Outdated reference: A later version (-12) exists of draft-ietf-radext-radsec-09 == Outdated reference: A later version (-16) exists of draft-ietf-emu-chbind-10 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Howlett 3 Internet-Draft JANET(UK) 4 Intended status: Informational S. Hartman 5 Expires: April 23, 2012 Painless Security 6 October 21, 2011 8 Key Negotiation Protocol (KNP) 9 draft-howlett-radsec-knp-02 11 Abstract 13 The Key Negotiation Protocol enables an untrusting RADIUS client and 14 RADIUS server to derive a key by reference to a mutually trusted 15 actor called the Introducer. This key may subsequently be used for 16 one of two purposes. First, it can credential a TLS PSK ciphersuite 17 applied to a RadSec connection between the RADIUS client and RADIUS 18 server; or secondly, to establish a trust relationship between the 19 RADIUS client and a second Introducer that is trusted by the first 20 Introducer. 22 The composition of these capabilities enables a RADIUS client to 23 establish a RadSec connection with any RADIUS server with whom it 24 shares a direct or indirect trust relationship via one or more 25 Introducers. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 23, 2012. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Conventions used in this document . . . . . . . . . . . . . . 5 65 5. The KNP Actors . . . . . . . . . . . . . . . . . . . . . . . . 5 66 6. Relationships With Other Protocols . . . . . . . . . . . . . . 6 67 6.1. Relationship to EAP . . . . . . . . . . . . . . . . . . . 6 68 6.2. Relationship to RADIUS . . . . . . . . . . . . . . . . . . 7 69 6.3. Relationship to the GSS API . . . . . . . . . . . . . . . 7 70 6.4. Relationship to the HTTP . . . . . . . . . . . . . . . . . 7 71 7. Key Negotiation Protocol . . . . . . . . . . . . . . . . . . . 7 72 7.1. Operation Independent Flow . . . . . . . . . . . . . . . . 8 73 7.2. The Credentialing Operation . . . . . . . . . . . . . . . 10 74 7.3. The Introduction Operation . . . . . . . . . . . . . . . . 10 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 78 11. Normative References . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 TLS encryption for RADIUS (RadSec) [I-D.ietf-radext-radsec] provides 83 a mechanism for securing the communication between a RADIUS [RFC2865] 84 client and server on the transport layer by using TLS [RFC5246]. 86 RadSec mandates the use of one of the [RFC5246] ciphersuites and 87 recommends the use of two other ciphersuites specified in that 88 document. However any ciphersuite, including the TLS Pre-Shared Key 89 (PSK) ciphersuites [RFC4279], may be used providing that it supports 90 encryption. 92 The Key Negotiation Protocol enables an untrusting RADIUS client and 93 RADIUS server to derive a key by means of a mutually trusted actor 94 called the Introducer. This key may subsequently for two purposes. 96 First, the key can be used to credential a TLS PSK ciphersuite when 97 applied to a RadSec connection between the RADIUS client and RADIUS 98 server, permitting a trusted exchange of RADIUS messages in the 99 absence of a pre-existing relationship between the RADIUS client and 100 RADIUS server. This is described as "Credentialing". 102 Secondly, the key can used as a credential by a RADIUS client to 103 establish a trust relationship with a second Introducer that happens 104 to be trusted by the first Introducer. This is described as 105 "Introduction". 107 The composition of Credentialing and Introduction enables a RADIUS 108 client to establish a RadSec connection with any RADIUS server with 109 whom it shares an indirect trust relationship via one or more 110 Introducers. 112 2. Motivation 114 The KNP is motivated by the following requirements: 116 o In the case of a non-federated RADIUS environment where a RADIUS 117 client and RADIUS AS.server shares a direct trust relationship, a 118 shared secret credential is used as the trust anchor between these 119 systems. In transitioning to the use of RadSec, it may be more 120 convenient if these systems are able to continue using the 121 existing credential technology rather than introduce a new 122 credential technology (such as X.509 certificates), as this may 123 impose significant changes to operational practices (such as 124 deploying a Public Key Infrastructure). 126 o In the case of a federated RADIUS environment where RADIUS clients 127 and RADIUS servers are associated with different domains, 128 transitioning to the use of RadSec may impose a requirement to 129 distribute and manage multiple trust anchors. It may be more 130 convenient if the systems within these domains were able to use a 131 single trust anchor for RADIUS systems in all other domains, in 132 addition to those systems within its own domain. This may 133 facilitate the scaling of large heterogeneous RADIUS environments 134 where it may be difficult - for technical and/or administrative 135 reasons - to impose support for even a small set of trust anchors. 137 o The use of multiple trust anchors within complex federated 138 environments may impede essential trust management functions such 139 as timely revocation. Reducing the number of trust anchors may 140 therefore improve trust management within these environments, 141 particularly if it can be reduced to a single trust anchor. 143 3. Overview 145 The Key Negotiation Protocol (KNP) enables a RADIUS client and RADIUS 146 server that do not share a direct trust relationship to derive a 147 shared key by virtue of both systems having a trust relationship with 148 an EAP server called the Introducer. This key may be used for the 149 following purposes: 151 1. Credentialing: the RADIUS client and RADIUS server can use the 152 key to credential a TLS PSK ciphersuite applied to a RadSec 153 connection. 155 2. Introduction: a credential can be derived from the key that can 156 be used to authenticate the RADIUS client against a second 157 Introducer that is trusted by the first Introducer. 159 The composition of these capabilities enables a RADIUS client to 160 derive a key that can be used to credential a RadSec connection with 161 any other RADIUS server with whom it shares a common Introducer and, 162 through transitivity, any number of intermediate Introducers. 164 This transitivity of trust between a RADIUS client and RADIUS server 165 across a chain of intermediate Introducers may appear very similar to 166 the use of RADIUS proxies to establish a chain of trust between a 167 RADIUS client and RADIUS server. There is however a very significant 168 difference: 170 o In the case of RADIUS proxy, the RADIUS messages emitted by the 171 RADIUS client and RADIUS server must transit through the 172 intermediate RADIUS proxy(ies). There is no end-to-end 173 relationship between the RADIUS client and RADIUS server, either 174 in terms of connectivity or trust. 176 o In the case of KNP, the RADIUS messages are able to transit 177 directly between RADIUS client and RADIUS server. The path of 178 transmissions between these systems is therefore entirely 179 decoupled from the path of trust . There is an end-to-end 180 relationship between the RADIUS client and RADIUS server, both in 181 terms of connectivity and trust. 183 The use of RADIUS Proxies and Introducers are not mutually exclusive; 184 deployers may choose to use both. 186 4. Conventions used in this document 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in RFC 2119 [RFC2119]. 192 5. The KNP Actors 194 In the KNP, the RADIUS client and RADIUS server do not initially 195 share a trust relationship. Instead, these actors share a trust 196 relationship with a mutually trusted third party known as the 197 "Introducer". 199 Figure 1 below depicts the trust relationships for a RADIUS client, 200 RADIUS server and Introducer before the KNP has been invoked. 202 Introducer 203 /\ 204 / \ 205 / \ 206 RADIUS RADIUS 207 Client Server 209 Figure 1 211 Figure 2 below depicts the new trust relationship between the RADIUS 212 client, RADIUS server and Introducer after the KNP has been invoked. 214 Introducer 215 /\ 216 / \ 217 / \ 218 RADIUS------RADIUS 219 Client Server 221 Figure 2 223 Figure 3 below depicts the flow of RADIUS packets from the RADIUS 224 client to the RADIUS server using the new trust relationship. 226 Introducer 228 RADIUS ---> RADIUS 229 Client Server 231 Figure 3 233 Note that the RADIUS messages are not routed by the Introducer, as 234 they would in the case of a RADIUS Proxy. Instead, they flow 235 directly from RADIUS client to RADIUS server. 237 6. Relationships With Other Protocols 239 The KNP builds on a variety of protocols. This section describes the 240 relationship of KNP to these. 242 6.1. Relationship to EAP 244 In the KNP the RADIUS client assumes the role of an EAP peer. In 245 this role, it attempts to authenticate against a RADIUS server that 246 assumes the role of a pass-through EAP authenticator. An EAP server 247 acts as the Introducer. 249 The KNP enables all three actors - RADIUS client (EAP peer), RADIUS 250 server (EAP authenticator) and Introducer (EAP server) - to establish 251 a common view of their mutual relationships as described by the EAP 252 names and keys that the EAP exchange yields, using the norms 253 established by the EAP Key Management Framework [RFC5247]. 255 The RADIUS client must possess an EAP credential for the Introducer, 256 allowing mutual authentication of both parties. 258 Figure 4 below depicts the relationships between these actors: 260 Introducer 261 /\ 262 / \ 263 / \ 264 RADIUS RADIUS 265 Client Server 266 (possessing an EAP 267 credential for 268 the Introducer) 269 Figure 4 271 6.2. Relationship to RADIUS 273 The RADIUS server uses the RADIUS protocol to forward the EAP 274 transaction to the Introducer. 276 The RADIUS server must share a RADIUS secret with the Introducer, 277 allowing mutual authentication of both actors. 279 Figure 5 below depicts the relationships between these actors: 281 Introducer 282 /\ 283 / \ 284 / \ 285 RADIUS RADIUS 286 Client Server 287 (possessing an EAP (possessing a RADIUS 288 credential for secret for 289 the Introducer) the Introducer) 291 Figure 5 293 6.3. Relationship to the GSS API 295 The KNP builds on the GSS API [RFC2743] framework by using the GSS 296 EAP mechanism [I-D.ietf-abfab-gss-eap] and EAP [RFC3748]. The GSS 297 EAP tokens are transported between the RADIUS client and RADIUS 298 server using the HTTP Negotiate authentication scheme [RFC4559]. 300 6.4. Relationship to the HTTP 302 The KNP uses HTTP to transport its request and response protocol 303 messages between the RADIUS Client and RADIUS server. 305 7. Key Negotiation Protocol 307 As described previously, the KNP provides two operations: 308 Credentialing and Introduction. 310 The KNP provides these operations using a common protocol pattern. 311 This pattern is applied against two types of Target actor, depending 312 on the operation in question: 314 o In the case of Credentialing, the Target actor is a RADIUS server. 315 If Credentialing is successful, the RADIUS client and RADIUS 316 server will derive a common PSK that can be applied with a TLS-PSK 317 ciphersuite and RadSec. 319 o In the case of Introduction, the Target actor is an Introducer. 320 If an Introduction is successful, the RADIUS client and Introducer 321 will derive an EAP credential that can subsequently be used for 322 subsequent Credentialing or Introduction operations. 324 For both operations it is essential that all three actors - RADIUS 325 Client, Introducer and Target (whether a RADIUS server, in the case 326 of Credentialing, or another Introducer, in the case of Introduction) 327 - are able to authorise the claims that the other actors make about 328 their respective names. These claims are validated using different 329 processes for each relationship; these are summarised in Figure 6 330 below. 332 +===============+===============+==================+===============+ 333 | Subject | Relying Party | Process | Evidence from | 334 +===============+===============+==================+===============+ 335 | RADIUS Client | Introducer | GSS EAP | EAP method | 336 +---------------+---------------+ authentication | w/ qualifying | 337 | Introducer | RADIUS Client | |Security Claims| 338 +===============+===============+==================+===============+ 339 | Introducer | Target | RADIUS | RADIUS | 340 +---------------+---------------+ authentication | shared | 341 | Target | Introducer | | secret | 342 +===============+===============+==================+===============+ 343 | Target | RADIUS | Channel bindings | Assertion by | 344 | | Client | | Introducer | 345 +---------------+---------------+------------------+---------------+ 346 | RADIUS | Target | RADIUS attribute | Assertion by | 347 | Client | | | Introducer | 348 +===============+===============+==================+===============+ 349 Figure 6 351 7.1. Operation Independent Flow 353 The RADIUS Client invokes the KNP by establishing an HTTP connection 354 with the Target's KNP end-point. 356 The RADIUS Client MUST use the GSS EAP mechanism 357 [I-D.ietf-abfab-gss-eap] to authenticate to the Introducer, 358 requesting mutual authentication from the GSS layer. 360 The RADIUS Client, Target and Introducer MUST support EAP channel 361 bindings [I-D.ietf-emu-chbind]. The Introducer MUST use validate the 362 EAP channel bindings [I-D.ietf-emu-chbind] provided by the RADIUS 363 Client. If the channel binding verification fails, the Introducer 364 MUST reject the authentication. 366 The completion of the EAP method exchange results in the derivation 367 of an EAP MSK known only to the RADIUS Client and Introducer and 368 Peer-Id(s) and Server-Id(s) identifying these respectively. The 369 Introducer MUST replicate the keying material and Server-Id to the 370 Target. 372 The RADIUS Client and Target, in possession of the EAP MSK, create a 373 GSS-API security context as described in section 6 of 374 [I-D.ietf-abfab-gss-eap]. 376 The RADIUS Client POSTs a key negotiation request, encoded as an HTML 377 form dataset, to the Target. This request contains a set of 378 operation-specific controls that specifies key negotiation 379 parameters. A key negotiation request MUST contain the following 380 controls: 382 o Version: the version of the KNP. 384 o Request-Identifier: a unique alphanumeric identifier for the 385 request. 387 o Requestor-Name: the requestor's GSS EAP initiator name. 389 o Operation-Type: the type of operation. 391 o Authenticator-Type: message authentication algorithm. 393 o Authenticator-Value: message authenticator value. 395 The Target extracts the key negotiation parameters and assesses their 396 compliance to the Target's key negotiation policies. The Target MUST 397 return an operation-specific document providing information about the 398 resulting key negotiation context. 400 o Version: the version of the KNP. 402 o Request-Identifier: the identifier for the request that this is a 403 reponse to. 405 o Responder-Name: the requestor's GSS EAP acceptor name. 407 o Operation-Type: the type of operation. 409 o Status-Code: a status code. 411 o Expires-After: a timestamp indicating the time of expiration. 413 o Authenticator-Type: message authentication algorithm. 415 o Authenticator-Value: message authenticator value. 417 TODO: consider use of SAML authentication assertion instead? 419 The RADIUS server and client SHOULD cache the GSS context until 420 expiry of the GSS context. However, either party MAY delete a GSS 421 context at any time. If a GSS context is deleted, any operation- 422 specific derived materials SHOULD also be deleted, although such 423 materials MAY be retained for auditing purposes. 425 7.2. The Credentialing Operation 427 This section describes the Credentialing operation-specific 428 extensions to the general KNP flow. 430 The RADIUS Client MUST specify the following control values within 431 the key negotiation request: 433 o Operation-Type: Credentialing 435 The PSK identity and value shall be outputs of GSS_Pseudo_random() 436 [RFC4401] using the Pseudo-Random Function defined for the GSS EAP 437 mechanism [I-D.ietf-abfab-gss-eap]. 439 For the PSK identity, the prf_in input string MUST be prepended with 440 the string "tls-psk-knp-identity"; desired_out_len MUST be set to 128 441 octets. 443 For the PSK value, the prf_in input string MUST be prepended with the 444 string "tls-psk-knp-value"; desired_out_len MUST be set to 64 octets. 446 Note: these output values should use base64 encoding 448 7.3. The Introduction Operation 450 This section describes the Introduction operation-specific extensions 451 to the general KNP flow. 453 The RADIUS Client MUST specify the following control values within 454 the key negotiation request: 456 o Operation-Type: Introduction" 458 The EAP identity and credential shall be outputs of 459 GSS_Pseudo_random() [RFC4401] using the Pseudo-Random Function 460 defined for the GSS EAP mechanism [I-D.ietf-abfab-gss-eap]. 462 For the EAP identity, the prf_in input string MUST be prepended with 463 the string "tls-psk-eap-identity"; desired_out_len MUST be set to 128 464 octets. The output string MUST be appended with the realm of the 465 Introducer to form an NAI. 467 For the EAP credential, the prf_in input string MUST be prepended 468 with the string "tls-psk-eap-psk"; desired_out_len MUST be set to 64 469 octets. 471 Note: these output values should use base64 encoding. 473 8. Security Considerations 475 TODO 477 9. IANA Considerations 479 TODO 481 10. Acknowledgements 483 TODO 485 11. Normative References 487 [RFC2119] Bradner, S., "Key words for use in RFCs to 488 Indicate Requirement Levels", BCP 14, 489 RFC 2119, March 1997. 491 [RFC2743] Linn, J., "Generic Security Service 492 Application Program Interface Version 2, 493 Update 1", RFC 2743, January 2000. 495 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. 496 Simpson, "Remote Authentication Dial In 497 User Service (RADIUS)", RFC 2865, 498 June 2000. 500 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., 501 Carlson, J., and H. Levkowetz, "Extensible 502 Authentication Protocol (EAP)", RFC 3748, 503 June 2004. 505 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared 506 Key Ciphersuites for Transport Layer 507 Security (TLS)", RFC 4279, December 2005. 509 [RFC4401] Williams, N., "A Pseudo-Random Function 510 (PRF) API Extension for the Generic 511 Security Service Application Program 512 Interface (GSS-API)", RFC 4401, 513 February 2006. 515 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, 516 "SPNEGO-based Kerberos and NTLM HTTP 517 Authentication in Microsoft Windows", 518 RFC 4559, June 2006. 520 [RFC5246] Dierks, T. and E. Rescorla, "The Transport 521 Layer Security (TLS) Protocol Version 1.2", 522 RFC 5246, August 2008. 524 [RFC5247] Aboba, B., Simon, D., and P. Eronen, 525 "Extensible Authentication Protocol (EAP) 526 Key Management Framework", RFC 5247, 527 August 2008. 529 [I-D.ietf-abfab-gss-eap] Hartman, S. and J. Howlett, "A GSS-API 530 Mechanism for the Extensible Authentication 531 Protocol", draft-ietf-abfab-gss-eap-03 532 (work in progress), October 2011. 534 [I-D.ietf-radext-radsec] Winter, S., McCauley, M., Venaas, S., and 535 K. Wierenga, "TLS encryption for RADIUS", 536 draft-ietf-radext-radsec-09 (work in 537 progress), July 2011. 539 [I-D.ietf-emu-chbind] Hartman, S., Clancy, T., and K. Hoeper, 540 "Channel Binding Support for EAP Methods", 541 draft-ietf-emu-chbind-10 (work in 542 progress), October 2011. 544 Authors' Addresses 546 Josh Howlett 547 JANET(UK) 548 Lumen House, Library Avenue, Harwell 549 Oxford OX11 0SG 550 UK 552 Phone: +44 1235 822363 553 EMail: Josh.Howlett@ja.net 554 Sam Hartman 555 Painless Security 557 EMail: hartmans-ietf@mit.edu