Subject: [Hipsec] AW: [Hipsec-rg] I-D ACTION:draft-papadoglou-hiprg-hit-presence-00.txt

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 1 Nov 2005 14:11:06 +0100

hi pekka, 

interesting that you mention this.
we have an ietf draft about hip and sip interaction (see draft-tschofenig-hiprg-host-identities-02.txt) hanging around for some time. the approach outlined in draft-papadoglou-hiprg-hit-presence-00.txt illustrates the first item of our open issue list. 

ciao
hannes 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Pekka Nikander
Gesendet: Dienstag, 1. November 2005 11:49
An: Papadoglou, Nick, VF-Group
Cc: [email-masked]; [email-masked]
Betreff: Re: [Hipsec-rg] I-D ACTION:draft-papadoglou-hiprg-hit-presence-00.txt

This looks like an interesting approach to me; I'd encourage people  
to read.

--Pekka

On Oct 30, 2005, at 19:09, Papadoglou, Nick, VF-Group wrote:

>  Dear all,
>
> Please find below a new ID that we submitted and we intent to
> present/discuss in the Vancouver meeting. Your comments/suggestions  
> and
> constructive comments are more than welcome.
>
> Best regards,
>
> Nick
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 18, 2005 12:50 PM
> To: [email-masked]
> Subject: I-D ACTION:draft-papadoglou-hiprg-hit-presence-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>     Title        : Host Identity Tags (HIT) in Presence
> Information Data Format (PIDF)
>     Author(s)    : N. Papadoglou, H. Zisimopoulos
>     Filename    : draft-papadoglou-hiprg-hit-presence-00.txt
>     Pages        : 11
>     Date        : 2005-10-18
>
>    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
>    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.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-papadoglou-hiprg-hit- 
> presence-
> 00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
>     "get draft-papadoglou-hiprg-hit-presence-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>     [email-masked].
> In the body type:
>     "FILE
> /internet-drafts/draft-papadoglou-hiprg-hit-presence-00.txt".
>
> NOTE:    The mail server at ietf.org can return the document in
>     MIME-encoded form by using the "mpack" utility.  To use this
>     feature, insert the command "ENCODING mime" before the "FILE"
>     command.  To decode the response(s), you will need "munpack" or
>     a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
>     exhibit different behavior, especially when dealing with
>     "multipart" MIME messages (i.e. documents which have been split
>     up into multiple messages), so check your local documentation on
>     how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> <draft-papadoglou-hiprg-hit-presence-00.URL>
>

_______________________________________________
Hipsec-rg mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec-rg

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Jari Arkko <[email-masked]>
Date: Sun, 06 Nov 2005 00:50:23 +0200

Hannes,

The discussion on draft-papadoglou-hiprg-hit-presence-00.txt
led me to go back to your draft and re-read it... and I have a
question.

Your note about this being related to the PBK idea led
me to think about the semantics of the transported HITs.
What specifically are the semantics? The security of
PBK approaches depend very much on to what the
keys are bound to, how, and for how long. Here's
some potential answers and related considerations:

1. Receiver binds sip-level identity to the HIT forever.

    This could lead to a vulnerability where, if I can
    once spoof a signalling message in some environment,
    I can take over someone's identity or at least render
    it unusable.

2. Receiver binds sip-level identity to the HIT after
    SSH style user confirmation (similar to what the base
    SIP spec already does for S/MIME).

    This is more workable. Not sure people in
    all environments are willing to do the
    confirmations in reliable manner.

3. HITs apply for a session; The HITs may be
    updated at any time through the SIP signalling
    messages.

    This seems more reasonable. But if hosts may
    talk directly SIP to each other (as they can in SIP)
    then one of your assumptions about a different path
    for the signaling traffic is violated. Of course, if
    there's security for the direct SIP connection then
    this won't be a problem - but such security essentially
    implies some cert-based solution, which could obviously
    be used for media protection too, without HIP.

4. The HITs may be updated at any time during a
    session, but we only support configuration through
    infrastructure.

    Based on item 3 above, this seems quite sensible.
    Incidentally, this is similar to what the presence
    approach was.

5. Session-based semantics where initial message has
    to contain all the identities.

    Identity hijack is not an issue beyond one session.
    Security of direct host-to-host SIP communications
    does not matter, because the initial messages are
    typically through the infrastructure anyway.

Approach 4 seems most reasonable, but I could
be missing something.

--Jari