* 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
*
*
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!
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
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
updated 13 Dec 2001 13:23:08 -0600