Re: [secdir] sec-dir review of draft-ietf-bliss-shared-appearances-11

[Alan Johnston <[e-mail]>]

Derek,

Thank you for your review of the document.  I will fix the issues you
identify below in the next version of the draft.  My proposed text for
the Security Considerations is included here.

- Alan -


12.  Security Considerations

   Since multiple line appearance features are implemented using
   semantics provided by SIP [RFC3261], the SIP Event Package for Dialog
   State [RFC4235], and the SIP Event Framework
   [I-D.ietf-sipcore-rfc3265bis] and [RFC3903], security considerations
   in these documents apply to this document as well.

   To provide confidentiality, NOTIFY or PUBLISH message bodies that
   provide the dialog state information and the dialog identifiers MAY
   be encrypted end-to-end using the standard mechanisms such as S/MIME
   described in [RFC3261].  Alternatively, sending the NOTIFY and
   PUBLISH requests over TLS also provides confidentiality, although on
   a hop-by-hop basis.  All SUBSCRIBES and PUBLISHES between the UAs and
   the Appearance Agent MUST be authenticated.  Without proper
   authentication and confidentiality, a third party could learn
   information about dialogs associated with a AOR and could try to use
   this information to hijack or manipulate those dialogs using SIP call
   control primitives.

   All INVITEs with Replaces or Join header fields MUST only be accepted
   if the peer requesting dialog replacement or joining has been
   properly authenticated using a standard SIP mechanism (such as Digest
   or S/MIME), and authorized to request a replacement.  Otherwise, a
   third party could disrupt or hijack existing dialogs in the
   appearance group.

   For an emergency call, a UA MUST NOT wait for a confirmed seizure of
   an appearance before sending an INVITE.  Waiting for confirmation
   could inadvertently delay or block the emergency call, which by its
   nature needs to be placed as expeditiously as possible.  Instead, a
   emergency call MUST proceed regardless of the status of the PUBLISH
   transaction.


On Wed, Jun 27, 2012 at 9:21 PM, Derek Atkins <[e-mail]> wrote:
> Hi,
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
>    This document describes the requirements and implementation of a
>    group telephony feature commonly known as Bridged Line Appearance
>    (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
>    Appearance (SCA).  When implemented using the Session Initiation
>    Protocol (SIP), it is referred to as shared appearances of an Address
>    of Record (AOR) since SIP does not have the concept of lines.  This
>    feature is commonly offered in IP Centrex services and IP-PBX
>    offerings and is likely to be implemented on SIP IP telephones and
>    SIP feature servers used in a business environment.  This feature
>    allows several user agents (UAs) to share a common AOR, learn about
>    calls placed and received by other UAs in the group, and pick up or
>    join calls within the group.  This document discusses use cases,
>    lists requirements and defines extensions to implement this feature.
>
> The first sentence of the first paragraph of the Security Considerations
> section is missing a reference.  It says:
>
>    ...
>    semantics provided by [RFC3261], Event Package for Dialog State as
>    define in , and Event Notification [I-D.ietf-sipcore-rfc3265bis],
>    [RFC3903], ...
>
> The "define in" should be "defined in", and needs a place where it is
> defined.
>
> The second paragraph says that dialog state information and dialog
> identifiers MAY be encrypted, but doesn't talk about why one would
> choose not to encrypt it.
>
> Similarly, the last paragraph provides guidance on waiting for
> confirmed seizures, but does not explain the details about why one must
> do so.
>
> Both of these might be obvious to writers, but to someone reading the
> document they are not clear.
>
> -derek
>
> --
>        Derek Atkins                 617-623-3745
>        [e-mail]             www.ihtfp.com
>        Computer and Internet Security Consultant