idnits 2.17.1 draft-ietf-calsch-irip-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 1) being 63 lines 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.) ** The abstract seems to contain references ([ICAL], [ICMS], [RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048], [RFC-2049], [ITIP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance 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 147: '...ich the Receiver MUST interpret relati...' RFC 2119 keyword, line 736: '...anslations of it MAY be copied and fur...' RFC 2119 keyword, line 738: '...ts implmentation MAY be prepared, copi...' RFC 2119 keyword, line 746: '...tandards process MUST be followed, or ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: This document and translations of it MAY be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation MAY be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself MAY NOT be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process MUST be followed, or as required to translate it into languages other than English. -- 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 (November 21, 1997) is 9654 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 section? 'ITIP' on line 643 looks like a reference -- Missing reference section? 'ICAL' on line 635 looks like a reference -- Missing reference section? 'RFC-2045' on line 668 looks like a reference -- Missing reference section? 'RFC-2046' on line 672 looks like a reference -- Missing reference section? 'RFC-2047' on line 675 looks like a reference -- Missing reference section? 'RFC-2049' on line 32 looks like a reference -- Missing reference section? 'RFC-2048' on line 679 looks like a reference -- Missing reference section? 'ICMS' on line 640 looks like a reference -- Missing reference section? 'IMIP' on line 647 looks like a reference -- Missing reference section? 'ICSM' on line 119 looks like a reference -- Missing reference section? 'SASL' on line 244 looks like a reference -- Missing reference section? 'RFC-822' on line 655 looks like a reference -- Missing reference section? 'ANON-SASL' on line 633 looks like a reference -- Missing reference section? 'ID-UTF8' on line 651 looks like a reference -- Missing reference section? 'RFC-1847' on line 658 looks like a reference -- Missing reference section? 'RFC-2112' on line 662 looks like a reference -- Missing reference section? 'RFC-2015' on line 665 looks like a reference -- Missing reference section? 'RFC-2222' on line 683 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Andre Courtemanche/CS&T 3 Internet Draft Steve Mansour/Netscape 4 Pete O'Leary/Amplitude 5 Expires six months after November 21, 1997 7 iCalendar Real-time Interoperability Protocol (iRIP) 9 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 andits working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months. 16 Internet-Drafts may be updated, replaced, or made obsolete by other 17 documents at any time. It is not appropriate to use Internet-Drafts as 18 reference material or to cite them other than as a "working draft" or 19 "work in progress". 21 To learn the current status of any Internet-Draft, please check the 1id- 22 abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 24 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 Distribution of this document is unlimited. 28 Abstract 29 This document specifies a binding from the iCalendar Transport- 30 independent Interoperability Protocol [ITIP] to a real-time transport. 31 Calendaring entries defined by the iCalendar Object Model [ICAL] are 32 composed using constructs from [RFC-2045], [RFC-2046], [RFC-2047], [RFC- 33 2048] and [RFC-2049]. 35 This document is based on the calendaring and scheduling model defined 36 by [ICMS]. 38 This document is based on discussions within the Internet Engineering 39 Task Force (IETF) Calendaring and Scheduling (CALSCH) working group. 40 More information about the IETF CALSCH working group activities can be 41 found on the IMC website at http://www.imc.org, the IETF website at 42 http://www.ietf.org/html.charters/calsch-charter.html. Refer to the 43 references within this document for further information on how to access 44 these various documents. 46 Distribution of this document is unlimited. Comments and suggestions for 47 improvement should be sent to the authors. 49 1. Introduction 51 This binding document provides the transport specific information 52 necessary convey iCalendar Transport-independent Interoperability 53 Protocol [ITIP] over a real-time transport. 55 Courtemanche/Mansour/O'Leary 1 Expires May 1998 56 1.1 Related Memos 58 Implementors will need to be familar with several other memos that, 59 along with this memo, form a framework for Internet calendaring and 60 scheduling standards. 62 This document - specifies an Internet email binding for [ITIP]. 64 [ICMS] - specifies a common terminology and abstract; 66 [ICAL] - specifies a core specification of objects, data types, 67 properties and property parameters; 69 [ITIP] - specifies an interoperability protocol for scheduling between 70 different implementations; 72 [IMIP] - specifies a messaging-based protocol binding for [ITIP]. 74 This memo does not attempt to repeat the specification of concepts or 75 definitions from these other memos. Where possible, references are made 76 to the memo that provides for the specification of these concepts or 77 definitions. 79 1.2 Formatting Conventions 81 The mechanisms defined in this memo are defined in propose. In order to 82 refer to elements of the calendaring and scheduling model, core object 83 or interoperability protocol defined in [ICMS], [ICAL] and [ITIP] some 84 formatting conventions have been used. 86 Calendaring and scheduling roles defined by [ICMS] are referred to in 87 quoted-strings of text with the first character of each word in upper 88 case. For example, "Organizer" refers to a role of a "Calendar User" 89 within the scheduling protocol defined by [ITIP] 91 Calendar components defined by [ICAL] are referred to with capitalized, 92 quoted-strings of text. All calendar components start with the letter 93 "V". For example, "VEVENT" refers to the event calendar component, 94 "VTODO" refers to the to-do calendar component and "VJOURNAL" refers to 95 the daily journal calendar component. 97 Scheduling methods defined by [ITIP] are referred to with capitalized, 98 quoted-strings of text. For example, "REQUEST" refers to the method for 99 requesting a scheduling calendar component be created or modified, 100 "REPLY" refers to the method a recipient of a request uses to update 101 their status with the "Organizer" of the calendar component. 103 Properties defined by [ICAL] are referred to with capitalized, quoted- 104 strings of text, followed by the word "property". For example, 105 "ATTENDEE" property refers to the iCalendar property used to convey the 106 calendar address of a calendar user. 108 Courtemanche/Mansour/O'Leary 2 Expires May 1998 109 Property parameters defined by [ICAL] are referred to with lower case, 110 quoted-strings of text, followed by the word "parameter". For example, 111 "VALUE" parameter refers to the iCalendar property parameter used to 112 override the default data type for a property value. 114 2. Architecture 116 The goal of iRIP is to enable real-time interoperability between 117 scheduling systems using the iCalendar [ICAL] format for information 118 exchange. iRIP is designed primarily to allow Calendar Services (CS) as 119 defined in [ICSM] to forward real-time requests on behalf of Calendar 120 User Agents (CUA). The goal of iRIP is to allow two or more CS's to 121 establish connections between them and operate as a single Calendar 122 Domain. 124 iRIP allows a CS to initiate a session and perform operations on behalf 125 of multiple CUA's without the need to reauthenticate the session for 126 each CUA. 128 The design of iRIP does not preclude its use from CUA directly to CS, 129 however. iRIP does not support client access functions such as calendar 130 browsing, retrieval and search. These requirements will be addressed by 131 the Calendar Access Protocol (CAP). 133 Terms used in the following discussion include: 135 . the User, the CU that initiates a request. 136 . the Sender, the agent used to contact a receiving device, send 137 commands, and receive replies, and 138 . the Receiver, the agent that accepts commands and sends replies. 140 The Sender and Receiver can take on varying roles of CUA and CS as 141 described in [ICMS]. 143 iRIP allows two CS's to establish different levels of trust so that 144 scheduling operations can be performed as efficiently as possible. When 145 an iRIP connection is first established, both parties to the connection 146 authenticate one another using the AUTHENTICATE command. The Sender can 147 then initiate commands which the Receiver MUST interpret relative to the 148 Sender's access control. If proxy operations are required, then an 149 authentication that supports both the authorization user id and 150 authentication user id must be used. 152 2.1 State Diagram 154 An iRIP session begins when a TCP/IP connection is made on port 5228. 155 The protocol begins in the Connected state. The AUTHENTICATE command, 156 when successful, begins the Authenticated state. From the Authenticated 157 state, the sender can initiate a request using the RECIPIENT command. 158 The Sender can then issues as many RECIPIENT commands as the operation 159 in progress requires until sending an ICALDATA command. After issuing 161 Courtemanche/Mansour/O'Leary 3 Expires May 1998 162 the ICALDATA command, the Sender must wait for a response from the 163 receiver. The Receiver can respond that the request has been completed 164 or that the request could not be completed in the time specified by the 165 Sender. When the Receive has ended, the Sender returns to the 166 Authenticated state where another request can be initiated. 168 >From the Authenticated state, the Sender can issue a PROXY command to 169 indicate that the following command is being performed on behalf of 170 another party. After the PROXY command succeeds and the send and receive 171 are accomplished, the PROXY information is cleared and the Sender 172 returns to the Authenticated state. 174 +------------------+ 175 | | 176 V | 177 +------------+ +---------------+ | 178 | Connected |--AUTHENTICATE-->| Authenticated |-----+ | 179 +------------+ +---------------+ | | 180 | | 181 +-----------------RECIPIENT-----------------------+ | 182 | | | 183 V | | 184 +------+ +------------+ | | 185 | Send |<----RECIPIENT-----| Auth/Proxy |<---PROXY---+ | 186 +------+ +------------+ | 187 | | 188 | | 189 | +---------+ +--------+ | 190 +--| Receive |--(Response from Server)-->| Idle |---+ 191 +---------+ +--------+ 192 A | 193 | | 194 +--------------CONTINUE---------------+ 196 2.2 Bounded Latency 198 iRIP is designed so that the Sender can either obtain an immediate 199 response from a request or discover within a known amount of time that 200 the request cannot be completed. When the Sender initiates a command 201 that the Receiver cannot complete within a given amount of time, the 202 Receiver can return an error code to the Sender indicating this 203 condition. The Sender then issues either a CONTINUE or ABORT command. 204 The ABORT command immediately terminates the command in progress. The 205 CONTINUE command instructs the Receiver to continue processing the 206 command. The ABORT command causes the Receiver to discard the current 207 command and return to the Authenticated state. 209 3. Commands 211 In the examples below, lines preceded with "S:" refer to the Sender and 212 lines preceded with "R:" refer to the Receiver. 214 Courtemanche/Mansour/O'Leary 4 Expires May 1998 215 3.1 ABORT 217 The ABORT command is issued by the Sender to stop an ICALDATA request 218 from being processed further. When the latency time is specified on the 219 ICALDATA command, the Receiver must issue a reply to the Sender within 220 the specified time. The reply may be a reply code indicating that the 221 server has not yet processed the request. The Sender must then tell the 222 server whether to continue or abort. 224 Example: 226 ... 227 S: ICALDATA:10 228 R: 3.5.4 Start ICAL input; end with . 229 S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 230 S: Content-Transfer-Encoding: quoted-printable 231 S: 232 S: BEGIN:VCALENDAR 233 S: ... 234 S: END:VCALENDAR 235 S: . 236 237 R: . 238 R: 3.5.0 Reply Pending 239 S: ABORT 240 R: 2.5 OK 242 3.2 AUTHENTICATE 244 The authentication mechanism used in iRIP is based on [SASL]. This 245 allows the iRIP senders and receivers to dynamically negotiate 246 authentication and encryption mechanisms. SASL defines authentication 247 methods such as ANONYMOUS and encapsulates concepts of PROXY used in 248 iRIP. 250 The AUTHENTICATE command is used by the client to identify itself to the 251 server. Authenticate is required before any other command can be used 252 and must be the first one sent following the server's welcome message. 253 The format of the command is of the following: 255 AUTHENTICATE 257 from which the standard SASL interchange will take place as defined in 258 the SASL profile. 260 Example of an authentication session: 262 R: Welcome IRIP Server 263 S: AUTHENTICATE KERBEROS_V4 744RTU3r# 264 S: sfdkjgs;lfdjg s;ldfkj gslkfdjgwrt949jsl4ns.dlngsdf 265 S: slkfjgsdlfjg;dslfjgdsfg 266 S: ;lasfgsdfg 45243 z!$14325dc 267 R: OK Kerberos V4 authentication successful 269 Courtemanche/Mansour/O'Leary 5 Expires May 1998 270 3.2.1 Authentication with Proxy Access 272 The proxy mechanism is the ability to have data posted from through an 273 indirect source. To handle this requirement, SASL mechanisms have a 274 separate _Authentication_ and _authorization_ identity. Thus, server A 275 could authenticate to server B using server A's credentials with the 276 authorization identity of user X. This effectively allows PROXY 277 operations between servers. Some older SASL mechanisms do not support 278 both authentication and authorization and therefore can't be used when 279 PROXY operations are required. As per the SASL profile, the 280 authorization identity is the one used to determine if the operation 281 should be allowed or not. The authentication identity ensures the 282 transaction is originating from a trusted sender. 284 3.2.2 Authentication for Anonymous Access 286 SASL defines an ANONYMOUS authentication mechanism that must be used if 287 anonymous access is to be implemented by an iRIP capable server. This is 288 done by using the standard SASL authentication method and requesting the 289 ANONYMOUS mechanism. The mechanism consists of a single message from the 290 client to the server. The client sends optional trace information in the 291 for of a human readable string. It is recommended that the trace 292 information take one of three forms: An [RFC-822] Internet e-mail 293 address, an opaque ASCII string wich does not contain the _@_ character 294 and can be interpreted by the system administrator of the client's 295 domain or nothing. 297 The following is an example of anonymous access using an opaque ASCII 298 string: 300 R: 301 S: 302 R: 2.2 AboutTime iRIPServer@xyx.com Ready 303 S: AUTHENTICATE ANONYMOUS 304 R: + 305 S: c21yaGM 306 R: 2.2 Welcome anonymous 308 An iRIP capable server permitting anonymous access will permit 309 operations, usually restricted to limited and non-destructive commands. 311 To properly implement the ANONYMOUS authentication, refer to [ANON- 312 SASL]. 314 3.3 CAPABILITY 316 The CAPABILITY command tells the server to return a list of capabilities 317 it supports. The server must return a CAPABILITY response with 318 "IRIPrev1" as one of the listed capabilities. The CAPBILITY command can 319 be issued in any connection state and the reply is not dependent upon 320 the connection state. 322 Courtemanche/Mansour/O'Leary 6 Expires May 1998 323 A capability name which begins with "AUTH=" indicates that the server 324 supports that particular authentication mechanism. 326 Example: 328 S: CAPABILITY 329 R: CAPABILITY IRIPrev1 AUTH=KERBEROS_V4 330 R: 2.0 OK 332 3.4 CONTINUE 334 The CONTINUE command is issued by the Sender to allow an ICALDATA 335 request to continue being processed. When the latency time is specified 336 on the ICALDATA command, the Receiver must issue a reply to the Sender 337 within the specified time. The reply may be a reply code indicating 338 that the server has not yet processed the request. The Sender must then 339 tell the server whether to continue or abort. 341 Example: 343 ... 344 S: ICALDATA:10 345 R: 354 Start ICAL input; end with . 346 S: BEGIN:VCALENDAR 347 ... 348 S: END:VCALENDAR 349 S: . 350 351 R: . 352 R: 3.5.0 Reply Pending 353 S: CONTINUE 354 R: BEGIN:VCALENDAR 355 ... 356 R: END:VCALENDAR 357 R: . 358 R: 2.0 OK 360 3.5 DISCONNECT 362 The DISCONNECT command signals the end of communication between the 363 Sender and Receiver. 365 Example: 367 S: DISCONNECT 368 R: 2.1 EXAMPLE.COM IRIP Service closing transmission channel 370 3.6 ICALDATA 372 The ICALDATA is used specify the iCalendar Object that is to be 373 delivered to one or more recipients specified in the RECIPIENT command. 374 The format of the command is: 376 Courtemanche/Mansour/O'Leary 7 Expires May 1998 377 S: ICALDATA[:latencyTime] 378 S: 379 S: . 380 R: 381 R: . 382 R: 384 An optional argument to ICALDATA specifies the maximum amount of time 385 the Sender can wait for a reply. This is followed by iCalendar Object 386 data. The data is terminated by the special sequence .. The 387 server reply may optionally contain an iCalendar Object, the special 388 sequence . followed by a reply code. 390 S: ICALDATA 391 R: 3.5.4 Start ICAL input; end with . 392 S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 393 S: Content-Transfer-Encoding: 7bit 394 S: 395 S: BEGIN:VCALENDAR 396 S: etc., etc. 397 S: END:VCALENDAR 398 S: . 399 R: . 400 R: 2.0 OK 402 3.7 RECIPIENT 404 The RECIPIENT command is used to identify a recipient of the iCalendar 405 Object. Use multiple RECIPIENT commands to specify multiple recipients. 406 The command format is 408 RECIPIENT rfc822address 410 3.8 SWITCH 412 The SWITCH command is used to allow the Sender and Receiver to change 413 roles. Its format is: 415 SWITCH 417 The SWITCH command is useful in environments where the firewall of a 418 Sender would not allow the Receiver to initiate a connection. The SWITCH 419 command is issued by the Sender to give the Receiver the opportunity to 420 take the role of the Sender. 422 The Receiver must respond in one of the following fashions: 424 . send an OK reply and take on the role of Sender 425 . send a error reply indicating refusal and retain the role of Receiver 427 Courtemanche/Mansour/O'Leary 8 Expires May 1998 428 If program-A is currently the Sender and sends the SWITCH command and 429 receives an OK reply then program-A becomes the Receiver. Program-A is 430 then in its initial state and sends a service ready greeting message. 432 If program-B is currently the Receiver and sends an OK reply in response 433 to a SWITCH command then program-B becomes the Sender. Program-B is 434 then in the initial state as if the transmission channel just opened, 435 and expects to receive a service ready greeting. 437 3.9 Error Codes 439 iRIP error codes follow the format defined for Status Replies in [ITIP]. 440 All Status Replies as defined in [ITIP] are valid error codes when 441 returned by an iRIP command. 443 In addition to those defined in [ITIP], iRIP defines the following error 444 codes: 446 6.0 AUTHORIZATION FAILED General authorization failure 448 6.1 TRANSITION-NEEDED Indicates the transition from 449 a legacy database to a more 450 secure password mechanism, and 451 reports that the new mechanism 452 is not usable until "AUTHENTICATE 453 PLAIN" or a login procedure is used. 455 6.2 AUTH-TOO-WEAK Indicates that multiple remote 456 services are offered, and therefore 457 there is no practical way to transition 458 every remote service. So, the mechanism 459 must not allow users to have different 460 passwords for different services. The 461 error code reports that no new plaintext 462 passwords will be accepted from the user 463 at a later date. It could also indicate 464 that the requested mechanism is not 465 available. 467 6.3 ENCRYPT-NEEDED Indicates that the requested mechanism 468 it to be used in conjunction with a 469 strong external encryption layer. 471 7.0 TIMEOUT The requested operation could not be 472 completed in the time allotted. 474 8.0 GENERAL FAILURE A failure has occurred in the Receiver 475 that prevents the operation from 476 succeeding. 477 8.1 SERVER TOO BUSY Sent when a connection cannot be 478 established because the iRIP Receiver 479 is too busy. 481 Courtemanche/Mansour/O'Leary 9 Expires May 1998 482 9.0 INVALID IRIP COMMAND An unrecongnized command was received. 484 10.0 NOT HERE The Receiver does not know how to 485 contact the Calendar Store for the 486 specified RECIPIENT. 488 10.1 REFERRAL Accompanied by an alternate address. 489 The RECIPIENT specified should be 490 contacted at the given alternate 491 address. 493 4. Security Considerations 495 The security of iRIP with SASL support is highly dependent on the 496 mechanism used to authenticate the client and whether or not the 497 security layer is further negotiated. Without a robust security layer, 498 iRIP transactions are subject to eavesdropping and the integrity of iRIP 499 transactions may be compromised. Since iRIP is designed specifically for 500 real time Internet transactions, it is recommended that implementations 501 use the highest degree of authentication and transmission security 502 possible. 504 Authentication is fundamental to iRIP. It is the basis for granting and 505 denying access. Without a robust security layer iRIP will be subject to 506 many possible attacks and the full contents of the server itself may be 507 at risk. 509 4.1 SASL ANONYMOUS Mechanism 511 Implementing support for the Anonymous SASL significantly increases the 512 vulnerability of the calendar server and its data. Refer to [ANON-SASL] 513 for further information on many threats specific to Anonymous SASL 514 access. 516 4.2 SASL Profile Definition 518 (Need to complete with full details) 520 The implementation of SASL in iRIP requires the server and client to 521 comply to the following profile extension: 523 AUTHENTICATE command. 525 Full description of the challenge/response definition. 527 Starting octet. 529 Interpretation of the authorization identity passed should be 530 interpreted. 532 Courtemanche/Mansour/O'Leary 10 Expires May 1998 533 4.3 ITIP Threats 535 Threat: Spoofing the organizer or attendee. 537 Solution: The entire protection for spoofing attendees or organizer of a 538 meeting resides in the fact that the connection needs to be 539 authenticated. Spoofing would be possible in the absence of 540 authentication. 542 Threat: Eavesdropping on the traffic. 544 Solution: If SASL is used to negotiate with the server a security layer, 545 then traffic is no longer in the clear and eavesdropping will not be 546 restricted. 548 Threat: Flooding of a calendar 550 Solution: Implementation of iRIP should limit the size and traffic of 551 transaction from a given source. 553 Threat: Procedural Alarms 555 Solution: Implementation of iRIP should remove or disallow procedural 556 alarms before delivery. 558 4.4 IRIP-Specific Threats 560 Threat: Flooding of connections 562 Solution: Connections that have not been authenticated within 3 seconds 563 should be disconnected. Peter/Steve, this looks very arbitrary. Is there 564 a better way of doing this ? 566 5. Examples 568 5.1 Unathenticated Freebusy Request 570 This examples shows an anonymous request for the freebusy time of 571 sman@example.com 573 R: 574 S: 575 R: 2.2 BIG-Time iRIPServer@example.com Ready 576 S: AUTHENTICATE LOGIN anonymous xyz.unknown.com 577 R: 2.2 Welcome anonymous 578 S: RECIPIENT:sman 579 R: 2.0 OK 580 S: ICALDATA 581 R: 3.5.4 Start ICAL input; end with . 582 S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 583 S: Content-Transfer-Encoding: 7bit 585 Courtemanche/Mansour/O'Leary 11 Expires May 1998 586 S: 587 S: BEGIN:VCALENDAR 588 S: PRODID:-//ACME/DesktopCalendar//EN 589 S: METHOD:REQUEST 590 S: VERSION:2.0 591 S: BEGIN:VFREEBUSY 592 S: ATTENDEE;ROLE=OWNER:A@acme.com 593 S: ATTENDEE:sman@acme.com 594 S: DTSTAMP:19971113T190000-0800 595 S: DTSTART:19971115T080000-0800 596 S: DTEND:19971115T200000-0800 597 S: UID:www.acme.com-873970198738777@host.com 598 S: END:VFREEBUSY 599 S: END:VCALENDAR 600 S: . 601 R: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 602 R: Content-Transfer-Encoding: 7bit 603 R: 604 R: BEGIN:VCALENDAR 605 R: PRODID:-//ACME/DesktopCalendar//EN 606 R: METHOD:REPLY 607 R: VERSION:2.0 608 R: BEGIN:VFREEBUSY 609 R: ATTENDEE:sman@example.com 610 R: DTSTAMP:19971113T190005-0800 611 R: DTSTART:19971115T080000-0800 612 R: DTEND:19971115T200000-0800 613 R: UID:www.acme.com-873970198738777@host.com 614 R: FREEBUSY:19970701T090000-0700/PT1H,19970701T140000-0700/PT30H 615 R: END:VFREEBUSY 616 R: END:VCALENDAR 617 R: . 618 R: 2.5 OK 619 S: DISCONNECT 620 R: OK 621 R: 622 S: 624 6. Acknowledgments 626 The following have participated in the drafting and discussion of this 627 memo: 629 Mugino Saeki 631 7. Bibliography 633 [ANON-SASL] "Anonymous SASL mechanism", draft-newman-sasl-anon-00.txt 635 [ICAL] "Internet Calendaring and Scheduling Core Object Specification - 636 iCalendar", Internet-Draft, July 1997, ftp://ftp.ietf.org/internet- 637 drafts/draft-ietf-calsch-ical-02.txt. 639 Courtemanche/Mansour/O'Leary 12 Expires May 1998 640 [ICMS] "Internet Calendaring Model Specification", Internet-Draft, July 641 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-00.txt. 643 [ITIP] "iCalendar Transport-Independent Interoperability Protocol (iTIP) 644 : Scheduling Events, Busy Time, To-dos and Journal Entries ", Internet- 645 Draft, October 1997, http://www.imc.org/draft-ietf-calsch-itip-01.txt. 647 [IMIP] "iCalendar Message-based Interoperability Protocol (iMIP), 648 Internet-Draft, October 1997, http://www.imc.org/draft-ietf-calsch-imip- 649 02.txt. 651 [ID-UTF8] "UTF-8, a transformation format of Unicode and ISO 10646", 652 Internet-Draft, July,1996, ftp://ftp.ietf.org/internet-drafts/draft- 653 yergeau-utf8-01.txt. 655 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 656 Messages", STD 11, RFC 822, August 1982. 658 [RFC-1847]. J. Galvin, S. Murphy, S. Crocker & N. Freed, "Security 659 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 660 1847, October 1995. 662 [RFC-2112] Levinson, E., "The MIME Multipart/Related Content-type," RFC 663 2112, March 1997. 665 [RFC-2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)," 666 RFC 2015, October 1996. 668 [RFC-2045] Freed, N., Borenstein, N., " Multipurpose Internet Mail 669 Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 670 2045, November 1996. 672 [RFC-2046] Freed, N., Borenstein, N., " Multipurpose Internet Mail 673 Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996. 675 [RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - 676 Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 677 November 1996. 679 [RFC-2048] Freed, N., J. Klensin, J. Postel, "Multipurpose Internet Mail 680 Extensions (MIME) - Part Four: Registration Procedures", RFC 2048, 681 January 1997. 683 [RFC-2222] J. Meyers, Simple Authentication and Security Layer (SASL)", 684 RFC 2222, October 1997. 686 8. Open Issues. 688 Anonymous access _ Mugino, 690 Proxy Access via SASL _ Mugino, how does the proxy capability of SASL 691 maches iRIP's requirement for PROXY capability ? 693 Courtemanche/Mansour/O'Leary 13 Expires May 1998 694 Registration of the SASL profile for iRIP with the IANA. 696 9. Author's Address 698 The following address information is provided in a vCard v2.1, 699 Electronic Business Card, format. 701 BEGIN:VCARD 702 FN:Andre Courtemanche 703 ORG:CS&T 704 ADR;WORK;POSTAL;PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R 705 3L5;Canada 706 TEL;WORK;MSG:+1-514-733-8500 707 TEL;WORK;FAX:+1-514-733-8788 708 EMAIL;INTERNET:andre@cst.ca 709 END:VCARD 711 BEGIN:VCARD 712 FN:Steve Mansour 713 ORG:Netscape Communications Corporation 714 ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain 715 View;CA;94043;USA 716 TEL;WORK;MSG:+1-415-937-2378 717 TEL;WORK;FAX:+1-415-428-4059 718 EMAIL;INTERNET:sman@netscape.com 719 END:VCARD 721 BEGIN:VCARD 722 FN:Peter O'Leary 723 ORG:Amplitude Software Corp. 724 ADR;WORK;POSTAL;PARCEL:;;185 Berry St. Suite 4700; San Francisco;CA; 725 94107;USA 726 TEL;WORK;MSG:+1-415-659-3511 727 TEL;WORK;FAX:+1-415-659-0006 728 EMAIL;INTERNET:poleary@amplitude.com 729 END:VCARD 731 Courtemanche/Mansour/O'Leary 14 Expires May 1998 732 10. Full Copyright Statement 734 "Copyright (C) The Internet Society (date). All Rights Reserved. 736 This document and translations of it MAY be copied and furnished to 737 others, and derivative works that comment on or otherwise explain it or 738 assist in its implmentation MAY be prepared, copied, published and 739 distributed, in whole or in part, without restriction of any kind, 740 provided that the above copyright notice and this paragraph are included 741 on all such copies and derivative works. However, this document itself 742 MAY NOT be modified in any way, such as by removing the copyright notice 743 or references to the Internet Society or other Internet organizations, 744 except as needed for the purpose of developing Internet standards in 745 which case the procedures for copyrights defined in the Internet 746 Standards process MUST be followed, or as required to translate it into 747 languages other than English. 749 The limited permissions granted above are perpetual and will not be 750 revoked by the Internet Society or its successors or assigns. 752 This document and the information contained herein is provided on an "AS 753 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 754 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 755 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 756 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 757 FITNESS FOR A PARTICULAR PURPOSE. 759 Courtemanche/Mansour/O'Leary 15 Expires May 1998