Re: [secdir] sec-dir review of draft-ietf-bliss-shared-appearances-11
Alan Johnston <alan.b.johnston@gmail.com> Fri, 20 July 2012 18:02 UTC
Return-Path: <alan.b.johnston@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1125C11E8097; Fri, 20 Jul 2012 11:02:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96OQFXz1s3kb; Fri, 20 Jul 2012 11:02:45 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA4211E807F; Fri, 20 Jul 2012 11:02:44 -0700 (PDT)
Received: by lbbgo11 with SMTP id go11so5863274lbb.31 for <multiple recipients>; Fri, 20 Jul 2012 11:03:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eZmCFwUBiLn9GsLzUYzSwUJF6VMtubSyJsFrBOFd8kc=; b=oTWxalV+CpIg7rWGYTf1BNg8d0yj5k3y/CqBfbEOwXdhpeIEOekQG/h0WU75fknlGx x67pjNXpeMvl1eJtHRmq/zrstw1Gg1KWNZUItWElf0MDkEIR67Wyp5f5Bdh+9FDXRJJC lV/LgfM2wd2H6ATvwpovVKxKyfPjfOq802c2ONQM1Ls+JTxvkSPvFQoph4fadfGlK0pl 1UalQZQocFmFb/AV0BNkp6UQ77cCsTEJqLVSVfYSpprS/mjQArpv+c55116KO+CdGZJq DsJ66RPwIQuZBCaojbC+S0EXUIaUip1fuda+68i9iTgeFm1GLvZmV5FQjjIJxirqaDC2 hl+w==
MIME-Version: 1.0
Received: by 10.112.83.198 with SMTP id s6mr3415641lby.76.1342807420012; Fri, 20 Jul 2012 11:03:40 -0700 (PDT)
Received: by 10.112.133.130 with HTTP; Fri, 20 Jul 2012 11:03:39 -0700 (PDT)
In-Reply-To: <sjmfw9gnple.fsf@mocana.ihtfp.org>
References: <sjmfw9gnple.fsf@mocana.ihtfp.org>
Date: Fri, 20 Jul 2012 13:03:39 -0500
Message-ID: <CAKhHsXEr0bs6ecYH0V4OvHoiW_NL3TZxOd4LjeXZAiat9DhFNQ@mail.gmail.com>
From: Alan Johnston <alan.b.johnston@gmail.com>
To: Derek Atkins <derek@ihtfp.com>
Content-Type: text/plain; charset="ISO-8859-1"
X-Mailman-Approved-At: Mon, 23 Jul 2012 08:04:30 -0700
Cc: vvenkatar@gmail.com, msoroush@gmail.com, iesg@ietf.org, bliss-chairs@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] sec-dir review of draft-ietf-bliss-shared-appearances-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jul 2012 18:02:46 -0000
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 <derek@ihtfp.com> 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 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant
- [secdir] sec-dir review of draft-ietf-bliss-share… Derek Atkins
- Re: [secdir] sec-dir review of draft-ietf-bliss-s… Alan Johnston