GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3428

Network Working Group B. Campbell, Ed. Request for Comments: 3428 J. Rosenberg Category: Standards Track dynamicsoft

                                                        H. Schulzrinne
                                                   Columbia University
                                                            C. Huitema
                                                              D. Gurle
                                                 Microsoft Corporation
                                                         December 2002
 Session Initiation Protocol (SIP) Extension for Instant Messaging

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

 Instant Messaging (IM) refers to the transfer of messages between
 users in near real-time.  These messages are usually, but not
 required to be, short.  IMs are often used in a conversational mode,
 that is, the transfer of messages back and forth is fast enough for
 participants to maintain an interactive conversation.
 This document proposes the MESSAGE method, an extension to the
 Session Initiation Protocol (SIP) that allows the transfer of Instant
 Messages.  Since the MESSAGE request is an extension to SIP, it
 inherits all the request routing and security features of that
 protocol.  MESSAGE requests carry the content in the form of MIME
 body parts.  MESSAGE requests do not themselves initiate a SIP
 dialog; under normal usage each Instant Message stands alone, much
 like pager messages.  MESSAGE requests may be sent in the context of
 a dialog initiated by some other SIP request.

Campbell, et. al. Standards Track [Page 1] RFC 3428 SIP Message Extension December 2002

Terminology

 In this document, the key words "MUST", "MUST NOT", "REQUIRED",
 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
 RECOMMENDED", "MAY" and "OPTIONAL" are to be interpreted as described
 in BCP 14, RFC 2119 [6] and indicate requirement levels for compliant
 SIP implementations.

Table of Contents

 1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
 2.    Scope of Applicability . . . . . . . . . . . . . . . . . . .  3
 3.    Overview of Operation  . . . . . . . . . . . . . . . . . . .  4
 4.    UAC Processing . . . . . . . . . . . . . . . . . . . . . . .  5
 5.    Use of Instant Message URIs  . . . . . . . . . . . . . . . .  6
 6.    Proxy Processing . . . . . . . . . . . . . . . . . . . . . .  6
 7.    UAS Processing . . . . . . . . . . . . . . . . . . . . . . .  7
 8.    Congestion Control . . . . . . . . . . . . . . . . . . . . .  8
 9.    Method Definition  . . . . . . . . . . . . . . . . . . . . .  9
 10.   Example Messages . . . . . . . . . . . . . . . . . . . . . . 11
 11.   Security Considerations  . . . . . . . . . . . . . . . . . . 13
 11.1  Outbound authentication  . . . . . . . . . . . . . . . . . . 13
 11.2  SIPS URIs  . . . . . . . . . . . . . . . . . . . . . . . . . 14
 11.3  End-to-End Protection  . . . . . . . . . . . . . . . . . . . 14
 11.4  Replay Prevention  . . . . . . . . . . . . . . . . . . . . . 14
 11.5  Using message/cpim bodies  . . . . . . . . . . . . . . . . . 15
 12.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 15
 13.   Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
 14.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 15
 15.   Normative References . . . . . . . . . . . . . . . . . . . . 16
 16.   Informational References . . . . . . . . . . . . . . . . . . 16
 17.   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
 18.   Full Copyright Statement . . . . . . . . . . . . . . . . . . 18

1. Introduction

 Instant Messaging (IM) is defined as the exchange of content between
 a set of participants in near real time.  Generally, the content is
 short text messages, although that need not be the case.  Generally,
 the messages that are exchanged are not stored, but this also need
 not be the case.  IM differs from email in common usage in that
 instant messages are usually grouped together into brief live
 conversations, consisting of numerous small messages sent back and
 forth.
 Instant messaging as a service has been in existence within intranets
 and IP networks for quite some time.  Early implementations include
 zephyr [11], the UNIX talk application, and IRC.  More recently, IM

