[secdir] sec-dir review of draft-ietf-bliss-shared-appearances-11
Derek Atkins <derek@ihtfp.com> Thu, 28 June 2012 02:21 UTC
Return-Path: <derek@ihtfp.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 43D2C11E817C; Wed, 27 Jun 2012 19:21:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 gkDWVxZzv+bP; Wed, 27 Jun 2012 19:21:40 -0700 (PDT)
Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id C924711E8171; Wed, 27 Jun 2012 19:21:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id B742E2602B7; Wed, 27 Jun 2012 22:21:35 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 08938-04; Wed, 27 Jun 2012 22:21:34 -0400 (EDT)
Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 85CCF260224; Wed, 27 Jun 2012 22:21:34 -0400 (EDT)
Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q5S2LXba019270; Wed, 27 Jun 2012 22:21:33 -0400
From: Derek Atkins <derek@ihtfp.com>
To: iesg@ietf.org, secdir@ietf.org
Date: Wed, 27 Jun 2012 22:21:33 -0400
Message-ID: <sjmfw9gnple.fsf@mocana.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Virus-Scanned: Maia Mailguard 1.0.2a
Cc: mohsen.soroush@sylantro.com, alan.b.johnston@gmail.com, vvenkatar@gmail.com, bliss-chairs@tools.ietf.org
Subject: [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: Thu, 28 Jun 2012 02:21:41 -0000
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