HIP WG N.Papadoglou Internet Draft H.Zisimopoulos Expires: April 2006 Vodafone Group October 13, 2005 Host Identity Tags (HIT) in Presence Information Data Format (PIDF) draft-papadoglou-hiprg-hit-presence-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 This Internet-Draft will expire on April 13, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document describes a new way of exchanging Host Identities (or Host Identity Tags) by means of the Presence Information Data Format [6] using the Host Identity Protocol (HIP). A new presence information element is proposed as an extension to the Presence Information Data Format (PIDF), to include and convey the Host Papadoglou Expires April 13, 2006 [Page 1] Internet-Draft HIT in PIDF October 2005 Identity that corresponds to the different SIP URI's the node may have registered. This automatically creates a list of associations between the SIP URI and the Host identity for the different UA instances on the same or different node. Table of Contents 1. Introduction................................................2 2. Terminology.................................................3 3. Disseminating Host Identity Tags using Presence Information...3 3.1. Concept................................................3 4. Extension for indicating HITs in PIDF........................4 4.1. The XML schema definition...............................5 4.2. Example................................................5 5. Discussion..................................................6 6. Security Considerations......................................7 7. Acknowledgments.............................................7 8. IANA Considerations.........................................7 8.1. URN sub-namespace registration..........................7 9. References..................................................9 9.1. Normative References....................................9 Author's Addresses.............................................9 Intellectual Property Statement................................10 Disclaimer of Validity........................................10 Copyright Statement...........................................11 Acknowledgment................................................11 1. Introduction This document specifies a new way of disseminating Host Identities (or Host Identity Tags- HIT) using SIP [1], in particular using the SIMPLE Presence data model for future use of the Host Identity Protocol (HIP)[2]. There has already been a lot of interest and relevant work regarding the interoperability and relationship of HIP and SIP and how to optimize the use of either of them. Hannes et al [9] have investigated a possible way of exchanging HITs using the Session Description Protocol (SDP) attribute contained in a SIP Invite request while a session is being established. This is one possible approach to optimizing the exchange of HIT when the opportunistic mode is not used using SIP to convey the HIT in the SDP attribute. This document proposes an alternative way of distributing the HIT by adding a new presence information element to the presence document, denoting the Host Identity that the particular UA operates on, and Papadoglou Expires April 13, 2006 [Page 2] Internet-Draft HIT in PIDF October 2005 may have registered with. The watcher not only obtains information on the presentity's status for the UA instance reporting but the Host Identity as well as of which it resides. 2. Terminology This section defines terms used throughout the remainder of this specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in his document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Disseminating Host Identity Tags using Presence Information 3.1. Concept To establish a secure tunnel between two HIP-enabled nodes requires them to exchange the HITs either in opportunistic mode or using alternative methods such as DNS, Distributed Hash tables [9] or via the newly proposed approach using the offer/answer model based on SDP. Although a HIP node can initiate HIP communication "opportunistically", i.e., without a priori knowledge of its peer's HI, doing so exposes both endpoints to Man-in-the-Middle attacks on the HIP handshake and its cryptographic protocol. Hence, there is a desire to gain knowledge of peers' HIs before applications and Upper Layer Protocol's (ULPs) initiate communication. An alternative way of distributing the HITs between any two nodes is to include them in the presence document by introducing a new presence information element as an extension to PIDF. This is an appropriate candidate for the distribution of HI's given that the Presence Data Model defines a logical split between person (irrelevant in this context), service and device components. It is then possible to separate the notion of a service (one SIP UA identified by its Globally Routable Unique UA URI (GRUU)) that may be running on multiple physical devices, represented by multiple HITs. In addition, the presence information processing mechanism already provides privacy filtering rules such as those defined in [8]. This can potentially determine who is authorized to retrieve presence information like the Host Identity Tag, thus addressing the aforementioned concerns regarding "opportunistic" mode. It is also possible for the UA publishing its presence information for the different services, to denote on which device (identified by its HIT) it is available or busy. Papadoglou Expires April 13, 2006 [Page 3] Internet-Draft HIT in PIDF October 2005 Figure 1 illustrates the distribution of the various HITs using the proposed presence element. +---------+ PUBLISH | | NOTIFY +-------->| Presence|---------+ | HI/HIT | Server | HI/HIT | | | | | | +---------+ | | V +-----+ +-----+ |SIP | SIP and HIP |SIP | |UA |<--------------------->|UA | |Bob | |Alice| | (R) | | (I) | +-----+ +-----+ Figure 1 Distribution of the HIT using SIMPLE Presence Data model The steps to be followed are: 1. Retrieval of the HIT through presence information. 2. Initiation of the session using a preconditions-like approach similar to that used for Quality of Service (QoS) in [11]. 3. Establishment of an IPSec tunnel using the keys derived by the HIT 4. Establishment of the session. 5. Media exchange. The proposed solution is flexible enough to also work with a rendezvous server as proposed in [3].The IP address obtained for the particular HIT corresponding to the particular UA (SIP URI) from the watcher (in the above case from Alice UA) can be the address of a rendezvous server (RVS). When an initiator (I) wants to establish a HIP association (Alice UA) then the I1 message, containing the HIT of Bob as well as that of Alice, will be directed towards the IP address of the RVS rather than towards the IP address of the responder (R) (which will convey the message to Bob). 4. Extension for indicating HITs in PIDF This section presents the extension element to be used to contain the HIT. Papadoglou Expires April 13, 2006 [Page 4] Internet-Draft HIT in PIDF October 2005 This extension is intended to be used within the PIDF [6]. Following the Presence Data Model guidelines, it defines a document that describes device capabilities, and so should be used within the device component of the Presence Data Model. 4.1. The XML schema definition The proposed extension schema contains only one element under a new proposed namespace "urn:ietf:params:xml:ns:pidf:hitexten". 4.2. Example An example combining PIDF, the Presence Data Model and the HIT extension is shown below: open uuid:992fbae3-f1c9-4223-8ef8-95ef5727d5ce sip:someone@example.com Papadoglou Expires April 13, 2006 [Page 5] Internet-Draft HIT in PIDF October 2005 idle uuid:992fbae3-f1c9-4223-8ef8-95ef5727d5ce 6A95B5F4E067992C856750F091440377 5. Discussion Currently based on the HIP draft, the mapping is FQDN -> IP lookup, FQDN -> HI lookup, which results in the mapping of the HI to IP address. The proposed method achieves the dissemination of the HI where each UA resides, and potentially creates a relationship at the watcher end between the SIP URI (which may or may not be registered) or UA by its GRUU and the HIT. When a UA wishes to initiate a service it will still need to do a HIT to IP lookup in order to initially establish a secure communication using HIP and subsequently the wanted service. The result is the watcher being able to separate the notion of a service (one SIP UA identified by its Globally Routable Unique UA URI (GRUU)) that may be running on multiple physical devices, represented by multiple HITs and thus initiate a service accordingly. Furthermore, the "opportunistic" mode of HIP raises some security considerations, as described in the above sections, which the current proposal addresses. The Presence Authorization Rules provide a secure way of disseminating the HI's that a user may have registered with every UA instance only to those who are authorized to receive them. As briefly mentioned in the introduction of this document, the addition of the HIT as part of the Presence Document can assist the Watcher establish communication using the SIP offer/answer model. How exactly the watcher uses the HIT is out of scope of the present document. One possible use of this is described in [9]. The authors of this draft believe that the mechanism presented in [9] can be further enhanced by introducing a preconditions-like mechanism, similar to that of [11] that is being used for resource reservation. This will guarantee the establishment of a security association prior to starting any media exchange. Finally, recently there was discussion in the SIMPLE WG regarding the definition of appropriate identifiers to represent device components as part of the presence data model. The addition of the as an extension to PIDF can potentially also serve this purpose. 6. Security Considerations All security considerations specified in the Presence Data Model [5] and PIDF [6] apply to this document. Compared to PIDF, this presence document format reveals additional information about presentities that can be highly sensitive. Beyond traditional security measures to protect confidentiality and integrity, systems SHOULD also offer mechanisms to selectively reveal information to particular watchers. Therefore privacy filtering mechanisms similar to those described in [8] will apply for the element as well. Open issue: Although the element of the presence authorization rules might be used to restrict access to the element, it may be appropriate to define a new extension to the Presence Authorisation Rules document for that purpose. 7. Acknowledgments The authors would like to thank Patrick Brick and Marcus Brunner for their invaluable comments and suggestions on this work. 8. IANA Considerations This memo calls for IANA to register one new XML namespace URNs as defined in RFC3688 [7]. 8.1. URN sub-namespace registration URI: urn:ietf:params:xml:ns:pidf:hitexten Registrant Contact: IETF, SIMPLE working group, simple@ietf.org, Nick Papadoglou (nick.papadoglou@vodafone.com) XML: BEGIN Papadoglou Expires April 13, 2006 [Page 7] Internet-Draft HIT in PIDF October 2005 Namespace for PIDF HIT identifier extension

