idnits 2.17.00 (12 Aug 2021) /tmp/idnits33681/draft-mglt-btns-ipsec-api-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2, 2009) is 4821 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: 'LR' is mentioned on line 897, but not defined ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4307 (Obsoleted by RFC 8247) == Outdated reference: A later version (-04) exists of draft-ietf-btns-c-api-03 == Outdated reference: draft-ietf-btns-connection-latching has been published as RFC 5660 -- No information found for draft-mglt-ipsec-appdb - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BTNS Working Group D. Migault 3 Internet-Draft Orange Labs R&D 4 Intended status: Standards Track March 2, 2009 5 Expires: September 3, 2009 7 IPSEC_API requirements 8 draft-mglt-btns-ipsec-api-requirements-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 3, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 IPsec suite has been designed to secure communication between two 47 nodes. Security is performed at the network layer, and there are 48 almost no interactions between applications and the IPsec layer. The 49 main motivation of this API is to enable any applications to interact 50 with the IPsec layer and to take advantage of the security deployed 51 in IPsec suite. This draft lists applications requirements with 52 regard to the IPsec suite, and we tried not to limit the requirements 53 to today's application requirements, but also to consider future 54 applications' requirements. Applications are associated to different 55 privileges, and IPsec layer MUST be protected from nasty IPsec 56 manipulations. This draft is not considering applications privileges 57 management. This draft lists any possible requirements on the IPsec 58 layer an application might require. 60 Table of Contents 62 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. Application goals . . . . . . . . . . . . . . . . . . . . 4 67 4.2. Architecture description . . . . . . . . . . . . . . . . . 5 68 4.3. Impacts with IPsec . . . . . . . . . . . . . . . . . . . . 7 69 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. Application requirements with IPSEC_API . . . . . . . . . 9 71 5.2. IPSEC_API requirements with IPsec layer . . . . . . . . . 9 72 5.3. IPSEC_API requirements with IPSEC_API . . . . . . . . . . 10 73 5.4. Next step to this draft . . . . . . . . . . . . . . . . . 10 74 6. HOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 6.1. Dynamic interaction between the IPSEC_API and an 76 applications. . . . . . . . . . . . . . . . . . . . . . . 11 77 6.1.1. non ESTABLISHED connections parameters . . . . . . . . 12 78 6.1.2. ESTABLISHED connection parameters . . . . . . . . . . 12 79 6.1.3. Action performed by applications . . . . . . . . . . . 12 80 6.2. Simple Security Request Method . . . . . . . . . . . . . . 13 81 7. WHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 7.1. The dynamic interaction between the IPSEC_API and an 83 applications. . . . . . . . . . . . . . . . . . . . . . . 15 84 7.1.1. NON ESTABLISHED parameters . . . . . . . . . . . . . . 16 85 7.1.2. ESTABLISHED connection parameters . . . . . . . . . . 18 86 7.1.3. Actions performed by the application . . . . . . . . . 18 87 7.2. Simple Security Request Method . . . . . . . . . . . . . . 19 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 90 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 92 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 93 11.2. Informative References . . . . . . . . . . . . . . . . . . 22 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 1. Requirements notation 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2. Introduction 104 This draft is based [I-D.ietf-btns-ipsec-apireq] and adopts a similar 105 structure to ease merge of the two drafts. This draft has been re- 106 written since the former [I-D.ietf-btns-ipsec-apireq] was not any 107 more active, and requirements did not match those of the IPSEC_API we 108 are developing in our labs. 110 IPsec suite [RFC4301] [RFC4302] [RFC4306] [RFC4307] has been designed 111 to secure communication between two nodes. Security is performed at 112 the network layer, and there are almost no interactions between 113 applications and the IPsec layer. The main motivation of this API is 114 to enable any applications to interact with the IPsec layer and to 115 take advantage of the security deployed in IPsec suite. This draft 116 lists applications requirements with regard to the IPsec suite, and 117 we tried not to limit the requirements to today's application 118 requirements, but also to consider future applications requirements. 119 Applications are associated to different privileges, and IPsec layer 120 MUST be protected from nasty IPsec manipulations. This draft is not 121 considering applications privileges management which is described in 122 [I-D.mglt-ipsec-appdb]. This draft lists any possible requirements 123 on the IPsec layer an application might require. 125 BTNS WG has designed solutions that enable IPsec communication 126 without authentication [RFC5386]. 127 [I-D.ietf-btns-connection-latching] enables ULP protocols to specify 128 IPsec parameters for the connection. IPsec parameters are associated 129 with a socket either in a listening mode or initiating a connection. 130 This configures IKE for the key negotiation and update of the SAD. 132 This is a first step for interrelations between ULP and the IPsec 133 layer. This draft is considering more interactions between 134 applications and the IPsec stack. Interactions will be provided 135 through an API: IPSEC_API. This draft is defining application 136 requirements with the IPsec stack. Today's Interfaces of IPSEC_API 137 are defined in [I-D.ietf-btns-abstract-api], and C implementation is 138 defined in [I-D.ietf-btns-c-api]. Those documents partly implement 139 the requirements of this paper and need to be completed or to be re- 140 written. 142 3. Terminology 144 - IPSEC_API : designates the layer (interfaces / daemons) that is 145 between the IPsec layer and the application layer. This 146 IPSEC_API is composed of three interfaces one with the 147 application layer, one with the IPsec layer and one with remote 148 IPSEC_API. 149 - APPDB : stands for APplication Privilege DataBase. This database 150 contains all attributes to determine which action on the IPsec 151 Database can be performed by a specific application, a specific 152 user, ... this database is described in [I-D.mglt-ipsec-appdb]. 153 - APP : stands for application 154 - API : stands for APplication Interface 155 - SPD* or logical SPD : is the SPD used by the kernel. This SPD 156 can results from the correlated SPD, and ULP-driven SPD as 157 defined in [I-D.ietf-btns-connection-latching] 158 - IKE* : IKE Database is the aggregation of IKE_CONF and IKE_CTX. 159 - IKE_CONF : are the parameters required by IKE for negotiation. 160 Typically that the parameters one set before launching the IKE 161 daemon. 162 - IKE_CTX : are the IKE parameters for a given association between 163 two peers. 165 4. Goals 167 This section lists the goals of this API. Such goals have an impact 168 on the IPsec stack. This section provides architecture of our API 169 and its interactions with the IPsec and application layer. Then for 170 all listed goals, and analysis on impacts with the IPsec layer is 171 provided. 173 4.1. Application goals 175 An application can be either located on the same device as the one 176 with the considered IPsec layer, or on a remote device. On the 177 application point of view this draft is considering the following 178 main types of actions : 180 o An application wants to get IPsec information for a specific 181 ESTABLISHED connection. This type of information includes WHO is 182 on the other side, HOW the peer has been authenticated, and HOW 183 the communication is protected. That information is stored into 184 specific database, memory, contexts... 185 o An application wants to check the security policy or different 186 IPsec parameters before connection is ESTABLISHED with a peer. 188 o An application wants to interact with the IPsec layer and provide 189 requirements on security parameters on a connection before it is 190 established. For example an application should be able to specify 191 how authentication should be proceeded, how the communication 192 should be protected. By default application security requirements 193 are accepted when security requirements are higher than IPsec 194 security. Nevertheless an application might also require lower 195 security in very specific situation when security is balanced by 196 CPU consumption for small device. Such application MUST be 197 configured to have such properties. 198 o An application wants also to interact with the IPsec and perform 199 the authentication of the peer on the behave of the IPsec stack. 200 o An application DOES NOT want to have a complete knowledge of the 201 IPsec stack. Security MUST be set up with very simple key words 202 and easy-to-understand operations. 204 4.2. Architecture description 206 This API should be placed between the application and the transport 207 layer. This IPSEC_API is interfacing the applications with the IPsec 208 layer. Network security mainly relies on IPsec and so IPsec 209 configuration must be changed by authorized applications and in a 210 controlled way. This IPSEC_API is not a replacement for existing 211 IPsec management protocol and must reuse those protocols (IPsec /IKE 212 [RFC4301] [RFC4306] as well as associated management APIs such as 213 PF_KEYv2 [RFC2367]. 215 The figure below represents the Interaction applications and the 216 IPsec stack through the API. 218 +-----------------------------------+ 219 |+----+ +------+ +-----+------+| 220 ||SPD | | IKE | | App1| App2 || 221 |+----+ +------+ +-----+------+| 222 ||PAD | | | ^ | 223 |+----+ | | APP / API | | 224 +--^-----|--|----------------|------+ 225 | | | +---=======|===---+ 226 +-----|--|-----|IPSEC_API v || API / API 227 | | | ^ || 228 +-------+ +---+ +---==|========---+ User land 229 _|______________|_______|________________________ 230 +|--------------|-------|-----------+ Kernel 231 || PF_KEY | +---+API / IPsec| 232 || +--------+ | | | 233 || | SPD* |<-----+ | 234 || +--------+ | | +--------+ | 235 || | SAD |<-+---+--->|Latch DB| | 236 || +--------+ | +--------+ | 237 |+->| IKE* |<-----+--->| ... | | 238 | +--------+ +--------+ | 239 +-----------------------------------+ 241 IPSEC_API Architecture 243 Concerned IPsec databases are : 245 o SPD* is a logical SPD as mentioned in 246 [I-D.ietf-btns-connection-latching]. This includes the SPD- 247 decorrelated DB as well as ULP-driven SPD. In this draft one must 248 also consider application driven SPD. 249 o SAD is the security Association Database. 250 o IKE* is the database containing IKE parameters about SAs, SPs, and 251 their negotiation status in IKE_CTX. IKE_CONF contains the IKE 252 parameters used for negotiation. 253 o Latch DB is the list of latched objects 254 [I-D.ietf-btns-connection-latching] 255 o ... stands for other IPsec related Databases. 257 The IPSEC_API is composed of three interfaces : 259 o API / API : is an interface between APIs on local and remote host. 260 The interface can be used by the two communicating nodes or but 261 also by a third party that manages IPsec parameters of the two 262 communicating nodes. 264 o APP / API : is an interface between APPlications and the 265 IPSEC_API. This interface enables APPlications to send requests 266 and get information on IPsec layer. This API MUST check that 267 requested modification from applications are authorized before 268 applying the modification to the kernel. 269 o API / IPsec : is an interface between the API and the IPsec layer. 270 The interface enables the API to modify the IPsec databases. SAD 271 can be modified by using PF_KEY [RFC2367] 273 4.3. Impacts with IPsec 275 If an application wants to know IPsec information on and established 276 connection, its needs to be able to read the various IPsec databases 277 like PAD, SPD*, SAD, LD, IKE*. SPD is used to get information on 278 used policies, SAD on how security is performed between two 279 endpoints, PAD what kind of ID were used for the IKE authentication 280 phase. IKE* although NOT so standardized, can provides the different 281 proposed parameters proposed during the IKE negotiation. (We said 282 NOT so standardized since no IKE context have been defined, and IKE 283 parameters are usually implementation dependant). For a given 284 established communication, IKE* could provide a picture of the 285 negotiation status between the two peers, used keys, information on 286 how authentication has been performed. LD and SAD might be useful 287 for ULP to latch connection [I-D.ietf-btns-connection-latching]. 288 Some information might not be stored in such database and so must be 289 stored in the IPSEC_API local database. Interface with SAD is 290 provided with PFKEYv2 [RFC2367], but there are no standardized 291 interface with SPD and IKE*. Since it is hard to consider what are 292 the IPsec parameters each application need to access now and in the 293 future, all IPsec parameters should be accessed by applications. 294 Restriction policies on read / write privileges MUST be clearly 295 specified for any application. IPsec parameters MUST also include 296 implementation dependent IPsec parameters. Such privileges are 297 stored in the APplication Privilege Database (APPDB) 298 [I-D.mglt-ipsec-appdb]. This would for example enable context 299 transfer for one given application (raccon2, ...). Applications do 300 not need necessarily understand all IPsec parameters, application 301 should also be able to request security status of a given established 302 IPsec connection in the form of "encryption", "authentication", 303 "strong-security".... 305 One application might request information in prevision of a future 306 IPsec connection. This is especially the case when an application 307 wants to initiate a secure connection with one specific host. It 308 might check what the security at the IPsec layer is. This includes 309 what mode is used, what types of algorithms are used what 310 authentication method is used... The application could then proceed 311 to requirements on the IPsec layer, or decide it will proceed to the 312 authentication. Authorized application must be able to access all 313 those information, but application are not required to know precisely 314 all IPsec parameters. Applications could also expect response with 315 basic words like "encryption", "authentication", "strong security"... 316 The involved IPsec databases are mainly SPD and IKE_CONF since the 317 connection is not in an established mode. SAD / LD / IKE_CTX might 318 also be useful since a connection might be in a dormant state. 319 Application should be able to check all IPsec parameters but 320 privileges of each application MUST be clearly specified in an 321 Application Privilege Database (APPDB). Of course the requirements 322 above will in most of the cases generate closer interaction and 323 modification of IPsec parameters by the application. 325 One application MUST be able to specify IPsec parameters. This means 326 that an application can change its security policies. According to 327 its privileges the application will be able force a weaker or 328 stronger security. By default application will be only able to 329 request stronger security. The API MUST be able to send 330 ACKknowledgemnt of the request or an ERROR message. Applications 331 privilege on the different IPsec parameters MUST be clearly specified 332 in the APPD. Application MUST be able to set every single IPsec 333 parameters as well as setting IPsec parameters with generic key 334 words. For a non initiated IPsec connection, such requirements will 335 mainly involve the SPD, and eventually IKE_CONF and PAD, or at least 336 there application-driven equivalent. When the application specifies 337 it will perform the authentication on behalf of IKE, the application 338 MUST send Acknowledgment or ERROR message to the API. Such 339 interaction will be done during the IKE authentication phase. Once a 340 connection has been initiated, an application MUST be able to change 341 the IPsec parameters, by renegotiating or re-keying IPsec material. 342 An application MUST also be able to proceed authentication either by 343 using IKE or on the behalf of IKE. A typical situation would be an 344 application requesting to proceed to authentication of an 345 unauthenticated IPsec connection [RFC5386]. This would require 346 binding the unauthenticated channel to the authentication. 347 Authentication would be proceeded with selected information (or hash 348 of them) of the IPsec connection. This is called channel binding 349 [RFC5056]. This requirements means that applications can change 350 IPsec parameters but can also trigger actions such as re-keying, re- 351 authenticating, on IKE. 353 5. Requirements 355 This sections aims at defining the requirements on an IPsec point of 356 view. A first subsection lists the application requirements on the 357 IPsec layer. Those requirements are treated through the IPSEC_API. 358 Other subsection lists requirements of the IPSEC_API and the its 359 interface with applications, with the IPsec layer and with other 360 IPSEC_API. 362 5.1. Application requirements with IPSEC_API 364 o Application MUST be able to establish connection with the 365 IPSEC_API. This can be done by local applications, or remote 366 applications. 367 o Application MUST be able to read / write / create / delete any 368 data in the IPsec databases, as well as other parameters within 369 the local IPSEC_API database. Such parameters can concern already 370 established IPsec connection, non already established IPsec 371 connection. Such action MUST only be performed by authorized 372 applications defined in APPDB [I-D.mglt-ipsec-appdb]. 373 o Application requests MUST be controlled by the IPSEC_API. 374 Unauthorized requests MUST be responded with an ERROR message. 375 o Application MUST be able to trigger action with IPsec daemon such 376 as IKE. 377 o Application MUST be able to interact with IPsec by using generic 378 key words. Such Key words MUST be defined according to use cases. 379 o Applications MUST be able to perform authentication on behalf of 380 the IPsec layer, and provides the results to the IPSEC_API. 382 5.2. IPSEC_API requirements with IPsec layer 384 o IPSEC API MUST be aware of any change in IPsec Databases. 385 IPSEC_API could eventually build its own local copies of IPsec 386 databases. 387 o IPSEC_API SHOULD maintain local databases dealing with 388 authentication status, of IP address function, so to be aware of 389 the "Quality of Security", and to be able to adapt IPsec 390 connections to very common network operations such as Multihoming 391 and Mobility operations. 392 o IPSEC_API has root / admin privilege so it can change IPsec 393 parameters. The IPSEC_API MUST check privileges of any 394 application before proceeding to any changes. By default an 395 application could not change IPsec parameters that do not concern 396 its own connection. By default, the set of parameters for each 397 operation should also be reduced. API like PF_KEYv2 [RFC2367] 398 provides interface with SAD and the IPSEC_API. Other interface 399 with other IPsec databases MUST be either standardized or 400 considered implementation dependent. 401 o IPSEC_API MUST understand high level application requests. Such 402 requests consider pre-configured operations that will be performed 403 by IPSEC_API, which in turn guarantee operation will be performed 404 in a secure manner. Changing an SA for example will not be 405 performed by simply changing the SAD, but rather by using IKE. 406 Other operation (like those involved in Mobility or Multi-Homing) 407 might involve communication between the two involved IPSEC_API 408 (which can probably be done through a future IKE-extension). 409 o IPSEC_API MUST compare security and eventually overwrite the 410 network security. A flag could specify whether SP is allowed to 411 be weakened, strengthen or not. The IPSEC_API MUST balanced the 412 application authorization, the SP upgrade flag, and the requested 413 / configured security policy. The new SP MUST NOT survive to 414 crash, and so MUST only impact the logical SPD. 415 o IPSEC_API MUST be able to ask for application authentication. 416 Necessary information for channel binding MUST be provided to the 417 application. Such information MUST NOT appear in a clear mode by 418 default, so not to communicate IPsec parameters. On the other 419 hand such parameters MUST be clearly specified so that for a given 420 ESTABLISHED connection both sides can have a similar Nonce value 421 use to bind the channel to the authentication. 423 5.3. IPSEC_API requirements with IPSEC_API 425 o IPSEC_API MUST be able to communicate between each other. 426 Communication between IPSEC_API can be done by using IKE channel. 427 o IPSEC_API channel MUST be secured. IPsec can be used but should 428 NOT rely on IP addresses. -- IPsec BEET mode, or HIP can be used. 429 o All commands on the IPSEC_API / IPsec layer could be sent through 430 the IPSEC_API / IPSEC_API interface. 432 5.4. Next step to this draft 434 This draft does not consider the way Applications and IPSEC_API are 435 establishing a channel to communicate. In particularly it does not 436 treat the authentication problematic which enables the IPSEC_API to 437 authenticate the application it is communicating with. 439 IPsec parameter protection is described in [I-D.mglt-ipsec-appdb]. 440 It shows privileges of any application on any IPsec parameters. 441 Before performing an action, IPSEC_API MUST check the application has 442 the required privileges. 444 For a given REQUESTER and a given IPsec PARAMETER the possible 445 ACTIONS are : 447 o CREATE: A VALUE MUST be specified. 448 o DELETE: No VALUE needs to be specified. 449 o UPDATE: A VALUE needs to be specified. 450 o READ: No VALUE needs to be specified. 452 Other function can be created like SEARCH. A complete description of 453 the abstract interface should be defined in future version of 454 [I-D.ietf-btns-abstract-api]. 456 PARAMETER are designed by a TYPE and a SELECTOR which enables to 457 distinct it from others in specific DATABASEs (SAD, LD, SPD, PAD, 458 IKE_CONF, IKE_CTX). Complete list of TYPEs, SELECTORs, and DATABASEs 459 is defined in [I-D.ietf-btns-abstract-api]. 461 Such functions are the basic functions that handle the IPsec 462 PARAMETERS. Those functions are the same on the IPSEC_API / 463 APPlication and on the IPSEC_API / IPsec layer interface. On the 464 IPSEC_API / IPsec layer those functions are the only interface. 466 IPsec is composed of two distinct parts : 468 o Authentication of peers: the WHO part 469 o Protection of datagrams: the HOW part 471 For each of those two parts, this draft will focus on the different 472 requirements between the application. For each of those parts, we 473 will define: 475 o The dynamic interaction between the IPSEC_API and an application. 476 o Simple Security Request Method (SSRM). 478 This draft also mentions what are the different modifications on 479 IKEv1, IKEv2 and other IPsec related protocols. 481 6. HOW 483 6.1. Dynamic interaction between the IPSEC_API and an applications. 485 The HOW part is considering three type of actions : 487 o An application can REQUEST security parameters of an ESTABLISHED 488 connection. 489 o An application can REQUEST security parameters for a future 490 connection. 491 o An application can PERFORM some action : 492 o 493 * DELETE a connection. 494 * REKEY a SA. 495 * Manage IPsec connection in Multihoming environment. 496 * Manage IPsec connection in Mobility environment. 498 There are two cases to consider the connection is in an ESTABLISHED 499 state and the connection is not in an established state. An 500 application MUST be able to check whether a connection is ESTABLISHED 501 or not. 503 6.1.1. non ESTABLISHED connections parameters 505 When the connection is not in an established state, the application 506 requirements might be on the following security parameters : 508 o NATURE_PROP: List of proposition of the NATURE of the connection. 509 The list is ordered from the most preferred NATURE to the least 510 preferred NATURE. NATURE of the connection is a combination of 511 COMPRESSION, CONFIDENTIALITY and INTEGRITY. 512 o ALGorithm_PROP: List of proposed ALG associated to one NATURE 513 value. The list is ordered. 515 Those parameters values could be either REQUESTed by the application 516 to know how the connection will be negotiated. It can also be 517 REQUIRED by the application. Such requirements will update the 518 decorrelated SPD (confidentiality, Integrity) and the IKE_CONF 519 database. NATURE_PROP and ALG_PROP are list of possibilities for the 520 non established connection. The ESTABLISHED connection MUST have a 521 NATURE and ALG mentioned in the List. Propositions MUST be kept in a 522 context in case of re-negotiation of parameters. 524 6.1.2. ESTABLISHED connection parameters 526 When the connection is in an ESTABLISHED state, changing the security 527 policy would require to renegotiate the IKE exchange. On the other 528 hand an application might only want to get some information about how 529 the connection is protected. Such parameters can be read from the 530 SA. The application requirements might be the following : 532 o NATURE_STATUS: indicates the NATURE of the connection it MUST be 533 one of the value mentioned in the NATURE_PROP parameters. 534 o ALGorithm_STATUS: indicates which algorithm is used. 535 o Protection CTX: All protection parameters, it might be useful for 536 an application . 537 o STATUS: Status of the connection ESTABLISHED, LARVAL, ... 538 o NATURE_PROP: List of proposition of the NATURE of the connection. 539 The list is ordered from the most preferred NATURE to the least 540 preferred NATURE. NATURE of the connection is a combination of 541 COMPRESSION, CONFIDENTIALITY and INTEGRITY. 542 o ALGorithm_PROP: List of proposed ALG associated to one NATURE 543 value. The list is ordered. 545 6.1.3. Action performed by applications 547 To avoid multiple IKE negotiations, an application wants an IPsec 548 channel to be inherited from an already existing IPsec connection. 549 This is especially the case in multihoming scenario. IPSEC_API MUST 550 check the SA matches the SPD, build the new SA from the already 551 existing SA, communicate such change to the other IPSEC_API and 552 update the SAD. 554 An application MUST be able to close an IPsec connection and put the 555 IPsec status to close, so that it could not be used unless the 556 application is latching this connection. 558 An application wants to ask for mobility and transfer IPsec 559 parameters to another endpoint. This case can be seen as a 560 combination of the two previous cases. One need to add the other 561 connection, wait it works and delete the currently used address. 562 MOBIKE is considering this operation, for tunnel mode. The IPSEC_API 563 is extending this functionality to transport mode. 565 An application wants to initiate an IKE negotiation before sending 566 any packet. This is mainly to avoid network latency. Considering 567 the previous cases, this will create a new SA, and there is no 568 inheritance properties. 570 An application wants to REKEY the IPsec connection when KEYs are 571 consider short, or when an authentication has just been performed. 573 6.2. Simple Security Request Method 575 As mentioned previously, the main purpose of SSRM is to enable a safe 576 interaction between application and IPsec layer. With considered 577 previous scenario, one can consider the REQUIRE method which attempt 578 to send requirements, and the REQUEST method for IPsec parameters of 579 established connection. By default such SSRM are only applied for 580 connection the application is involved in. 582 Example of requests can be : 584 REQUIRE [APP_ID] CONNECTION_ID PARAM 586 REQUEST message to IPSEC_API for a non establish connection 588 where : 590 o APP_ID is the application identifier. It can be an option if the 591 connection between the application and the IPSEC_API identifies 592 the application. We do not specify here how applications are 593 identified by the IPSEC_API. It could be by the port, or another 594 ID. We need to consider APP_ID if we consider security at the 595 application layer. Deriving security at the network layer is only 596 a means to use IPsec for securing communication between 597 applications. APP_ID can also be seen as a higher granularity of 598 SA descriptors than CONNECTION_ID. 600 o CONNECTION_ID identifies the connection (@IP_src, @IP_dst, 601 port_src, port_dst). Value "ANY" could also be used as a 602 wildcard. 603 o PARAM is required. It can be CONFIDENTIALTY_PROP, INTEGRITY_PROP, 604 and COMPRESSION_PROP with associated values MUST, MAY, NONE. EALG 605 with its related value, IALG with its related value. The 606 different value for EALG and IALG can be of keywords like 607 STRONGEST, FASTEST - ([I-D.ietf-btns-abstract-api] suggests the 608 following terms for policies : "secure", "ospf", "iSCSI", "very- 609 secure", "do-not-tell-mom-secure", "minimum-security", "was- 610 posted-on-usenet-security"). Values are specified only for the 611 REQUIRE request. 613 REQUEST [APP_ID] CONNECTION_ID PARAM 615 REQUEST message to IPSEC_API for an established connection 617 where : 619 o APP_ID is the application identifier. It can be option if the 620 connection between the application and the IPSEC_API identifies 621 the application. We do not specify here how applications are 622 identified by the IPSEC_API. It could be by the port, or another 623 ID. Deriving security at the network layer is only a means to use 624 IPsec for securing communication between applications. APP_ID can 625 also be seen as a higher granularity of SA descriptors than 626 CONNECTION_ID. 627 o CONNECTION_ID identifies the connection (@IP_src, @IP_dst, 628 port_src, port_dst). Value "ANY" could also be used. 629 o PARAM is required. It can be CONFIDENTIALTY_STATUS, 630 INTEGRITY_STATUS, and COMPRESSION_STATUS, EALG, IALG. The 631 different value for EALG and IALG can be of keywords like 632 STRONGEST, FASTEST. Values are specified only for the REQUIRE 633 request. STATUS defines the connection status. This status can 634 be ESTABLISHED, LARVAL, DORMANT, NULL... PROTECT_CTX. 636 MULTIHOME [APP_ID] NEW_CONNECTION_ID INHERIT_MTHD 638 MULTIHOMING message to IPSEC_API 640 where : 642 o NEW_CONNECTION_ID is the new connection to establish. 643 o INHERIT_MTHD is the method used to derive the NEW_CONNECTION 645 MOBILITY [APP_ID] CONNECTION_ID INHERIT_MTHD 647 MOBILITY message to IPSEC_API 649 where : 651 o CONNECTION_ID is the new connection SHOULD inherit from. 652 o INHERIT_MTHD is how the transition from the new and old address 653 should be done. This mainly includes how the previous connection 654 SHOULD be deleted, and usually includes a Time stamp that 655 indicates when the deletion occurs. 657 DELETE [APP_ID] CONNECTION_ID DELETE_MODE 659 DELETE message to IPSEC_API 661 where : 663 o CONNECTION_ID is the new connection to delete. 664 o DELETE_MODE defines how the SA SHOULD be deleted. 666 The IPSEC_API MUST answer to such requests with a message of type : 668 ACK RESPONSE_DATA 670 DELETE message to IPSEC_API 672 or 674 ERROR ERROR_MSG 676 DELETE message to IPSEC_API 678 o ACK is a positive answer with the expected response in 679 RESPONSE_DATA. 680 o ERROR is an ERROR message with the ERROR_MSG value. 682 7. WHO 684 7.1. The dynamic interaction between the IPSEC_API and an applications. 686 As in the HOW part, there are different things to consider : 688 o An application can REQUEST authentication information of an 689 ESTABLISHED connection. 690 o An application can REQUIRE authentication method and mode for a 691 NON already ESTABLISHED connection. For an already ESTABLISHED 692 connection, this will generated a renegotiation as if the 693 authentication had not been previously performed. Since then we 694 consider the following case as part of the NON ESTABLISHED case. 696 o An application can interact with the IPsec layer in the 697 authentication process : 698 o 699 * Proceed to authentication on behalf of the IKE daemon. 700 * Ask the IKE daemon to proceed to authentication, providing a 701 list of authentication method. 702 * Ask the IKE daemon to application confirmation for 703 authentication validation. A peer might have correctly been 704 authenticated but is black listed by the application, or 705 further local checks must be performed by the application. 706 * Provide ACL, black white lists to the IPSEC_API. 707 * Require the authentication to be proceeded. 709 Unlike protection parameters, authentication is a local process, i.e; 710 not shared between the two nodes, and so MUST be considered different 711 when in local and remote peers. In the following description of the 712 parameters (LR) indicates that the parameter should be considered for 713 local and peer entities. Thus PARAMETER (LR) stands for the two 714 names PARAMETER_LOCAL and PARAMETER_REMOTE. 716 7.1.1. NON ESTABLISHED parameters 718 The application should be able to choose who is proceeding to the 719 authentication, i.e. to say if the authentication will be proceeded 720 by the IPsec layer or the application it self. 722 Then an application should be able to accept/refuse an IPsec 723 authenticated peer. An application should also be able to provide 724 blacklist and white list to the IPsec layer. 726 It should also be able to provide how the authentication should be 727 done. Some parameters like who is proceeding to the authentication 728 can be defined when the application is launched or when the 729 application is receiving/sending packets. 731 By default IPsec and applications are considering their own 732 authentication rules. The IPsec authentication rules are defined in 733 the PAD. [RFC5386] is providing some unauthenticated IPsec 734 connection. 736 By default, the IPsec is proceeding to the authentication according 737 to the PAD. Application proceeding to authentication might 738 "overwrite" IPsec rules of the PAD. Thus such applications should be 739 with CREATE or UPDATE privilege in the APPDB [I-D.mglt-ipsec-appdb]. 740 If not, the authentication cannot be proceeded by the application 741 layer only, and should match the PAD policies. If the IPsec SPD / 742 PAD rules cannot be changed, the IPSEC_API should send a warning 743 message. If more authentication is done then requested (i.e.; by 744 application and IPsec layer) then the IPSEC_API should send a warning 745 message. If the IPsec rule do not enable the connection to be 746 initiated, and error message should be sent. On the other hand 747 changes requested by applications MUST NOT survive crash, so changes 748 on the PAD or SPD MUST by default be registered in application driven 749 IPsec Databases. Only administrators SHOULD change the reference SPD 750 / PAD. When both application layer and IPsec layer are required, 751 then the peer is considered authenticated when both authentication 752 have been proceeded. 754 An application can REQUIRE the following authentication parameters : 756 o AUTH_LAYER_PROP indicates where the authentication MUST be 757 performed possible values are APP_ONLY, IKE_ONLY, IKE_APP_ACK, 758 NONE. 759 o AUTH_LAYER_PROP: Where the authentication is / has / will be 760 proceeded. Possible values are APPlication, IPSEC, NONE. 761 o AUTH_METHOD_PROP: Method used for the authentication. 762 o AUTH_PARAMETERS_PROP: Parameters required for the authentication, 763 or at least their location. 765 Most of if not all of those information MUST be stored into the 766 IPSEC_API. Such information is not already stored in usual IPsec 767 databases except for some of the AUTH_PARAMETERS. 769 When an application proceeds to the authentication phase on behalf of 770 the IKE daemon, the Authentication channel MUST be bound to the 771 secured channel. This means that applications MUST return a value 772 from authentication that will be considered while deriving keys. (cf 773 TLS). 775 When an application asks to validate the authenticated peer. The 776 authentication MUST be performed by IKE. If successful, the IKE 777 daemon MUST send to the application the identity of the peer and wait 778 for an answer from the application. The answer can be an 779 ACKnowledgment or a NACKnowledgment. When receiving an NACK the IKE 780 daemon MUST go on. When receiving NACK IKE MUST send an 781 authentication failure message to the peer. 783 An application can REQUIRE that some peer will be black listed. An 784 authentication will be considered done by IKE if the usual 785 authentication has been performed properly by IKE AND the peer is not 786 black listed. If the peer is black listed an ERROR message MUST be 787 sent to the application. 789 An application might require the authentication to be performed. 790 When a connection is already in an ESTABLISHED state, performing the 791 authentication means that no more packets MUST be accepted before 792 authentication is validated. This action SHOULD be followed by a re- 793 keying operation. [need to check how an authentication in IKE can be 794 re-done] 796 7.1.2. ESTABLISHED connection parameters 798 For an ESTABLISHED connection, applications can request the following 799 parameters : 801 o AUTH_STATUS [LR]: The status of the authentication. Possible 802 values are: NONE, PROCCEDING, ESTABLISHED, FAILED. 803 o AUTH_LAYER_STATUS [LR]: Where the authentication is / has / will 804 be proceeded. 805 o AUTH_LAYER_PROP [LR] indicates where the authentication MUST be 806 performed possible values are APP_ONLY, IKE_ONLY, IKE_APP_ACK, 807 NONE. 808 o AUTH_METHOD_STATUS [LR]: Methods used for the authentication. 809 o AUTH_LAYER_PROP [LR]: Where the authentication is / has / will be 810 proceeded. Possible values are APPlication, IPSEC, NONE. 811 o AUTH_PARAMETERS_PROP [LR]: Parameters required for the 812 authentication, or at least their location. 814 Most of if not all of those information MUST be stored into the 815 IPSEC_API. Such information is not already stored in usual IPsec 816 databases. 818 7.1.3. Actions performed by the application 820 An application MUST be able to set some parameters and to require the 821 authentication to be performed. 823 By default, setting parameters SHOULD NOT affect the IPsec databases, 824 and SHOULD NOT subsist to crash. Changed parameters SHOULD be stored 825 into application driven databases. Location of such databases 826 depends on the implementation but they are most likely to be in the 827 kernel space. Some application like administrator's application that 828 set the Security Policy can change the IPsec database. 830 Requiring authentication means that for a given connection in 831 ESTABLISH state, the application wants to proceed to an 832 authentication. The given connection might already have been 833 authenticated or not. This operation requires the authentication be 834 bound to the communication. Wherever authentication is being 835 proceeded by the IPsec suite or by a third application, the 836 authentication MUST include a token derived from IP connectivity 837 parameters. 839 7.2. Simple Security Request Method 841 REQUEST [APP_ID] CONNECTION_ID PARAM 843 REQUEST message to IPSEC_API 845 where : 847 o APP_ID: is the application identifier. It can be option if the 848 connection between the application and the IPSEC_API identifies 849 the application. We do not specify here how application is 850 identified by the IPSEC_API. It could be by the port, or another 851 ID. 852 o CONNECTION_ID identifies the connection (@IP_src, @IP_dst, 853 port_src, port_dst). Value "ANY" could also be used. 854 o PARAM can be : 855 o 856 * AUTH_APP_STATUS [LR]. Response will be of the following NONE, 857 PROCCEDING, ESTABLISHED, FAILED. 858 * AUTH_IPSEC_STATUS [LR]. Response will be of the following 859 NONE, PROCCEDING, ESTABLISHED, FAILED. 860 * AUTH_LAYER_STATUS [LR]. Response will be of the following 861 APP_ONLY, IKE_ONLY, IKE_APP_ACK, NONE. 862 * AUTH_IPSEC_METHOD_STATUS [LR]: Methods used for the 863 authentication. Response will be of the following [NONE, BTNS, 864 LEATOFFAITH, PRESHAREDKEY, GROUPKEY, XAUTH, EAP, PKIX_TRUSTED, 865 PKIX_INLINE, PKIX_OFFLINE]. 866 * AUTH_APP_METHOD_STATUS [LR]: Methods used for the 867 authentication. 868 * ACTION: an action to perform like DELETE, AUTHENTICATE... 870 REQUIRE [APP_ID] CONNECTION_ID PARAM 872 REQUIRE message to IPSEC_API 874 where : 876 o APP_ID: is the application identifier. It can be option if the 877 connection between the application and the IPSEC_API identifies 878 the application. We do not specify here how applications are 879 identified by the IPSEC_API. It could be by the port, or another 880 ID. 881 o CONNECTION_ID identifies the connection (@IP_src, @IP_dst, 882 port_src, port_dst). Value "ANY" could also be used. 883 o PARAM can be : 884 o 885 * AUTH_LAYER_PROP [LR] with its associated value: APP_ONLY, 886 IKE_ONLY, IKE_APP_ACK, NONE. 887 * AUTH_IPSEC_METHOD_PROP [LR]: is an ordered list of 888 authentication methods. If one authentication method is not 889 recognized, a warning message is sent. If no authentication 890 method is recognized, an error message is sent. Possible 891 values for the list elements are [I-D.ietf-btns-c-api]: [NONE, 892 BTNS, LEATOFFAITH, PRESHAREDKEY, GROUPKEY, XAUTH, EAP, 893 PKIX_TRUSTED, PKIX_INLINE, PKIX_OFFLINE]. 894 * AUTH_APP_METHOD_PROP [LR]: is an ordered list of authentication 895 methods of application. A common list MUST be set in 896 [I-D.ietf-btns-abstract-api]. 897 * AUTH_PARAMETERS_PROP [LR]: Parameters required for the 898 authentication, or at least their location. Possible values 899 are : AUTHCTX_IPSEC_ sharedKeyID : list of shared key to 900 consider, AUTHCTX_IPSEC_ sharedKey : list of public key to 901 consider, AUTHCTX_IPSEC_ sharedKey_DIR : list of directories 902 with the public keys to consider, AUTHCTX_IPSEC_ pukKeyID : 903 list or public key id to consider, AUTHCTX_IPSEC_ pukKey : list 904 of public key to consider, AUTHCTX_IPSEC_ pukKey_DIR : list of 905 directories with the public keys to consider, 906 AUTHCTX_IPSEC_certificateDN : list of certificate DN to 907 consider, AUTHCTX_IPSEC_certificateCERT : list of certificates 908 to consider for peer authentication, 909 AUTHCTX_IPSEC_certificateCERT_DIR : directory with certificates 910 to consider for peer authentication, 911 AUTHCTX_IPSEC_certificateAuthorityDN : list of certificate 912 authority DN to consider, 913 AUTHCTX_IPSEC_certificateAuthorityCERT : list of certificates 914 authority to consider for peer authentication, 915 AUTHCTX_IPSEC_certificateAuthorityCERT_DIR : directory 916 containing certificates authority to consider for peer 917 authentication 918 * AUTHCTX_IPSEC_ACL_file 919 * ACTION: an action to perform like DELETE, AUTHENTICATE... 921 8. Security Considerations 923 This paper provides a description of application requirements to take 924 benefit of the IPsec layer. Security considerations concerns are 925 that remote and local applications can interact and potentially 926 modify IPsec databases. 928 Access and application privileges MUST be configured properly. 929 Access policy is described in [I-D.mglt-ipsec-appdb]. 931 Changes on IPsec Databases SHOULD NOT subsist to crash. Changes 932 SHOULD be stored, at least for regular application in application 933 driven databases. 934 When IPsec databases are changed by applications; one MUST 935 identify the requester application. An application can use the 936 APP_ID of another application to be assigned more privileges. 937 This problematic MUST clearly be described but is out of scope of 938 this paper. On a local system, PATH and application names can 939 identify the application since the system is considered trusted. 940 With remote applications, one can accept modifications only from 941 nodes that are trusted or believed so. This can be the case for 942 end users accepting modifications from their ISP for example. In 943 that case network authentication is enough, and then application 944 name can be trusted to identify applications. [Can we do better?] 946 9. IANA Considerations 948 There are no IANA considerations. 950 10. Acknowledgments 952 Daniel Migault is partly funded by 3MING, a research project 953 supported by the French 'National Research Agency'(ANR). 955 11. References 957 11.1. Normative References 959 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 960 Requirement Levels", BCP 14, RFC 2119, March 1997. 962 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 963 Internet Protocol", RFC 4301, December 2005. 965 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 966 December 2005. 968 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 969 RFC 4306, December 2005. 971 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 972 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 973 December 2005. 975 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 976 Channels", RFC 5056, November 2007. 978 11.2. Informative References 980 [I-D.ietf-btns-abstract-api] 981 Richardson, M., "An abstract interface between 982 applications and IPsec", draft-ietf-btns-abstract-api-02 983 (work in progress), February 2008. 985 [I-D.ietf-btns-c-api] 986 Richardson, M., Williams, N., Komu, M., and S. Tarkoma, 987 "IPsec Application Programming Interfaces", 988 draft-ietf-btns-c-api-03 (work in progress), 989 February 2008. 991 [I-D.ietf-btns-connection-latching] 992 Williams, N., "IPsec Channels: Connection Latching", 993 draft-ietf-btns-connection-latching-08 (work in progress), 994 April 2008. 996 [I-D.ietf-btns-ipsec-apireq] 997 Richardson, M. and B. Sommerfeld, "Requirements for an 998 IPsec API", draft-ietf-btns-ipsec-apireq-00 (work in 999 progress), April 2006. 1001 [I-D.mglt-ipsec-appdb] 1002 Migault, D., "Application IPsec privileges Database", 1003 draft-mglt-ipsec-appdb-00 (work in progress), 1004 November 2008. 1006 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 1007 Management API, Version 2", RFC 2367, July 1998. 1009 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 1010 Security: An Unauthenticated Mode of IPsec", RFC 5386, 1011 November 2008. 1013 Author's Address 1015 Daniel Migault 1016 Orange Labs R&D 1017 38 rue du General Leclerc 1018 92794 Issy-les-Moulineaux Cedex 9 1019 France 1021 Phone: +33 1 45 29 60 52 1022 Email: mglt.ietf@gmail.com