Campbell, et. al. Standards Track [Page 2] RFC 3428 SIP Message Extension December 2002

 has been used as a service coupled with presence and buddy lists;
 that is, when a friend comes online, a user can be made aware of this
 and have the option of sending the friend an instant message.  The
 protocols for accomplishing this are all proprietary, which has
 seriously hampered interoperability.
 The integration of instant messaging, presence, and session-oriented
 communications is very powerful.  The Session Initiation Protocol
 (SIP) [1] provides mechanisms that are useful for presence
 applications, and for session-oriented communication applications,
 but not for instant messages.
 This document proposes an extension method for SIP called the MESSAGE
 method.  MESSAGE requests normally carry the instant message content
 in the request body.
 RFC 2778 [3] and RFC 2779 [2] give a model and requirements for
 presence and instant messaging protocols.  Implementations of the
 MESSAGE method SHALL support all the instant message requirements in
 RFC 2779 relevant to its scope of applicability.

2. Scope of Applicability

 This document describes the use of the MESSAGE method for sending
 instant messages using a metaphor similar to that of a two-way pager
 or SMS enabled handset.  That is, there are no explicit association
 between messages.  Each IM stands alone--any sense of a
 "conversation" only exists in the client user interface, or perhaps
 in the user's own imagination.  We contrast this with a "session"
 model, where there is an explicit conversation with a clear beginning
 and end.  In the SIP environment, an IM session would be a media
 session initiated with an INVITE transaction and terminated with a
 BYE transaction.
 There is value in each model.  Most modern IM clients offer both user
 experiences.  The user can choose to send an IM to a contact, or he
 can choose to invite one or more contacts to join a conversation.
 The pager model makes sense when the user wishes to send a small
 number of short IMs to a single (or small number of) recipients.  The
 session model makes sense for extended conversations, joining chat
 groups, if there is a need to associate a conversation with some
 other SIP initiated session, etc.
 This document addresses the pager model only.  We recognize the value
 of the session model as well, but we do not define it here.  Such a
 solution will require additional work beyond that of this document.
 The SIMPLE work group currently plans to address IM sessions in a
 separate document.

Campbell, et. al. Standards Track [Page 3] RFC 3428 SIP Message Extension December 2002

 There may be a temptation to simulate a session of IMs by initiating
 a dialog, then sending MESSAGE requests in the context of that
 dialog.  This is not an adequate solution for IM sessions, in that
 this approach forces the MESSAGE requests to follow the same network
 path as any other SIP requests, even though the MESSAGE requests
 arguably carry media rather than signaling.  IM applications are
 typically high volume, and we expect the IM volume in sessions to be
 even higher.  This will likely cause congestion problems if sent over
 a transport without congestion control, and there is no clear
 mechanism in SIP to prevent some hop from forwarding a MESSAGE
 request over UDP.
 Additionally, MESSAGE requests sent over an existing dialog must, by
 the nature of SIP, go to the same destination as any other request
 sent in that dialog.  This prevents any separation between the IM
 endpoint and the signaling endpoint.  This is not an acceptable
 limitation for the session-model of instant messaging.
 The authors recognize that there may be valid reasons to send MESSAGE
 requests in the context of a dialog.  For example, one participant in
 a voice session may wish to send an IM to another participant, and
 associate that IM with the session.  But implementations SHOULD NOT
 create dialogs for the primary purpose of associating MESSAGE
 requests with one another.
 Note that this statement does not prohibit using SIP to initiate a
 media session made up of IMs, just like any other session.  Indeed,
 we expect the solution for IM sessions to use that metaphor.  The
 reader should avoid confusing the concepts of a SIP dialog and a
 media session.

3. Overview of Operation

 When one user wishes to send an instant message to another, the
 sender formulates and issues a SIP request using the new MESSAGE
 method defined by this document.  The Request-URI of this request
 will normally be the "address of record" for the recipient of the
 instant message, but it may be a device address in situations where
 the client has current information about the recipient's location.
 For example, the client could be coupled with a presence system that
 supplies an up to date device contact for a given address of record.
 The body of the request will contain the message to be delivered.
 This body can be of any MIME type, including message/cpim [7].  Since
 the message/cpim format is expected to be supported by other instant
 message protocols, endpoints using different IM protocols, but
 otherwise supporting message/cpim body types, should be able to

