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]