Internet DRAFT - draft-papadoglou-hiprg-hit-presence

draft-papadoglou-hiprg-hit-presence



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". 
 
   <?xml version="1.0" encoding="UTF-8"?> 
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:hitexten"  
                     xmlns:hit="urn:ietf:params:xml:ns:pidf:hitexten" 
                     xmlns:xs="http://www.w3.org/2001/XMLSchema" 
                     elementFormDefault="qualified" 
                     attributeFormDefault="unqualified"> 
    
   <!-- This import brings in the XML language attribute xml:lang--> 
   <xs:import namespace="http://www.w3.org/XML/1998/namespace" 
   schemaLocation="http://www.w3.org/2001/xml.xsd"/> 
      
   <!-- Extension to PDM device element to describe the HIT --> 
   <xs:element name="hit-identifier" /> 
            <xs:simpleType> 
              <xs:restriction base="xs:anyURI"> 
                 
              </xs:restriction> 
            </xs:simpleType> 
   </xs:element>       
    
4.2. Example 

   An example combining PIDF, the Presence Data Model and the HIT 
   extension is shown below: 
    
     <?xml version="1.0" encoding="UTF-8"?> 
      <presence xmlns="urn:ietf:params:xml:ns:pidf" 
       xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" 
       xmlns:hit="urn:ietf:params:xml:ns:pidf:hitexten" 
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
       <tuple id="sg89ae"> 
        <status> 
         <basic>open</basic> 
        </status> 
        <dm:deviceID>uuid:992fbae3-f1c9-4223-8ef8-95ef5727d5ce 
   </dm:deviceID>    
        <contact>sip:someone@example.com</contact> 
 
 
Papadoglou             Expires April 13, 2006                 [Page 5] 

Internet-Draft               HIT in PIDF                  October 2005 
    

       </tuple> 
       <dm:device id="pc122"> 
        <rp:user-input>idle</rp:user-input> 
        <dm:deviceID> uuid:992fbae3-f1c9-4223-8ef8-95ef5727d5ce 
   </dm:deviceID> 
       <hit:hit-identifier>6A95B5F4E067992C856750F091440377</hit:hit-
   identifier> 
       </dm:device> 
      </presence> 
    
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 <hit-

 
 
Papadoglou             Expires April 13, 2006                 [Page 6] 

Internet-Draft               HIT in PIDF                  October 2005 
    

   identifier> 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 <hit-identifier> element as well. 
    
   Open issue: Although the <provide-unknown-attribute> element of the 
   presence authorization rules might be used to restrict access to the 
   <hit-identifier> 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 
      <?xml version="1.0"?> 
      <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" 
      "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> 
 
 
Papadoglou             Expires April 13, 2006                 [Page 7] 

Internet-Draft               HIT in PIDF                  October 2005 
    

      <html xmlns="http://www.w3.org/1999/xhtml 
      <head> 
           <meta http-equiv="content-type" 
           content="text/html;charset=iso-8859-1"/> 
           <title>Namespace for PIDF HIT identifier 
                  extension</title> 
      </head> 
      <body> 
          <h1>Namespace for PIDF HIT identifier extension</h1> 
          <h2>urn:ietf:params:xml:ns:pidf:hitexten</h2> 
          <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> 
       </body> 
       </html> 
      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]