Campbell, et. al. Standards Track [Page 4] RFC 3428 SIP Message Extension December 2002

 exchange messages without modification of the content by a gateway or
 other intermediary.  This helps to enable end-to-end security between
 endpoints that use different IM protocols.
 The request may traverse a set of SIP proxies, using a variety of
 transports, before reaching its destination.  The destination for
 each hop is located using the address resolution rules detailed in
 the Common Profile for Instant Messaging (CPIM) [8] and SIP
 specifications.  During traversal, each proxy may rewrite the request
 URI based on available routing information.
 Provisional and final responses to the request will be returned to
 the sender as with any other SIP request.  Normally, a 200 OK
 response will be generated by the user agent of the request's final
 recipient.  Note that this indicates that the user agent accepted the
 message, not that the user has seen it.
 MESSAGE requests do not establish dialogs.

4. UAC Processing

 Unless stated otherwise in this document, MESSAGE requests and
 associated responses are constructed according to the rules in
 section 8.1 of the SIP specification [1].
 All UACs which support the MESSAGE method MUST be prepared to send
 MESSAGE requests with a body of type text/plain.  They may send
 bodies of type message/cpim [7].
 MESSAGE requests do not initiate dialogs.  User Agents MUST NOT
 insert Contact header fields into MESSAGE requests.
 A UAC MAY associate a MESSAGE request with an existing dialog.  If a
 MESSAGE request is sent within a dialog, it is "associated" with any
 media session or sessions associated with that dialog.
 If the UAC receives a 200 OK response to a MESSAGE request, it may
 assume the message has been delivered to the final destination.  It
 MUST NOT assume that the recipient has actually read the instant
 message.  If the UAC receives a 202 Accepted response, the message
 has been delivered to a gateway, store and forward server, or some
 other service that may eventually deliver the message.  In this case,
 the UAC MUST NOT assume the message has been delivered to the final
 destination.  If confirmation of delivery is required for a message
 that has been responded to with a 202 Accepted, that confirmation
 must be delivered via some other mechanism, which is beyond the scope
 of this specification.

Campbell, et. al. Standards Track [Page 5] RFC 3428 SIP Message Extension December 2002

 Note that a downstream proxy could fork a MESSAGE request.  If this
 occurs, the forking proxy will forward one final response upstream,
 even though it may receive multiple final responses.  The UAC will
 have no way to detect whether or not a fork occurs.  Therefore the
 UAC MUST NOT assume that a given final response represents the only
 UAS that receives the request.  For example, multiple branches of a
 fork could have resulted in 2xx responses.  Even though the UAC only
 sees one of those responses, the request has in fact been received by
 the second device as well.
 The UAC MAY add an Expires header field to limit the validity of the
 message content.  If the UAC adds an Expires header field with a
 non-zero value, it SHOULD also add a Date header field containing the
 time the message is sent.

5. Use of Instant Message URIs

 An instant inbox may be most generally referenced by an Instant
 Message URI [8] in the form of "im:user@domain".  IM URIs are
 abstract, and will eventually be translated to concrete, protocol-
 dependent URI.
 If a UA is presented with an IM URI as the address for an instant
 message, it SHOULD resolve it to a SIP URI, and place the resulting
 URI in the Request-URI of the MESSAGE request before sending.  If the
 UA is unable to resolve the IM URI, it MAY place the IM URI in the
 Request-URI, thus delegating the resolution to a downstream device
 such as proxy or gateway.  Performing this translation as early as
 possible allows SIP proxies, which may be unaware of the im:
 namespace, to route the requests normally.
 MESSAGE requests also contain logical identifiers of the sender and
 intended recipient, in the form of the From and To header fields.
 These identifiers SHOULD contain SIP (or SIPS) URIs, but MAY include
 IM URIs if the SIP URIs are not known at the time of request
 construction.
 Record-Route and Route header fields MUST NOT contain IM URIs.  These
 header fields contain concrete SIP or SIPS URIs according to the
 rules of SIP [1].

