idnits 2.17.1 draft-gupta-idef-iap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 79: '...ding agent which MAY do some rewriting...' RFC 2119 keyword, line 120: '...understanding their content. It MAY do...' RFC 2119 keyword, line 147: '...at. IAP entities MUST accept data sent...' RFC 2119 keyword, line 158: '... in a proxy role MAY rewrite content t...' RFC 2119 keyword, line 168: '...server (manager) MAY choose to accept ...' (31 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: After the protocol setup phase, an entity in a proxy role MUST be transparent. It MUST not alter any data being relayed between the client and server. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: IAP entities MUST not use any trailer fields in a chunked body. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The TLS 1.0 protocol MUST be used. An IDEF entity MUST not allow older protocol HELLO messages, and reject attempts to negotiate an older version of the protocol. The following TLS ciphersuite MUST be supported in line with recommendations from the tls working group: -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 section? '1' on line 634 looks like a reference -- Missing reference section? '2' on line 637 looks like a reference -- Missing reference section? '3' on line 641 looks like a reference -- Missing reference section? '4' on line 646 looks like a reference -- Missing reference section? '5' on line 651 looks like a reference -- Missing reference section? '6' on line 655 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Dipankar Gupta 2 Internet Engineering Task Force Hewlett-Packard 3 Intrusion Detection Exchange Format Working Group 15 September, 1999 4 Expires: March, 2000 6 IAP: Intrusion Alert Protocol 7 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 The Intrusion Alert Protocol (IAP) is an application--level protocol 33 for exchanging intrusion alert data between intrusion detection 34 elements, notably sensor/analyzers and managers in IP networks. The 35 protocol is designed to be independent of the type of data 36 representation. The data definition and formatting model for alerts 37 is described in companion documents of the working group. 39 1 Introduction 41 1.1 Purpose 43 The Intrusion Alert Protocol (IAP) is an application--level protocol 44 for exchanging intrusion alert data. The protocol is designed to 45 provide the necessary transport and security properties to allow 46 sensitive alert data to be sent across IP networks. In addition, the 47 protocol is designed so that future extensions may use the 48 application layer for configuring IDEF entities. 50 1.2 Transport layer protocol 52 IAP uses the transmission control protocol (TCP) [1] as its 53 underlying transport layer mechanism. This protocol is used for a 54 wide variety of IP services. It has a number of features such as 55 congestion control, slow start, etc. that enable it to work over 56 large networks with a wide variety of latency, bandwidth and 57 congestion characteristics. TCP provides reliable and sequenced 58 delivery of data between IP peers. 60 1.3 Terminology 62 Terminology is borrowed from [2]. 64 1.4 Overall operation 66 IAP is primarily oriented towards supporting the transmission of 67 alert data from an intrusion detection sensor/analyser that detects a 68 potential intrusion, to a manager that displays it to a human, logs 69 it to a database or takes appropriate action. 71 In the simplest case, a sensor/analyser (SA) sends alerts to a 72 manager(M). 74 SA -------------------> M 76 In a more complex situation, there are more than one intermediaries 77 in the communication path. Two common forms of intermediary are: 79 Proxy A proxy is a forwarding agent which MAY do some rewriting 80 of the content, and forward the message. 82 Gateway A gateway is used to translate messages from/to some 83 native format (such as SNMPv3 UDP wire protocol). 85 A proxy may be used to relay two connections when the communication 86 needs to pass through an intermediary such as a firewall. 88 SA ----> P -----> G ----> M 90 Here, IDEF data is generated by SA and passed to a proxy P. P 91 connects to a gateway G, which translates alerts into a native format 92 to be consumed by the manager M. In this exchange, the connections 93 between SA and P, and P and G use IAP. The connection between G and M 94 uses the native protocol supported by M. 96 IAP communication takes place over an IP network using the transport 97 control protocol (TCP). To connect with other networks, gateways 98 should be used to transform protocol data into the native 99 representation. 101 2 IAP notation 103 2.1 Entity roles 105 2.1.1 Server role 107 An IDEF entity acts in an IAP server role if it serves as the 108 consumer of alert data sent over IAP, that is, a manager in an IDEF 109 setting. 111 2.1.2 Client role 113 An IDEF entity acts in an IAP client role if it serves as a producer 114 of alert data sent over IAP, that is, a sensor/analyzer in an IDEF 115 setting. 117 2.1.3 Proxy role 119 An IDEF entity in a proxy role does not have an IAP identity. It acts 120 as a relay of messages without understanding their content. It MAY do 121 some rewriting of the content, but in a manner that does not impact 122 the security properties of alerts. 124 2.2 Augmented BNF 126 We use the augmented BNF definitions of [3]. 128 3 Protocol parameters 130 IAP uses a . numbering scheme to indicate versions of 131 the protocol. The minor number is changed when updates to the 132 protocol add features that do not change the parsing algorithm. The 133 major number is changed when the parsing algorithm is modified. 135 This document describes version 0.1 of IAP. The version string for 136 this is iap-version: IAP/0.1. 138 3.1 Media Types 140 IAP uses Internet Media Types [4] to denote the type of alert data. 141 Media types are used to define the encapsulation of data, in a manner 142 that can be extended without requiring changes to the application 143 protocol. 145 The only media type used by IAP/0.1 is application/x-idef-alert. It 146 is expected that the IANA will allocate a registered media type for 147 the IDEF alert format. IAP entities MUST accept data sent in this 148 format. 150 4 Structure of IAP protocol sessions 152 An IAP protocol session is split into four phases. 154 4.1 Protocol Setup 156 This is the first phase after a TCP connection is established. In 157 this phase, the two parties set up the transport parameters of the 158 protocol. An IAP entity in a proxy role MAY rewrite content to set 159 up the protocol in this phase. This phase uses a request--response 160 form. The primary reason for this phase is to allow the protocol 161 to be proxied in an effective manner. 163 Response codes are borrowed from the hypertext transfer protocol [3]. 165 In its most primitive form, this negotiation is initiated by an IAP 166 client (sensor/analyzer) by issuing an iap-connect-request command. 168 A corresponding IAP server (manager) MAY choose to accept this 169 connection, and respond using an iap-response command, with the 170 status code set to 200 to denote success. The parties can then 171 proceed to the next phase. 173 Alternatively, the entity MAY reject the connection request by 174 setting the status code to 4xx to denote failure. In particular, the 175 403 Forbidden command MAY be used by the entity in server role. 177 An intermediate entity in a proxy role MAY, upon receiving the 178 request, rewrite the iap-connect-request command. A proxy MAY append 179 the iap-proxy-via command to the connection request before passing it 180 on to the receiving entity. The version string used by the proxy MUST 181 be the same as the one specified in iap-connect-request. This is 182 important to ensure that newer versions of IAP can work with older 183 proxies. 185 A proxy SHOULD relay the server's response back to the client without 186 rewriting it. A proxy MUST verify that existing proxy-via headers in 187 the request don't match its own identity in order to limit the damage 188 from misconfigured proxies. Otherwise, it MUST send a bad gateway 189 (502) response to the client that requested the connection. 191 4.2 Security Setup 193 After the protocol setup phase, an entity in a proxy role MUST be 194 transparent. It MUST not alter any data being relayed between the 195 client and server. 197 A single request--response pair is used to upgrade the security of 198 a connected transport. An entity in a client role, upon receiving 199 an iap-response command without any errors, issues an 200 iap-upgrade-request command. 202 A server should expect the iap-upgrade-request command after sending 203 an iap-response reply indicating acceptance of the connection. The 204 server SHOULD terminate if the request is not received, or some other 205 request is received. Upon receiving the request, it SHOULD send an 206 iap-response reply with the status code set to 101 to indicate 207 acceptance of the upgrade. 209 It MAY also send a 500 to denote server configuration error, if for 210 instance, it is not yet configured and does not have a certificate. 212 Once the client receives an iap-response message indicating success 213 of its request to upgrade the security of the connection, it 214 initiates the TLS 1.0 handshake protocol [5]. This protocol 215 negotiates the protocol version, cryptographic algorithms, mutual 216 authentication and generates shared secrets for the next phase. 218 If the parties complete the TLS handshake protocol successfully, they 219 enter exchange final setup request--response pairs, using the TLS 220 record protocol. These pairs are exchanged after a successful 221 handshake and is used by the parties to verify connection parameters. 222 Any entities in a proxy role MUST forward data transparently. End 223 entities detect any attempts to manipulate or inject messages into 224 the data stream. 226 First, the client informs the server about the IAP version it intends 227 to employ for the session using a iap-version-verify message. The 228 server matches this against the version in the iap-connect-request 229 header, and issues a iap-response reply. The server then sends its 230 own iap-version-verify message which is verified by the client, which 231 responds with a iap-response reply. The status code 200 SHOULD be 232 used to indicate success. 234 The protocol and security setup phases are now complete, and the 235 channel is ready to communicate alert data. 237 4.3 Secured data transport 239 This is the main phase of the protocol. In this phase, encoded IDEF 240 alerts are sent by the client (sensor/analyzer) to the server 241 (manager) over the TLS record layer. 243 In addition to data in the form x-idef-alert, compatible clients and 244 servers MAY send other data using this transport. A peer, upon 245 receipt of data that it is unable to decode (unknown IAP content 246 type), SHOULD reject the data. It MAY choose not to terminate the 247 connection. This allows clients (analyzers) supporting richer content 248 types to communicate with legacy servers (managers). 250 4.4 Termination 252 Termination can be initiated by either peer by sending a TLS close- 253 notify alert (section 7.2.1). The recipient, on receipt of this 254 alert, should in turn respond with a close-notify alert and the 255 parties can close the connection gracefully. 257 4.5 Example 259 In this example, an analyzer A is configured to connect to proxy P. P 260 connects to a manager M to deliver the alerts. The following diagram 261 depicts message flow in the case where there are no errors, and a 262 connection is set up. 264 A P M 265 ---------------> 266 iap-connect-request 268 ---------------> 269 iap-connect-request 270 <--------------- 271 iap-response 273 <--------------- 274 iap-response 276 [proxy is now a transparent forwarding agent] 278 ---------------> 279 iap-upgrade-request 281 <--------------- 282 iap-response 284 (TLS handshake negotiation) 286 [TLS handshake completed: data sent using the TLS record layer] 288 ---------------> 289 iap-version-verify 291 <--------------- 292 iap-response 294 <--------------- 295 iap-version-verify 297 ---------------> 298 iap-response 300 ---------------> 301 iap-content 303 <--------------- 304 iap-response 306 5 IAP Wire Protocol 308 IAP uses a subset of the HTTP/1.1 syntax to send IDEF alerts. The 309 request--response protocol is modeled on HTTP, with the exception 310 that the each request and response must be prefixed with the IAP 311 version number during the setup phase. 313 All requests must be responded to using an iap-response message 314 indicating whether the recipient was able to successfully interpret 315 (and act on) the request. Response codes are borrowed from HTTP/1.1. 317 5.1 Alert transfer encoding 319 Alert content is transferred using the chunked transfer encoding of 320 HTTP/1.1 [3]. This encoding imposes an almost fixed overhead on every 321 alert. The overhead (additional octets transferred) for alerts is 322 approximately 90 octets per alert. 324 5.2 Syntax 326 In the wire protocol, requests and responses are terminated by a 327 pair of carriage-return/line-feed (CRLF) sequences, following 328 HTTP/1.1. The following definitions from [3] are used. 330 + host 332 + DIGIT 334 + Chunked-Body 336 + CRLF 338 IAP entities MUST not use any trailer fields in a chunked body. 340 An IAP message is denoted by iap-message. 342 iap-message = 343 ( iap-connect-request | 344 iap-upgrade-request | 345 iap-version-verify | 346 iap-content | 347 iap-response ) 348 CRLF 350 The version of the protocol is denoted by iap-t-version 352 iap-t-version = "IAP/0.1" 354 5.3 Protocol messages 356 5.3.1 Responses 358 An iap-response denotes the status code returned by an IAP entity in 359 response to a request. 361 iap-response = iap-t-version SP 362 3DIGIT CRLF 364 5.3.2 Connection Request 366 A iap-connect-request denotes a request message sent by an IAP client 367 to establish an IAP protocol connection. 369 iap-connect-request 370 = iap-t-connect-request 371 ( iap-t-via )* 373 iap-t-connect-request 374 = iap-t-version SP 375 "CONNECT" SP host CRLF 377 iap-t-via = iap-t-version SP 378 "VIA" SP host CRLF 380 5.3.3 Upgrade Request 382 An iap-upgrade-request contains a notification from the client that 383 it wishes to upgrade the security of the connection. 385 iap-upgrade-request 386 = iap-t-version SP 387 "Upgrade: TLS/1.0" CRLF 389 5.3.4 Version Verify 391 An iap-version-verify request contains a notification requesting that 392 the peer verify the version of IAP being used. 394 iap-version-verify 395 = iap-t-version SP 396 "IAP-Version: 0.1" CRLF 398 5.3.5 Alert Content 400 The iap-content message is an encoded alert sent using IAP. 402 iap-content 403 = iap-t-content-header 404 CRLF 405 iap-t-content-body 406 CRLF 408 iap-t-content-header 409 = iap-content-type 410 iap-transfer-encoding 412 iap-content-type = "Content-Type:" SP 413 "application/x-idef-alert" 414 CRLF 416 iap-transfer-encoding 417 = "Transfer-Encoding: " SP 418 "chunked" CRLF 420 iap-t-content-body 421 = Chunked-Body 423 5.4 Example 425 Here is a transcript of a scenario in which an IDEF sensor/analyzer 426 A wishes to send alerts to manager M. The proxy P mediates this 427 connection. After the connection is set up, A sends an IDEF alert 428 64 octets in length with each octet set to 0xFF. 430 A P M 431 iap-connect-request 432 ---------------> 433 IAP/0.1 CONNECT M.DOM.ORG CRLF 434 CRLF 435 iap-connect-request 436 ---------------> 437 IAP/0.1 CONNECT M.DOM.ORG CRLF 438 IAP/0.1 VIA P.DOM.ORG CRLF 439 CRLF 440 iap-response 441 <--------------- 442 IAP/0.1 200 CRLF 443 CRLF 444 iap-response 445 <--------------- 446 IAP/0.1 200 CRLF 447 CRLF 449 [proxy is now a transparent forwarding agent] 450 iap-upgrade-request 451 ---------------> 452 IAP/0.1 Upgrade: TLS/1.0 CRLF 453 CRLF 454 iap-response 455 <--------------- 456 IAP/0.1 101 CRLF 457 CRLF 459 (TLS handshake negotiation) 461 [TLS handshake completed: data sent using the TLS record layer] 462 iap-version-verify 463 ---------------> 464 IAP/0.1 IAP-Version: 0.1 CRLF 465 CRLF 466 iap-response 467 <--------------- 468 IAP/0.1 200 CRLF 469 CRLF 471 iap-version-verify 472 <--------------- 473 IAP/0.1 IAP-Version: 0.1 CRLF 474 CRLF 476 iap-response 477 ---------------> 478 IAP/0.1 200 CRLF 479 CRLF 481 iap-content 482 ---------------> 483 Content-Type: application/x-idef-alert CRLF 484 Transfer-Encoding: chunked CRLF 485 CRLF (end of chunked data header) 486 40 CRLF (end of chunk length) 487 64 * 0xFF octet (IDEF alert data) 488 CRLF (end of chunk) 489 0 CRLF (end of last chunk) 490 CRLF (end of Chunked-Body) 491 CRLF (end of iap-content) 492 CRLF (end of iap-message) 494 iap-response 495 <--------------- 496 IAP/0.1 200 CRLF 497 CRLF 499 6 Implementation Considerations 501 6.1 TCP connection initiation 503 The entity that initiates a TCP connection will be variable, and 504 dependent on the exact deployment model. A common scenario is that of 505 sensor/analyzers outside a security perimeter, with the manager 506 inside. In such configurations, the manager MAY initiate the 507 connection in line with perimeter security requirements. 509 Another common scenario is that of remote sensor/analyzers being 510 managed by a service provider. In this case, the sensor/analyzer MAY 511 contact a proxy on the perimeter, which in turn connects to the 512 remote manager in a service provider's network. 514 The communications protocol should allow chained proxies to carry IAP 515 data across multiple security perimeters. 517 6.2 Urgent data 519 Urgent data at the TCP layer MUST NOT be used by an entity using IAP. 520 Endpoints SHOULD terminate a connection upon receipt of urgent data. 522 6.3 TLS/1.0 protocol 524 The TLS 1.0 protocol MUST be used. An IDEF entity MUST not allow 525 older protocol HELLO messages, and reject attempts to negotiate an 526 older version of the protocol. The following TLS ciphersuite MUST be 527 supported in line with recommendations from the tls working group: 529 + TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 531 The recommendations in sections 2.1 and 2.2 of [6] must be followed 532 by IAP client and server implementations. 534 6.4 Mandatory client certificates 536 In line with the requirement for strong mutual authentication, client 537 certificates (for sensor/analyzers acting in an IAP client role) are 538 mandatory, and the entity should verify the certificate's content 539 during the TLS handshake. 541 6.5 Certificate conventions 543 One or more of the following extensions MUST be specified in X.509v3 544 certificates issued to an IAP client or server entity: 546 + IAP_ALERT_GENERATOR 548 + IAP_ALERT_CONSUMER 550 + IAP_IDEF_CONFIGURATOR 552 The object identifiers (OIDs) for these extensions will be specified 553 in a companion document. The presence of the extension means that the 554 signer believes that the holder of the certificate is allowed to 555 function in the corresponding IAP role. 557 An entity in a IAP server role MUST have the IAP_ALERT_CONSUMER 558 extension in its certificate. Similarly, an entity in a IAP client 559 role MUST have the IAP_ALERT_GENERATOR extension in its certificate. 561 6.6 Verification of peer identity 563 As the peer identity is initially sent in the clear, it is essential 564 that the IAP client and server entities verify the identity of their 565 peer using criteria based on their public key certificates. Also, the 566 version of the protocol MUST be verified to stop protocol downgrade 567 attacks. The mechanism specified in section 2.4 of [6] for verifying 568 peer certificates must be followed. 570 6.7 TLS session resumption 572 The entities MUST be configured to support TLS session resumption. 573 Because of the possibility of external entities maliciously 574 terminating IAP sessions, clients and servers MAY attempt to resume a 575 session even if the TLS close-notify alert was not received before 576 the transport closed. 578 7 Security Considerations 580 As IAP is intended to be used for carrying security--sensitive data, 581 we will list a number of security considerations. 583 7.1 Reliable and sequenced delivery 585 Although reliable and sequenced delivery can be built on top of UDP, 586 this usually reimplements some of the protocol features of TCP. 587 Certain deployment scenarios may prefer fast unreliable delivery with 588 the manager doing a "best effort" attempt to keep up with the flow of 589 alerts. This proposal does not address such a scenario. One potential 590 alternative for this scenario is to use the SNMP trap as a means to 591 represent the alert. We remark that the above scenario is at odds 592 with a number of items in section 6 of the requirements document of 593 the working group. 595 7.2 TCP handshake 597 TCP uses a three--message handshake mechanism to set up connections. 598 This opens the protocol up to certain well-known denial of service 599 attacks. This protocol does not address this vulnerability. The 600 effect of such attacks can be mitigated by a number of techniques, 601 such as restricting the set of peer IP addresses allowed to connect, 602 etc. 604 7.3 Key Management 606 For a public--key based communications model to be useful, good key 607 management principles must be used for the lifecycle of public key 608 certificates. The pkix working group of the IETF is defining 609 mechanisms that can be used for this purpose. 611 7.4 Message length 613 Traffic analysis may allow an observer to induce the type of alert 614 from the size of the message. If this is a threat, IDEF entities 615 SHOULD pad their data so that it observes some known distribution 616 (such as the uniform distribution) over time. 618 7.5 Proxy considerations 620 As the proxy transparently forwards encrypted traffic after 621 connections are established, it is prudent to deploy the proxy in a 622 manner that it can't be used to violate the perimeter security 623 policy. 625 8 Acknowledgements 627 This document makes heavy use of prior work in the IETF on HTTP, MIME 628 and TLS. Their effort is gratefully acknowledged. Members of the 629 IETF's intrusion detection working group (idwg) have made extensive 630 comments that are reflected in the draft. 632 9 Bibliography 634 [1] J. Postel, "Transmission control protocol," Request for Comments 635 (Standard) 793, Internet Engineering Task Force, Sept. 1981. 637 [2] M. Wood, "Intrusion detection exchange format requirements," 638 internet draft (work in progress), Internet Engineering Task Force, 639 June 1999. 641 [3] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 642 Leach, and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," 643 Request for Comments (Draft Standard) 2616, Internet Engineering Task 644 Force, June 1999. 646 [4] N. Borenstein and N. Freed, "MIME (multipurpose internet mail 647 extensions): Mechanisms for specifying and describing the format of 648 internet message bodies," Request for Comments (Proposed Standard) 649 1341, Internet Engineering Task Force, June 1992. 651 [5] T. Dierks and C. Allen, "The TLS protocol version 1.0," Request 652 for Comments (Proposed Standard) 2246, Internet Engineering Task 653 Force, Jan. 1999. 655 [6] C. Newman, "Using TLS with IMAP, POP3 and ACAP," Request for 656 Comments (Proposed Standard) 2595, Internet Engineering Task Force, 657 June 1999. 659 A Author's Address 661 Dipankar Gupta 662 Hewlett-Packard 663 690 E Middlefield Road, MS 31R 664 Mountain View, CA 94043, USA 665 Fax: +1(650)919-8540 666 Email: dg@mayfield.hp.com 668 B Full Copyright Statement 670 Copyright (C) The Internet Society (1999). All Rights Reserved. 672 This document and translations of it may be copied and furnished to 673 others, and derivative works that comment on or otherwise explain it 674 or assist in its implementation may be prepared, copied, published 675 and distributed, in whole or in part, without restriction of any 676 kind, provided that the above copyright notice and this paragraph are 677 included on all such copies and derivative works. However, this 678 document itself may not be modified in any way, such as by removing 679 the copyright notice or references to the Internet Society or other 680 Internet organizations, except as needed for the purpose of 681 developing Internet standards in which case the procedures for 682 copyrights defined in the Internet Standards process must be 683 followed, or as required to translate it into languages other than 684 English. 686 The limited permissions granted above are perpetual and will not be 687 revoked by the Internet Society or its successors or assigns. 689 This document and the information contained herein is provided on an 690 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 691 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 692 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 693 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 694 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 696 Table of Contents 698 1 Introduction ........................................ 1 700 1.1 Purpose ............................................. 1 702 1.2 Transport layer protocol ............................ 2 704 1.3 Terminology ......................................... 2 706 1.4 Overall operation ................................... 2 708 2 IAP notation ........................................ 3 710 2.1 Entity roles ........................................ 3 712 2.1.1 Server role ......................................... 3 714 2.1.2 Client role ......................................... 3 716 2.1.3 Proxy role .......................................... 3 718 2.2 Augmented BNF ....................................... 3 720 3 Protocol parameters ................................. 4 722 3.1 Media Types ......................................... 4 724 4 Structure of IAP protocol sessions .................. 4 726 4.1 Protocol Setup ...................................... 4 728 4.2 Security Setup ...................................... 5 730 4.3 Secured data transport .............................. 6 732 4.4 Termination ......................................... 6 734 4.5 Example ............................................. 6 736 5 IAP Wire Protocol ................................... 7 738 5.1 Alert transfer encoding ............................. 8 740 5.2 Syntax .............................................. 8 741 5.3 Protocol messages ................................... 9 743 5.3.1 Responses ........................................... 9 745 5.3.2 Connection Request .................................. 9 747 5.3.3 Upgrade Request ..................................... 9 749 5.3.4 Version Verify ...................................... 10 751 5.3.5 Alert Content ....................................... 10 753 5.4 Example ............................................. 11 755 6 Implementation Considerations ....................... 12 757 6.1 TCP connection initiation ........................... 12 759 6.2 Urgent data ......................................... 13 761 6.3 TLS/1.0 protocol .................................... 13 763 6.4 Mandatory client certificates ....................... 13 765 6.5 Certificate conventions ............................. 13 767 6.6 Verification of peer identity ....................... 14 769 6.7 TLS session resumption .............................. 14 771 7 Security Considerations ............................. 14 773 7.1 Reliable and sequenced delivery ..................... 14 775 7.2 TCP handshake ....................................... 14 777 7.3 Key Management ...................................... 15 779 7.4 Message length ...................................... 15 781 7.5 Proxy considerations ................................ 15 783 8 Acknowledgements .................................... 15 785 9 Bibliography ........................................ 15 787 A Author's Address .................................... 16 788 B Full Copyright Statement ............................ 16