idnits 2.17.00 (12 Aug 2021) /tmp/idnits4757/draft-tschofenig-nsis-gist-security-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1512. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 26, 2006) is 5801 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: 'ServerKeyExchange' is mentioned on line 1197, but not defined == Missing Reference: 'EAP-Context' is mentioned on line 537, but not defined == Missing Reference: 'AAA-Context' is mentioned on line 538, but not defined == Missing Reference: 'TLS-Options' is mentioned on line 538, but not defined == Unused Reference: 'I-D.arkko-eap-service-identity-auth' is defined on line 1357, but no explicit reference was found in the text == Unused Reference: 'RFC4081' is defined on line 1434, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-funk-tls-inner-application-extension-02 -- Possible downref: Normative reference to a draft: ref. 'I-D.funk-tls-inner-application-extension' == Outdated reference: draft-ietf-nsis-ntlp has been published as RFC 5971 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. 'I-D.ietf-nsis-ntlp') ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) == Outdated reference: A later version (-04) exists of draft-ietf-nfsv4-channel-bindings-03 == Outdated reference: draft-ietf-nsis-nslp-natfw has been published as RFC 5973 == Outdated reference: draft-ietf-pana-pana has been published as RFC 5191 == Outdated reference: draft-ietf-tls-ecc has been published as RFC 4492 -- Obsolete informational reference (is this intentional?): RFC 2078 (Obsoleted by RFC 2743) -- Obsolete informational reference (is this intentional?): RFC 2222 (Obsoleted by RFC 4422, RFC 4752) -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 2630 (Obsoleted by RFC 3369, RFC 3370) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) Summary: 5 errors (**), 0 flaws (~~), 14 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS Working Group H. Tschofenig 3 Internet-Draft Siemens 4 Expires: December 28, 2006 P. Eronen 5 Nokia 6 June 26, 2006 8 Analysis of Options for Securing the Generic Internet Signaling 9 Transport (GIST) 10 draft-tschofenig-nsis-gist-security-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 28, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document investigates the different options for securing the 44 Generic Internet Signaling Transport (GIST) protocol with the goal of 45 using existing credentials, user and policy databases and other 46 security infrastructure. We examine, among other options, Transport 47 Layer Security (TLS) with X.509 PKI, Extensible Authentication 48 Protocol (EAP), and 3GPP Generic Bootstrapping Architecture (GBA). 50 Table of Contents 52 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 53 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 55 1.3. Disclaimer and Limitations . . . . . . . . . . . . . . . . 4 56 2. Transport Layer Security (TLS) with X.509 PKI . . . . . . . . 5 57 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.2. Proposal Discussion . . . . . . . . . . . . . . . . . . . 5 59 2.3. GIST API Viewpoint . . . . . . . . . . . . . . . . . . . . 6 60 2.4. GIST Protocol Viewpoint . . . . . . . . . . . . . . . . . 7 61 2.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3. Extensible Authentication Protocol (EAP) . . . . . . . . . . . 10 63 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10 64 3.2. EAP with TLS Inner Application . . . . . . . . . . . . . . 12 65 3.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 12 66 3.2.2. Proposal Discussion . . . . . . . . . . . . . . . . . 12 67 3.2.3. GIST API Viewpoint . . . . . . . . . . . . . . . . . . 12 68 3.2.4. GIST Protocol Viewpoint . . . . . . . . . . . . . . . 14 69 3.2.5. Example . . . . . . . . . . . . . . . . . . . . . . . 14 70 3.3. EAP in NSLP . . . . . . . . . . . . . . . . . . . . . . . 17 71 3.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 17 72 3.3.2. Proposal Discussion . . . . . . . . . . . . . . . . . 18 73 3.3.3. GIST API Viewpoint . . . . . . . . . . . . . . . . . . 20 74 3.3.4. GIST Protocol Viewpoint . . . . . . . . . . . . . . . 21 75 3.3.5. Example . . . . . . . . . . . . . . . . . . . . . . . 21 76 4. 3GPP Generic Bootstrapping Architecture (GBA) . . . . . . . . 23 77 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 23 78 4.2. Proposal Discussion . . . . . . . . . . . . . . . . . . . 25 79 4.3. GIST API Viewpoint . . . . . . . . . . . . . . . . . . . . 25 80 4.4. GIST Protocol Viewpoint . . . . . . . . . . . . . . . . . 26 81 4.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 27 82 5. Discussion and Conclusions . . . . . . . . . . . . . . . . . . 29 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 30 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 31 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 90 Intellectual Property and Copyright Statements . . . . . . . . . . 35 92 1. Introduction and Problem Statement 94 1.1. Background 96 When designing security mechanisms for NSIS, two important design 97 decisions that have to be made are how exactly the entities involved 98 are authenticated, and how authorization decisions (e.g., whether or 99 not to process a request received from an authenticated peer) are 100 made. In many cases, these two aspects are intertwined: usually the 101 identity (identifier) of the requestor is considered when making an 102 authorization decision, and often the information about how an entity 103 can be authenticated and what resources that entity is allowed to 104 access is stored at the same place. 106 How exactly the authorization decision is made depends a lot on the 107 NSLP in question; the details are mostly beyond the scope of this 108 document. This document adopts a model where the GIST layer makes 109 only very simple decisions: either it drops a request, or delivers it 110 to the NSLP for processing together with whatever authenticated 111 information about the requestor can be found (e.g., identities 112 authenticated by security mechanisms at the GIST layer or below). 114 While NSLP-specific policy issues are mostly beyond the scope of this 115 document, it is worthwhile to note that there is an important 116 dependency. If the NSLP's policy expects as input authenticated 117 information GIST cannot provide (and the NSLP cannot obtain itself), 118 the policy cannot be effectively enforced. For instance, if the NSLP 119 is faced with the decision whether to allow opening a firewall 120 pinhole with certain addresses and ports, knowing the request came 121 from a peer authenticated as "joe@example.com" may not be that 122 helpful -- unless the NSLP can somehow look up this identity from 123 some access control list to find out what kind of rules Joe is 124 allowed to create. Thus, authenticating a particular identity 125 (identifier) may not be always needed if the identifier is not 126 actually used in making the authorization decision (but that 127 authentication may still be required for some other purpose, such as 128 auditing). 130 1.2. Problem Statement 132 In many NSIS usage scenarios it is not realistic to assume that new 133 authentication credentials and user/policy databases would be 134 deployed just for NSIS. This is especially the case when the 135 entities are end-user terminals rather than routers or servers in the 136 network. 138 In this document, we examine how existing security infrastructure can 139 be used to secure NSIS communication. As "existing security 140 infrastructure" heavily depends on the environment, a single solution 141 is unlikely to be appropriate for all usage scenarios. Thus we 142 examine several options. 144 We have currently selected three quite different options for 145 consideration. 147 Section 2 describes how Transport Layer Security (TLS) authenticated 148 with certificates can be used to secure GIST. In this case, entities 149 of the existing infrastructure (PKI) are not actively involved during 150 NSIS session (except possibly for certificate revocation checks). In 151 many other cases, infrastructure elements participate in the exchange 152 when authentication/authorization is needed. 154 One example is given by Extensible Authentication Protocol (EAP) 155 [RFC3748], as typically embedded in IETF RADIUS/Diameter based AAA 156 infrastructure [RFC3579] [RFC4072]. This is described in Section 3. 157 As EAP alone does not provide mechanisms for authenticating or 158 encrypting the actual NSIS messages, it has to be used together with 159 another protocol. Several alternatives of what this protocol could 160 be and how it fits together with EAP, GIST and the NSLP in question 161 are discussed in this section. 163 Section 4 presents another example where infrastructure entities 164 participate in the exchange. The 3GPP Generic Bootstrapping 165 Architecture (GBA) [TS33.220] includes an on-line key distribution 166 center, called Bootstrapping Server Function (BSF), that is 167 responsible for distributing keys and authorization-related 168 information to the parties involved in the actual protocol (NSIS 169 peers). 171 These three cases are not meant to be exhaustive; Section 5 lists 172 several other possibilities that are not yet considered in this 173 document. 175 1.3. Disclaimer and Limitations 177 This document is very much work-in-progress, and its goal is to 178 enable discussion rather than present finished solutions. 180 Many of the options described may not be suitable for GIST due to 181 various technical and non-technical reasons we do not yet fully know. 182 Nevertheless, the authors believe analyzing options that in the end 183 are rejected is valuable to gain better understanding of why they are 184 not suitable. 186 In this document, we limit our consideration to cryptographic 187 mechanisms that are visible and explicitly controlled by NSIS. In 188 some environments, NSIS may be able to rely on the security of the 189 routing infrastructure and link-layer security mechanisms instead. 191 Consider, for instance, an ISP offering dial-up Internet access using 192 PPP. An NSIS-capable NAT/firewall [I-D.ietf-nsis-nslp-natfw] placed 193 "near" the NAS (Network Access Server) might be able to assume that 194 any packet it receives from its NAS-side interface comes from a valid 195 customer of the ISP, and that the client who sent the packet is the 196 current "owner" of the IP address found in the source address field. 197 This assumption depends on specific characteristics of the 198 environment: the NAS provides access only to authenticated customers 199 and prevents IP spoofing by other clients; possibly additional link- 200 layer security mechanisms are used to secure the link between the 201 client and the NAS; and the network between the NAS and the NAT/ 202 firewall is "sufficiently secured" using various various physical and 203 administrative methods (and possibly cryptographic link-layer and/or 204 network layer mechanisms as well). 206 2. Transport Layer Security (TLS) with X.509 PKI 208 2.1. Introduction 210 TLS [RFC2246] is one of the most popular security mechanisms for 211 protecting application-layer protocols. TLS supports authenticating 212 the parties using public-key certificates [RFC2246], pre-shared keys 213 [RFC4279], and Kerberos [RFC2712], and also includes an "anonymous" 214 Diffie-Hellman key exchange that does not itself authenticate the 215 parties. TLS is usually run over TCP or SCTP, but datagram TLS 216 [RFC4347] also allows the use of unreliable transports such as UDP. 218 2.2. Proposal Discussion 220 In this section, we consider how TLS authenticated using certificates 221 can be used to protect GIST messaging over TCP. The use of datagram 222 TLS and other authentication mechanisms is left for further 223 specification. 225 This approach is suitable when an existing authentication 226 infrastructure based on X.509 certificates is present, or a new one 227 can be deployed for NSIS purposes. This clearly does not cover all 228 possible scenarios for NSIS: for instance, assuming that all users 229 have X.509 certificates has proven to be unrealistic in many 230 environments. 232 However, we do allow flexibility in what kind of semantics the 233 certificates have. X.509 certificates bind together one or more 234 identifiers and a public key, but sometimes they have additional 235 authorization semantics: the certificate either implicitly or 236 explicitly grants some kind of permission to do something (that is 237 not simply an identifier uniquely identifying the subject). For 238 instance, we do not rule out a certificate essentially saying the 239 "subject is a valid NSIS QoS NSLP node in Autonomous System (AS) 240 64512", although we not anticipate seeing such certificates in the 241 near future. 243 2.3. GIST API Viewpoint 245 To support this flexibility, we make certificates explicitly visible 246 in the abstract GIST API. This allows different NSLPs to have 247 different certificates and semantics for interpreting them. 249 o An NSLP can specify the certificate (and private key) to be used 250 for this NSLP's traffic. Most likely this operation is done only 251 once when the node is started. 253 o When sending a message, the NSLP can verify the peer's certificate 254 before the message is actually sent. This is done using the 255 MessageStatus primitive; certificates and other security details 256 are contained in the Transfer-Attributes parameter. 258 o When a message is received, the certificates are given to the NSLP 259 for verification, contained in the Transfer-Attributes parameter 260 of the RecvMessage primitive. 262 o When sending a message, the NSLP can also specify the peer's 263 certificate explicitly: this is useful when the NSLP wants to send 264 a message to the same peer a message was received. 266 For the first procedure, we define a new primitive in the abstract 267 API: 269 ConfigureSecurity(Mechanism, Local-Certificates, Local-Key, [TLS- 270 Options]) 272 Mechanism: 'tls-certificates' 274 Local-Certificates: One or more X.509 certificates that will be 275 presented to the peer during the TLS handshake. 277 Local-Key: A private key (or a "handle" to a private key) that 278 will be used for authentication during the TLS handshake. 279 Depending on the certificates, the key type could be RSA, DSA, 280 Diffie-Hellman, Elliptic Curve DSA, or Elliptic Curve Diffie- 281 Hellman [I-D.ietf-tls-ecc]. 283 TLS-Options: Optional preferences about TLS details, such as 284 encryption algorithms and their strengths, or perfect forward 285 secrecy (PFS). 287 It is an open question whether the ConfigureSecurity primitive should 288 be considered as part of the GIST API or not. One option would be to 289 limit the GIST API to those primitives that map directly to 290 individual messages or flows, and consider ConfigureSecurity to be a 291 part of some other as-yet-undefined configuration/management 292 interface between the NSLPs and GIST. 294 For SendMessage, MessageStatus, and RecvMessage, we define a number 295 of security-related Transfer-Attributes: 297 Security: 'integrity' and optionally 'confidentiality' 299 Mechanism: 'tls-certificates' 301 Peer-Certificates: In MessageStatus and RecvMessage primitives, 302 the list of X.509 certificates presented during the TLS handshake. 303 The first certificate contains the public key actually 304 authenticated by TLS. In SendMessage primitive, this parameter 305 can be omitted; if included, it includes the end entity 306 certificate that must be authenticated during the TLS handshake. 308 TLS-Options: Information about TLS details, such as exactly which 309 ciphersuite was chosen and what properties (algorithm, strength, 310 perfect forward secrecy) it has. 312 2.4. GIST Protocol Viewpoint 314 From GIST point of view, TLS is used to secure reliable messaging 315 over TCP. Thus, it is used together with the Forwards-TCP protocol 316 defined in [I-D.ietf-nsis-ntlp]; the protection is not applied to 317 datagram mode messages. 319 A new MA-Protocol-ID value, "TLS-Certificates", needs to be assigned 320 to allow the negotiation of TLS using the Stack-Proposal object in 321 the GIST-Query/Response phase. This use of TLS does not require any 322 additional information in the Stack-Configuration-Data object (in 323 addition to the port number for Forwards-TCP). 325 2.5. Example 327 When a NSLP is started, it must at least configure the key/ 328 certificate for establishing and accepting messaging associations 329 protected with TLS. 331 Host A NSLP --> GIST: 332 ConfigureSecurity(Mechanism=tls-certificates, 333 Local-Certificates=CERT_A, Local-Key=KEY_A) 335 Host B: GIST <-- NSLP 336 ConfigureSecurity(Mechanism=tls-certificates, 337 Local-Certificates=CERT_B, Local-Key=KEY_B) 339 Later, host A's NSLP sends a message 341 Host A: NSLP --> GIST: 342 SendMessage(NSLP-Data=DATA1, NSLP-Message-Handle=H1, 343 MRI=MRI1, Transfer-Attributes: Security=integrity+confidentiality, 344 Mechanism=tls-certificates, ...) 346 GIST notices that a new messaging association is needed, and 347 initiates Query/Response 348 UDP(GIST-Query( 349 Common-Header, 350 Message-Routing-Information=MRI1, 351 Session-Identification, 352 Network-Layer-Information, 353 Query-Cookie, 354 Stack-Proposal=Forwards-TCP+TLS-Certificates, 355 Stack-Configuration-Data=NONE)) --> 357 Eventually this reaches host B and it replies 359 <-- UDP(GIST-Response( 360 Common-Header, 361 Message-Routing-Information=MRI2, 362 Session-Identification, 363 Network-Layer-Information=IP_B, 364 Query-Cookie, 365 Responder-Cookie, 366 Stack-Proposal=Forwards-TCP+TLS-Certificates, 367 Stack-Configuration-Data=PORT_B)) 369 Next, host A establishes a TCP connection to IP_B:PORT_B, and starts 370 the TLS handshake 372 TLS(ClientHello) --> 374 <-- TLS(ServerHello, Certificate=CERT_B, [ServerKeyExchange], 375 CertificateRequest, ServerHelloDone) 377 TLS(Certificate=CERT_A, ClientKeyExchange, Finished) --> 379 <-- TLS(Finished) 381 On host A, GIST now asks the NSLP to verify the certificates before 382 actually sending the NSLP data: 384 Host A: NSLP <-- GIST 385 MessageStatus(NSLP-Message-Handle=H1, Transfer-Attributes: 386 Security=integrity+confidentiality, Mechanism=tls-certificates, 387 Peer-Certificates=CERT_B, TLS-Options) 389 Host A: NSLP --> GIST: 390 OK 392 Next GIST sends the Confirm message containing the actual NSLP data: 394 TLS(GIST-Confirm(Common-Header, 395 Message-Routing-Information=MRI1, 396 Session-Identification, 397 Network-Layer-Information, 398 Responder-Cookie, 399 Stack-Proposal=Forwards-TCP+TLS-Certificates, 400 NSLP-Data=DATA1)) --> 402 GIST on host B delivers the message to the NSLP, together with 403 the peer certificate and other security-related attributes: 405 Host B: GIST --> NSLP 406 RecvMessage(NSLP-Data=DATA1, MRI=MRI1, 407 Transfer-Attributes: Security=integrity+confidentiality, 408 Mechanism=tls-certificates, Peer-Certificate=CERT_A, 409 TLS-Options) 411 The message is now processed by the NSLP, which may eventually decide 412 to reply... 414 Host B: GIST <-- NSLP: 415 SendMessage(NSLP-Data=DATA2, MRI=MRI2, 416 Transfer-Attributes: Security=integrity+confidentiality, 417 Mechanism=tls-certificates, Peer-Certificate=CERT_B, ...) 419 <-- TLS(GIST-Data(Common-Header, 420 Message-Routing-Information=MRI2, 421 Session-Identification, 422 NSLP-Data=DATA2)) 424 GIST on Host A delivers the message to NSLP: 426 Host A: NSLP <-- GIST 427 RecvMessage(NSLP-Data=DATA2, MRI=MRI2, 428 Transfer-Attributes: Security=integrity+confidentiality, 429 Mechanism=tls-certificates, Peer-Certificate=CERT_B, ...) 431 NSLP processes the message. 433 3. Extensible Authentication Protocol (EAP) 435 3.1. Introduction 437 In order to support different deployment scenarios, NSIS signaling 438 should have flexible authentication and authorization capabilities. 439 This can be achieved by interacting with the AAA infrastructure for 440 computing the authorization decision of various NSLP requests. To 441 support existing credentials and the large number of different usage 442 scenarios, the Extensible Authentication Protocol (EAP) might be 443 reused. EAP provides the following capabilities: 445 o Flexible support for authentication and key exchange protocols. 447 o Ability to reuse existing long-term credentials and already 448 deployed authentication and key exchange protocols (for example, 449 the UMTS-AKA) 451 o Integration into the existing AAA infrastructure, namely RADIUS 452 [RFC2869] and Diameter [RFC4072]. 454 o Ability to execute the authorization decision at the user's home 455 network based on the capabilities of protocols like RADIUS and 456 Diameter. 458 EAP is not the only security framework that could be used. Others, 459 such as the GSS-API (see [RFC2078] and [RFC2743]) or SASL [RFC2222], 460 could theoretically also be used but are from a functional point of 461 view very similar and therefore not explored here. The lack of 462 integration of the GSS-API and SASL into the AAA infrastructure 463 (except for very simple password and challenge-based authentication) 464 makes EAP the preferred choice. 466 As EAP alone does not provide mechanisms for data origin 467 authentication or encrypting the actual NSIS messages, it has to be 468 used together with another protocol. 470 Three main choices 472 o TLS Inner Application [I-D.funk-tls-inner-application-extension] 474 o TLS (unauthenticated Diffie-Hellman) below GIST, with channel 475 bindings to EAP run in NSLP. 477 o Intermediate "TLS/EAP-shim" layer above TLS (unauthenticated 478 Diffie-Hellman) but below GIST. This has the advantage of not 479 requiring modifications to the individual NSLPs but thas the 480 disadvantage of lacking the knowledge about the specific 481 authorization requirements. Since this approach is very similar 482 to the previous one from an encoding and protocol point of view we 483 will omit the description in this version of the document. 485 Note that TLS I/A does not preclude the use of certificate based 486 authentication of the server to the client and vice versa. In fact, 487 the usage of certificates for server-based authentication is 488 recommended. 490 The aspect of enhancing NSIS with an RSVP alike integrity object or 491 the usage of the Cryptographic Message Syntax (CMS) [RFC2630] that 492 use the EAP derived session key for signaling message protection is 493 not considered in this version of the document and is left for 494 further study. 496 3.2. EAP with TLS Inner Application 498 3.2.1. Introduction 500 TLS I/A provides a means to perform EAP-based user authentication 501 between the EAP client and the EAP server integrated within the TLS 502 handshake. TLS I/A can thus be used both for flexible user 503 authentication within a TLS session and as a basis for tunneled 504 authentication within EAP. The TLS I/A approach is to insert an 505 additional message exchange between the TLS handshake and the 506 subsequent data communications phase. This message exchange is 507 carried in a new record type, which is distinct from the record type 508 that carries upper layer data. Thus, the data portion of the TLS 509 exchange becomes available for NSIS (or another protocol that needs 510 to be secured). 512 3.2.2. Proposal Discussion 514 When authentication and key exchange is provided with TLS I/A (and 515 therefore the embedded EAP exchange) then the specific NSLP payloads 516 are not yet processed. Hence, authorizing the specific NSLP 517 operation (such as a request for reserving a certain amount of 518 bandwidth) can only be provided at the QoS NSLP layer. As such, the 519 AAA interaction triggered as part of the TLS I/A (and the EAP method 520 processing) performs only authentication, key establishment and a 521 separate exchange might be required at the NSLP. 523 The main advantage of this approach is that it does not require 524 modifications for the NSIS protocol suite since the EAP exchange is 525 encapsulated within the TLS Handshake exchange. 527 3.2.3. GIST API Viewpoint 529 The GIST API for usage of TLS I/A might need to be make TLS based 530 credentials and the EAP capabilities visible in the abstract GIST 531 API. This allows different NSLPs to use different security 532 mechanisms. 534 For the first procedure, the previously defined primitive needs to be 535 refined in order to offer an abstract API: 537 ConfigureSecurity(Mechanism, [EAP-Context], [Local-Certificates, 538 Local-Key], [AAA-Context], [TLS-Options]) 540 Mechanism: 'tls-ia-eap' 542 EAP-Context: This parameter is present only on the "client" side, 543 and contains information to be used during the EAP authentication 544 (which EAP method, what credentials, etc.). 546 Local-Certificates: This parameter is present only on the 547 "network" side, and contains certificates that will be presented 548 to the client during the TLS handshake. If authentication is 549 based solely on a mutually authenticating EAP method, certificates 550 can be omitted. 552 Local-Key: A private key (or a "handle" to a private key) 553 corresponding to Local-Certificates. 555 AAA-Context: This parameter is present only on the "client" side, 556 and contains information needed to operate as EAP "pass-through" 557 authenticator; i.e., information about the AAA protocol and its 558 details. 560 TLS-Options: As described in Section 2.3. 562 For SendMessage, MessageStatus, and RecvMessage, we define a number 563 of security-related Transfer-Attributes. Please note that public key 564 based server authentication inside the TLS handshake might be support 565 and alternatively an unauthenticated TLS handshake is used. 567 Security: 'integrity' and optionally 'confidentiality' 569 Mechanism: 'tls-ia-eap' 571 Peer-Certificates: This parameter is present only on the "client" 572 side. In MessageStatus and RecvMessage primitives, the list of 573 X.509 certificates presented during the TLS handshake (if any). 574 The first certificate contains the public key actually 575 authenticated by TLS. In SendMessage primitive, this parameter 576 can be omitted; if included, it includes the end entity 577 certificate that must be authenticated during the TLS handshake. 579 EAP-Information: On the "client" side, information that has been 580 provided by the EAP method (or in SendMessage primitive, has to be 581 provided). The exact details depend on the EAP method in 582 question, but typically includes the EAP method used and 583 identifiers authenticated during the EAP exchange. Since there is 584 no standarized EAP API it is difficult to provide a full set of 585 details. Proprietary APIs (such as [EAP-API]) might give some 586 ideas about the needed parameters. 588 AAA-Information: On the "network" side, information that has been 589 provided by the AAA infrastructure (or in SendMessage primitive, 590 has to be provided). The exact details depend on the AAA 591 infrastructure and its configuration, but the AAA server could, 592 for instance, provide information about what identities were 593 authenticated and what types of NSIS requests the client is 594 authorized to make. 596 TLS-Options: As described in Section 2.3. 598 3.2.4. GIST Protocol Viewpoint 600 From a GIST point of view, the TLS Record Layer is used to secure 601 reliable messaging over TCP. Thus, it is used together with the 602 Forwards-TCP protocol defined in [I-D.ietf-nsis-ntlp]; the protection 603 is not applied to datagram mode messages. 605 A new MA-Protocol-ID value, "TLS-I/A", may need to be assigned to 606 allow the negotiation of TLS I/A using the Stack-Proposal object in 607 the GIST-Query/Response phase. Alternatively, a Stack-Proposal for 608 "TLS" is indicated and the support for TLS I/A is indicated as part 609 of the ciphersuite negotiation. 611 3.2.5. Example 613 The following example shows the interaction of GIST / QoS NSLP with 614 TLS I/A. In the following example we assume that server-side 615 authentication using certificates is provided within TLS I/A. Client- 616 side authentication is provided using a specific EAP method (such as 617 EAP-AKA). 619 When a NSLP is started, the server side of the communication must at 620 least configure the key/certificate for accepting messaging 621 associations protected with TLS. 623 Host A NSLP --> GIST: 624 ConfigureSecurity(Mechanism=tls-ia-eap, 625 EAP-Context={EAP-AKA, local USIM card, ...}) 627 Host B: GIST <-- NSLP 628 ConfigureSecurity(Mechanism=tls-ia-eap, 629 Local-Certificates=CERT_B, Local-Key=KEY_B, 630 AAA-Context={Diameter EAP, ...}) 632 Later, host A's NSLP sends a message 634 Host A: NSLP --> GIST: 635 SendMessage(NSLP-Data=DATA1, NSLP-Message-Handle=H1, 636 MRI=MRI1, Transfer-Attributes: Security=integrity+confidentiality, 637 Mechanism=tls-ia-eap, ...) 639 GIST notices that a new messaging association is needed, and 640 initiates Query/Response 642 UDP(GIST-Query( 643 Common-Header, 644 Message-Routing-Information=MRI1, 645 Session-Identification, 646 Network-Layer-Information, 647 Query-Cookie, 648 Stack-Proposal=Forwards-TCP+TLS-IA-EAP, 649 Stack-Configuration-Data=NONE)) --> 651 Eventually this reaches host B and it replies 653 <-- UDP(GIST-Response( 654 Common-Header, 655 Message-Routing-Information=MRI2, 656 Session-Identification, 657 Network-Layer-Information=IP_B, 658 Query-Cookie, 659 Responder-Cookie, 660 Stack-Proposal=Forwards-TCP+TLS-IA-EAP, 661 Stack-Configuration-Data=PORT_B)) 663 Next, host A establishes a TCP connection to IP_B:PORT_B, and starts 664 the TLS handshake. The InnerApplicationExtension TLS extension 665 indicates that TLS I/A will be used. 667 TLS(ClientHello, InnerApplicationExtension) --> 669 <-- TLS(ServerHello, InnerApplicationExtension, 670 Certificate=CERT_B, [ServerKeyExchange], 671 ServerHelloDone) 673 TLS(ClientKeyExchange, Finished) --> 675 <-- TLS(Finished) 677 Next, the EAP exchange begins. On the "network" side, EAP messages 678 are not processed by the NSIS responder, but rather a separate AAA 679 server. 681 TLS(ApplicationPayload={EAP-Response, Identity, 682 joe@example.com}) --> 684 <-- TLS(ApplicationPayload={EAP-Request, AKA-Challenge, ...}) 686 TLS(ApplicationPayload={EAP-Response, AKA-Challenge, ..}) --> 688 <-- TLS(FinalPhaseFinished) 690 TLS(FinalPhaseFinished) --> 692 On host A, GIST now asks the NSLP to verify the certificates and 693 the result of EAP authentication before ctually sending the NSLP 694 data: 696 Host A: NSLP <-- GIST 697 MessageStatus(NSLP-Message-Handle=H1, Transfer-Attributes: 698 Security=integrity+confidentiality, Mechanism=tls-ia-eap, 699 Peer-Certificates=CERT_B, EAP-Information=..., TLS-Options) 701 Host A: NSLP --> GIST: 702 OK 704 Next GIST sends the Confirm message containing the actual NSLP data: 706 TLS(GIST-Confirm(Common-Header, 707 Message-Routing-Information=MRI1, 708 Session-Identification, 709 Network-Layer-Information, 710 Responder-Cookie, 711 Stack-Proposal=Forwards-TCP+TLS-IA-EAP, 712 NSLP-Data=DATA1)) --> 714 GIST on host B delivers the message to the NSLP in addition 715 to the information about the client authentication: 717 Host B: GIST --> NSLP 718 RecvMessage(NSLP-Data=DATA1, MRI=MRI1, 719 Transfer-Attributes: Security=integrity+confidentiality, 720 Mechanism=tls-ia-eap, AAA-Information=..., TLS-Options) 722 The message is now processed by the NSLP, which may eventually decide 723 to reply... 725 Host B: GIST <-- NSLP: 726 SendMessage(NSLP-Data=DATA2, MRI=MRI2, 727 Transfer-Attributes: Security=integrity+confidentiality, 728 Mechanism=tls-ia-eap, ...) 730 <-- TLS(GIST-Data(Common-Header, 731 Message-Routing-Information=MRI2, 732 Session-Identification, 733 NSLP-Data=DATA2)) 735 GIST on Host A delivers the message to NSLP: 737 Host A: NSLP <-- GIST 738 RecvMessage(NSLP-Data=DATA2, MRI=MRI2, 739 Transfer-Attributes: Security=integrity+confidentiality, 740 Mechanism=tls-ia-eap, Peer-Certificates=CERT_B, 741 EAP-Information=..., TLS-Options) 743 NSLP processes the message. 745 3.3. EAP in NSLP 747 3.3.1. Introduction 749 This section describes the aspects of the EAP integration into the 750 NSLP. It should be noted that integrating EAP encapsulation into QoS 751 signaling protocol is more than just adding an object into the QoS 752 message exchange. The suggested enhancement of supporting EAP based 753 authentication and authorization for the QoS signaling needs to be 754 investigated for the impact of the integration on the QoS signaling 755 protocol framework. The aspect of authentication and authorization 756 in the QoS environment has raised a number of security concerns in 757 the past. 759 +-----------+ 760 |Entity C | 761 |authorizing| 762 |resource | 763 |request | 764 +----------++ 765 ^ | 766 | | 767 QoS | | QoS 768 authz| |authz 769 req.| | res. 770 | | 771 | v 772 +----------+QoS RESERVE +-+---------+ QoS RESERVE +-----------+ 773 |End Host A|-------------->|Router 1 |------------->|End Host B | 774 |requesting| |performing | ........ |performing | 775 |QoS |QoS RESPONSE |QoS | QoS RESPONSE |QoS | 776 |resource |<--------------|reservation|<-------------|reservation| 777 +----------+ +-----------+ +-----------+ 779 3.3.2. Proposal Discussion 781 For integrating EAP into a NSLP application a new NSLP payload object 782 should be defined to carry the EAP packets. The EAP session will be 783 established between a QoS-NSLP initiator (Host A), a QoS-NSLP policy 784 aware node (Router 1) and an Authorizing entity (Entity C). Node A 785 and Router 1 insert the EAP packets into exchanged QoS-NSLP messages 786 between them and are the EAP peer and EAP authenticator in the 787 session. The Router 1 communicates with Entity C (EAP server) via 788 AAA infrastructure and completes the EAP session. Other IETF 789 protocols that decided to use EAP have analyzed some aspects of EAP 790 integration already, such as PANA [I-D.ietf-pana-pana]. This 791 experience is reused for identification of the following aspects that 792 necessitate further investigation: 794 Transport requirements of EAP and their support by the NSIS 795 framework. EAP itself is a container, and sets requirements on 796 specific transport service features - fragmentation, reliability, 797 in-order delivery and retransmission. 799 Seamless integration of EAP into the QoS-NSLP message processing. 801 Number of security considerations related to inter-working with 802 lower layer security mechanism (if present) or trust placed on the 803 QoS NSLP policy aware node or provision of secured transport 804 methods for QoS NSLP messages, utilizing the resulting exchanged 805 EAP method session keys. 807 In more details, two approaches are investigated in [I-D.tschofenig- 808 nsis-qos-ext-authz] for provision of transport integration between 809 EAP and the NSIS framework. The first one does not introduce any new 810 requirements on the NSIS framework but suggest that the used EAP 811 methods should deal with fragmentation, reliability and re- 812 transmission of the EAP data into the QoS NSLP messages. However, 813 this approach loads QoS NSLP application with functions that are not 814 specific to it (e.g., fragmentation). In the second approach, QoS- 815 NSLP should request reliable transmission for the messages of the 816 signaling session, which involves EAP authentication and 817 authorization. Reliable transport service provided by GIST utilizing 818 TCP and SCTP protocols includes fragmentation and in-order delivery. 819 Considering that a MA establishment (for reliable transport) may be 820 initiated only by the requesting (upstream) peer, additional 821 attention should be paid to the case in which the QoS-NSLP initiator 822 is not initially aware of the EAP usage and does not request reliable 823 transmission from the GIST layer [I-D.tschofenig-nsis-qos-ext-authz]. 825 Each of the two protocols, EAP and QoS-NSLP, has its message 826 processing rules and state machines. Desired integration of both 827 protocols should not require adjustment or even extension of the QoS- 828 NSLP message exchange. [I-D.tschofenig-nsis-qos-ext-authz] shows 829 that a proper encapsulation of the EAP payloads into QoS NSLP 830 Reserve/Query/Response messages allows a seamless inter-working 831 between both protocols. 833 Until recently, engineers and scientists thought that running one 834 authentication and exchange protocol on top of another increases the 835 security of the entire exchange. Running these two exchanges 836 completely isolated may allow for Man-In-The-Middle (MITM) attacks, 837 as shown in [I-D.puthenkulam-eap-binding]. For example, when running 838 EAP over TLS (as analyzed in [I-D.puthenkulam-eap-binding]) the two 839 exchanges need to be cryptographically tied together. This can be 840 accomplished using a number of ways including combining the session 841 keys of both exchanges into additionally generated so called Compound 842 Message Keys according to [I-D.puthenkulam-eap-binding]. If the 843 transport layer is secured by TLS and additional authentication and 844 authorization is provided at the QoS signaling layer then the same 845 MITM vulnerabilities need to be addressed. In the NSIS case, these 846 two exchanges are handled at two different NSIS layers. Hence, 847 additional security attributes need to be exchanged through the API 848 between the transport and the QoS signaling layer. Currently, the 849 GIST specification does not provide a strict API specification. 850 Instead, a few clarifying hints to the implementers are given. 851 Specifying additional security attributes, e.g., EAP method derived 852 session keys to be pushed to the GIST layer, are therefore possible. 853 This is, however, not the only obstacle: Exporting keying material 854 from TLS or IKE/IPsec using standard mechanisms in order to combine 855 it with the EAP method derived keying material to compute a Compound 856 Message Key is difficult. Alternatively, if mutual authentication is 857 provided with TLS to secure GIST signaling then the authenticated 858 identities of both peers can be exchanged via the existing API 859 definition and used to create a binding. 861 Another common problem for EAP is the validation of the authorization 862 rights of the EAP Authenticator (QoS policy aware NE) that functions 863 in pass-through mode. An adversary might identify itself to the EAP 864 peer and the EAP server with a different identity or a different 865 role. This vulnerability is known as the 'Lying NAS' problem. For 866 example, in the QoS signaling case, an attacker might act as QoS 867 policy aware NE and could misuse an EAP exchange to create the 868 illusion for the EAP server that the context is different (e.g., 869 wireless LAN access instead of wired access). Then a user, who is 870 authenticated and authorized through the usage of EAP, might be 871 charged for services that he has not received. 873 In the currently discussed framework, EAP should be used to provide 874 authentication and the session key as part of an AAA application, 875 which is responsible for providing the authorization decision, based 876 on an EAP method that authenticates the user identity. This implies 877 that a QoS policy aware NE should be authenticated and authorized to 878 be one side in an AAA QoS Authorization session. In addition, the 879 authorization decision is based not only on an authenticated 880 identity, but also on the description of requested QoS parameters, 881 which would clearly identify the type of the requested service. It 882 should be noted that the second case is valid only if integrity 883 protection of the exchanged QoS data is available between the End 884 Host and the Authorizing entity. In addition, the problem in general 885 is identified and addressed by some EAP extensions, e.g., [I-D.arkko- 886 eap-service-identity-auth]. These solutions carry additional 887 authorization related data between the EAP peer and EAP server. 888 However, all above considerations that address the problem do not 889 involve any change to the interworking between EAP and QoS signaling 890 protocol. 892 3.3.3. GIST API Viewpoint 894 EAP does not provide a mechanism to secure the NSIS signaling 895 communication. Instead, keying material might be provided by the EAP 896 method that is delivered by the AAA infrastructure to the 897 Authentication and also available to the EAP peer via an API. As 898 such, it is possible to use this keying material for subsequent 899 signaling message protection. Instead of creating a new object that 900 is used to protect the signaling message communication at the NSLP 901 layer the approach described in the subsequent example is based on 902 the combination of TLS. Note that the TLS exchange might not utilize 903 any authentication mechanisms (neither server nor client side 904 authentication). The GIST specific API considerations therefore 905 appear in the context of configuring lower layer security mechanisms 906 (such as TLS with or without authentication) and the ability to 907 accomplish the channel binding. 909 As described in [I-D.puthenkulam-eap-binding], there are several 910 different ways to bind the channel at GIST layer with the EAP 911 authentication. From layering point of view, it seems that the 912 simplest option would be to pass channel binding information from the 913 GIST layer to the NSLP, and let the NSLP do the binding. In 914 particular, [I-D.ietf-nfsv4-channel-bindings] contains a suggestion 915 for channel binding information in the TLS case. 917 3.3.4. GIST Protocol Viewpoint 919 From a GIST point of view, the TLS Record Layer might be a good 920 approach to offer data origin authentication, integrity and 921 confidentiality protection of the GIST and the NSLP communication. 922 Thus, it is used together with the Forwards-TCP protocol defined in 923 [I-D.ietf-nsis-ntlp]; the protection is not applied to datagram mode 924 messages. 926 A new MA-Protocol-ID value, "NSLP-EAP", may need to be assigned to 927 allow the negotiation of EAP usage in the NSLP using the Stack- 928 Proposal object in the GIST-Query/Response phase. This would allow 929 an NSIS node to indicate the ability to support this functionality 930 and to thereby avoid relying on a policy for client-side TLS 931 authentication which thereby is provided by EAP at a later stage in 932 the protocol exchange. 934 3.3.5. Example 936 An example message flow is shown in Figure 7 which uses the EAP-AKA 937 method [RFC4187] for authentication and session key establishment. 938 Please note that the AAA messages triggered by this exchange are not 939 shown for editorial reasons. 941 +---------+ +---------+ 942 | MN | | R1 | 943 +---------+ +---------+ 944 (a) + <---------------------------------------------> + 945 | Discovery Request/Response (NTLP) | 946 | | 947 (b) | ----------------------------------------------> | 948 | C-Mode | 949 | NTLP/NSLP QoS RESERVE | 950 | (EAP-Auth/Authz requested; | Initial 951 | EAP-Identity) | Setup 952 | | 953 (c) | <---------------------------------------------- | 954 | C-Mode | 955 | NTLP/NSLP QoS QUERY . | 956 | (EAP-Request/AKA-Challenge | 957 | (AT_RAND, AT_AUTN, AT_MAC)) | 958 | (Algorithm/Parameter Negotiation) | 959 (d) | ----------------------------------------------> | 960 | C-Mode | 961 | NTLP/NSLP QoS RESPONSE | 962 | (EAP-Response/AKA-Challenge | 963 | (AT_RES, AT_MAC)) | 964 | (Algorithm/Parameter Negotiation) | 965 +~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~+ 966 (e) | Authentication Authorization finished | 967 | Secure TLS tunnel established | 968 +~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~+ 969 (f) | <---------------------------------------------- | 970 | NTLP/NSLP QoS RESPONSE | 971 | (EAP-Success) | 972 | ----------------------------------------------> | 973 | NTLP/NSLP QoS RESERVE | 974 | (Secure Confirmation) | 975 | | 976 + + 977 .......... 978 + + 979 | ----------------------------------------------> | 980 (g) | NTLP/NSLP QoS REFRSH msg | Refresh 981 | | Msg 982 | <---------------------------------------------- | 983 | NTLP/NSLP QoS ACK msg | 984 + + 986 Figure 7: EAP based Auth/Authz exchange using EAP-AKA 988 The message exchange shown in Figure 7 starts with the optional 989 discovery of the next QoS NSLP aware node (messages (a)). The first 990 QoS NSLP message with a resource request is sent with the Network 991 Access Identity and a request to perform EAP-based authentication 992 (message (b)). Note that this exchange assumes that the EAP-Request/ 993 Identity and the EAP-Response/Identity exchange is omitted. This 994 exchange is optional in EAP if the identity can be provided by other 995 means. Router 1 contacts the AAA infrastructure, and the EAP server 996 starts the message exchange. The AAA message communication is not 997 shown. Subsequently, two messages (messages (c) and (d)) are 998 exchanged between the EAP peer and the EAP server which contain EAP- 999 AKA specific information. After successful authentication and 1000 authorization, session keys are derived and provided to R1 via AAA 1001 mechanisms (see [RFC4072] and [RFC3579]). These session keys can 1002 then be used to protect subsequent NSLP messages as indicated by (e). 1003 The EAP-Success message can already experience such a protection (see 1004 message (f)). Furthermore, it is useful to repeat the previously 1005 sent objects. Subsequent refresh messages (g) are protected with the 1006 previously established session keys and are therefore associated with 1007 the previous authentication and authorization protocol execution. 1009 4. 3GPP Generic Bootstrapping Architecture (GBA) 1011 4.1. Introduction 1013 The 3GPP Generic Bootstrapping Architecture (GBA), specified in 1014 [TS33.220], is an authentication system with three parties: a trusted 1015 third party (called Bootstrapping Server Function or BSF), is 1016 involved in authentication and key exchange between two other nodes, 1017 a client (called User Equipment or UE) and server (called Network 1018 Application Function or NAF). 1020 The goal of the architecture is to isolate knowledge of long-term 1021 secrets and credentials to a single trusted node, the BSF. The 1022 actual servers (NAFs) do not have access to the clients' long-term 1023 credentials, and indeed, do not even have to know exactly what kinds 1024 of credentials (such as smart cards) were used between the client and 1025 the BSF. 1027 In a simple case, the authentication process is as follows (also 1028 depicted in the figure below). 1030 +--------+ +------+ +-----+ 1031 | client | |server| | BSF | 1032 +--------+ +------+ +-----+ 1033 | | | 1034 1. | Authenticate and agree | | 1035 | on B-TID and key Ks | | 1036 |<----------------------------------------------->| 1037 | | | 1038 2. | Initiate connection | | 1039 | and send B-TID | | 1040 |------------------------>| | 1041 +-------------+ | | 1042 |Derive Ks_NAF| | | 1043 +-------------+ | | 1044 | | B-TID | 1045 3. | |---------------------->| 1046 | | +-------------+ 1047 | | |Derive Ks_NAF| 1048 | | +-------------+ 1049 | | Ks_NAF, IMPI, | 1050 | | user profile | 1051 | |<----------------------| 1052 4. | Authenticate using | | 1053 | Ks_NAF | | 1054 |<----------------------->| | 1055 | | | 1057 1. First, the client contacts the Bootstrapping Server Function 1058 (BSF) and they authenticate each other using long-term 1059 credentials. This usually involves contacting back-end 1060 authentication databases such as the Home Subscriber System 1061 (HSS). As a result of the authentication, the client and BSF 1062 share a secret session key (Ks) and a Bootstrapping Transaction 1063 Identifier (B-TID) identifying the key and other related state. 1064 Currently the authentication between the client and BSF is based 1065 UMTS Subscriber Identity Module (USIM) smart cards and HTTP 1066 Digest AKA protocol [RFC3310]. However, it is assumed that in 1067 the future, other authentication mechanisms may be added between 1068 the client and BSF. 1070 2. When the client contacts a server (NAF) it wants to authenticate 1071 to, it sends the transaction identifier (B-TID) to the server. 1073 3. The server then sends the B-TID to the BSF, and gets back a 1074 server-specific key (Ks_NAF), the user's permanent identity (IP 1075 Multimedia Private Identity or IMPI) and application-specific 1076 parts of the user profile. This is done using the Diameter-based 1077 Zn interface specified in [TS29.109] 1079 4. Finally, the client and server authenticate each other using the 1080 server-specific key (Ks_NAF). How exactly this authentication is 1081 done depends on the protocol used between the client and the 1082 server; this again depends on what exactly the service is. 1083 Currently, [TS33.222] specifies that HTTP-based services can use 1084 either HTTP Digest authentication [RFC2617] or TLS pre-shared key 1085 ciphersuites [RFC4279]. 1087 4.2. Proposal Discussion 1089 In this section, we consider how 3GPP Generic Bootstrapping 1090 Architecture (GBA) can be used to protect GIST messages. Since GBA 1091 is by its nature asymmetric, we assume that the querying node is the 1092 client (3G User Equipment) and the responder node is a node in the 3G 1093 network (in the role of Network Application Function). 1095 The most promising approach seems to use something like the pre- 1096 shared key TLS [RFC4279] in a fashion resembling GAA HTTPS services 1097 [TS33.222]. However, the HTTPS approach assumes the querying node 1098 (3G terminal) knows the FQDN of the responding node beforehand. This 1099 would limit the use of GBA to certain message routing methods. 1100 Instead, we decided to communicate the FQDN in GIST-Response message, 1101 and assume the client can verify whether the FQDN looks correct or 1102 not. 1104 4.3. GIST API Viewpoint 1106 The asymmetric nature of GBA is reflected in the GIST API as well: 1107 the security-related details contained in the Transfer-Attributes 1108 parameter are different on the client and server side. 1110 o When sending a message, the NSLP can verify the server's NAF_ID 1111 (or client's IMPI and user profile) before the message is actually 1112 sent. This is done using the MessageStatus primitive; the 1113 identities and other security details are contained n the 1114 Transfer-Attributes parameter. 1116 o When a message is received, the identities and other security 1117 details are given to the NSLP for verification, contained in the 1118 Transfer-Attributes parameter of the RecvMessage primitive. 1120 o When sending a message, the NSLP can also specify the peer's 1121 identity (NAF_ID or IMPI) explicitly; this is useful when the NSLP 1122 wants to send a message to the same peer a message received from. 1124 For SendMessage, MessageStatus, and RecvMessage, we define a number 1125 of security-related Transfer-Attributes: 1127 Security: 'integrity' and optionally 'confidentiality' 1129 Mechanism: 'tls-gba' 1131 Peer-NAF-ID: This parameter is present only on the "client" 1132 (mobile terminal) side. In MessageStatus and RecvMessage 1133 primitives, it contains the NAF identifier (FQDN) that was 1134 authenticated using GBA/TLS procedures. In SendMessage primitive, 1135 this parameter can be omitted; if included, it specifies the NAF 1136 identifier that must be authenticated. 1138 Peer-IMPI: This parameter is present only on the "network" (NAF) 1139 side. In MessageStatus and RecvMessage primitives, it contains 1140 the user identity (IMPI) that was authenticated using GBA/TLS 1141 procedures. In SendMessage primitive, this parameter can be 1142 omitted; if included, it specifies the user identity that must be 1143 authenticated. 1145 Peer-User-Profile: This parameter is present only on the "network" 1146 (NAF) side. In MessageStatus and RecvMessage primitives, it 1147 contains the application-specific part of the user profile 1148 received from the BSF. 1150 TLS-Options: Information about TLS details, such as exactly which 1151 ciphersuite was chosen and what properties (algorithm, strength, 1152 perfect forward secrecy) it has. 1154 4.4. GIST Protocol Viewpoint 1156 From GIST point of view, TLS-GBA looks similar to TLS with 1157 certificates. A new MA-Protocol-ID, "TLS-GBA", needs to be assigned. 1159 4.5. Example 1161 Host A's NSLP sends a message 1163 Host A: NSLP --> GIST: 1164 SendMessage(NSLP-Data=DATA1, NSLP-Message-Handle=H1, 1165 MRI=MRI1, Transfer-Attributes: Security=integrity+confidentiality, 1166 Mechanism=tls-gba, ...) 1168 GIST notices that a new messaging association is needed, and 1169 initiates Query/Response 1171 UDP(GIST-Query( 1172 Common-Header, 1173 Message-Routing-Information=MRI1, 1174 Session-Identification, 1175 Network-Layer-Information, 1176 Query-Cookie, 1177 Stack-Proposal=Forwards-TCP+TLS-GBA, 1178 Stack-Configuration-Data=NONE)) --> 1180 Eventually this reaches host B and it replies 1182 <-- UDP(GIST-Response( 1183 Common-Header, 1184 Message-Routing-Information=MRI1, 1185 Session-Identification, 1186 Network-Layer-Information=IP_B, 1187 Query-Cookie, 1188 Responder-Cookie, 1189 Stack-Proposal=Forwards-TCP+TLS-GBA, 1190 Stack-Configuration-Data=PORT_B, NAF_ID_B)) 1192 Next, host A establishes a TCP connection to IP_B:PORT_B, and starts 1193 the TLS handshake: 1195 TLS(ClientHello, ServerName(NAF_ID_B)) --> 1197 <-- TLS(ServerHello, [ServerKeyExchange], ServerHelloDone) 1199 TLS(ClientKeyExchange(B-TID), Finished) --> 1201 Host B fetches the key (Ks_NAF) and the application-specific part of 1202 the user profile from the BSF. This is done using the Diameter-based 1203 Zn interface specified in [TS29.109]. 1205 <-- TLS(Finished) 1207 On host A, GIST now asks the NSLP to verify the certificates before 1208 actually sending the NSLP data: 1210 Host A: NSLP <-- GIST 1211 MessageStatus(NSLP-Message-Handle=H1, Transfer-Attributes: 1212 Security=integrity+confidentiality, Mechanism=tls-gba, 1213 Peer-NAF-ID=NAF_ID_B, TLS-Options) 1215 Host A: NSLP --> GIST: 1216 OK 1218 Next GIST sends the Confirm message containing the actual NSLP data: 1220 TLS(GIST-Confirm(Common-Header, 1221 Message-Routing-Information=MRI1, 1222 Session-Identification, 1223 Network-Layer-Information, 1224 Responder-Cookie, 1225 Stack-Proposal=Forwards-TCP+TLS-GBA, 1226 NSLP-Data=DATA1)) --> 1228 GIST on host B delivers this to the NSLP, together with the peer 1229 identity (IMPI), application-specific parts of the user profile, 1230 and other security-related attributes: 1232 Host B: GIST --> NSLP 1233 RecvMessage(NSLP-Data=DATA1, MRI=MRI1, 1234 Transfer-Attributes: Security=integrity+confidentiality, 1235 Mechanism=tls-gba, Peer-IMPI=IMPI_A, Peer-User-Profile=..., 1236 TLS-Options) 1238 The message is now processed by the NSLP, which may eventually decide 1239 to reply... 1241 Host B: GIST <-- NSLP: 1242 SendMessage(NSLP-Data=DATA2, MRI=MRI2, 1243 Transfer-Attributes: Security=integrity+confidentiality, 1244 Mechanism=tls-gba, Peer-IMPI=IMPI_A, ...) 1246 <-- TLS(GIST-Data(Common-Header, 1247 Message-Routing-Information=MRI2, 1248 Session-Identification, 1249 NSLP-Data=DATA2)) 1251 GIST on Host A delivers the message to NSLP: 1253 Host A: NSLP <-- GIST 1254 RecvMessage(NSLP-Data=DATA2, MRI=MRI2, 1255 Transfer-Attributes: Security=integrity+confidentiality, 1256 Mechanism=tls-gba, Peer-NAF-ID=NAF_ID_B, ...) 1258 NSLP processes the message. 1260 5. Discussion and Conclusions 1262 We have examined how three different types of existing security 1263 infrastructure, namely X.509 PKI, EAP/AAA and 3GPP GBA, can be used 1264 to secure GIST messaging. In all three cases, the TLS record layer 1265 provides encryption and integrity protection for NSLP messages; the 1266 differences are in how the authentication, key exchange, and 1267 authorization work. All three cases assume the existence of an 1268 infrastructure beyond what is defined in TLS: either a PKI where the 1269 infrastructure elements are not actively involved during the GIST 1270 messaging, or on-line AAA/bootstrapping servers. 1272 These three cases are not meant to be exhaustive. Some options that 1273 have not yet been analyzed include the following: 1275 o IKE/IPsec with X.509 PKI. 1277 o TLS or IKE/IPsec with manually configured shared secrets. 1279 o TLS with Cryptographically Generated Addresses (CGA) [RFC3972]. 1281 o IPsec with Host Identity Protocol (HIP) [RFC4423]. 1283 o Integration with SAML/Liberty infrastructure [SAMLOverview]. 1285 o Usage of Kerberos within the TLS Handshake [RFC2712]. This 1286 approach was utilized for enterprise environments with RSVP (see 1287 also [MADS01] for information about the authorization information 1288 that may be carried in such a ticket). 1290 Moreover, since integration with an existing infrastructure depends 1291 largely on what exactly that infrastructure is, it may be more 1292 productive to examine NSIS security in some particular deployment 1293 scenario, rather than in abstract or generic fashion. 1295 6. Security Considerations 1297 This document discusses different proposals for securing GIST and 1298 hence security is addressed throughout the document. As part of 1299 future work additional security considerations might need to be added 1300 to GIST [I-D.ietf-nsis-ntlp]. 1302 7. IANA Considerations 1304 A future version of this draft might require IANA actions. Depending 1305 on the outcome of the discussions it might be necessary to register 1306 IANA numbers for stack proposals used in GIST. 1308 8. Acknowledgements 1310 The authors would like to Tseno Tsenov, Henning Peters, Mika Kousa, 1311 and Robert Hancock for their input to this work. Tseno Tsenov 1312 investigated the integration of EAP into the QoS in the past. 1314 This document has been produced in the context of the Ambient 1315 Networks Project. The Ambient Networks Project is part of the 1316 European Community's Sixth Framework Program for research and is as 1317 such funded by the European Commission. All information in this 1318 document is provided "as is" and no guarantee or warranty is given 1319 that the information is fit for any particular purpose. The user 1320 thereof uses the information at its sole risk and liability. For the 1321 avoidance of all doubts, the European Commission has no liability in 1322 respect of this document, which is merely representing the authors 1323 view. 1325 9. References 1327 9.1. Normative References 1329 [I-D.funk-tls-inner-application-extension] 1330 Funk, P., "TLS Inner Application Extension (TLS/IA)", 1331 draft-funk-tls-inner-application-extension-02 (work in 1332 progress), March 2006. 1334 [I-D.ietf-nsis-ntlp] 1335 Schulzrinne, H. and R. Hancock, "GIST: General Internet 1336 Signaling Transport", draft-ietf-nsis-ntlp-09 (work in 1337 progress), February 2006. 1339 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1340 RFC 2246, January 1999. 1342 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1343 Levkowetz, "Extensible Authentication Protocol (EAP)", 1344 RFC 3748, June 2004. 1346 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 1347 for Transport Layer Security (TLS)", RFC 4279, 1348 December 2005. 1350 9.2. Informative References 1352 [EAP-API] Microsoft Corporation, "Platform SDK: Extensible 1353 Authentication Protocol", MSDN Library, http:// 1354 msdn.microsoft.com/library/en-us/eap/eap/ 1355 eap_start_page.asp, 2005. 1357 [I-D.arkko-eap-service-identity-auth] 1358 Arkko, J. and P. Eronen, "Authenticated Service 1359 Information for the Extensible Authentication Protocol 1360 (EAP)", draft-arkko-eap-service-identity-auth-04 (work in 1361 progress), October 2005. 1363 [I-D.ietf-nfsv4-channel-bindings] 1364 Williams, N., "On the Use of Channel Bindings to Secure 1365 Channels", draft-ietf-nfsv4-channel-bindings-03 (work in 1366 progress), February 2005. 1368 [I-D.ietf-nsis-nslp-natfw] 1369 Stiemerling, M., "NAT/Firewall NSIS Signaling Layer 1370 Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-11 (work in 1371 progress), April 2006. 1373 [I-D.ietf-pana-pana] 1374 Forsberg, D., "Protocol for Carrying Authentication for 1375 Network Access (PANA)", draft-ietf-pana-pana-11 (work in 1376 progress), March 2006. 1378 [I-D.ietf-tls-ecc] 1379 Gupta, V., "ECC Cipher Suites for TLS", 1380 draft-ietf-tls-ecc-12 (work in progress), October 2005. 1382 [I-D.puthenkulam-eap-binding] 1383 Puthenkulam, J., "The Compound Authentication Binding 1384 Problem", draft-puthenkulam-eap-binding-04 (work in 1385 progress), October 2003. 1387 [I-D.tschofenig-nsis-qos-ext-authz] 1388 Tschofenig, H., "Extended QoS Authorization for the QoS 1389 NSLP", draft-tschofenig-nsis-qos-ext-authz-00 (work in 1390 progress), July 2004. 1392 [MADS01] ""Microsoft Authorization Data Specification v. 1.0 for 1393 Microsoft Windows 2000 Operating Systems", April 2000. 1395 [RFC2078] Linn, J., "Generic Security Service Application Program 1396 Interface, Version 2", RFC 2078, January 1997. 1398 [RFC2222] Myers, J., "Simple Authentication and Security Layer 1399 (SASL)", RFC 2222, October 1997. 1401 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1402 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1403 Authentication: Basic and Digest Access Authentication", 1404 RFC 2617, June 1999. 1406 [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, 1407 June 1999. 1409 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 1410 Suites to Transport Layer Security (TLS)", RFC 2712, 1411 October 1999. 1413 [RFC2743] Linn, J., "Generic Security Service Application Program 1414 Interface Version 2, Update 1", RFC 2743, January 2000. 1416 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS 1417 Extensions", RFC 2869, June 2000. 1419 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 1420 Protocol (HTTP) Digest Authentication Using Authentication 1421 and Key Agreement (AKA)", RFC 3310, September 2002. 1423 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1424 Dial In User Service) Support For Extensible 1425 Authentication Protocol (EAP)", RFC 3579, September 2003. 1427 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1428 RFC 3972, March 2005. 1430 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1431 Authentication Protocol (EAP) Application", RFC 4072, 1432 August 2005. 1434 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 1435 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 1437 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 1438 Protocol Method for 3rd Generation Authentication and Key 1439 Agreement (EAP-AKA)", RFC 4187, January 2006. 1441 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1442 Security", RFC 4347, April 2006. 1444 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1445 (HIP) Architecture", RFC 4423, May 2006. 1447 [SAMLOverview] 1448 Hughes, J. and E. Maler, "Security Assertion Markup 1449 Language (SAML) V2.0 Technical Overview", OASIS 1450 document sstc-saml-tech-overview-2.0-draft-08, 1451 September 2005. 1453 [TS29.109] 1454 3rd Generation Partnership Project (3GPP), "Generic 1455 Authentication Architecture (GAA); Zh and Zn Interfaces 1456 based on the Diameter protocol; Stage 3 (Release 6)", 3GPP 1457 TS 29.109 V6.3.0, June 2005. 1459 [TS33.220] 1460 3rd Generation Partnership Project (3GPP), "Generic 1461 Authentication Architecture (GAA); Generic bootstrapping 1462 architecture (Release 6)", 3GPP TS 33.220 V6.5.0, 1463 June 2005. 1465 [TS33.222] 1466 3rd Generation Partnership Project (3GPP), "Generic 1467 Authentication Architecture (GAA); Access to network 1468 application functions using Hypertext Transfer Protocol 1469 over Transport Layer Security (HTTPS) (Release 6)", 3GPP 1470 TS 33.222 V6.4.0, June 2005. 1472 Authors' Addresses 1474 Hannes Tschofenig 1475 Siemens 1476 Otto-Hahn-Ring 6 1477 Munich, Bayern 81739 1478 Germany 1480 Email: Hannes.Tschofenig@siemens.com 1482 Pasi Eronen 1483 Nokia Research Center 1484 P.O. Box 407 1485 FIN-00045 Nokia Group 1486 Finland 1488 Email: pasi.eronen@nokia.com 1490 Intellectual Property Statement 1492 The IETF takes no position regarding the validity or scope of any 1493 Intellectual Property Rights or other rights that might be claimed to 1494 pertain to the implementation or use of the technology described in 1495 this document or the extent to which any license under such rights 1496 might or might not be available; nor does it represent that it has 1497 made any independent effort to identify any such rights. Information 1498 on the procedures with respect to rights in RFC documents can be 1499 found in BCP 78 and BCP 79. 1501 Copies of IPR disclosures made to the IETF Secretariat and any 1502 assurances of licenses to be made available, or the result of an 1503 attempt made to obtain a general license or permission for the use of 1504 such proprietary rights by implementers or users of this 1505 specification can be obtained from the IETF on-line IPR repository at 1506 http://www.ietf.org/ipr. 1508 The IETF invites any interested party to bring to its attention any 1509 copyrights, patents or patent applications, or other proprietary 1510 rights that may cover technology that may be required to implement 1511 this standard. Please address the information to the IETF at 1512 ietf-ipr@ietf.org. 1514 Disclaimer of Validity 1516 This document and the information contained herein are provided on an 1517 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1518 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1519 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1520 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1521 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1522 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1524 Copyright Statement 1526 Copyright (C) The Internet Society (2006). This document is subject 1527 to the rights, licenses and restrictions contained in BCP 78, and 1528 except as set forth therein, the authors retain all their rights. 1530 Acknowledgment 1532 Funding for the RFC Editor function is currently provided by the 1533 Internet Society.