6. Proxy Processing

 Proxies route MESSAGE requests according to the rules of SIP [1].
 Note that the MESSAGE request MAY fork; this allows for delivery of
 the message to several possible terminals where the user might be.  A
 proxy forking a MESSAGE request follows the normal SIP rules for
 forking a non-INVITE request.  In particular, even if the fork

Campbell, et. al. Standards Track [Page 6] RFC 3428 SIP Message Extension December 2002

 results in multiple successful deliveries, the forking proxy will
 only forward one final response upstream.

7. UAS Processing

 A UAS that receives a MESSAGE request processes it following the
 rules of SIP [1].
 A UAS receiving a MESSAGE request SHOULD respond with a final
 response immediately.  Note, however, that the UAS is not obliged to
 display the message to the user either before or after responding
 with a 200 OK.  That is, a 200 OK response does not necessarily mean
 the user has read the message.
 A 2xx response to a MESSAGE request MUST NOT contain a body.  A UAS
 MUST NOT insert a Contact header field into a 2xx response.
 A UAS which is, in fact, a message relay, storing the message and
 forwarding it later on, or forwarding it into a non-SIP domain,
 SHOULD return a 202 (Accepted) [5] response indicating that the
 message was accepted, but end to end delivery has not been
 guaranteed.
 A 4xx or 5xx response indicates that the message was not delivered
 successfully.  A 6xx response means it was delivered successfully,
 but refused.
 A UAS that supports the MESSAGE method MUST be prepared to receive
 and render bodies of type "text/plain", and may support reception and
 rendering of bodies of type "message/cpim" [7].
 A MESSAGE request is said to be expired if its expiration time has
 passed. The expiration time is determined by examining the Expires
 header field, if present.  MESSAGE requests without an Expires header
 field do not expire.  If the MESSAGE request containing an Expires
 header field also contains a Date header field, the UAS SHOULD
 interpret the Expires header field value as delta time from the Date
 header field value.  If the request does not contain a Date header
 field, the UAS SHOULD interpret the Expires header value as delta
 time from the time the UAS received the request.
 If the MESSAGE expires before the UAS is able to present the message
 to the user, the UAS SHOULD handle the message based on local policy.
 This policy could mean: the message is deleted undisplayed,

Campbell, et. al. Standards Track [Page 7] RFC 3428 SIP Message Extension December 2002

 the message is still displayed to the user, or some other policy may
 be invoked.  If the message is displayed, the UAS SHOULD clearly
 indicate to the user that the message has expired.
 If the UAS is acting as a message relay, and is unable to deliver the
 message before expiration, it chooses an action based on local
 policy.  This action could involve deleting the message undelivered,
 delivering it as is, logging the expired message, or any other local
 policy.

8. Congestion Control

 Existing IM services have a history of very high volume usage.
 Additionally, MESSAGE requests differ from other sorts of SIP
 requests in that they carry media, in the form of IMs, as payload.
 Conventional SIP payloads carry signaling information about media,
 but not media itself.  There is potential that when a SIP
 infrastructure is shared between call signaling and instant
 messaging, the IM traffic will interfere with call signaling traffic.
 Congestion control in general is an issue that should be addressed at
 the SIP specification level rather than for an individual method.
 But since the traffic patterns are likely to be different for MESSAGE
 than for most other methods, it makes sense to give MESSAGE special
 consideration.
 Whenever possible, MESSAGE requests SHOULD be sent over transports
 that implement end-to-end congestion control, such as TCP or SCTP.
 However, SIP does not provide a mechanism to prevent a downstream hop
 from sending a request over UDP.  Even the requirement to use TCP for
 requests over a certain size can be overridden by the receiver.
 Therefore use of a congestion-controlled transport by the UAC is not
 sufficient.
 The size of MESSAGE requests outside of a media session MUST NOT
 exceed 1300 bytes, unless the UAC has positive knowledge that the
 message will not traverse a congestion-unsafe link at any hop, or
 that the message size is at least 200 bytes less than the lowest MTU
 value found en route to the UAS.  Larger payloads may be sent as part
 of a media session, or using some type of content-indirection.
    At the time of this writing, there is no mechanism for a UAC to
    gain such knowledge outside of trivial network architectures, or
    networks that are wholly controlled by a single administrative
    domain.  But if a mechanism for ensuring congestion-control at
    each hop is created in the future, MESSAGE clients can relax the
    size limit without requiring a change to this specification.  The
    authors expect that such a mechanism or mechanism will be created
    in the near future.

