Subject: [Sip-security] Official Minutes from SIP Security Adhoc at 51st IETF

From: "Frank W. Miller" <[email-masked]>
Date: Mon, 13 Aug 2001 14:31:53 -0400

Been trying to send out the combined minutes but they are bouncing for
size.  Sending them one piece at a time…
 
FM

Frank W. Miller, Ph.D.
Chief Technical Officer
sentitO Networks, Inc.
www.sentito.com

SIP Security Adhoc Meeting Minutes
 
Meeting held on Wednsday August 8, 2001 at 51st IETF located at the
Hilton Metropole in London, England.

Some early comments:
 
* Removal of Signal Header (?) means that some way of passing security
information transitively is required
 
* Security information must be handed from one UA to another
 
Meeting proper:
 
* A threat model and analysis must be developed
 
* Mike?s draft could be used as a starting point (Henning pointed out
that the draft would be alright as a starting point but that it is
incomplete)
 
* Mike?s draft discusses ?inside? vs. ?outside? threats
 
* Oran asked for these to defined
 
* Mike defined them as follows: an outside threat is one that is
presented by an entity that is not participating and has no visibility
into a conversation and an inside threat is one that is presented by a
participant in a conversation
 
* For outside threats, the use of TLS etc. vs. http digest may suffice
 
* Some discussion about inside vs. outside being an instance of thread
prioritization
 
* Mention of possible use of call control model as a way to model inside
vs. outside and to breakdown the description of inside threats to the
next level
 
* Jonathan described an example (which I didn?t get to write down) of
what he referred to as a ?SIP-specific? threat
 
* The relationship between entities needs to be defined: Henning
referred to the relationship between a UA and a gateway as
?semi-adverserial?
 
* At this point in the meeting, the question of whether the remainder of
the meeting would focus on the threat model or would also include
mechanisms came up.
 
* An immediate mention of several mechanisms was made: authentication,
authorization, and integrity checking
 
* The discussion of mechanisms was agreed to a bit later
 
* A list of threats was proposed and some examples of use included
 
List of Threats
Examples of Use
Identical Replay                                                Hangup,
Service Theft,
Modified Replay
Registration Hijacking,
Message Forgery
User Impersonation
Disclosure of Call Signaling Information
Denial of Service (DoS)
    - Message Injection
    - Message Deletion
    - Message Amplification
 
It was noted that the list of threats constitutes a different taxonomy
for describing the threats than Mike?s taxonomy
 
Henning commented that this approach may be superior since it seemed
intuitively easier to show completeness for
 
Also noted that this new taxonomy does not capture descriptions of level
of trust
 
Dave described an example where a UA uses a RADIUS sever for
authentication but that anyone that can compromise the RADIUS server
also compromises the UA, allowing it to be impersonated (not sure I
copied this right Dave)
 
A description of the ?Pentagon? described in Mike?s draft was presented
 
The Pentagon is used to describe boundaries of trust
 
Mike?s draft presents a fully connected graph and describes the level of
trust between each pair of endpoints
 
Discussion centered on the possibility that this approach may imply that
all mechanisms are necessary for all types of connections
 
Dave mentioned that the saving grace was that it would probably possible
to also describe when those mechanisms would and would not actually be
used
 
The question was raised about whether conformance to security
requirements and any mechanisms necessary to indicate this was or was
not the case was necessary all along the signaling path?
 
The question was asked but never answered, ?where are the keys for SRTP
handled??
 
It was noted that the ability to do end-to-end body encryption will be
necessary!
 
The question was asked, ?will parties along a signaling path need to be
able to authenticate a UAC??
 
Discussion then ensued about whether authentication should be wrt UAs or
users.  Some agreement emerged that UA (i.e. domain level)
authentication might be valuable but that user level authentication
would probably be impractical
 
This agreement came from a discussion about whether authentication was
necessary for unsolicited calls.  In this case, domain-level
authentication would probably provide some additional value but that
user level authentication might be difficult if not impossible
 
The discussion then turned to what mechanisms will be included the bis
regarding security given the looming Dec. deadline
 
Some agreement on the hop-by-hop discussion only that more complex
mechanisms will need to be put in a separate draft
 
The point was made that mechanisms should only be proposed for the
separated draft after at least one round of requirements had been
circulated
 
Backward compatibility is important, additional security features cannot
force a wholesale change to the existing bis mechanisms
 
Henning mentioned a potential practical problem: a separate draft will
require a separate implementation.  The group did not see this as a
serious problem
 
The discussion then turned to whether TLS or IPSec should be specified
for hop-by-hop security
 
Mike?s main issue was that TLS does not work with UDP
 
Henning made the point that TCP works well for ?signaling trunks?,
nailed up signaling connections that persist.  There was some question
about the implications of HOL blocking in this situation. SCTP solves
that potential problem
 
Main issue with IPSec is that it is somewhat decoupled from the
application since it is done at Layer 3.  It is harder to do
?automatically?
 
Some agreement that TLS is appropriate for some cases and IPSec for
others
 
It was noted that something must be made mandatory implementation, which
is the quandary given the difficulties that the MobileIP group had
 
Dave noted that the UA to Proxy and Proxy to Proxy security can be
different
 
A proposal was made to use TLS for Proxy to Proxy only as a mandatory
implementation
 
Another potential bis problem was noted, ?how is a UA-to-UA with no
previous trust relationship handled??  I did not gather any additional
notes from that discussion
 
The meeting ended with a short discussion on the question of what the
IESG would accept for a mandatory implementation