[Hipsec-rg] Comment on draft-tschofenig-hiprg-host-identities-02.txt

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.

Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related honor.trusecure.com Links hipsec-rg Request more information about Pantek

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.

Do you need more help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related honor.trusecure.com Links hipsec-rg Request more information about Pantek

    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