Campbell, et. al. Standards Track [Page 8] RFC 3428 SIP Message Extension December 2002

    There have been discussions on making the 1300 byte limit based on
    the path MTU to the next hop SIP device.  The SIP specification
    does exactly that, choosing the limit 200 bytes less than the path
    MTU, or 1300 bytes if the device does not know the path MTU.
    Transport decisions are made on a per-hop basis.  However, the
    point of this limit is to make sure that no upstream proxy chooses
    to send a MESSAGE request with large content over UDP.  Since,
    except in trivial circumstances, a MESSAGE client is very unlikely
    to know the MTU for upstream devices beyond the next hop, an MTU
    based limit is not very useful.
 A UAC MUST NOT initiate a new out-of-dialog MESSAGE transaction to a
 given URI if there is a previous out-of-dialog transaction pending
 for the same URI.  Similarly, A UAC SHOULD NOT initiate overlapping
 MESSAGE transactions inside a dialog, and MUST NOT do so unless the
 route set for that dialog uses a congestion-controlled transport at
 every hop.
    The prohibition against overlapping MESSAGE request provides some
    degree of congestion-safe behavior.  A request and its associated
    response must each cross the full path between the UAC and the
    UAS.  The time required for this will increase as networks become
    congested.  This provides an adaptive mechanism to slow the
    introduction of new MESSAGE requests to the same destination.
 It has been suggested that provisional responses should not be
 allowed for pager-model MESSAGE requests.  However, it is not
 possible to require special treatment for MESSAGE, since many proxy
 servers will not be aware of the MESSAGE method.  Therefore MESSAGE
 requests will receive the same provisional response treatment as any
 other non-INVITE method, as described in the SIP specification.

9. Method Definition

 This specification defines a new SIP method, MESSAGE.  The BNF for
 this method is:
    MESSAGEm = %x4D.45.53.53.41.47.45 ;MESSAGE in caps
 As with all other methods, the MESSAGE method name is case sensitive.
 Tables 1 and 2 extend Tables 2 and 3 of SIP [1] by adding an
 additional column, defining the header fields that can be used in
 MESSAGE requests and responses.

Campbell, et. al. Standards Track [Page 9] RFC 3428 SIP Message Extension December 2002

                 Header Field       where  proxy  MESSAGE
                 __________________________________________
                 Accept               R              -
                 Accept              2xx             -
                 Accept              415             m*
                 Accept-Encoding      R              -
                 Accept-Encoding     2xx             -
                 Accept-Encoding     415             m*
                 Accept-Language      R              -
                 Accept-Language     2xx             -
                 Accept-Language     415             m*
                 Alert-Info           R              -
                 Alert-Info          180             -
                 Allow                R              o
                 Allow               2xx             o
                 Allow                r              o
                 Allow               405             m
                 Authentication-Info 2xx             o
                 Authorization        R              o
                 Call-ID              c      r       m
                 Call-Info                  ar       o
                 Contact              R              -
                 Contact             1xx             -
                 Contact             2xx             -
                 Contact             3xx             o
                 Contact             485             o
                 Content-Disposition                 o
                 Content-Encoding                    o
                 Content-Language                    o
                 Content-Length             ar       t
                 Content-Type                        *
                 CSeq                c       r       m
                 Date                        a       o
                 Error-Info       300-699    a       o
                 Expires                             o
                 From                c       r       m
                 In-Reply-To         R               o
                 Max-Forwards        R      amr      m
                 Organization               ar       o
                 Table 1: Summary of header fields, A--O

