Subject: [Sipping] Security Considerations Section for 'A Session Initiation Protocol (SIP) Event Package for Conference State'

From: "Orit Levin" <[email-masked]>
Date: Wed, 11 May 2005 13:04:54 -0700

Guys,

As one of the items regarding the package, I promised to rework the
Security Considerations section of the document. Below is my proposal
for the improved text.

Please, take a look and post any comments!

Thanks a lot,
Orit.

--------------------------
8. Security Considerations

Subscriptions to conference state information can reveal very sensitive
information. For this reason, the document RECOMMENDS using a strong
means for authentication, conference information protection, and
applying comprehensive authorization rules when using the conference
notification mechanism defined in this document. Following sections
discuss each of the mentioned aspects in more details.

8.1 Connection Security

It is RECOMMENDED to authenticate the package subscriber using the
normal SIP authentication mechanisms, such as Digest as defined in
Section 22 of [RFC3261].

The mechanism used for conveying the conference information MUST ensure
integrity and SHOULD ensure confidentially of the information. In order
to achieve these, end-to-end SIP encryption mechanism S/MIME as
described in Section 26.2.4 SHOULD be used.

If the strong end-to-end security means (such as above) is not
available, it is RECOMMENDED to use mutual hop-by-hop TLS authentication
and encryption mechanisms described in Section 26.2.2 "SIPS URI Scheme"
and Section 26.3.2.2 "Interdomain Requests" of [RFC 3261] .

8.2 Authorization Considerations

Generally speaking, conference applications are very concerned about
authorization decisions. Mechanisms for establishing and enforcing such
authorization rules is a central concept throughout [replace with the
RFC number for draft-ietf-sipping-conferencing-framework-xx]. Because
most of the information about a conference can be presented using the
conference package, many of the authorization rules directly apply to
this specification. As a result, a notification server MUST be capable
of generating distinct conference information views to different
subscribers, subject to subscriber's role in a conference, personal
access rights, etc. - all subject to local authorization policies and
rules.

For example, a focus provides participant identity information using
this event package, participant privacy needs to be taken into account.
A focus MUST support requests by participants for privacy.  Privacy can
be indicated by the conference policy - for every participant or select
participants.  It can also be indicated in the session signaling.  In
SIP this can be done using the Privacy header field described in RFC
3323 [15].  For a participant requesting privacy, no identity
information SHOULD be revealed by the focus such as a URI (e.g.  the
Address of Record, Contact, or GRUU).  For these cases, the anonymous
URI generation method outlined in section Section 5.5 of this document
MUST be followed.
------------------------------------------------------------------------
--------------

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of The IESG
> Sent: Friday, May 06, 2005 8:20 AM
> To: IETF-Announce
> Cc: [email-masked]
> Subject: [Sipping] Last Call: 'A Session Initiation Protocol 
> (SIP) Event Package for Conference State' to Proposed Standard 
> 
> The IESG has received a request from the Session Initiation 
> Proposal Investigation WG to consider the following document:
> 
> - 'A Session Initiation Protocol (SIP) Event Package for 
> Conference State '
>    <draft-ietf-sipping-conference-package-10.txt> as a 
> Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and 
> solicits final comments on this action.  Please send any 
> comments to the [email-masked] or [email-masked] mailing lists 
> by 2005-05-20.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-confere
> nce-package-10.txt
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 15 May 2005 22:52:37 +0300

All,

note that the IETF LC on this document will finish in five days. Send 
your comments on the document and on the new security considerations 
sections before then.

Orit,

note that RECOMMENDS is not one of the terms defined in RFC 2119. 
Therefore, you should not capitalize it.

OLD:
the document RECOMMENDS

NEW:
it is RECOMMENDED

Thanks,

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo