Internet Engineering Task Force IMPP WG Internet Draft Jonathan Rosenberg Dean Willis Robert Sparks Ben Campbell dynamicsoft Henning Schulzrinne Jonathan Lennox Columbia U. Bernard Aboba Christian Huitema David Gurle Microsoft draft-rosenberg-impp-qauth-00.txt June 15, 2000 Expires: December, 2000 SIP Extensions for Presence Authorization STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document proposes a simple SIP extension that allows presence servers to query presence user agents for authorization for a subscription. 1 Introduction Presence is (indirectly) defined in RFC2778 [1] as subscription to and notification of changes in the communications state of a user. This communications state consists of the set of communications means, communications address, and status of that user. A presence protocol is a protocol for providing such a service over the Internet or any IP network. An example of a presence protocol is described in [2]. Rosenberg et al. [Page 1] Internet Draft presence authorization June 15, 2000 A critical component of a presence protocol is authorization. Presence servers will receive subscription requests for presentities served by the presence server. Before accepting or rejecting these subscriptions, the presence server needs to be able to determine if the presentity is willing to authorize the subscription. Such authorization can be determined at the time of subscription (in which case it is an authorization query, or "pull" from presence server to presence user agent), or authorization can be pushed to the server ahead of time. Authorization policies can be arbitrarily complex. They can depend on any combination of variables available to the presence system, including subscriber profiles, subscription details, and time of day. Supporting these kinds of authorizations through pushes of authorization policies is important, but best left to policy description languages, such as the Call Processing Language (CPL) [3], designed for expressing call processing policies. However, we recognize that in many cases, a simple policy of "user X may subscribe" and "user Y may not subscribe" will suffice. Furthermore, we realize that there is a critical need to pull subscription authorization, as the PUA cannot possibly know ahead of time all the users that might like to subscribe to it. Thus, to support these requirements, this document defines a simple SIP extension for pulling basic authorization state. This is accomplished by defining a new request method, QAUTH, used to query a PUA as to whether it is willing to authorize a subscriber. 2 Overview of Operation Operation of this extension is simple. When a PA wishes to obtain authorization for a subscription from a principal or its agent, it formulates a QAUTH request. This request contains the identity of the subscriber in the From field, and the identity of the presentity in the To field. The Call-ID, CSeq, Via and Contact headers are created by the PA for this request; they are not copied from the SUBSCRIBE. The QAUTH request is then sent to a user agent capable of authorizing subscriptions for a presentity. We call such an agent a Subscription Authorizer (SA). A user agent can indicate that is is an SA through SIP REGISTER requests. REGISTER requests are used to establish address bindings at a registrar, used for routing of messages. An extension to SIP for caller preferences and callee capabilities [4] allows these bindings to contain additional parameters to assist in request routing. One such parameter is the methods parameter, which indicates what methods a user agent can support. A SA includes the value of QAUTH in its registration, indicating that it can support QAUTH requests. This Rosenberg et al. [Page 2] Internet Draft presence authorization June 15, 2000 allows a presentity to have different user agents for authorization of subscriptions, and for processing of subscriptions. An example REGISTER message containing this parameter is as follows: REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP mypc.example.com To: sip:user@example.com From: sip:user@example.com Call-ID: asidhasd@1.2.3.4 CSeq: 39 REGISTER Contact: sip:user@sa-pc.example.com;methods="QAUTH,SUBSCRIBE" Content-Length: 0 In this case, the same user agent can handle both authorizations and subscriptions. When the QAUTH request arrives at an SA, the SA authenticates the request (note that the credentials supplied will be those of the PA, not of the original subscriber. This mechanism depends on a trust relationship between the subscription authorizer and its presence agent). If the request is authenticated as coming from the preconfigured PA for the agent, it next determines if the subscriber is authorized. It can do this by prompting the principal, or through pre-configuration of some sort; the mechanism is outside the scope of this specification. If authorization is granted, a 200 OK response is generated. If denied, a 600 class response is generated. If no authorization can be obtained at all, positive or negative, a 500 class response is generated. The response MAY contain an Expires header indicating the duration for which authorization is granted. The PA can then use the response to QAUTH to accept or reject the subscription. If authorization is granted for a finite time, the PA MUST destroy the subscription once authorization expires. 3 Detailed Operation This extension defines a new request method, QAUTH, used to obtain authorization for a subscription. Qauth = QAUTH Rosenberg et al. [Page 3] Internet Draft presence authorization June 15, 2000 Like all method names, QAUTH is case sensitive. A client sends a QAUTH request if it wishes to obtain authorization for a subscription. The client will often be a presence agent (PA), although that need not be the case. QAUTH requests are sent to user agent servers (UAS) which are believed to be capable of providing authorization. The client sending a QAUTH request MUST only send it to a server whom the client is configured to consider authoritative for providing authorizations. Tables 1 and 2 extend Tables 4 and 5 of SIP by adding an additional column, defining the headers that can be used in QAUTH requests and responses. where enc. e-e QAUTH ________________________________________ Accept R e o Accept 415 e o Accept-Encoding R e o Accept-Encoding 415 e o Accept-Language R e o Accept-Language 415 e o Allow 200 e o Allow 405 e m Authorization R e o Authorization r e o Call-ID gc n e m Contact R e o Contact 2xx e o Contact 3xx e o Contact 485 e o Content-Encoding e e o Content-Length e e m Content-Type e e * CSeq gc n e m Date g e o Encryption g n e o Expires g e o From gc n e m Hide R n h o Max-Forwards R n e o Organization g c h o Table 1: Summary of header fields, A--O Rosenberg et al. [Page 4] Internet Draft presence authorization June 15, 2000 where enc. e-e QAUTH ______________________________________________________ Priority R c e o Proxy-Authenticate 407 n h o Proxy-Authorization R n h o Proxy-Require R n h o Record-Route R h o Record-Route 2xx,401,484 h o Require R e o Retry-After R c e - Retry-After 404,413,480,486 c e o 500,503 c e o 600,603 c e o Response-Key R c e o Route R h o Server r c e o Subject R c e o Timestamp g e o To gc(1) n e m Unsupported 420 e o User-Agent g c e o Via gc(2) n e m Warning r e o WWW-Authenticate R c e o WWW-Authenticate 401 c e o Table 2: Summary of header fields, P--Z; (1): copied with possible addition of tag; (2): UAS removes first Via header field A QAUTH request MUST contain a From field. The From field identifies the subscriber requesting authorization. A QUATH request MUST contain a To field, identifying the principal from whom authorization is sought. The request MUST contain a Call-ID and CSeq header, which together with the To and From, uniquely identify the request. Note that subsequent QAUTH requests need not use the same Call-ID. There is no notion of a persisent session for QAUTH requests; it is like the SIP OPTIONS request in this regard. However, QAUTH requests MAY be record-routed, although there is little or no benefit in doing so. Like all other SIP requests, QAUTH MUST also contain a Via header. QAUTH MAY contain a body, which indicates details about the subscription requeste by the subscriber. Typically, this body will be copied from the SUBSCRIBE which is triggering the QAUTH request. A response to QAUTH MAY contain a body only if an Accept header was present in the request, listing the allowed body types for the response. Absence of the Accept header from the request implies a body MUST NOT be placed in the response. Rosenberg et al. [Page 5] Internet Draft presence authorization June 15, 2000 A QAUTH request SHOULD be authenticated by the UAS receiving it. Note that the credentials supplied will be those of the originator of the QAUTH (typically, the presence server), and *not* the credentials of the originator of the SUBSCRIBE which triggered the QAUTH. The response to a QAUTH is 200 OK if authorization is approved for the subscriber indicated in the From field, 600 class is the authorization is rejected, and 500 class if no authorization could be obtained at this time. A response to QAUTH copies the To, From, Call-ID, CSeq, Record-Route, and Via headers from the request. The UAS SHOULD additionally sign the response. A client sending QAUTH SHOULD verify that the response has been signed by the entity listed in the To field. 4 Example Message Flow The following shows an example message flow using QAUTH. It also includes SUBSCRIBE and NOTIFY requests. In the message flow, a subscriber asks to subscribe to some presentity. However, neither a PUA or an SA are currently available for that presentity. So, the server authenticates the subscription (not shown in the flow) and tentatively accepts it. When an SA for the presentity becomes available (known to the presence server through a registration), the server creates a QAUTH request to authorize the previous subscription. The response is 200 OK, authorizing the subscription. However, since the original subscription had expired, the server does not generate a NOTIFY. The watcher subscribes again, after the REGISTER has expired, and has its subscription approved. Note that since there are no contacts registered for the resource at that time, the presence document is vacuous. subscriber server PUA | | | | F1 SUBSCRIBE | | |--------------------->| (PUA not "online") | | F2 202 Accepted | | |<---------------------| | | (subscription expires) | | | F3 REGISTER | | |<--------------------| | | F4 200 OK | | |-------------------->| Rosenberg et al. [Page 6] Internet Draft presence authorization June 15, 2000 | | F5 QAUTH | | |-------------------->| | | F6 200 OK | | |<--------------------| | (registration expires)| | F7 SUBSCRIBE | | |--------------------->| | | F8 200 OK | | |<---------------------| | Message Details F1 SUBSCRIBE subscriber->server SUBSCRIBE sip:presentity@example.com SIP/2.0 Via: SIP/2.0/UDP watcherhost.example.com:5060 From: Subscriber To: Presentity Call-ID: 3248543@watcherhost.example.com CSeq: 1 SUBSCRIBE Date: Mon, 12 Jun 2000 16:00:00 GMT Expires: 600 Contact: sip:subscriber@watcherhost.example.com F2 202 Accepted server->subscriber SIP/2.0 202 Accepted Via: SIP/2.0/UDP watcherhost.example.com:5060 From: Subscriber To: Presentity Call-ID: 3248543@watcherhost.example.com CSeq: 1 SUBSCRIBE Expires: 600 F3 REGISTER PUA->server Rosenberg et al. [Page 7] Internet Draft presence authorization June 15, 2000 REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com:5060 To: From: Call-ID: 2001@pua.example.com CSeq: 1 REGISTER Date: Wed, 14 Jun 2000 09:57:16 GMT Contact: Contact: Expires: 600 F4 200 OK server->PUA SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com:5060 To: From: Call-ID: 2001@pua.example.com CSeq: 1 REGISTER Contact: Contact: Expires: 600 F5 QAUTH server->PUA QAUTH sip:authagent@pua.example.com SIP/2.0 Via: SIP/2.0/UDP server.example.com:5060 From: Subscriber To: Presentity Call-ID: 47774@server.example.com CSeq: 1 QAUTH Expires: Sun, 14 Jun 2036 00:00:00 GMT Contact: sip:server.example.com Rosenberg et al. [Page 8] Internet Draft presence authorization June 15, 2000 F6 200 OK PUA->server SIP/2.0 200 OK Via: SIP/2.0/UDP server.example.com:5060 From: Subscriber To: Presentity Call-ID: 47774@server.example.com CSeq: 1 QAUTH Expires: Sun, 14 Jun 2036 00:00:00 GMT F7 SUBSCRIBE subscriber->server SUBSCRIBE sip:presentity@example.com SIP/2.0 Via: SIP/2.0/UDP watcherhost.example.com:5060 From: Subscriber To: Presentity Call-ID: 3248544@watcherhost.example.com CSeq: 2 SUBSCRIBE Date: Thu, 15 Jun 2000 07:22:15 GMT Expires: 600 Contact: sip:subscriber@watcherhost.example.com F8 200 OK server->watcher SIP/2.0 200 OK Via: SIP/2.0/UDP watcherhost.example.com:5060 From: Subscriber To: Presentity Call-ID: 3248544@watcherhost.example.com CSeq: 2 SUBSCRIBE Expires: 600 Content-Type: text/lpidf Content-Length: 31 To: sip:presentity@example.com 5 Authors Addresses Rosenberg et al. [Page 9] Internet Draft presence authorization June 15, 2000 Jonathan Rosenberg dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: jdrosen@dynamicsoft.com Dean Willis dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: dwillis@dynamicsoft.com Robert Sparks dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: rsparks@dynamicsoft.com Ben Campbell dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: bcampbell@dynamicsoft.com Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 email: schulzrinne@cs.columbia.edu Jonathan Lennox Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 email: lennox@cs.columbia.edu Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 email: huitema@microsoft.com Rosenberg et al. [Page 10] Internet Draft presence authorization June 15, 2000 Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 email: bernarda@microsoft.com David Gurle Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 email: dgurle@microsoft.com 6 Bibliography [1] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and instant messaging," Request for Comments 2778, Internet Engineering Task Force, Feb. 2000. [2] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, H. Schulzrinne, J. Lennox, C. Huitema, B. Aboba, and D. Gurle, "SIP extensions for presence," Internet Draft, Internet Engineering Task Force, June 2000. Work in progress. [3] J. Lennox and H. Schulzrinne, "CPL: a language for user control of internet telephony services," Internet Draft, Internet Engineering Task Force, Mar. 1999. Work in progress. [4] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and callee capabilities," Internet Draft, Internet Engineering Task Force, Mar. 2000. Work in progress. Rosenberg et al. [Page 11]