Campbell, et. al. Standards Track [Page 10] RFC 3428 SIP Message Extension December 2002

                 Header Field       where  proxy  MESSAGE
                 __________________________________________
                 Priority             R     ar         o
                 Proxy-Authenticate  407    ar         m
                 Proxy-Authenticate  401    ar         o
                 Proxy-Authorization  R     dr         o
                 Proxy-Require        R     ar         o
                 Record-Route               ar         -
                 Reply-To                              o
                 Require                    ar         c
                 Retry-After   404,413,480,486         o
                                   500,503             o
                                   600,603             o
                 Route                R     adr        o
                 Server               r                o
                 Subject              R                o
                 Timestamp                             o
                 To                 c(1)     r         m
                 Unsupported         420               o
                 User-Agent                            o
                 Via                  R     amr        m
                 Via                 rc     dr         m
                 Warning              r                o
                 WWW-Authenticate    401    ar         m
                 WWW-Authenticate    407    ar         o
               (1): copied  with  possible addition of tag
                 Table 2: Summary of header fields, P--Z
 A MESSAGE request MAY contain a body, using the standard MIME header
 fields to identify the content.

10. Example Messages

 An example message flow is shown in Figure 1.  The message flow shows
 an initial IM sent from User 1 to User 2, both users in the same
 domain, "domain", through a single proxy.

Campbell, et. al. Standards Track [Page 11] RFC 3428 SIP Message Extension December 2002

         |  F1 MESSAGE          |                         |
         |--------------------> |  F2 MESSAGE             |
         |                      | ----------------------->|
         |                      |                         |
         |                      |  F3 200 OK              |
         |                      | <-----------------------|
         |  F4 200 OK           |                         |
         |<-------------------- |                         |
         |                      |                         |
         |                      |                         |
         |                      |                         |
      User 1                  Proxy                    User 2
                 Figure 1: Example Message Flow
 Message F1 looks like:
 MESSAGE sip:user2@domain.com SIP/2.0
 Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse
 Max-Forwards: 70
 From: sip:user1@domain.com;tag=49583
 To: sip:user2@domain.com
 Call-ID: asd88asd77a@1.2.3.4
 CSeq: 1 MESSAGE
 Content-Type: text/plain
 Content-Length: 18
 Watson, come here.
 User1 forwards this message to the server for domain.com.  The proxy
 receives this request, and recognizes that it is the server for
 domain.com.  It looks up user2 in its database (built up through
 registrations), and finds a binding from sip:user2@domain.com to
 sip:user2@user2pc.domain.com.  It forwards the request to user2.  The
 resulting message, F2, looks like:
 MESSAGE sip:user2@domain.com SIP/2.0
 Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds
 Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
                                            received=1.2.3.4
 Max-Forwards: 69
 From: sip:user1@domain.com;tag=49394
 To: sip:user2@domain.com
 Call-ID: asd88asd77a@1.2.3.4
 CSeq: 1 MESSAGE
 Content-Type: text/plain
 Content-Length: 18

Campbell, et. al. Standards Track [Page 12] RFC 3428 SIP Message Extension December 2002

 Watson, come here.
 The message is received by user2, displayed, and a response is
 generated, message F3, and sent to the proxy:
 SIP/2.0 200 OK
 Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds;
                                          received=192.0.2.1
 Via: SIP/2.0/TCP user1pc.domain.com;;branch=z9hG4bK776sgdkse;
                                             received=1.2.3.4
 From: sip:user1@domain.com;tag=49394
 To: sip:user2@domain.com;tag=ab8asdasd9
 Call-ID: asd88asd77a@1.2.3.4
 CSeq: 1 MESSAGE
 Content-Length: 0
 Note that most of the header fields are simply reflected in the
 response.  The proxy receives this response, strips off the top Via,
 and forwards to the address in the next Via, user1pc.domain.com, the
 result being message F4:
 SIP/2.0 200 OK
 Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
                                            received=1.2.3.4
 From: sip:user1@domain.com;;tag=49394
 To: sip:user2@domain.com;tag=ab8asdasd9
 Call-ID: asd88asd77a@1.2.3.4
 CSeq: 1 MESSAGE
 Content-Length: 0

