[Sipping] Revised Security Considerations for cc-conferencing

["Johnston, Alan" <[e-mail]>]

Based on AD feedback, here is a revised Security Considerations section
for draft-ietf-sipping-cc-conferencing, currently in IETF Last Call.

Comments and feedback are most welcome.

Thanks
Alan Johnston
sip:[e-mail]

- - - 
5.  Security Considerations

This specification defines the interaction between a focus UA and a
participant UA in a conferencing application.  As a result, the security
considerations and mechanisms defined in RFC 3261 [RFC3261] apply.
However, there are some aspects unique to conferencing which will be
discussed here.

A conference often involves the use of substantial network bandwidth and
computing resources.  As a result, authentication is even more important
than in a simple peer to peer session.  As discussed in the conferencing
framework [framework], conferences often have policy related to
conferencing resources.   A focus SHOULD authenticate participants
before joining them to a conference and allowing utilization of
conferencing resources. Different policies can be applied by a focus to
different participants based on the result of authentication.

A participant will be interacting with a number of other participants
through the focus.  As a result, a participant should authenticate the
focus and be sure that the focus used for the conference is trusted.
Normal SIP authentication mechanisms are suitable for participant and
focus authentication, such as SIP Digest utilizing a shared secret, or
certificates, or a secured SIP identity mechanism.  In addition, a focus
SHOULD support Secure SIP connections so that hop by hop mutual
authentication and confidentiality provided by TLS can be achieved.  

In the SIP dialog between them, a focus utilizes the "isfocus" feature
tag to indicate that the UA is acting as a focus.  As such, the SIP
header fields such as Contact SHOULD have end to end integrity.  A
participant and focus SHOULD support an end to end integrity mechanism
such as S/MIME.
 
Once a participant has learned that the other UA is a focus, SIP call
control operations (such as REFER) can be implemented, or a subscription
to the conference package of the focus might be attempted.   The
security considerations described in RFC 3515 [RFC3515] apply to any
REFER call control operations.  A focus and participant will apply
policy to determine which call control operations are allowed.

A focus accepting subscriptions to the conference package must follow
the security considerations in RFC XXXX [conf-package].  Since
notifications can carry sensitive information, the subscriptions should
be authenticated and the notifications delivered with confidentiality
and integrity protection.  Since a participant is not able to
authenticate other participants directly, a participant must rely on the
focus to perform this authentication.

A focus MUST support a participant's request for privacy, either through
conference policy or as expressed through the signaling.  For example, a
participant joining a conference and including a Privacy header field
[RFC3323] must not have identity information revealed to other
participants by the focus.  If other signaling protocols are used,
privacy signaled through them also must be respected.  

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP