idnits 2.17.00 (12 Aug 2021) /tmp/idnits9304/draft-tschofenig-nsis-gist-security-00.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 1523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1513. ** 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 (October 17, 2005) is 6059 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 1196, but not defined == Missing Reference: 'EAP-Context' is mentioned on line 538, but not defined == Missing Reference: 'AAA-Context' is mentioned on line 539, but not defined == Missing Reference: 'TLS-Options' is mentioned on line 539, but not defined == Unused Reference: 'RFC4081' is defined on line 1435, but no explicit reference was found in the text == Outdated reference: draft-ietf-nsis-ntlp has been published as RFC 5971 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. 'GIST') ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) == Outdated reference: A later version (-03) exists of draft-funk-tls-inner-application-extension-01 -- Possible downref: Normative reference to a draft: ref. 'TLS-IA' == Outdated reference: draft-ietf-tls-psk has been published as RFC 4279 == Outdated reference: A later version (-04) exists of draft-ietf-nfsv4-channel-bindings-03 == Outdated reference: draft-rescorla-dtls has been published as RFC 4347 == Outdated reference: draft-arkko-pppext-eap-aka has been published as RFC 4187 == Outdated reference: draft-ietf-hip-arch has been published as RFC 4423 == 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 -- 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) == Outdated reference: A later version (-04) exists of draft-arkko-eap-service-identity-auth-03 == Outdated reference: draft-ietf-tls-ecc has been published as RFC 4492 Summary: 5 errors (**), 0 flaws (~~), 18 warnings (==), 12 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: April 20, 2006 P. Eronen 5 Nokia 6 October 17, 2005 8 Analysis of Options for Securing the Generic Internet Signaling 9 Transport (GIST) 10 draft-tschofenig-nsis-gist-security-00.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 April 20, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 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 . . . . . . . . 6 57 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 58 2.2. Proposal Discussion . . . . . . . . . . . . . . . . . . . 6 59 2.3. GIST API Viewpoint . . . . . . . . . . . . . . . . . . . . 6 60 2.4. GIST Protocol Viewpoint . . . . . . . . . . . . . . . . . 8 61 2.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 3. Extensible Authentication Protocol (EAP) . . . . . . . . . . . 11 63 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . 13 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) . . . . . . . . 24 77 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 24 78 4.2. Proposal Discussion . . . . . . . . . . . . . . . . . . . 25 79 4.3. GIST API Viewpoint . . . . . . . . . . . . . . . . . . . . 26 80 4.4. GIST Protocol Viewpoint . . . . . . . . . . . . . . . . . 27 81 4.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 27 82 5. Discussion and Conclusions . . . . . . . . . . . . . . . . . . 30 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 32 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 90 Intellectual Property and Copyright Statements . . . . . . . . . . 36 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 [NATFW] placed "near" the NAS 193 (Network Access Server) might be able to assume that any packet it 194 receives from its NAS-side interface comes from a valid customer of 195 the ISP, and that the client who sent the packet is the current 196 "owner" of the IP address found in the source address field. This 197 assumption depends on specific characteristics of the environment: 198 the NAS provides access only to authenticated customers and prevents 199 IP spoofing by other clients; possibly additional link-layer security 200 mechanisms are used to secure the link between the client and the 201 NAS; and the network between the NAS and the NAT/firewall is 202 "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 [TLS-PSK], 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 [DTLS] 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 [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 [GIST]; the protection is not applied to datagram mode 317 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 349 UDP(GIST-Query( 350 Common-Header, 351 Message-Routing-Information=MRI1, 352 Session-Identification, 353 Network-Layer-Information, 354 Query-Cookie, 355 Stack-Proposal=Forwards-TCP+TLS-Certificates, 356 Stack-Configuration-Data=NONE)) --> 358 Eventually this reaches host B and it replies 360 <-- UDP(GIST-Response( 361 Common-Header, 362 Message-Routing-Information=MRI2, 363 Session-Identification, 364 Network-Layer-Information=IP_B, 365 Query-Cookie, 366 Responder-Cookie, 367 Stack-Proposal=Forwards-TCP+TLS-Certificates, 368 Stack-Configuration-Data=PORT_B)) 370 Next, host A establishes a TCP connection to IP_B:PORT_B, and starts 371 the TLS handshake 373 TLS(ClientHello) --> 375 <-- TLS(ServerHello, Certificate=CERT_B, [ServerKeyExchange], 376 CertificateRequest, ServerHelloDone) 378 TLS(Certificate=CERT_A, ClientKeyExchange, Finished) --> 380 <-- TLS(Finished) 382 On host A, GIST now asks the NSLP to verify the certificates before 383 actually sending the NSLP data: 385 Host A: NSLP <-- GIST 386 MessageStatus(NSLP-Message-Handle=H1, Transfer-Attributes: 387 Security=integrity+confidentiality, Mechanism=tls-certificates, 388 Peer-Certificates=CERT_B, TLS-Options) 390 Host A: NSLP --> GIST: 391 OK 393 Next GIST sends the Confirm message containing the actual NSLP data: 395 TLS(GIST-Confirm(Common-Header, 396 Message-Routing-Information=MRI1, 397 Session-Identification, 398 Network-Layer-Information, 399 Responder-Cookie, 400 Stack-Proposal=Forwards-TCP+TLS-Certificates, 401 NSLP-Data=DATA1)) --> 403 GIST on host B delivers the message to the NSLP, together with 404 the peer certificate and other security-related attributes: 406 Host B: GIST --> NSLP 407 RecvMessage(NSLP-Data=DATA1, MRI=MRI1, 408 Transfer-Attributes: Security=integrity+confidentiality, 409 Mechanism=tls-certificates, Peer-Certificate=CERT_A, 410 TLS-Options) 412 The message is now processed by the NSLP, which may eventually decide 413 to reply... 415 Host B: GIST <-- NSLP: 416 SendMessage(NSLP-Data=DATA2, MRI=MRI2, 417 Transfer-Attributes: Security=integrity+confidentiality, 418 Mechanism=tls-certificates, Peer-Certificate=CERT_B, ...) 420 <-- TLS(GIST-Data(Common-Header, 421 Message-Routing-Information=MRI2, 422 Session-Identification, 423 NSLP-Data=DATA2)) 425 GIST on Host A delivers the message to NSLP: 427 Host A: NSLP <-- GIST 428 RecvMessage(NSLP-Data=DATA2, MRI=MRI2, 429 Transfer-Attributes: Security=integrity+confidentiality, 430 Mechanism=tls-certificates, Peer-Certificate=CERT_B, ...) 432 NSLP processes the message. 434 3. Extensible Authentication Protocol (EAP) 436 3.1. Introduction 438 In order to support different deployment scenarios, NSIS signaling 439 should have flexible authentication and authorization capabilities. 440 This can be achieved by interacting with the AAA infrastructure for 441 computing the authorization decision of various NSLP requests. To 442 support existing credentials and the large number of different usage 443 scenarios, the Extensible Authentication Protocol (EAP) might be 444 reused. EAP provides the following capabilities: 446 o Flexible support for authentication and key exchange protocols. 448 o Ability to reuse existing long-term credentials and already 449 deployed authentication and key exchange protocols (for example, 450 the UMTS-AKA) 452 o Integration into the existing AAA infrastructure, namely RADIUS 453 [RFC2869] and Diameter [RFC4072]. 455 o Ability to execute the authorization decision at the user's home 456 network based on the capabilities of protocols like RADIUS and 457 Diameter. 459 EAP is not the only security framework that could be used. Others, 460 such as the GSS-API (see [RFC2078] and [RFC2743]) or SASL [RFC2222], 461 could theoretically also be used but are from a functional point of 462 view very similar and therefore not explored here. The lack of 463 integration of the GSS-API and SASL into the AAA infrastructure 464 (except for very simple password and challenge-based authentication) 465 makes EAP the preferred choice. 467 As EAP alone does not provide mechanisms for data origin 468 authentication or encrypting the actual NSIS messages, it has to be 469 used together with another protocol. 471 Three main choices 473 o TLS Inner Application [TLS-IA] 475 o TLS (unauthenticated Diffie-Hellman) below GIST, with channel 476 bindings to EAP run in NSLP. 478 o Intermediate "TLS/EAP-shim" layer above TLS (unauthenticated 479 Diffie-Hellman) but below GIST. This has the advantage of not 480 requiring modifications to the individual NSLPs but thas the 481 disadvantage of lacking the knowledge about the specific 482 authorization requirements. Since this approach is very similar 483 to the previous one from an encoding and protocol point of view we 484 will omit the description in this version of the document. 486 Note that TLS I/A does not preclude the use of certificate based 487 authentication of the server to the client and vice versa. In fact, 488 the usage of certificates for server-based authentication is 489 recommended. 491 The aspect of enhancing NSIS with an RSVP alike integrity object or 492 the usage of the Cryptographic Message Syntax (CMS) [RFC2630] that 493 use the EAP derived session key for signaling message protection is 494 not considered in this version of the document and is left for 495 further study. 497 3.2. EAP with TLS Inner Application 499 3.2.1. Introduction 501 TLS I/A provides a means to perform EAP-based user authentication 502 between the EAP client and the EAP server integrated within the TLS 503 handshake. TLS I/A can thus be used both for flexible user 504 authentication within a TLS session and as a basis for tunneled 505 authentication within EAP. The TLS I/A approach is to insert an 506 additional message exchange between the TLS handshake and the 507 subsequent data communications phase. This message exchange is 508 carried in a new record type, which is distinct from the record type 509 that carries upper layer data. Thus, the data portion of the TLS 510 exchange becomes available for NSIS (or another protocol that needs 511 to be secured). 513 3.2.2. Proposal Discussion 515 When authentication and key exchange is provided with TLS I/A (and 516 therefore the embedded EAP exchange) then the specific NSLP payloads 517 are not yet processed. Hence, authorizing the specific NSLP 518 operation (such as a request for reserving a certain amount of 519 bandwidth) can only be provided at the QoS NSLP layer. As such, the 520 AAA interaction triggered as part of the TLS I/A (and the EAP method 521 processing) performs only authentication, key establishment and a 522 separate exchange might be required at the NSLP. 524 The main advantage of this approach is that it does not require 525 modifications for the NSIS protocol suite since the EAP exchange is 526 encapsulated within the TLS Handshake exchange. 528 3.2.3. GIST API Viewpoint 530 The GIST API for usage of TLS I/A might need to be make TLS based 531 credentials and the EAP capabilities visible in the abstract GIST 532 API. This allows different NSLPs to use different security 533 mechanisms. 535 For the first procedure, the previously defined primitive needs to be 536 refined in order to offer an abstract API: 538 ConfigureSecurity(Mechanism, [EAP-Context], [Local-Certificates, 539 Local-Key], [AAA-Context], [TLS-Options]) 541 Mechanism: 'tls-ia-eap' 543 EAP-Context: This parameter is present only on the "client" side, 544 and contains information to be used during the EAP authentication 545 (which EAP method, what credentials, etc.). 547 Local-Certificates: This parameter is present only on the 548 "network" side, and contains certificates that will be presented 549 to the client during the TLS handshake. If authentication is 550 based solely on a mutually authenticating EAP method, certificates 551 can be omitted. 553 Local-Key: A private key (or a "handle" to a private key) 554 corresponding to Local-Certificates. 556 AAA-Context: This parameter is present only on the "client" side, 557 and contains information needed to operate as EAP "pass-through" 558 authenticator; i.e., information about the AAA protocol and its 559 details. 561 TLS-Options: As described in Section 2.3. 563 For SendMessage, MessageStatus, and RecvMessage, we define a number 564 of security-related Transfer-Attributes. Please note that public key 565 based server authentication inside the TLS handshake might be support 566 and alternatively an unauthenticated TLS handshake is used. 568 Security: 'integrity' and optionally 'confidentiality' 570 Mechanism: 'tls-ia-eap' 572 Peer-Certificates: This parameter is present only on the "client" 573 side. In MessageStatus and RecvMessage primitives, the list of 574 X.509 certificates presented during the TLS handshake (if any). 575 The first certificate contains the public key actually 576 authenticated by TLS. In SendMessage primitive, this parameter 577 can be omitted; if included, it includes the end entity 578 certificate that must be authenticated during the TLS handshake. 580 EAP-Information: On the "client" side, information that has been 581 provided by the EAP method (or in SendMessage primitive, has to be 582 provided). The exact details depend on the EAP method in 583 question, but typically includes the EAP method used and 584 identifiers authenticated during the EAP exchange. Since there is 585 no standarized EAP API it is difficult to provide a full set of 586 details. Proprietary APIs (such as [EAP-API]) might give some 587 ideas about the needed parameters. 589 AAA-Information: On the "network" side, information that has been 590 provided by the AAA infrastructure (or in SendMessage primitive, 591 has to be provided). The exact details depend on the AAA 592 infrastructure and its configuration, but the AAA server could, 593 for instance, provide information about what identities were 594 authenticated and what types of NSIS requests the client is 595 authorized to make. 597 TLS-Options: As described in Section 2.3. 599 3.2.4. GIST Protocol Viewpoint 601 From a GIST point of view, the TLS Record Layer is used to secure 602 reliable messaging over TCP. Thus, it is used together with the 603 Forwards-TCP protocol defined in [GIST]; the protection is not 604 applied to datagram mode messages. 606 A new MA-Protocol-ID value, "TLS-I/A", may need to be assigned to 607 allow the negotiation of TLS I/A using the Stack-Proposal object in 608 the GIST-Query/Response phase. Alternatively, a Stack-Proposal for 609 "TLS" is indicated and the support for TLS I/A is indicated as part 610 of the ciphersuite negotiation. 612 3.2.5. Example 614 The following example shows the interaction of GIST / QoS NSLP with 615 TLS I/A. In the following example we assume that server-side 616 authentication using certificates is provided within TLS I/A. Client- 617 side authentication is provided using a specific EAP method (such as 618 EAP-AKA). 620 When a NSLP is started, the server side of the communication must at 621 least configure the key/certificate for accepting messaging 622 associations protected with TLS. 624 Host A NSLP --> GIST: 625 ConfigureSecurity(Mechanism=tls-ia-eap, 626 EAP-Context={EAP-AKA, local USIM card, ...}) 628 Host B: GIST <-- NSLP 629 ConfigureSecurity(Mechanism=tls-ia-eap, 630 Local-Certificates=CERT_B, Local-Key=KEY_B, 631 AAA-Context={Diameter EAP, ...}) 633 Later, host A's NSLP sends a message 635 Host A: NSLP --> GIST: 636 SendMessage(NSLP-Data=DATA1, NSLP-Message-Handle=H1, 637 MRI=MRI1, Transfer-Attributes: Security=integrity+confidentiality, 638 Mechanism=tls-ia-eap, ...) 640 GIST notices that a new messaging association is needed, and 641 initiates Query/Response 643 UDP(GIST-Query( 644 Common-Header, 645 Message-Routing-Information=MRI1, 646 Session-Identification, 647 Network-Layer-Information, 648 Query-Cookie, 649 Stack-Proposal=Forwards-TCP+TLS-IA-EAP, 650 Stack-Configuration-Data=NONE)) --> 652 Eventually this reaches host B and it replies 654 <-- UDP(GIST-Response( 655 Common-Header, 656 Message-Routing-Information=MRI2, 657 Session-Identification, 658 Network-Layer-Information=IP_B, 659 Query-Cookie, 660 Responder-Cookie, 661 Stack-Proposal=Forwards-TCP+TLS-IA-EAP, 662 Stack-Configuration-Data=PORT_B)) 664 Next, host A establishes a TCP connection to IP_B:PORT_B, and starts 665 the TLS handshake. The InnerApplicationExtension TLS extension 666 indicates that TLS I/A will be used. 668 TLS(ClientHello, InnerApplicationExtension) --> 670 <-- TLS(ServerHello, InnerApplicationExtension, 671 Certificate=CERT_B, [ServerKeyExchange], 672 ServerHelloDone) 674 TLS(ClientKeyExchange, Finished) --> 676 <-- TLS(Finished) 678 Next, the EAP exchange begins. On the "network" side, EAP messages 679 are not processed by the NSIS responder, but rather a separate AAA 680 server. 682 TLS(ApplicationPayload={EAP-Response, Identity, 683 joe@example.com}) --> 685 <-- TLS(ApplicationPayload={EAP-Request, AKA-Challenge, ...}) 687 TLS(ApplicationPayload={EAP-Response, AKA-Challenge, ..}) --> 689 <-- TLS(FinalPhaseFinished) 691 TLS(FinalPhaseFinished) --> 693 On host A, GIST now asks the NSLP to verify the certificates and 694 the result of EAP authentication before ctually sending the NSLP 695 data: 697 Host A: NSLP <-- GIST 698 MessageStatus(NSLP-Message-Handle=H1, Transfer-Attributes: 699 Security=integrity+confidentiality, Mechanism=tls-ia-eap, 700 Peer-Certificates=CERT_B, EAP-Information=..., TLS-Options) 702 Host A: NSLP --> GIST: 703 OK 705 Next GIST sends the Confirm message containing the actual NSLP data: 707 TLS(GIST-Confirm(Common-Header, 708 Message-Routing-Information=MRI1, 709 Session-Identification, 710 Network-Layer-Information, 711 Responder-Cookie, 712 Stack-Proposal=Forwards-TCP+TLS-IA-EAP, 713 NSLP-Data=DATA1)) --> 715 GIST on host B delivers the message to the NSLP in addition 716 to the information about the client authentication: 718 Host B: GIST --> NSLP 719 RecvMessage(NSLP-Data=DATA1, MRI=MRI1, 720 Transfer-Attributes: Security=integrity+confidentiality, 721 Mechanism=tls-ia-eap, AAA-Information=..., TLS-Options) 723 The message is now processed by the NSLP, which may eventually decide 724 to reply... 726 Host B: GIST <-- NSLP: 727 SendMessage(NSLP-Data=DATA2, MRI=MRI2, 728 Transfer-Attributes: Security=integrity+confidentiality, 729 Mechanism=tls-ia-eap, ...) 731 <-- TLS(GIST-Data(Common-Header, 732 Message-Routing-Information=MRI2, 733 Session-Identification, 734 NSLP-Data=DATA2)) 736 GIST on Host A delivers the message to NSLP: 738 Host A: NSLP <-- GIST 739 RecvMessage(NSLP-Data=DATA2, MRI=MRI2, 740 Transfer-Attributes: Security=integrity+confidentiality, 741 Mechanism=tls-ia-eap, Peer-Certificates=CERT_B, 742 EAP-Information=..., TLS-Options) 744 NSLP processes the message. 746 3.3. EAP in NSLP 748 3.3.1. Introduction 750 This section describes the aspects of the EAP integration into the 751 NSLP. It should be noted that integrating EAP encapsulation into QoS 752 signaling protocol is more than just adding an object into the QoS 753 message exchange. The suggested enhancement of supporting EAP based 754 authentication and authorization for the QoS signaling needs to be 755 investigated for the impact of the integration on the QoS signaling 756 protocol framework. The aspect of authentication and authorization 757 in the QoS environment has raised a number of security concerns in 758 the past. 760 +-----------+ 761 |Entity C | 762 |authorizing| 763 |resource | 764 |request | 765 +----------++ 766 ^ | 767 | | 768 QoS | | QoS 769 authz| |authz 770 req.| | res. 771 | | 772 | v 773 +----------+QoS RESERVE +-+---------+ QoS RESERVE +-----------+ 774 |End Host A|-------------->|Router 1 |------------->|End Host B | 775 |requesting| |performing | ........ |performing | 776 |QoS |QoS RESPONSE |QoS | QoS RESPONSE |QoS | 777 |resource |<--------------|reservation|<-------------|reservation| 778 +----------+ +-----------+ +-----------+ 780 3.3.2. Proposal Discussion 782 For integrating EAP into a NSLP application a new NSLP payload object 783 should be defined to carry the EAP packets. The EAP session will be 784 established between a QoS-NSLP initiator (Host A), a QoS-NSLP policy 785 aware node (Router 1) and an Authorizing entity (Entity C). Node A 786 and Router 1 insert the EAP packets into exchanged QoS-NSLP messages 787 between them and are the EAP peer and EAP authenticator in the 788 session. The Router 1 communicates with Entity C (EAP server) via 789 AAA infrastructure and completes the EAP session. Other IETF 790 protocols that decided to use EAP have analyzed some aspects of EAP 791 integration already, such as PANA [PANA]. This experience is reused 792 for identification of the following aspects that necessitate further 793 investigation: 795 Transport requirements of EAP and their support by the NSIS 796 framework. EAP itself is a container, and sets requirements on 797 specific transport service features - fragmentation, reliability, 798 in-order delivery and retransmission. 800 Seamless integration of EAP into the QoS-NSLP message processing. 802 Number of security considerations related to inter-working with 803 lower layer security mechanism (if present) or trust placed on the 804 QoS NSLP policy aware node or provision of secured transport 805 methods for QoS NSLP messages, utilizing the resulting exchanged 806 EAP method session keys. 808 In more details, two approaches are investigated in [EAP-QoS] for 809 provision of transport integration between EAP and the NSIS 810 framework. The first one does not introduce any new requirements on 811 the NSIS framework but suggest that the used EAP methods should deal 812 with fragmentation, reliability and re-transmission of the EAP data 813 into the QoS NSLP messages. However, this approach loads QoS NSLP 814 application with functions that are not specific to it (e.g., 815 fragmentation). In the second approach, QoS-NSLP should request 816 reliable transmission for the messages of the signaling session, 817 which involves EAP authentication and authorization. Reliable 818 transport service provided by GIST utilizing TCP and SCTP protocols 819 includes fragmentation and in-order delivery. Considering that a MA 820 establishment (for reliable transport) may be initiated only by the 821 requesting (upstream) peer, additional attention should be paid to 822 the case in which the QoS-NSLP initiator is not initially aware of 823 the EAP usage and does not request reliable transmission from the 824 GIST layer [EAP-QoS]. 826 Each of the two protocols, EAP and QoS-NSLP, has its message 827 processing rules and state machines. Desired integration of both 828 protocols should not require adjustment or even extension of the QoS- 829 NSLP message exchange. [EAP-QoS] shows that a proper encapsulation 830 of the EAP payloads into QoS NSLP Reserve/Query/Response messages 831 allows a seamless inter-working 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 [EAPBinding]. For example, when running EAP over TLS (as 838 analyzed in [EAPBinding]) the two exchanges need to be 839 cryptographically tied together. This can be accomplished using a 840 number of ways including combining the session keys of both exchanges 841 into additionally generated so called Compound Message Keys according 842 to [EAPBinding]. If the transport layer is secured by TLS and 843 additional authentication and authorization is provided at the QoS 844 signaling layer then the same MITM vulnerabilities need to be 845 addressed. In the NSIS case, these two exchanges are handled at two 846 different NSIS layers. Hence, additional security attributes need to 847 be exchanged through the API between the transport and the QoS 848 signaling layer. Currently, the GIST specification does not provide 849 a strict API specification. Instead, a few clarifying hints to the 850 implementers are given. Specifying additional security attributes, 851 e.g., EAP method derived session keys to be pushed to the GIST layer, 852 are therefore possible. This is, however, not the only obstacle: 853 Exporting keying material from TLS or IKE/IPsec using standard 854 mechanisms in order to combine it with the EAP method derived keying 855 material to compute a Compound Message Key is difficult. 857 Alternatively, if mutual authentication is provided with TLS to 858 secure GIST signaling then the authenticated identities of both peers 859 can be exchanged via the existing API definition and used to create a 860 binding. 862 Another common problem for EAP is the validation of the authorization 863 rights of the EAP Authenticator (QoS policy aware NE) that functions 864 in pass-through mode. An adversary might identify itself to the EAP 865 peer and the EAP server with a different identity or a different 866 role. This vulnerability is known as the 'Lying NAS' problem. For 867 example, in the QoS signaling case, an attacker might act as QoS 868 policy aware NE and could misuse an EAP exchange to create the 869 illusion for the EAP server that the context is different (e.g., 870 wireless LAN access instead of wired access). Then a user, who is 871 authenticated and authorized through the usage of EAP, might be 872 charged for services that he has not received. 874 In the currently discussed framework, EAP should be used to provide 875 authentication and the session key as part of an AAA application, 876 which is responsible for providing the authorization decision, based 877 on an EAP method that authenticates the user identity. This implies 878 that a QoS policy aware NE should be authenticated and authorized to 879 be one side in an AAA QoS Authorization session. In addition, the 880 authorization decision is based not only on an authenticated 881 identity, but also on the description of requested QoS parameters, 882 which would clearly identify the type of the requested service. It 883 should be noted that the second case is valid only if integrity 884 protection of the exchanged QoS data is available between the End 885 Host and the Authorizing entity. In addition, the problem in general 886 is identified and addressed by some EAP extensions, e.g., 887 [ServiceInfoAuth]. These solutions carry additional authorization 888 related data between the EAP peer and EAP server. However, all above 889 considerations that address the problem do not involve any change to 890 the interworking between EAP and QoS signaling 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 [EAPBinding], there are several different ways to 910 bind the channel at GIST layer with the EAP authentication. From 911 layering point of view, it seems that the simplest option would be to 912 pass channel binding information from the GIST layer to the NSLP, and 913 let the NSLP do the binding. In particular, [ChannelBindings] 914 contains a suggestion for channel binding information in the TLS 915 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 [GIST]; the protection is not applied to datagram mode messages. 925 A new MA-Protocol-ID value, "NSLP-EAP", may need to be assigned to 926 allow the negotiation of EAP usage in the NSLP using the Stack- 927 Proposal object in the GIST-Query/Response phase. This would allow 928 an NSIS node to indicate the ability to support this functionality 929 and to thereby avoid relying on a policy for client-side TLS 930 authentication which thereby is provided by EAP at a later stage in 931 the protocol exchange. 933 3.3.5. Example 935 An example message flow is shown in Figure 7 which uses the EAP-AKA 936 method [EAP-AKA] for authentication and session key establishment. 937 Please note that the AAA messages triggered by this exchange are not 938 shown for editorial reasons. 940 +---------+ +---------+ 941 | MN | | R1 | 942 +---------+ +---------+ 943 (a) + <---------------------------------------------> + 944 | Discovery Request/Response (NTLP) | 945 | | 946 (b) | ----------------------------------------------> | 947 | C-Mode | 948 | NTLP/NSLP QoS RESERVE | 949 | (EAP-Auth/Authz requested; | Initial 950 | EAP-Identity) | Setup 951 | | 952 (c) | <---------------------------------------------- | 953 | C-Mode | 954 | NTLP/NSLP QoS QUERY . | 955 | (EAP-Request/AKA-Challenge | 956 | (AT_RAND, AT_AUTN, AT_MAC)) | 957 | (Algorithm/Parameter Negotiation) | 958 (d) | ----------------------------------------------> | 959 | C-Mode | 960 | NTLP/NSLP QoS RESPONSE | 961 | (EAP-Response/AKA-Challenge | 962 | (AT_RES, AT_MAC)) | 963 | (Algorithm/Parameter Negotiation) | 964 +~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~+ 965 (e) | Authentication Authorization finished | 966 | Secure TLS tunnel established | 967 +~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~+ 968 (f) | <---------------------------------------------- | 969 | NTLP/NSLP QoS RESPONSE | 970 | (EAP-Success) | 971 | ----------------------------------------------> | 972 | NTLP/NSLP QoS RESERVE | 973 | (Secure Confirmation) | 974 | | 975 + + 976 .......... 977 + + 978 | ----------------------------------------------> | 979 (g) | NTLP/NSLP QoS REFRSH msg | Refresh 980 | | Msg 981 | <---------------------------------------------- | 982 | NTLP/NSLP QoS ACK msg | 983 + + 985 Figure 7: EAP based Auth/Authz exchange using EAP-AKA 987 The message exchange shown in Figure 7 starts with the optional 988 discovery of the next QoS NSLP aware node (messages (a)). The first 989 QoS NSLP message with a resource request is sent with the Network 990 Access Identity and a request to perform EAP-based authentication 991 (message (b)). Note that this exchange assumes that the EAP-Request/ 992 Identity and the EAP-Response/Identity exchange is omitted. This 993 exchange is optional in EAP if the identity can be provided by other 994 means. Router 1 contacts the AAA infrastructure, and the EAP server 995 starts the message exchange. The AAA message communication is not 996 shown. Subsequently, two messages (messages (c) and (d)) are 997 exchanged between the EAP peer and the EAP server which contain EAP- 998 AKA specific information. After successful authentication and 999 authorization, session keys are derived and provided to R1 via AAA 1000 mechanisms (see [RFC4072] and [RFC3579]). These session keys can 1001 then be used to protect subsequent NSLP messages as indicated by (e). 1002 The EAP-Success message can already experience such a protection (see 1003 message (f)). Furthermore, it is useful to repeat the previously 1004 sent objects. Subsequent refresh messages (g) are protected with the 1005 previously established session keys and are therefore associated with 1006 the previous authentication and authorization protocol execution. 1008 4. 3GPP Generic Bootstrapping Architecture (GBA) 1010 4.1. Introduction 1012 The 3GPP Generic Bootstrapping Architecture (GBA), specified in 1013 [TS33.220], is an authentication system with three parties: a trusted 1014 third party (called Bootstrapping Server Function or BSF), is 1015 involved in authentication and key exchange between two other nodes, 1016 a client (called User Equipment or UE) and server (called Network 1017 Application Function or NAF). 1019 The goal of the architecture is to isolate knowledge of long-term 1020 secrets and credentials to a single trusted node, the BSF. The 1021 actual servers (NAFs) do not have access to the clients' long-term 1022 credentials, and indeed, do not even have to know exactly what kinds 1023 of credentials (such as smart cards) were used between the client and 1024 the BSF. 1026 In a simple case, the authentication process is as follows (also 1027 depicted in the figure below). 1029 +--------+ +------+ +-----+ 1030 | client | |server| | BSF | 1031 +--------+ +------+ +-----+ 1032 | | | 1033 1. | Authenticate and agree | | 1034 | on B-TID and key Ks | | 1035 |<----------------------------------------------->| 1036 | | | 1037 2. | Initiate connection | | 1038 | and send B-TID | | 1039 |------------------------>| | 1040 +-------------+ | | 1041 |Derive Ks_NAF| | | 1042 +-------------+ | | 1043 | | B-TID | 1044 3. | |---------------------->| 1045 | | +-------------+ 1046 | | |Derive Ks_NAF| 1047 | | +-------------+ 1048 | | Ks_NAF, IMPI, | 1049 | | user profile | 1050 | |<----------------------| 1051 4. | Authenticate using | | 1052 | Ks_NAF | | 1053 |<----------------------->| | 1054 | | | 1056 1. First, the client contacts the Bootstrapping Server Function 1057 (BSF) and they authenticate each other using long-term 1058 credentials. This usually involves contacting back-end 1059 authentication databases such as the Home Subscriber System 1060 (HSS). As a result of the authentication, the client and BSF 1061 share a secret session key (Ks) and a Bootstrapping Transaction 1062 Identifier (B-TID) identifying the key and other related state. 1063 Currently the authentication between the client and BSF is based 1064 UMTS Subscriber Identity Module (USIM) smart cards and HTTP 1065 Digest AKA protocol [RFC3310]. However, it is assumed that in 1066 the future, other authentication mechanisms may be added between 1067 the client and BSF. 1069 2. When the client contacts a server (NAF) it wants to authenticate 1070 to, it sends the transaction identifier (B-TID) to the server. 1072 3. The server then sends the B-TID to the BSF, and gets back a 1073 server-specific key (Ks_NAF), the user's permanent identity (IP 1074 Multimedia Private Identity or IMPI) and application-specific 1075 parts of the user profile. This is done using the Diameter-based 1076 Zn interface specified in [TS29.109] 1078 4. Finally, the client and server authenticate each other using the 1079 server-specific key (Ks_NAF). How exactly this authentication is 1080 done depends on the protocol used between the client and the 1081 server; this again depends on what exactly the service is. 1082 Currently, [TS33.222] specifies that HTTP-based services can use 1083 either HTTP Digest authentication [RFC2617] or TLS pre-shared key 1084 ciphersuites [TLS-PSK]. 1086 4.2. Proposal Discussion 1088 In this section, we consider how 3GPP Generic Bootstrapping 1089 Architecture (GBA) can be used to protect GIST messages. Since GBA 1090 is by its nature asymmetric, we assume that the querying node is the 1091 client (3G User Equipment) and the responder node is a node in the 3G 1092 network (in the role of Network Application Function). 1094 The most promising approach seems to use something like the pre- 1095 shared key TLS [TLS-PSK] in a fashion resembling GAA HTTPS services 1096 [TS33.222]. However, the HTTPS approach assumes the querying node 1097 (3G terminal) knows the FQDN of the responding node beforehand. This 1098 would limit the use of GBA to certain message routing methods. 1099 Instead, we decided to communicate the FQDN in GIST-Response message, 1100 and assume the client can verify whether the FQDN looks correct or 1101 not. 1103 4.3. GIST API Viewpoint 1105 The asymmetric nature of GBA is reflected in the GIST API as well: 1106 the security-related details contained in the Transfer-Attributes 1107 parameter are different on the client and server side. 1109 o When sending a message, the NSLP can verify the server's NAF_ID 1110 (or client's IMPI and user profile) before the message is actually 1111 sent. This is done using the MessageStatus primitive; the 1112 identities and other security details are contained n the 1113 Transfer-Attributes parameter. 1115 o When a message is received, the identities and other security 1116 details are given to the NSLP for verification, contained in the 1117 Transfer-Attributes parameter of the RecvMessage primitive. 1119 o When sending a message, the NSLP can also specify the peer's 1120 identity (NAF_ID or IMPI) explicitly; this is useful when the NSLP 1121 wants to send a message to the same peer a message received from. 1123 For SendMessage, MessageStatus, and RecvMessage, we define a number 1124 of security-related Transfer-Attributes: 1126 Security: 'integrity' and optionally 'confidentiality' 1128 Mechanism: 'tls-gba' 1130 Peer-NAF-ID: This parameter is present only on the "client" 1131 (mobile terminal) side. In MessageStatus and RecvMessage 1132 primitives, it contains the NAF identifier (FQDN) that was 1133 authenticated using GBA/TLS procedures. In SendMessage primitive, 1134 this parameter can be omitted; if included, it specifies the NAF 1135 identifier that must be authenticated. 1137 Peer-IMPI: This parameter is present only on the "network" (NAF) 1138 side. In MessageStatus and RecvMessage primitives, it contains 1139 the user identity (IMPI) that was authenticated using GBA/TLS 1140 procedures. In SendMessage primitive, this parameter can be 1141 omitted; if included, it specifies the user identity that must be 1142 authenticated. 1144 Peer-User-Profile: This parameter is present only on the "network" 1145 (NAF) side. In MessageStatus and RecvMessage primitives, it 1146 contains the application-specific part of the user profile 1147 received from the BSF. 1149 TLS-Options: Information about TLS details, such as exactly which 1150 ciphersuite was chosen and what properties (algorithm, strength, 1151 perfect forward secrecy) it has. 1153 4.4. GIST Protocol Viewpoint 1155 From GIST point of view, TLS-GBA looks similar to TLS with 1156 certificates. A new MA-Protocol-ID, "TLS-GBA", needs to be assigned. 1158 4.5. Example 1160 Host A's NSLP sends a message 1162 Host A: NSLP --> GIST: 1163 SendMessage(NSLP-Data=DATA1, NSLP-Message-Handle=H1, 1164 MRI=MRI1, Transfer-Attributes: Security=integrity+confidentiality, 1165 Mechanism=tls-gba, ...) 1167 GIST notices that a new messaging association is needed, and 1168 initiates Query/Response 1170 UDP(GIST-Query( 1171 Common-Header, 1172 Message-Routing-Information=MRI1, 1173 Session-Identification, 1174 Network-Layer-Information, 1175 Query-Cookie, 1176 Stack-Proposal=Forwards-TCP+TLS-GBA, 1177 Stack-Configuration-Data=NONE)) --> 1179 Eventually this reaches host B and it replies 1181 <-- UDP(GIST-Response( 1182 Common-Header, 1183 Message-Routing-Information=MRI1, 1184 Session-Identification, 1185 Network-Layer-Information=IP_B, 1186 Query-Cookie, 1187 Responder-Cookie, 1188 Stack-Proposal=Forwards-TCP+TLS-GBA, 1189 Stack-Configuration-Data=PORT_B, NAF_ID_B)) 1191 Next, host A establishes a TCP connection to IP_B:PORT_B, and starts 1192 the TLS handshake: 1194 TLS(ClientHello, ServerName(NAF_ID_B)) --> 1196 <-- TLS(ServerHello, [ServerKeyExchange], ServerHelloDone) 1198 TLS(ClientKeyExchange(B-TID), Finished) --> 1200 Host B fetches the key (Ks_NAF) and the application-specific part of 1201 the user profile from the BSF. This is done using the Diameter-based 1202 Zn interface specified in [TS29.109]. 1204 <-- TLS(Finished) 1206 On host A, GIST now asks the NSLP to verify the certificates before 1207 actually sending the NSLP data: 1209 Host A: NSLP <-- GIST 1210 MessageStatus(NSLP-Message-Handle=H1, Transfer-Attributes: 1211 Security=integrity+confidentiality, Mechanism=tls-gba, 1212 Peer-NAF-ID=NAF_ID_B, TLS-Options) 1214 Host A: NSLP --> GIST: 1215 OK 1217 Next GIST sends the Confirm message containing the actual NSLP data: 1219 TLS(GIST-Confirm(Common-Header, 1220 Message-Routing-Information=MRI1, 1221 Session-Identification, 1222 Network-Layer-Information, 1223 Responder-Cookie, 1224 Stack-Proposal=Forwards-TCP+TLS-GBA, 1225 NSLP-Data=DATA1)) --> 1227 GIST on host B delivers this to the NSLP, together with the peer 1228 identity (IMPI), application-specific parts of the user profile, 1229 and other security-related attributes: 1231 Host B: GIST --> NSLP 1232 RecvMessage(NSLP-Data=DATA1, MRI=MRI1, 1233 Transfer-Attributes: Security=integrity+confidentiality, 1234 Mechanism=tls-gba, Peer-IMPI=IMPI_A, Peer-User-Profile=..., 1235 TLS-Options) 1237 The message is now processed by the NSLP, which may eventually decide 1238 to reply... 1240 Host B: GIST <-- NSLP: 1241 SendMessage(NSLP-Data=DATA2, MRI=MRI2, 1242 Transfer-Attributes: Security=integrity+confidentiality, 1243 Mechanism=tls-gba, Peer-IMPI=IMPI_A, ...) 1245 <-- TLS(GIST-Data(Common-Header, 1246 Message-Routing-Information=MRI2, 1247 Session-Identification, 1248 NSLP-Data=DATA2)) 1250 GIST on Host A delivers the message to NSLP: 1252 Host A: NSLP <-- GIST 1253 RecvMessage(NSLP-Data=DATA2, MRI=MRI2, 1254 Transfer-Attributes: Security=integrity+confidentiality, 1255 Mechanism=tls-gba, Peer-NAF-ID=NAF_ID_B, ...) 1257 NSLP processes the message. 1259 5. Discussion and Conclusions 1261 We have examined how three different types of existing security 1262 infrastructure, namely X.509 PKI, EAP/AAA and 3GPP GBA, can be used 1263 to secure GIST messaging. In all three cases, the TLS record layer 1264 provides encryption and integrity protection for NSLP messages; the 1265 differences are in how the authentication, key exchange, and 1266 authorization work. All three cases assume the existence of an 1267 infrastructure beyond what is defined in TLS: either a PKI where the 1268 infrastructure elements are not actively involved during the GIST 1269 messaging, or on-line AAA/bootstrapping servers. 1271 These three cases are not meant to be exhaustive. Some options that 1272 have not yet been analyzed include the following: 1274 o IKE/IPsec with X.509 PKI. 1276 o TLS or IKE/IPsec with manually configured shared secrets. 1278 o TLS with Cryptographically Generated Addresses (CGA) [RFC3972]. 1280 o IPsec with Host Identity Protocol (HIP) [HIPArch]. 1282 o Integration with SAML/Liberty infrastructure [SAMLOverview]. 1284 o Usage of Kerberos within the TLS Handshake [RFC2712]. This 1285 approach was utilized for enterprise environments with RSVP (see 1286 also [MADS01] for information about the authorization information 1287 that may be carried in such a ticket). 1289 Moreover, since integration with an existing infrastructure depends 1290 largely on what exactly that infrastructure is, it may be more 1291 productive to examine NSIS security in some particular deployment 1292 scenario, rather than in abstract or generic fashion. 1294 6. Security Considerations 1296 This document discusses different proposals for securing GIST and 1297 hence security is addressed throughout the document. As part of 1298 future work additional security considerations might need to be added 1299 to GIST [GIST]. 1301 7. IANA Considerations 1303 A future version of this draft might require IANA actions. Depending 1304 on the outcome of the discussions it might be necessary to register 1305 IANA numbers for stack proposals used in GIST. 1307 8. Acknowledgements 1309 The authors would like to Tseno Tsenov, Henning Peters, Mika Kousa, 1310 and Robert Hancock for their input to this work. Tseno Tsenov 1311 investigated the integration of EAP into the QoS in the past. 1313 This document has been produced in the context of the Ambient 1314 Networks Project. The Ambient Networks Project is part of the 1315 European Community's Sixth Framework Program for research and is as 1316 such funded by the European Commission. All information in this 1317 document is provided "as is" and no guarantee or warranty is given 1318 that the information is fit for any particular purpose. The user 1319 thereof uses the information at its sole risk and liability. For the 1320 avoidance of all doubts, the European Commission has no liability in 1321 respect of this document, which is merely representing the authors 1322 view. 1324 9. References 1326 9.1. Normative References 1328 [GIST] Schulzrinne, H. and R. Hancock, "GIST: General Internet 1329 Signaling Transport", draft-ietf-nsis-ntlp-08 (work in 1330 progress), September 2005. 1332 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1333 RFC 2246, January 1999. 1335 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1336 Levkowetz, "Extensible Authentication Protocol (EAP)", 1337 RFC 3748, June 2004. 1339 [TLS-IA] Funk, P., Blake-Wilson, S., Smith, N., Tschofenig, H., and 1340 T. Hardjono, "TLS Inner Application Extension (TLS/IA)", 1341 draft-funk-tls-inner-application-extension-01 (work in 1342 progress), February 2005. 1344 [TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 1345 for Transport Layer Security (TLS)", draft-ietf-tls-psk-09 1346 (work in progress), June 2005. 1348 9.2. Informative References 1350 [ChannelBindings] 1351 Williams, N., "On the Use of Channel Bindings to Secure 1352 Channels", draft-ietf-nfsv4-channel-bindings-03 (work in 1353 progress), February 2005. 1355 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1356 Security", draft-rescorla-dtls-05 (work in progress), 1357 June 2005. 1359 [EAP-AKA] Arkko, J. and H. Haverinen, "Extensible Authentication 1360 Protocol Method for 3rd Generation Authentication and Key 1361 Agreement (EAP-AKA)", draft-arkko-pppext-eap-aka-15 (work 1362 in progress), December 2004. 1364 [EAP-API] Microsoft Corporation, "Platform SDK: Extensible 1365 Authentication Protocol", MSDN Library, http:// 1366 msdn.microsoft.com/library/en-us/eap/eap/ 1367 eap_start_page.asp, 2005. 1369 [EAP-QoS] Tschofenig, H. and J. Kross, "Extended QoS Authorization 1370 for the QoS NSLP", draft-tschofenig-nsis-qos-ext-authz-00 1371 (work in progress), July 2004. 1373 [EAPBinding] 1374 Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon, 1375 "The Compound Authentication Binding Problem", 1376 draft-puthenkulam-eap-binding-04 (work in progress), 1377 October 2003. 1379 [HIPArch] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1380 Architecture", draft-ietf-hip-arch-03 (work in progress), 1381 August 2005. 1383 [MADS01] ""Microsoft Authorization Data Specification v. 1.0 for 1384 Microsoft Windows 2000 Operating Systems", April 2000. 1386 [NATFW] Stiemerling, M., Tschofenig, H., and C. Aoun, "NAT/ 1387 Firewall NSIS Signaling Layer Protocol (NSLP)", 1388 draft-ietf-nsis-nslp-natfw-07 (work in progress), 1389 July 2005. 1391 [PANA] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 1392 Yegin, "Protocol for Carrying Authentication for Network 1393 Access (PANA)", draft-ietf-pana-pana-10 (work in 1394 progress), July 2005. 1396 [RFC2078] Linn, J., "Generic Security Service Application Program 1397 Interface, Version 2", RFC 2078, January 1997. 1399 [RFC2222] Myers, J., "Simple Authentication and Security Layer 1400 (SASL)", RFC 2222, October 1997. 1402 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1403 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1404 Authentication: Basic and Digest Access Authentication", 1405 RFC 2617, June 1999. 1407 [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, 1408 June 1999. 1410 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 1411 Suites to Transport Layer Security (TLS)", RFC 2712, 1412 October 1999. 1414 [RFC2743] Linn, J., "Generic Security Service Application Program 1415 Interface Version 2, Update 1", RFC 2743, January 2000. 1417 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS 1418 Extensions", RFC 2869, June 2000. 1420 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 1421 Protocol (HTTP) Digest Authentication Using Authentication 1422 and Key Agreement (AKA)", RFC 3310, September 2002. 1424 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1425 Dial In User Service) Support For Extensible 1426 Authentication Protocol (EAP)", RFC 3579, September 2003. 1428 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1429 RFC 3972, March 2005. 1431 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1432 Authentication Protocol (EAP) Application", RFC 4072, 1433 August 2005. 1435 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 1436 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 1438 [SAMLOverview] 1439 Hughes, J. and E. Maler, "Security Assertion Markup 1440 Language (SAML) V2.0 Technical Overview", OASIS 1441 document sstc-saml-tech-overview-2.0-draft-08, 1442 September 2005. 1444 [ServiceInfoAuth] 1445 Arkko, J. and P. Eronen, "Authenticated Service 1446 Information for the Extensible Authentication Protocol 1447 (EAP)", draft-arkko-eap-service-identity-auth-03 (work in 1448 progress), July 2005. 1450 [TLS-ECC] Gupta, V., Blake-Wilson, S., Moeller, B., Hawk, C., and N. 1451 Bolyard, "ECC Cipher Suites for TLS", 1452 draft-ietf-tls-ecc-11 (work in progress), September 2005. 1454 [TS29.109] 1455 3rd Generation Partnership Project (3GPP), "Generic 1456 Authentication Architecture (GAA); Zh and Zn Interfaces 1457 based on the Diameter protocol; Stage 3 (Release 6)", 3GPP 1458 TS 29.109 V6.3.0, June 2005. 1460 [TS33.220] 1461 3rd Generation Partnership Project (3GPP), "Generic 1462 Authentication Architecture (GAA); Generic bootstrapping 1463 architecture (Release 6)", 3GPP TS 33.220 V6.5.0, 1464 June 2005. 1466 [TS33.222] 1467 3rd Generation Partnership Project (3GPP), "Generic 1468 Authentication Architecture (GAA); Access to network 1469 application functions using Hypertext Transfer Protocol 1470 over Transport Layer Security (HTTPS) (Release 6)", 3GPP 1471 TS 33.222 V6.4.0, June 2005. 1473 Authors' Addresses 1475 Hannes Tschofenig 1476 Siemens 1477 Otto-Hahn-Ring 6 1478 Munich, Bayern 81739 1479 Germany 1481 Email: Hannes.Tschofenig@siemens.com 1483 Pasi Eronen 1484 Nokia Research Center 1485 P.O. Box 407 1486 FIN-00045 Nokia Group 1487 Finland 1489 Email: pasi.eronen@nokia.com 1491 Intellectual Property Statement 1493 The IETF takes no position regarding the validity or scope of any 1494 Intellectual Property Rights or other rights that might be claimed to 1495 pertain to the implementation or use of the technology described in 1496 this document or the extent to which any license under such rights 1497 might or might not be available; nor does it represent that it has 1498 made any independent effort to identify any such rights. Information 1499 on the procedures with respect to rights in RFC documents can be 1500 found in BCP 78 and BCP 79. 1502 Copies of IPR disclosures made to the IETF Secretariat and any 1503 assurances of licenses to be made available, or the result of an 1504 attempt made to obtain a general license or permission for the use of 1505 such proprietary rights by implementers or users of this 1506 specification can be obtained from the IETF on-line IPR repository at 1507 http://www.ietf.org/ipr. 1509 The IETF invites any interested party to bring to its attention any 1510 copyrights, patents or patent applications, or other proprietary 1511 rights that may cover technology that may be required to implement 1512 this standard. Please address the information to the IETF at 1513 ietf-ipr@ietf.org. 1515 Disclaimer of Validity 1517 This document and the information contained herein are provided on an 1518 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1519 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1520 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1521 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1522 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1523 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1525 Copyright Statement 1527 Copyright (C) The Internet Society (2005). This document is subject 1528 to the rights, licenses and restrictions contained in BCP 78, and 1529 except as set forth therein, the authors retain all their rights. 1531 Acknowledgment 1533 Funding for the RFC Editor function is currently provided by the 1534 Internet Society.