11. Security Considerations

 In normal usage, most SIP requests are used to setup and modify
 communication sessions.  The actual communication between
 participants happens in the media sessions, not in the SIP requests
 themselves.  The MESSAGE method changes this assumption; MESSAGE
 requests normally carry the actual communication between participants
 as payload.  This implies that MESSAGE requests have a greater need
 for security than most other SIP requests.  In particular, UAs that
 support the MESSAGE request MUST implement end-to-end authentication,
 body integrity, and body confidentiality mechanisms.

11.1 Outbound Authentication

 When local proxies are used for transmission of outbound messages,
 proxy authentication, as specified in RFC 3261, is RECOMMENDED.  This
 is useful to verify the identity of the originator, and prevent
 spoofing and spamming at the originating network.

Campbell, et. al. Standards Track [Page 13] RFC 3428 SIP Message Extension December 2002

11.2 SIPS URIs

 The SIPS URI mechanism [1] allows a UA to assert that every hop must
 occur over a secure connection.  This provides some level of
 integrity and privacy protection.  However, this requires the users
 to trust that each proxy in the request path is well-behaved, that
 is, they do not violate the rules for routing SIPS URIs.  Also, any
 unencrypted bodies are fully exposed to the proxies.
 Additionally, the possibility of a forking proxy allows a MESSAGE
 request to be delivered to additional endpoints without the knowledge
 of the UAC.  If only hop-by-hop protection is used, the users must
 trust all proxies in the chain to not fork requests to unauthorized
 destinations.

11.3 End-to-End Protection

 When the goal is to remedy the concerns stated above, the MESSAGE
 bodies MUST be secured with S/MIME.  If bodies specified in future to
 be carried by the MESSAGE method have different means of providing
 end-to-end security, their specification MUST describe the usage.
 SIP MESSAGE endpoints MUST support encryption (CMS EnvelopeData) and
 S/MIME signatures (CMS SignedData).
 The S/MIME algorithms are set by RFC 3369 [4].  The AES [10]
 algorithm should be preferred, as it is expected that AES best suits
 the capabilities of many platforms.  However, an IETF specification
 for this is still incomplete as of the time of this writing.

11.4 Replay Prevention

 To prevent the replay of old SIP requests, all signed MESSAGE
 requests and responses MUST contain a Date header field covered by
 the message signature.  Any message with a date older than several
 minutes in the past, or which is more than several minutes in the
 future, SHOULD be answered with a 400 (Incorrect Date or Time)
 message, unless such messages arrive repeatedly from the same source,
 in which case they MAY be discarded without sending a response.
 Obviously, this replay attack prevention mechanism does not work for
 devices without clocks.
 Note that there are situations where an stale Date header field is
 normal.  For example, the MESSAGE request may have been stored in a
 store and forward server while the recipient was offline.  When the
 recipient returns, that server might then forward the message.  Final
 receipt of the message would then occur some time after it was
 originally sent.

Campbell, et. al. Standards Track [Page 14] RFC 3428 SIP Message Extension December 2002

 If a UAS receives a stale message that can be confirmed to have come
 from a known store and forward server (perhaps over a TLS
 connection), it makes sense for it to accept the message normally.
 Also, if one or more stale messages arrive shortly after an offline
 period, the UAS MAY accept the message, but SHOULD warn the user that
 there is a risk the message has been replayed.

11.5 Using message/cpim Bodies

 The message/cpim format [7] allows for the S/MIME protection of
 metadata in addition to the message payload itself.  In many cases,
 this metadata is redundant with SIP header fields.  Still,
 message/cpim adds value in that the protection of metadata can extend
 across protocol boundaries.  For example, a signed message/cpim body
 can provide sender authentication using the message/cpim From header
 field, even if the message crosses a gateway to another CPIM
 compliant instant message service that does not understand SIP header
 fields.