Namespace for PIDF HIT identifier extension

urn:ietf:params:xml:ns:pidf:hitexten

See RFCXXXX.

END Papadoglou Expires April 13, 2006 [Page 8] Internet-Draft HIT in PIDF October 2005 9. References 9.1. 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] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-basee- 03 (work in progress), June 2005 [3] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", draft-ietf-hip-rvs-03 (work in progress), June 2005 [4] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol", RFC3856, Aug. 2004 [5] Rosenberg, J., "A Data Model for Presence", draft-simple-data- model-05, Sept. 2005 [6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004 [7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004 [8] Rosenberg, J.,"Presence Authorization Rules", draft-ietf- simple-presence-rules-03, Jul. 2005 [9] Tschofenig, H., "Interaction between SIP and HIP",draft- tschofenig-hiprg-host-identities-02 (work in progress), July 2005 [10] Laganier, J., " Host Identity Protocol (HIP) Rendezvous Extension", draft-ietf-hip-rvs-03 (work in progress), July 2005 [11] Camarilo, G., "Integration of Resource Management and Session Initiation Protocol (SIP), RFC3312, October 2002 Author's Addresses Nick Papadoglou Vodafone Group Papadoglou Expires April 13, 2006 [Page 9] Internet-Draft HIT in PIDF October 2005 Vodafone House The Connection Newbury, UK Phone: 44-1635-68-5653 Email: nick.papadoglou@vodafone.com Haris Zisimopoulos Vodafone Group Vodafone House The Connection Newbury, UK Phone: 44-1635-67-6647 Email: haris.zisimopoulos@vodafone.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE Papadoglou Expires April 13, 2006 [Page 10] Internet-Draft HIT in PIDF October 2005 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Papadoglou Expires April 13, 2006 [Page 11]