12. IANA Considerations

 This specification registers the MESSAGE method in the
 http://www.iana.org/assignments/sip-parameters/Method registry,
 according to the following information:
 MESSAGE        [RFC3428]

13. Contributors

 The following people made substantial contributions to this work:
 Bernard Aboba     Microsoft
 Steve Donovan     dynamicsoft
 Jonathan Lennox   Columbia University
 Dave Oran         Cisco
 Robert Sparks     dynamicsoft
 Dean Willis       dynamicsoft

14. Acknowledgments

 The authors would like to thank the following people for their
 support of the concept of SIP for IM, support for this work, and for
 their useful comments and insights:
    Jon Peterson     NeuStar
    Sean Olson       Microsoft
    Adam Roach       dynamicsoft
    Billy Biggs      University of Waterloo

Campbell, et. al. Standards Track [Page 15] RFC 3428 SIP Message Extension December 2002

    Stuart Barkley   UUNet
    Mauricio Arango  SUN
    Richard Shockey  NeuStar
    Jorgen Bjorker   Hotsip
    Henry Sinnreich  MCI Worldcom
    Ronald Akers     Motorola
    Torrey Searle    Indigo Software
    Rohan Mahy       Cisco
    Christian Groves Ericsson
    Allison Mankin   ISI
    Tan Ya-Ching     Siemens

15.Normative References

 [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
      Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
      Session Initiation Protocol", RFC 3261, June 2002.
 [2]  Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
      Presence Protocol Requirements", RFC 2779, February 2000.
 [3]  Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
      Instant Messaging", RFC 2778, February 2000.
 [4]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
      August 2002.
 [5]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
      Notification", RFC 3265, June 2002.
 [6]  Bradner, S., "Keywords for Use in RFC's to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

16. Informational References

 [7]  Atkins, D. and G. Klyne, "Common Presence and Instant Messaging
      Message Format", Work in Progress.
 [8]  Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, G.,
      Rose, M., Rosenberg, J., Sparks, R., Sugano, H. and J. Peterson,
      "Address Resolution for Instant Messaging and Presence", Work in
      Progress.
 [9]  Rosenberg, J. and H. Schulzrinne, "SIP Caller Preferences and
      Callee Capabilities", Work in Progress.
 [10] Schaad, J. and R. Housley, "Use of the AES Encryption Algorithm
      and RSA-OAEP Key Transport in CMS", Work in Progress.

Campbell, et. al. Standards Track [Page 16] RFC 3428 SIP Message Extension December 2002

 [11] DellaFera, C., Eichin, M., French, R., Jedlinski, D., Kohl, J.
      and W. Sommerfeld, "The Zephyr notification service", in USENIX
      Winter Conference (Dallas, Texas), Feb. 1988.

17. Authors' Addresses

 Ben Campbell
 dynamicsoft
 5100 Tennyson Parkway
 Suite 1200
 Plano, TX  75024
 EMail: bcampbell@dynamicsoft.com
 Jonathan Rosenberg
 dynamicsoft
 72 Eagle Rock Avenue
 First Floor
 East Hanover, NJ  07936
 EMail: jdrosen@dynamicsoft.com
 Henning Schulzrinne
 Columbia University
 M/S 0401
 1214 Amsterdam Ave.
 New York, NY  10027-7003
 EMail: schulzrinne@cs.columbia.edu
 Christian Huitema
 Microsoft Corporation
 One Microsoft Way
 Redmond, WA  98052-6399
 EMail: huitema@microsoft.com
 David Gurle
 Microsoft Corporation
 One Microsoft Way
 Redmond, WA  98052-6399
 EMail: dgurle@microsoft.com

Campbell, et. al. Standards Track [Page 17] RFC 3428 SIP Message Extension December 2002

18. Full Copyright Statement

 Copyright (C) The Internet Society (2002).  All Rights Reserved.
 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 implementation 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 limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Campbell, et. al. Standards Track [Page 18]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3428.txt · Last modified: 2002/12/04 21:07 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki