From prvs=249990ea54=david.borman@quantum.com Fri Jun 1 07:06:16 2012 Return-Path: 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 614AB11E814C; Fri, 1 Jun 2012 07:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_6CONS_WORD=0.356] 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 DZq+2W9M2rKS; Fri, 1 Jun 2012 07:06:15 -0700 (PDT) Received: from mx0b-000ceb01.pphosted.com (mx0b-000ceb01.pphosted.com [67.231.152.126]) by ietfa.amsl.com (Postfix) with ESMTP id 4677C11E8120; Fri, 1 Jun 2012 07:06:15 -0700 (PDT) Received: from pps.filterd (m0001158 [127.0.0.1]) by mx0b-000ceb01.pphosted.com (8.14.4/8.14.4) with SMTP id q51E535k005396; Fri, 1 Jun 2012 07:06:04 -0700 Received: from ppoxedge2.quantum.com ([146.174.252.28]) by mx0b-000ceb01.pphosted.com with ESMTP id 156qb2ge2y-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 01 Jun 2012 07:06:04 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE2.quantum.com (146.174.252.28) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 1 Jun 2012 07:05:39 -0700 Received: from PPOMSG1.QUANTUM.com ([fe80::6081:f8af:54f6:10cc]) by PPOMSG2.QUANTUM.com ([fe80::e4fd:df34:99ee:ac5e%20]) with mapi id 14.01.0355.002; Fri, 1 Jun 2012 08:06:03 -0600 From: David Borman To: "Scharf, Michael (Michael)" Thread-Topic: secdir review of draft-ietf-tcpm-tcpmss-04 Thread-Index: AQHNPnXIPFIPS9owW0+7AUuNti9CaZbi+xyAgAAC+4CAAAs/AP//voCggAMfLYA= Date: Fri, 1 Jun 2012 14:06:01 +0000 Message-ID: <94ADA294-87DB-488F-B784-A1FDCDF97A56@quantum.com> References: <4FC63731.7060409@cisco.com> <58B9B09F-ECA8-457E-B22C-34CE7A69CCFA@quantum.com> <2A886F9088894347A3BE0CC5B7A85F3E891A9BB37B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E891A9BB37B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <85A99760C794864DA3E005A6D087F438@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-06-01_03:2012-05-21, 2012-06-01, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1206010117 X-Mailman-Approved-At: Fri, 01 Jun 2012 07:33:13 -0700 Cc: "" , The IESG , "" Subject: Re: [secdir] secdir review of draft-ietf-tcpm-tcpmss-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 14:06:16 -0000 On May 30, 2012, at 3:47 PM, Scharf, Michael (Michael) wrote: >>>> I don't have a strong opinion about the current content of the=20 >>>> Security Considerations section. My leaning is to just=20 >> leave it as=20 >>>> is, but I'd be fine with moving the content up to section=20 >> 5.4 as an=20 >>>> "Additional Consideration", and then have section 6, "Security=20 >>>> Considerations" just have a comment that there are no security=20 >>>> considerations, if folks generally feel that would be better. >>>=20 >>> I don't feel comfortable with a security consideration that=20 >> isn't, so I would lean towards your alternative proposal. >>=20 >> Ok, I'll move the content to section 5, and leave "Security=20 >> Considerations" >> empty, unless someone else objects to making that change. >=20 > Instead of an empty security considerations section, you could also add a= sentence explaining that the document just clarifies what is mandated by R= FC 1122, and that it thus does not result in new security issues. >=20 > According to the working group discussions and the WGLC feedback, TCPM is= apparently not aware of any security issues with this draft, and I think t= hat TCPM would be fine with mentioning this more explicitly. Ok, how about: This document clarifies how to determine what=20 value should be used for the MSS option, and does not introduce any new security concerns. -David Borman >=20 > Just a thought... >=20 > Michael (as document shepard) ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From bew@cisco.com Fri Jun 1 11:16:05 2012 Return-Path: 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 74BCE21F897C; Fri, 1 Jun 2012 11:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.3 X-Spam-Level: X-Spam-Status: No, score=-109.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 8QddUgIOAe0k; Fri, 1 Jun 2012 11:16:04 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id D49E221F8979; Fri, 1 Jun 2012 11:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=1882; q=dns/txt; s=iport; t=1338574564; x=1339784164; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=oWsTGyDlvj1VaMR/gxzDgMjl0DRcqPjWbmB7+R4YImM=; b=hRDzHWAiXL9z+l86bGdZg8BcDKhhRuOsLidMQdhVePmu593Yf8cmkzH9 JoFwKY2CBc/TY+eWT8L6IB9maGLygoGK/c4BFf9HO6AuudPC3eQ71d7M0 IbGT/eE/Oav2o1rPfx0RBeXtqfRy4Fzrji8Qz6oLGJXPFkz0ZSbW6l8xu A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEABAGyU+rRDoI/2dsb2JhbABFtD+BB4IxASc/gT4BLQeHaJgkn2WQJGADiECMWY4PgWaDAA X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="44196675" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 01 Jun 2012 18:16:03 +0000 Received: from sjc-vpn6-2027.cisco.com (sjc-vpn6-2027.cisco.com [10.21.127.235]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q51IG2KI029112; Fri, 1 Jun 2012 18:16:02 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jun 2012 11:16:02 -0700 Message-Id: <714A20F7-D17E-46A9-9145-1BB07BED3326@cisco.com> To: secdir@ietf.org, The IESG Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: draft-ietf-mpls-ldp-gtsm.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-mpls-ldp-gtsm-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 18:16:05 -0000 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 applies the Generalized TTL Security Mechanism (GTSM) = mechanism defined in RFC 5082. This mechanism is used by routing = protocols as a low-cost non-cryptographic method intended to frustrate = off-path attackers. It is applicable when the peer is known to be = connected by a single hop. The security considerations of this draft mostly point to RFC 5082's = extensive security considerations section, which is appropriate. However = because this I-D discusses multi-hop cases in greater detail it would be = appropriate for the security considerations section to also discuss = multi-hop a bit more. Here are some thoughts for that: 1) Use of cryptographic integrity (e.g., RFC 5925) should be recommended = as an alternate solution for detecting forged protocol packets in the = multi-hop case. 2) GTSM is expected to be enabled by default for Basic Discovery because = it's usually a single-hop, and disabled for Extended Discovery because = it's usually multi-hop. But then Section 3 mentions several exceptions, = which apparently need to be administratively configured away from the = defaults. Failing to do this when needed results in security risks in = either case: either GTSM isn't deployed when it should be and the router = is inadvertently open to spoofing, or GTSM is deployed when it shouldn't = be and this results in an availability issue because LDP packets will be = dropped before reaching the LDP peer. This should be stated in the = Security Considerations. Brian=20 From bew@cisco.com Fri Jun 1 14:11:04 2012 Return-Path: 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 38E4C11E80BC; Fri, 1 Jun 2012 14:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.485 X-Spam-Level: X-Spam-Status: No, score=-110.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 cLfdQdNB1o37; Fri, 1 Jun 2012 14:11:02 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3A68711E80CE; Fri, 1 Jun 2012 14:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=3464; q=dns/txt; s=iport; t=1338585061; x=1339794661; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=yjA50Ym6doqLafWEB0v5+/vq9FfgowpbRf5y9eXXIEA=; b=cvWLPyNoXGEy3pmwYUH5p8iYBfBqZ/JpsnQoAYmF65M7Wtcbs16/1IqC Kpo7M72w2Iwc60ST7mKqUFEIDVqusLbr8qthpNAbnlj0/+zrnqEocL535 9pxKXuuc3KTtPmKt/96rMkaz+QBYJJc7FJUPQIWa6YWJGttupp4P5rblM Q=; X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="47245376" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 01 Jun 2012 21:11:01 +0000 Received: from dhcp-128-107-151-6.cisco.com (dhcp-128-107-151-6.cisco.com [128.107.151.6]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q51LB0wl029537; Fri, 1 Jun 2012 21:11:01 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: Date: Fri, 1 Jun 2012 14:11:01 -0700 Content-Transfer-Encoding: 7bit Message-Id: <2A2DAC2C-34CB-4D9B-84E0-34BCE799C1FC@cisco.com> References: <714A20F7-D17E-46A9-9145-1BB07BED3326@cisco.com> To: "Rajiv Asati (rajiva)" X-Mailer: Apple Mail (2.1257) Cc: draft-ietf-mpls-ldp-gtsm.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-mpls-ldp-gtsm-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 21:11:04 -0000 Hi Rajiv, Your proposed text looks good to me. I think it's good to go with this added. Thanks, Brian On Jun 1, 2012, at 1:37 PM, Rajiv Asati (rajiva) wrote: > Hi Brian, > > Really appreciate your critical review and suggestions. > > I agree to your both of your suggestions, and would propose the > following text for us to include in the next revision. > > > // > As discussed in section 3, it is possible that > - GTSM for LDP may not always be enforced on a single-hop LDP peering > session and may still be susceptible to forged/spoofed protocol packets, > if the single-hop LDP peering session is set up using Extended > Discovery. > - GTSM for LDP may cause LDP peering session to not get established (or > torn down), if IP routing ever declares that the directly connected peer > is more than one hop away. > Suffice to say, use of cryptographic integrity (e.g., RFC 5925) is > recommended as an alternate solution for detecting forged protocol > packets (especially for the multi-hop case). > // > > Cheers, > Rajiv > > >> -----Original Message----- >> From: Brian Weis (bew) >> Sent: Friday, June 01, 2012 2:16 PM >> To: secdir@ietf.org; The IESG >> Cc: draft-ietf-mpls-ldp-gtsm.all@tools.ietf.org >> Subject: Secdir review of draft-ietf-mpls-ldp-gtsm-07 >> >> 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 applies the Generalized TTL Security Mechanism (GTSM) >> mechanism defined in RFC 5082. This mechanism is used by routing >> protocols as a low-cost non-cryptographic method intended to frustrate > off- >> path attackers. It is applicable when the peer is known to be > connected by a >> single hop. >> >> The security considerations of this draft mostly point to RFC 5082's >> extensive security considerations section, which is appropriate. > However >> because this I-D discusses multi-hop cases in greater detail it would > be >> appropriate for the security considerations section to also discuss > multi-hop >> a bit more. Here are some thoughts for that: >> >> 1) Use of cryptographic integrity (e.g., RFC 5925) should be > recommended as >> an alternate solution for detecting forged protocol packets in the > multi-hop >> case. >> >> 2) GTSM is expected to be enabled by default for Basic Discovery > because >> it's usually a single-hop, and disabled for Extended Discovery because > it's >> usually multi-hop. But then Section 3 mentions several exceptions, > which >> apparently need to be administratively configured away from the > defaults. >> Failing to do this when needed results in security risks in either > case: either >> GTSM isn't deployed when it should be and the router is inadvertently > open >> to spoofing, or GTSM is deployed when it shouldn't be and this results > in an >> availability issue because LDP packets will be dropped before reaching > the >> LDP peer. This should be stated in the Security Considerations. >> >> Brian >> >> >> >> >> > -- Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From new-work-bounces@ietf.org Fri Jun 1 12:15:39 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB65311E80AD; Fri, 1 Jun 2012 12:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1338578139; bh=waAUo+YrogEa0IVYGR7V4qkTEGgQ4TYHV+j0ctr5PoU=; h=From:Date:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=LFwCGnysH1JDLL+yzP44+cd6IAtiULGpchsVvghgp5TKqaAri5fQNovaH8aGAQcW1 ODw3X7qGVzwZUVHQgHYK+VpiGSfCC0dcs5/IEHOLZP3HKq5DHD8vSMlsnYEHzRJdHI mCh0rbttnjnYAzxug/S6F+3XSrRxSI0spd1+gBXo= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86E111E80AD for ; Fri, 1 Jun 2012 12:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 2GnK6sFR6zMs for ; Fri, 1 Jun 2012 12:15:38 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 4C34B11E80A4 for ; Fri, 1 Jun 2012 12:15:38 -0700 (PDT) Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1SaXJx-0006Bq-F6; Fri, 01 Jun 2012 15:15:37 -0400 From: Ian Jacobs Date: Fri, 1 Jun 2012 14:15:36 -0500 To: new-work@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 01 Jun 2012 14:37:41 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: XML Core Working Group (until 2012-06-29) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 19:15:39 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the XML Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the XML Core Working Group: http://www.w3.org/XML/2012/05/xml-core-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2012-06-29 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Liam Quin, XML Activity Lead . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/XML/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From rajiva@cisco.com Fri Jun 1 13:37:38 2012 Return-Path: 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 8543611E8097; Fri, 1 Jun 2012 13:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 aLax1XVuwyAw; Fri, 1 Jun 2012 13:37:37 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDF611E808A; Fri, 1 Jun 2012 13:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3059; q=dns/txt; s=iport; t=1338583057; x=1339792657; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=bHw3hzN2M2U2tmEqIjqS4Oz5X5Q6MFOI5pPe+EPri5E=; b=Q46K3Wq7PHIOx7WJPEjED5Lm7TwaNrr0PS8ldZQtdSzpL1r+olQe0trb DP/zv8fq1NaG/QCT8W8wgWS5HwIPyvlmaLN9Z6vNQuPPKhgEXSJ0mkh4X dvXcw4KfI30W8pLsDXZmbRKKVTprBZ3m7p1U1KtxL7H0QnUKw8tAxxix2 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJ4nyU+tJXHB/2dsb2JhbABFtD+BB4IYAQEBBBIBHQo/DAQCAQgRBAEBCwYYBgFOCAEBBAESCBMHh2mYJJ9giw+FFWADiECaaIFmgn4 X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="88586209" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 01 Jun 2012 20:37:37 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q51KbavQ017984; Fri, 1 Jun 2012 20:37:37 GMT Received: from xmb-rcd-212.cisco.com ([72.163.62.219]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jun 2012 15:37:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jun 2012 15:37:35 -0500 Message-ID: In-Reply-To: <714A20F7-D17E-46A9-9145-1BB07BED3326@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secdir review of draft-ietf-mpls-ldp-gtsm-07 Thread-Index: Ac1AIqiWSKJ2uH5WSvSwmdbsLclYvwABVedA References: <714A20F7-D17E-46A9-9145-1BB07BED3326@cisco.com> From: "Rajiv Asati (rajiva)" To: "Brian Weis (bew)" , , "The IESG" X-OriginalArrivalTime: 01 Jun 2012 20:37:36.0509 (UTC) FILETIME=[611992D0:01CD4036] X-Mailman-Approved-At: Fri, 01 Jun 2012 14:37:41 -0700 Cc: draft-ietf-mpls-ldp-gtsm.all@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-mpls-ldp-gtsm-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 20:37:38 -0000 Hi Brian, Really appreciate your critical review and suggestions.=20 I agree to your both of your suggestions, and would propose the following text for us to include in the next revision. // As discussed in section 3, it is possible that=20 - GTSM for LDP may not always be enforced on a single-hop LDP peering session and may still be susceptible to forged/spoofed protocol packets, if the single-hop LDP peering session is set up using Extended Discovery.=20 - GTSM for LDP may cause LDP peering session to not get established (or torn down), if IP routing ever declares that the directly connected peer is more than one hop away. Suffice to say, use of cryptographic integrity (e.g., RFC 5925) is recommended as an alternate solution for detecting forged protocol packets (especially for the multi-hop case). // Cheers, Rajiv > -----Original Message----- > From: Brian Weis (bew) > Sent: Friday, June 01, 2012 2:16 PM > To: secdir@ietf.org; The IESG > Cc: draft-ietf-mpls-ldp-gtsm.all@tools.ietf.org > Subject: Secdir review of draft-ietf-mpls-ldp-gtsm-07 >=20 > 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. >=20 > This document applies the Generalized TTL Security Mechanism (GTSM) > mechanism defined in RFC 5082. This mechanism is used by routing > protocols as a low-cost non-cryptographic method intended to frustrate off- > path attackers. It is applicable when the peer is known to be connected by a > single hop. >=20 > The security considerations of this draft mostly point to RFC 5082's > extensive security considerations section, which is appropriate. However > because this I-D discusses multi-hop cases in greater detail it would be > appropriate for the security considerations section to also discuss multi-hop > a bit more. Here are some thoughts for that: >=20 > 1) Use of cryptographic integrity (e.g., RFC 5925) should be recommended as > an alternate solution for detecting forged protocol packets in the multi-hop > case. >=20 > 2) GTSM is expected to be enabled by default for Basic Discovery because > it's usually a single-hop, and disabled for Extended Discovery because it's > usually multi-hop. But then Section 3 mentions several exceptions, which > apparently need to be administratively configured away from the defaults. > Failing to do this when needed results in security risks in either case: either > GTSM isn't deployed when it should be and the router is inadvertently open > to spoofing, or GTSM is deployed when it shouldn't be and this results in an > availability issue because LDP packets will be dropped before reaching the > LDP peer. This should be stated in the Security Considerations. >=20 > Brian >=20 >=20 >=20 >=20 >=20 From rajiva@cisco.com Fri Jun 1 14:28:31 2012 Return-Path: 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 276F411E80BC; Fri, 1 Jun 2012 14:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 HgA7R4amYepY; Fri, 1 Jun 2012 14:28:30 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADC311E8081; Fri, 1 Jun 2012 14:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=4095; q=dns/txt; s=iport; t=1338586110; x=1339795710; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=i4OQbhQb0LjGkKnvYAORZGqDd2dCAd0q192DUPKzYcg=; b=M+ira3TT/Z71kz5wSFkRRN9PFfCUw0gBh40HdDvHj4Zer5U+Celipo5n bC/qV3bN3lOS/VZVATnuIwQ21hkSKn3ilhKan2CFcMDQyxfO46DIRVOdG GWe/KreG1wPlSYPlD3PWPFu3vq5mgCFrpmZ78f++sxBCMmyu4X6G5mXHM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMIzyU+tJXG9/2dsb2JhbABCA7RAgQeCGAEBAQMBEgEdCj8MBAIBCBEEAQEBCgYYBgFOCAEBBBMIEweHZAWYLp9giw+CWoI7YAOIQJpogWaCfoFB X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="88809790" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 01 Jun 2012 21:28:30 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q51LSTWJ031259; Fri, 1 Jun 2012 21:28:29 GMT Received: from xmb-rcd-212.cisco.com ([72.163.62.219]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jun 2012 16:28:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jun 2012 16:28:28 -0500 Message-ID: In-Reply-To: <2A2DAC2C-34CB-4D9B-84E0-34BCE799C1FC@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secdir review of draft-ietf-mpls-ldp-gtsm-07 Thread-Index: Ac1AOwwwqF3cFGWuS3q6UEKAL1EM5wAAe0cw References: <714A20F7-D17E-46A9-9145-1BB07BED3326@cisco.com> <2A2DAC2C-34CB-4D9B-84E0-34BCE799C1FC@cisco.com> From: "Rajiv Asati (rajiva)" To: "Brian Weis (bew)" X-OriginalArrivalTime: 01 Jun 2012 21:28:29.0407 (UTC) FILETIME=[7CC4D6F0:01CD403D] X-Mailman-Approved-At: Fri, 01 Jun 2012 14:37:41 -0700 Cc: draft-ietf-mpls-ldp-gtsm.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-mpls-ldp-gtsm-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 21:28:31 -0000 Hi Brian, Thanks. Will work with my co-author to get the next version submitted. Cheers, Rajiv > -----Original Message----- > From: Brian Weis (bew) > Sent: Friday, June 01, 2012 5:11 PM > To: Rajiv Asati (rajiva) > Cc: secdir@ietf.org; The IESG; draft-ietf-mpls-ldp-gtsm.all@tools.ietf.org > Subject: Re: Secdir review of draft-ietf-mpls-ldp-gtsm-07 >=20 > Hi Rajiv, >=20 > Your proposed text looks good to me. I think it's good to go with this added. >=20 > Thanks, > Brian >=20 >=20 > On Jun 1, 2012, at 1:37 PM, Rajiv Asati (rajiva) wrote: >=20 > > Hi Brian, > > > > Really appreciate your critical review and suggestions. > > > > I agree to your both of your suggestions, and would propose the > > following text for us to include in the next revision. > > > > > > // > > As discussed in section 3, it is possible that > > - GTSM for LDP may not always be enforced on a single-hop LDP peering > > session and may still be susceptible to forged/spoofed protocol > > packets, if the single-hop LDP peering session is set up using > > Extended Discovery. > > - GTSM for LDP may cause LDP peering session to not get established > > (or torn down), if IP routing ever declares that the directly > > connected peer is more than one hop away. > > Suffice to say, use of cryptographic integrity (e.g., RFC 5925) is > > recommended as an alternate solution for detecting forged protocol > > packets (especially for the multi-hop case). > > // > > > > Cheers, > > Rajiv > > > > > >> -----Original Message----- > >> From: Brian Weis (bew) > >> Sent: Friday, June 01, 2012 2:16 PM > >> To: secdir@ietf.org; The IESG > >> Cc: draft-ietf-mpls-ldp-gtsm.all@tools.ietf.org > >> Subject: Secdir review of draft-ietf-mpls-ldp-gtsm-07 > >> > >> 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 applies the Generalized TTL Security Mechanism (GTSM) > >> mechanism defined in RFC 5082. This mechanism is used by routing > >> protocols as a low-cost non-cryptographic method intended to > >> frustrate > > off- > >> path attackers. It is applicable when the peer is known to be > > connected by a > >> single hop. > >> > >> The security considerations of this draft mostly point to RFC 5082's > >> extensive security considerations section, which is appropriate. > > However > >> because this I-D discusses multi-hop cases in greater detail it would > > be > >> appropriate for the security considerations section to also discuss > > multi-hop > >> a bit more. Here are some thoughts for that: > >> > >> 1) Use of cryptographic integrity (e.g., RFC 5925) should be > > recommended as > >> an alternate solution for detecting forged protocol packets in the > > multi-hop > >> case. > >> > >> 2) GTSM is expected to be enabled by default for Basic Discovery > > because > >> it's usually a single-hop, and disabled for Extended Discovery > >> because > > it's > >> usually multi-hop. But then Section 3 mentions several exceptions, > > which > >> apparently need to be administratively configured away from the > > defaults. > >> Failing to do this when needed results in security risks in either > > case: either > >> GTSM isn't deployed when it should be and the router is inadvertently > > open > >> to spoofing, or GTSM is deployed when it shouldn't be and this > >> results > > in an > >> availability issue because LDP packets will be dropped before > >> reaching > > the > >> LDP peer. This should be stated in the Security Considerations. > >> > >> Brian > >> > >> > >> > >> > >> > > >=20 >=20 > -- > Brian Weis > Security Standards and Technology, SRTG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com >=20 >=20 >=20 >=20 From cpignata@cisco.com Sat Jun 2 09:23:39 2012 Return-Path: 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 C477521F85A2; Sat, 2 Jun 2012 09:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.538 X-Spam-Level: X-Spam-Status: No, score=-110.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Qm8TCdFJqcpg; Sat, 2 Jun 2012 09:23:39 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C6D0621F8468; Sat, 2 Jun 2012 09:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=4877; q=dns/txt; s=iport; t=1338654218; x=1339863818; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=ZwVnC1BuX/fpZ1jv2ofV+0JcSBs5vCGezFgMMs40Q/Q=; b=HfjQxLVFS+YbMFW7H+sOdT2DgDZ94bKyCsOKLdWR/PCzoXW4DG1T3Tgv kBezXsZBiEUYHezAUaU5yA5jh5nRK3cNkaf6UzVNeel6U6XoM8/CNHl1k KX3jryYMiZxyEjPFSDetv9tyxzwnw27H9PsS5F+Ua70KZmoyr5mPUFxXW w=; X-Files: signature.asc : 203 X-IronPort-AV: E=Sophos;i="4.75,703,1330905600"; d="asc'?scan'208";a="88956832" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 02 Jun 2012 16:23:38 +0000 Received: from rtp-cpignata-8919.cisco.com (rtp-cpignata-8919.cisco.com [10.117.115.58]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q52GNbr2022783; Sat, 2 Jun 2012 16:23:38 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_28C41DC6-B413-44AD-8B7C-25F09502D6A7"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Carlos Pignataro In-Reply-To: <2A2DAC2C-34CB-4D9B-84E0-34BCE799C1FC@cisco.com> Date: Sat, 2 Jun 2012 12:23:37 -0400 Message-Id: <35194C26-E381-4F8C-94E7-D81BB8B4D6BB@cisco.com> References: <714A20F7-D17E-46A9-9145-1BB07BED3326@cisco.com> <2A2DAC2C-34CB-4D9B-84E0-34BCE799C1FC@cisco.com> To: Brian Weis X-Mailer: Apple Mail (2.1278) Cc: secdir@ietf.org, draft-ietf-mpls-ldp-gtsm.all@tools.ietf.org, The IESG , "Rajiv Asati \(rajiva\)" Subject: Re: [secdir] Secdir review of draft-ietf-mpls-ldp-gtsm-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 16:23:39 -0000 --Apple-Mail=_28C41DC6-B413-44AD-8B7C-25F09502D6A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Brian, Many thanks for your review. The document already talks about these two cases, and also already = discusses that multi-hop is out of scope; however I agree with you that = highlighting this in the Security Considerations adds to completeness, = and also like Rajiv's text. I just posted a new rev that I believe addresses these (basically = Rajiv's text modulo minor edits). Thanks! -- Carlos. On Jun 1, 2012, at 5:11 PM, Brian Weis wrote: > Hi Rajiv, >=20 > Your proposed text looks good to me. I think it's good to go with this = added. >=20 > Thanks, > Brian >=20 >=20 > On Jun 1, 2012, at 1:37 PM, Rajiv Asati (rajiva) wrote: >=20 >> Hi Brian, >>=20 >> Really appreciate your critical review and suggestions.=20 >>=20 >> I agree to your both of your suggestions, and would propose the >> following text for us to include in the next revision. >>=20 >>=20 >> // >> As discussed in section 3, it is possible that=20 >> - GTSM for LDP may not always be enforced on a single-hop LDP peering >> session and may still be susceptible to forged/spoofed protocol = packets, >> if the single-hop LDP peering session is set up using Extended >> Discovery.=20 >> - GTSM for LDP may cause LDP peering session to not get established = (or >> torn down), if IP routing ever declares that the directly connected = peer >> is more than one hop away. >> Suffice to say, use of cryptographic integrity (e.g., RFC 5925) is >> recommended as an alternate solution for detecting forged protocol >> packets (especially for the multi-hop case). >> // >>=20 >> Cheers, >> Rajiv >>=20 >>=20 >>> -----Original Message----- >>> From: Brian Weis (bew) >>> Sent: Friday, June 01, 2012 2:16 PM >>> To: secdir@ietf.org; The IESG >>> Cc: draft-ietf-mpls-ldp-gtsm.all@tools.ietf.org >>> Subject: Secdir review of draft-ietf-mpls-ldp-gtsm-07 >>>=20 >>> 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. >>>=20 >>> This document applies the Generalized TTL Security Mechanism (GTSM) >>> mechanism defined in RFC 5082. This mechanism is used by routing >>> protocols as a low-cost non-cryptographic method intended to = frustrate >> off- >>> path attackers. It is applicable when the peer is known to be >> connected by a >>> single hop. >>>=20 >>> The security considerations of this draft mostly point to RFC 5082's >>> extensive security considerations section, which is appropriate. >> However >>> because this I-D discusses multi-hop cases in greater detail it = would >> be >>> appropriate for the security considerations section to also discuss >> multi-hop >>> a bit more. Here are some thoughts for that: >>>=20 >>> 1) Use of cryptographic integrity (e.g., RFC 5925) should be >> recommended as >>> an alternate solution for detecting forged protocol packets in the >> multi-hop >>> case. >>>=20 >>> 2) GTSM is expected to be enabled by default for Basic Discovery >> because >>> it's usually a single-hop, and disabled for Extended Discovery = because >> it's >>> usually multi-hop. But then Section 3 mentions several exceptions, >> which >>> apparently need to be administratively configured away from the >> defaults. >>> Failing to do this when needed results in security risks in either >> case: either >>> GTSM isn't deployed when it should be and the router is = inadvertently >> open >>> to spoofing, or GTSM is deployed when it shouldn't be and this = results >> in an >>> availability issue because LDP packets will be dropped before = reaching >> the >>> LDP peer. This should be stated in the Security Considerations. >>>=20 >>> Brian >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 > --=20 > Brian Weis > Security Standards and Technology, SRTG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_28C41DC6-B413-44AD-8B7C-25F09502D6A7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAk/KPgkACgkQtfDPGTp3USxvbACffhVdfuB5GyGhRpGm87gQ7CSL hcUAoM00rFaDQjslVzwtFnw0Vqi2mOwG =wggm -----END PGP SIGNATURE----- --Apple-Mail=_28C41DC6-B413-44AD-8B7C-25F09502D6A7-- From michael.scharf@alcatel-lucent.com Mon Jun 4 07:20:31 2012 Return-Path: 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 483E021F887D; Mon, 4 Jun 2012 07:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.782 X-Spam-Level: X-Spam-Status: No, score=-9.782 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_SUB_6CONS_WORD=0.356] 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 7cKNP1f6PLgk; Mon, 4 Jun 2012 07:20:30 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 67C4621F8864; Mon, 4 Jun 2012 07:20:30 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q54EKPXW024200 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Jun 2012 16:20:27 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 4 Jun 2012 16:19:32 +0200 From: "Scharf, Michael (Michael)" To: David Borman Date: Mon, 4 Jun 2012 16:19:30 +0200 Thread-Topic: secdir review of draft-ietf-tcpm-tcpmss-04 Thread-Index: AQHNPnXIPFIPS9owW0+7AUuNti9CaZbi+xyAgAAC+4CAAAs/AP//voCggAMfLYCABE8hoA== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E891A9BB408@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <4FC63731.7060409@cisco.com> <58B9B09F-ECA8-457E-B22C-34CE7A69CCFA@quantum.com> <2A886F9088894347A3BE0CC5B7A85F3E891A9BB37B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <94ADA294-87DB-488F-B784-A1FDCDF97A56@quantum.com> In-Reply-To: <94ADA294-87DB-488F-B784-A1FDCDF97A56@quantum.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 X-Mailman-Approved-At: Mon, 04 Jun 2012 07:21:28 -0700 Cc: "" , The IESG , "" Subject: Re: [secdir] secdir review of draft-ietf-tcpm-tcpmss-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 14:20:31 -0000 > >> Ok, I'll move the content to section 5, and leave "Security=20 > >> Considerations" > >> empty, unless someone else objects to making that change. > >=20 > > Instead of an empty security considerations section, you=20 > could also add a sentence explaining that the document just=20 > clarifies what is mandated by RFC 1122, and that it thus does=20 > not result in new security issues. > >=20 > > According to the working group discussions and the WGLC=20 > feedback, TCPM is apparently not aware of any security issues=20 > with this draft, and I think that TCPM would be fine with=20 > mentioning this more explicitly. >=20 > Ok, how about: > This document clarifies how to determine what=20 > value should be used for the MSS option, and does > not introduce any new security concerns. For what it is worth, I think that this is indeed better than an empty sect= ion.=20 Michael= From jsalowey@cisco.com Mon Jun 4 11:56:14 2012 Return-Path: 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 DDC0F11E80B5; Mon, 4 Jun 2012 11:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 HIrPCOkRqgzR; Mon, 4 Jun 2012 11:56:14 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 756FA11E80B3; Mon, 4 Jun 2012 11:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=558; q=dns/txt; s=iport; t=1338836174; x=1340045774; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=0LY+ocL+9bhQ0o1AmqDIEg9pS5u/ioNeHfeoO4V5K3A=; b=br0Pcp/sSA2RlBm1QoFzaVuK0HJQkfHmKMYpplYc3yf0Epxzs8qcCpnz tkOI6nvY72cuPJnixctkFhlekRY4WergEHJnAnS6ymu8m/HVl+bmRKX06 u0wNfDxlqW/2fEn7CGsH9v6fGaYehbhbJ3vU9EquM5eNhkFL2byA4NK+I o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAK8EzU+rRDoI/2dsb2JhbABFgx2xEoEHgjEBJ4F9ATSHaJcmn0KQQWADiECMW4VQiECBZoMA X-IronPort-AV: E=Sophos;i="4.75,714,1330905600"; d="scan'208";a="45043366" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 04 Jun 2012 18:56:01 +0000 Received: from [10.33.248.203] ([10.33.248.203]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q54Iu0MD003845; Mon, 4 Jun 2012 18:56:00 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Jun 2012 11:56:00 -0700 Message-Id: <4BADD87A-4CF2-409C-A14E-9AC03165E179@cisco.com> To: The IESG , secdir@ietf.org, draft-kucherawy-marf-source-ports.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [secdir] Secdir Review of draft-kucherawy-marf-source-ports-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 18:56:15 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document adds source port information to Abuse Reporting Format. = This seems useful. The security considerations refer to RFC 5965 (ARF) = and RFC 6302, which seems sufficient. =20 Thanks, Joe From mlepinski@bbn.com Mon Jun 4 20:49:26 2012 Return-Path: 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 282CD11E812A; Mon, 4 Jun 2012 20:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 t-4hHNlqIbnJ; Mon, 4 Jun 2012 20:49:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2638911E80B4; Mon, 4 Jun 2012 20:49:25 -0700 (PDT) Received: from mail.bbn.com ([128.33.0.48]:55999) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SbklE-0000Di-IL; Mon, 04 Jun 2012 23:48:48 -0400 Received: from [128.89.255.35] by mail.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Sbkll-0008Ab-VI; Mon, 04 Jun 2012 23:49:22 -0400 Message-ID: <4FCD81E7.7050001@bbn.com> Date: Mon, 04 Jun 2012 23:49:59 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-mboned-64-multicast-address-format.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Secdir review of draft-ietf-mboned-64-multicast-address-format-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 03:49:26 -0000 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 specifies an embedding (for use by IPv4 to IPv6 translation devices) as an IPv4 multicast address within an IPv6 address. (This is a companion document to RFC 6052, which specifies an embedding for IPv4 unicast addresses.) The Security Considerations section claims that the relevant security considerations are identical to those in RFC 6052. (That is, the security considerations for translating IPv4 multicast addresses are the same as those for translating unicast addresses.) I believe this is essentially true. However, the first security consideration discussed in RFC 6052 is source address spoofing. Although quite relevant for unicast address translation, source address spoofing does not seem (to me) to be an issue for multicast addresses translation because multicast addresses are typically not used as source addresses for IP datagrams. In situations such as this where the authors wish to incorporate security considerations by reference, I think it is helpful to the reader to add a couple sentences explaining which considerations in the referenced document (i.e., RFC 6052) are relevant to the current draft. Minor editorial note: It would be helpful if you define the acronyms ASM and SSM in the terminology section. (As someone who doesn't frequently think about multicast, it wasn't immediately obvious to what these two acronyms referred.) From mohamed.boucadair@orange.com Mon Jun 4 23:29:33 2012 Return-Path: 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 D425E21F86D6; Mon, 4 Jun 2012 23:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 6++5P5O5VyRn; Mon, 4 Jun 2012 23:29:33 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 204AF21F86D5; Mon, 4 Jun 2012 23:29:32 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id A1B683B4156; Tue, 5 Jun 2012 08:29:31 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 841584C017; Tue, 5 Jun 2012 08:29:31 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Tue, 5 Jun 2012 08:29:31 +0200 From: To: Matt Lepinski , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-mboned-64-multicast-address-format.all@tools.ietf.org" Date: Tue, 5 Jun 2012 08:29:30 +0200 Thread-Topic: Secdir review of draft-ietf-mboned-64-multicast-address-format-01 Thread-Index: Ac1CzkENTLr/Xj4dTACCUYehRpgE3QAE5RQw Message-ID: <94C682931C08B048B7A8645303FDC9F36E32ED1577@PUEXCB1B.nanterre.francetelecom.fr> References: <4FCD81E7.7050001@bbn.com> In-Reply-To: <4FCD81E7.7050001@bbn.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.5.55415 Subject: Re: [secdir] Secdir review of draft-ietf-mboned-64-multicast-address-format-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 06:29:34 -0000 Dear Matt, Thank you for the review.=20 Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : Matt Lepinski [mailto:mlepinski@bbn.com]=20 >Envoy=E9 : mardi 5 juin 2012 05:50 >=C0 : secdir@ietf.org; iesg@ietf.org;=20 >draft-ietf-mboned-64-multicast-address-format.all@tools.ietf.org >Objet : Secdir review of=20 >draft-ietf-mboned-64-multicast-address-format-01 > >I have reviewed this document as part of the security=20 >directorate's ongoing effort to review all IETF documents=20 >being processed by the IESG. These comments were written=20 >primarily for the benefit of the security area directors.=20 >Document editors and WG chairs should treat these comments=20 >just like any other last call comments. > >This document specifies an embedding (for use by IPv4 to IPv6=20 >translation devices) as an IPv4 multicast address within an=20 >IPv6 address. (This is a companion document to RFC 6052, which=20 >specifies an embedding for IPv4 unicast addresses.) > >The Security Considerations section claims that the relevant=20 >security considerations are identical to those in RFC 6052.=20 >(That is, the security considerations for translating IPv4=20 >multicast addresses are the same as those for translating=20 >unicast addresses.) I believe this is essentially true. > >However, the first security consideration discussed in RFC=20 >6052 is source address spoofing. Although quite relevant for=20 >unicast address translation, source address spoofing does not=20 >seem (to me) to be an issue for multicast addresses=20 >translation because multicast addresses are typically not used=20 >as source addresses for IP datagrams.=20 Med: address spoofing may also be harmful in multicast context (e.g., send = illegitimate PIM register messages). In situations such as=20 >this where the authors wish to incorporate security=20 >considerations by reference, I think it is helpful to the=20 >reader to add a couple sentences explaining which=20 >considerations in the referenced document (i.e., RFC 6052) are=20 >relevant to the current draft. Med: I personally think all items discussed in RFC6052 are still valid for = this draft. Do you think there is a need to modify the text?=20 > >Minor editorial note: >It would be helpful if you define the acronyms ASM and SSM in=20 >the terminology section. (As someone who doesn't frequently=20 >think about multicast, it wasn't immediately obvious to what=20 >these two acronyms referred.) Med: I fixed it in -02. See the diff available at: http://tools.ietf.org/rf= cdiff?url2=3Ddraft-ietf-mboned-64-multicast-address-format-02.txt From daedulus@btconnect.com Fri Jun 8 03:41:16 2012 Return-Path: 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 2784E21F8517; Fri, 8 Jun 2012 03:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.909 X-Spam-Level: X-Spam-Status: No, score=-4.909 tagged_above=-999 required=5 tests=[AWL=-1.090, BAYES_05=-1.11, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] 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 FQ74aMi2uo6h; Fri, 8 Jun 2012 03:41:15 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA4A21F850F; Fri, 8 Jun 2012 03:41:15 -0700 (PDT) Received: from mail11-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Jun 2012 10:40:24 +0000 Received: from mail11-tx2 (localhost [127.0.0.1]) by mail11-tx2-R.bigfish.com (Postfix) with ESMTP id 8589532053E; Fri, 8 Jun 2012 10:40:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT011.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz9371I542M1418Izz1202hzz1033IL8275dhz2dh2a8h5a9h668h839h93fhd24hf0ah304l) Received: from mail11-tx2 (localhost.localdomain [127.0.0.1]) by mail11-tx2 (MessageSwitch) id 1339152022770248_2063; Fri, 8 Jun 2012 10:40:22 +0000 (UTC) Received: from TX2EHSMHS009.bigfish.com (unknown [10.9.14.248]) by mail11-tx2.bigfish.com (Postfix) with ESMTP id B5784200046; Fri, 8 Jun 2012 10:40:22 +0000 (UTC) Received: from DB3PRD0702HT011.eurprd07.prod.outlook.com (157.55.224.141) by TX2EHSMHS009.bigfish.com (10.9.99.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Jun 2012 10:40:20 +0000 Received: from DBXPRD0610HT004.eurprd06.prod.outlook.com (157.56.252.181) by pod51017.outlook.com (10.3.48.170) with Microsoft SMTP Server (TLS) id 14.15.74.2; Fri, 8 Jun 2012 10:40:42 +0000 Message-ID: <004a01cd4562$b7b338e0$4001a8c0@gateway.2wire.net> From: t.p. References: <21762_1337814743_q4NNCMPh008981_alpine.BSF.2.00.1205231837020.9762@fledge.watson.org> <1337881837.3279.45.camel@destiny.pc.cs.cmu.edu> Date: Fri, 8 Jun 2012 11:37:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] X-OriginatorOrg: btconnect.com X-Mailman-Approved-At: Fri, 08 Jun 2012 05:36:59 -0700 Cc: draft-sakane-dhc-dhcpv6-kdc-option@tools.ietf.org, ietf , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 10:41:16 -0000 Just to make public what I have hinted at privately, I think that steps in section 4.1 may be somewhat underspecified. They give the logic a client, one which supports both DHCP and DNS, should follow in order to find a KDC, with DNS information being preferred. One scenario outlined in section 1 is of a user having entered userid and passphrase and waiting to be authenticated. The steps imply a number of timeouts in succession without specifying what balance to take of how long to wait for a server to respond versus how long to keep the user waiting. I would find it difficult to know what balance to strike without guidance. A related issue is that section 4.1 prefers DNS to DHCP for Kerberos information but the Security Considerations stress the weakness of DHCP and recommend authenticating DHCP. What if DHCP is secure and DNS is not? Should DNS still be preferred? Tom Petch ----- Original Message ----- From: "Jeffrey Hutzelman" To: "Samuel Weiler" Cc: ; ; ; Sent: Thursday, May 24, 2012 6:50 PM Subject: Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option From tglassey@earthlink.net Fri Jun 8 07:23:48 2012 Return-Path: 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 7E28821F8803; Fri, 8 Jun 2012 07:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 xfyrMR9EzgUt; Fri, 8 Jun 2012 07:23:47 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 81FA621F8759; Fri, 8 Jun 2012 07:23:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=g+9RJjk8v1WshDBWR/RmEL7fB0h3k7wKbDSLXkt3k4fMsECeXPtJjpnRGebJ2jxP; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.21] (helo=[192.168.15.2]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Sd06E-0007lj-GJ; Fri, 08 Jun 2012 10:23:38 -0400 Message-ID: <4FD20AE5.5060503@earthlink.net> Date: Fri, 08 Jun 2012 07:23:33 -0700 From: tglassey User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "t.p." References: <21762_1337814743_q4NNCMPh008981_alpine.BSF.2.00.1205231837020.9762@fledge.watson.org> <1337881837.3279.45.camel@destiny.pc.cs.cmu.edu> <004a01cd4562$b7b338e0$4001a8c0@gateway.2wire.net> In-Reply-To: <004a01cd4562$b7b338e0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec790ed8a6a3d1ea84abb910e2a94da62c8d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.21 X-Mailman-Approved-At: Fri, 08 Jun 2012 08:15:52 -0700 Cc: draft-sakane-dhc-dhcpv6-kdc-option@tools.ietf.org, ietf , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 14:23:48 -0000 On 6/8/2012 3:37 AM, t.p. wrote: > Just to make public what I have hinted at privately, I think that steps > in section 4.1 may be somewhat underspecified. > > They give the logic a client, one which supports both DHCP and DNS, > should > follow in order to find a KDC, with DNS information being preferred. Yes, this is because the DNS auth models are better than DHCP today AFAIK. > One scenario outlined in section 1 is of a user having entered userid > and > passphrase and waiting to be authenticated. The steps imply a number of > timeouts in succession without specifying what balance to take of how > long > to wait for a server to respond versus how long to keep the user > waiting. True but this is likely to be set in the client as a flat config value one would think. And if so this is actually a good thing you bring up Tom. My take is that from a policy management standpoint the timeout period should be a "policy level" control IMHO and should have both a default value and a method of overriding it to allow people when they need to to create a more "synchronous" expectation from a responder. > I would find it difficult to know what balance to strike without > guidance. > > A related issue is that section 4.1 prefers DNS to DHCP for Kerberos > information but the Security Considerations stress the weakness of > DHCP and recommend authenticating DHCP. What if DHCP is secure > and DNS is not? Should DNS still be preferred? DNSSEC is clearly beyond DHCP security models so perhaps for a working system this makes sense unless you want to create an autonomous DNS client which can exist in a pre-boot model. Pardon my restating the obvious but "Still the issue is that DNS services dont work until they are loaded and DHCP is designed to work from a firmware boot (as we all know)". How does this fit into what NEA is supposed to provide as a baseline? > > Tom Petch > > ----- Original Message ----- > From: "Jeffrey Hutzelman" > To: "Samuel Weiler" > Cc:; > ;; > Sent: Thursday, May 24, 2012 6:50 PM > Subject: Re: [secdir] secdir review of > draft-sakane-dhc-dhcpv6-kdc-option > > > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.2178 / Virus Database: 2433/5055 - Release Date: 06/07/12 > > From daedulus@btconnect.com Fri Jun 8 07:27:32 2012 Return-Path: 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 E5AF021F8920; Fri, 8 Jun 2012 07:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.254 X-Spam-Level: X-Spam-Status: No, score=-4.254 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 TI7n1J8qt9aW; Fri, 8 Jun 2012 07:27:32 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id E7AFA21F8800; Fri, 8 Jun 2012 07:27:31 -0700 (PDT) Received: from mail26-am1-R.bigfish.com (10.3.201.239) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Jun 2012 14:26:39 +0000 Received: from mail26-am1 (localhost [127.0.0.1]) by mail26-am1-R.bigfish.com (Postfix) with ESMTP id BFAD64003F8; Fri, 8 Jun 2012 14:26:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT009.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: PS-28(zzbb2dI98dI9371I542M1dbaI1432I1418I4015Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah304l) Received: from mail26-am1 (localhost.localdomain [127.0.0.1]) by mail26-am1 (MessageSwitch) id 1339165597980755_20655; Fri, 8 Jun 2012 14:26:37 +0000 (UTC) Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.252]) by mail26-am1.bigfish.com (Postfix) with ESMTP id E33F8220049; Fri, 8 Jun 2012 14:26:37 +0000 (UTC) Received: from DB3PRD0702HT009.eurprd07.prod.outlook.com (157.55.224.141) by AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Jun 2012 14:26:36 +0000 Received: from DBXPRD0610HT005.eurprd06.prod.outlook.com (157.56.252.181) by pod51017.outlook.com (10.3.4.174) with Microsoft SMTP Server (TLS) id 14.15.74.2; Fri, 8 Jun 2012 14:27:26 +0000 Message-ID: <020601cd4582$63db64c0$4001a8c0@gateway.2wire.net> From: t.p. To: ssakane References: Date: Fri, 8 Jun 2012 15:24:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] X-OriginatorOrg: btconnect.com X-Mailman-Approved-At: Fri, 08 Jun 2012 08:15:52 -0700 Cc: draft-sakane-dhc-dhcpv6-kdc-option@tools.ietf.org, ietf , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 14:27:33 -0000 ----- Original Message ----- From: "ssakane" To: "t.p." Cc: ; ; "ietf" Sent: Friday, June 08, 2012 2:29 PM > Hi Tom, > > Some reviewers suggested me to just remove the figure and its description in > 4.1 because it has ambiguity. I think it would be better to leave the 1st > paragraph in section 4.1, and I should remove the rest. What do you think > about this idea ? I would leave it in. The first paragraph on its own I would think underspecified and the rest of the section does cover a number of issues, issues that only occurred to me when I read the section carefully. As I said in my last post, I then found I had further issues - how long to wait, should a secure DHCP trump an insecure DNS? - which may be worth exploring in addition. I do think that this kind of pseudocode helps a lot of developers to understand the issues and would want a good reason to remove it; at the same time, others see it as an impurity that has no part in a Standards Track RFC. One option would be to remove it to an Appendix which implicitly makes it Informative and not Normative so it is there for those who would benefit from it but will not upset those who consider it out of place. But I would bounce this off the krb list to see what reaction you get. Tom Petch > Thanks, > Shoichi > > On 6/8/12 7:37 PM, "t.p." wrote: > > > Just to make public what I have hinted at privately, I think that steps > > in section 4.1 may be somewhat underspecified. > > > > They give the logic a client, one which supports both DHCP and DNS, > > should > > follow in order to find a KDC, with DNS information being preferred. > > One scenario outlined in section 1 is of a user having entered userid > > and > > passphrase and waiting to be authenticated. The steps imply a number of > > timeouts in succession without specifying what balance to take of how > > long > > to wait for a server to respond versus how long to keep the user > > waiting. > > I would find it difficult to know what balance to strike without > > guidance. > > > > A related issue is that section 4.1 prefers DNS to DHCP for Kerberos > > information but the Security Considerations stress the weakness of > > DHCP and recommend authenticating DHCP. What if DHCP is secure > > and DNS is not? Should DNS still be preferred? > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Jeffrey Hutzelman" > > To: "Samuel Weiler" > > Cc: ; > > ; ; > > Sent: Thursday, May 24, 2012 6:50 PM > > Subject: Re: [secdir] secdir review of > > draft-sakane-dhc-dhcpv6-kdc-option > > > > > > > > From daedulus@btconnect.com Sun Jun 10 00:20:36 2012 Return-Path: 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 6B01A21F8627; Sun, 10 Jun 2012 00:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] 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 v2KO6Rc6vH-i; Sun, 10 Jun 2012 00:20:34 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8F57C21F8621; Sun, 10 Jun 2012 00:20:31 -0700 (PDT) Received: from mail176-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Sun, 10 Jun 2012 07:19:35 +0000 Received: from mail176-tx2 (localhost [127.0.0.1]) by mail176-tx2-R.bigfish.com (Postfix) with ESMTP id 5535B40132; Sun, 10 Jun 2012 07:19:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT008.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: PS-27(zzbb2dI98dI9371I542M1432I1418I4015Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah304l) Received: from mail176-tx2 (localhost.localdomain [127.0.0.1]) by mail176-tx2 (MessageSwitch) id 1339312773294535_4105; Sun, 10 Jun 2012 07:19:33 +0000 (UTC) Received: from TX2EHSMHS018.bigfish.com (unknown [10.9.14.240]) by mail176-tx2.bigfish.com (Postfix) with ESMTP id 44E7D100047; Sun, 10 Jun 2012 07:19:33 +0000 (UTC) Received: from DB3PRD0702HT008.eurprd07.prod.outlook.com (157.55.224.141) by TX2EHSMHS018.bigfish.com (10.9.99.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 10 Jun 2012 07:19:31 +0000 Received: from BL2PRD0710HT002.namprd07.prod.outlook.com (157.56.240.133) by pod51017.outlook.com (10.3.4.173) with Microsoft SMTP Server (TLS) id 14.15.74.2; Sun, 10 Jun 2012 07:20:25 +0000 Message-ID: <005001cd46d9$10928de0$4001a8c0@gateway.2wire.net> From: t.p. To: ssakane References: Date: Sun, 10 Jun 2012 08:17:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.240.133] X-OriginatorOrg: btconnect.com X-Mailman-Approved-At: Sun, 10 Jun 2012 16:04:44 -0700 Cc: draft-sakane-dhc-dhcpv6-kdc-option@tools.ietf.org, ietf , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 07:20:36 -0000 ---- Original Message ----- From: "ssakane" To: "t.p." Cc: ; ; "ietf" Sent: Saturday, June 09, 2012 1:55 AM > Removing the section 4.1 to an Appendix is nicer idea rather than just > deleting it. Yes, but for me it is definitely second best. Arguably, following the steps in s 4.1 is necessary for interoperability. If DNS and DHCP produce the same KDC information, who cares what procedure is followed? It is only when they produce different results that the procedure matters. The dictum is that DNS information is preferred to DHCP information, but as the procedure shows, it is not quite that simple. It specifies that DNS is accessed via DHCP, ie DNS is only accessed if DHCP provides information about it. Without this guidance, an implementer might assume that eg preconfigured DNS information should be used to access DNS for KDC information rather than first asking DHCP for what it knows, in which case such an implementer would follow a different path to, potentially, a different KDC. So the client uses one KDC, the application server a different KDC; result, protocol failure. So you could see s 4.1 as necessary for the protocol to work. And again, as I said before, s 4.1 says that DNS SHOULD be used, while the Security Considerations say DHCP SHOULD be secured so given secure DHCP and insecure DNS giving different results, which SHOULD wins? Tom Petch > > Shoichi > > > On 6/8/12 11:24 PM, "t.p." wrote: > > > ----- Original Message ----- > > From: "ssakane" > > To: "t.p." > > Cc: ; > > ; "ietf" > > Sent: Friday, June 08, 2012 2:29 PM > >> Hi Tom, > >> > >> Some reviewers suggested me to just remove the figure and its > > description in > >> 4.1 because it has ambiguity. I think it would be better to leave the > > 1st > >> paragraph in section 4.1, and I should remove the rest. What do you > > think > >> about this idea ? > > > > I would leave it in. > > > > The first paragraph on its own I would think underspecified and the rest > > of the section does cover a number of issues, issues that only occurred > > to me when I read the section carefully. As I said in my last post, I > > then found I had further issues - how long to wait, should a secure DHCP > > trump an insecure DNS? - which may be worth exploring in addition. > > > > I do think that this kind of pseudocode helps a lot of developers to > > understand the issues and would want a good reason to remove it; at the > > same time, others see it as an impurity that has no part in a Standards > > Track RFC. One option would be to remove it to an Appendix which > > implicitly makes it Informative and not Normative so it is there for > > those who would benefit from it but will not upset those who consider it > > out of place. But I would bounce this off the krb list to see what > > reaction you get. > > > > Tom Petch > > > >> Thanks, > >> Shoichi > >> > >> On 6/8/12 7:37 PM, "t.p." wrote: > >> > >>> Just to make public what I have hinted at privately, I think that > > steps > >>> in section 4.1 may be somewhat underspecified. > >>> > >>> They give the logic a client, one which supports both DHCP and DNS, > >>> should > >>> follow in order to find a KDC, with DNS information being preferred. > >>> One scenario outlined in section 1 is of a user having entered > > userid > >>> and > >>> passphrase and waiting to be authenticated. The steps imply a > > number of > >>> timeouts in succession without specifying what balance to take of > > how > >>> long > >>> to wait for a server to respond versus how long to keep the user > >>> waiting. > >>> I would find it difficult to know what balance to strike without > >>> guidance. > >>> > >>> A related issue is that section 4.1 prefers DNS to DHCP for Kerberos > >>> information but the Security Considerations stress the weakness of > >>> DHCP and recommend authenticating DHCP. What if DHCP is secure > >>> and DNS is not? Should DNS still be preferred? > >>> > >>> Tom Petch > >>> > >>> ----- Original Message ----- > >>> From: "Jeffrey Hutzelman" > >>> To: "Samuel Weiler" > >>> Cc: ; > >>> ; ; > >>> Sent: Thursday, May 24, 2012 6:50 PM > >>> Subject: Re: [secdir] secdir review of > >>> draft-sakane-dhc-dhcpv6-kdc-option > >>> > >>> > >>> > >> > >> > > > > > > From new-work-bounces@ietf.org Tue Jun 12 09:12:38 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9498421F85BD; Tue, 12 Jun 2012 09:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1339517558; bh=/PYax7+PicnHL607XnIPFklyNoXA19t5FisBWqseuAU=; h=MIME-Version:From:To:Message-ID:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=FZ5VjFaLajB4ZwHuJTSHr4X/8RFIwB1o/VPxuSydWOuTRhJOb2RM+GZ1ukySlS98b PUHFB25+Qfi7CWdGL4AhPDlDp31vAcdgRzO7eCEdEztnlY+ztuTVNi9E/a3qHO2haY 9tEYt7eP5dAFVcBM7VemhO6aZGpnhDIFOkX+8RvQ= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5519521F85BD; Tue, 12 Jun 2012 09:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 LDeAnnXo6wak; Tue, 12 Jun 2012 09:12:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5FA21F85AE; Tue, 12 Jun 2012 09:12:35 -0700 (PDT) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120612161235.1186.33451.idtracker@ietfa.amsl.com> Date: Tue, 12 Jun 2012 09:12:35 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 15 Jun 2012 08:04:51 -0700 Subject: [secdir] [new-work] WG Review: IMAP MOVE extension (imapmove) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 16:12:38 -0000 A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 19, 2012. IMAP MOVE extension (imapmove) ---------------------------- Status: Proposed Working Group Last updated 2012-06-02 Chair(s): TBD Applications Area Director(s): Pete Resnick Barry Leiba Mailing Lists: General Discussion: imapext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/imapext Archive: http://www.ietf.org/mail-archive/web/imapext/ Description of Working Group: The Internet Message Access Protocol (IMAP), defined in RFC 3501, specifies a protocol for transferring email messages between a server that implements a message store, and a client. It also includes commands for manipulating the message store -- creating, deleting, and renaming mailboxes, adding a message to a mailbox, and copying messages from one mailbox to another. It's often the case that an IMAP client needs to move (not copy) messages from one mailbox to another. The mechanism that IMAP provides to do that is a multi-step process: 1. Copy the messages from the source mailbox to the target mailbox. 2. Flag the original messages in the source mailbox as deleted. 3. Expunge the deleted messages from the source mailbox. Implementors have long pointed out some shortcomings with this approach. Because the moving of a message is not an atomic process, interruptions can leave messages in intermediate states. Because multiple clients can be accessing the mailboxes at the same time, clients can see messages in intermediate states even without interruptions. If the source mailbox contains other messages that are flagged for deletion, the third step can have the side effect of expunging more than just the set of moved messages. And servers with certain types of back-end message stores might have efficient ways of moving messages, which don't involve actual copying of data. Such efficiencies are often not available to the copy/flag/expunge process. The IMAP MOVE extension (imapmove) working group has the single task of developing an IMAP MOVE extension that defines a single command to move a set of messages from a source mailbox to a target mailbox in a single operation. The group will use draft-gulbrandsen-imap-move as a starting point, and will produce a Standards Track document. As part of the protocol development, implementation experience on both the client and server side is highly desireable, so that the actual operational value of this extension can be assessed. The working group will document the results of this experience on the working group wiki. No other IMAP extension work is in scope for this working group. Milestones 07/2012 Initial adoption of IMAP MOVE protocol document 07/2012 Establishment of implementation tracking on the working group wiki 08/2012 Initial assessment of implementation results 09/2012 Final report on implementation results 10/2012 IMAP MOVE protocol document to IESG as Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From weiler+secdir@watson.org Tue Jun 19 16:25:24 2012 Return-Path: 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 45D3A11E808C for ; Tue, 19 Jun 2012 16:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 cgSJx6q6va5g for ; Tue, 19 Jun 2012 16:25:23 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8D27211E808A for ; Tue, 19 Jun 2012 16:25:23 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.5/8.14.5) with ESMTP id q5JNPLGI021559 for ; Tue, 19 Jun 2012 19:25:21 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.5/8.14.5/Submit) with ESMTP id q5JNPLkN021555 for ; Tue, 19 Jun 2012 19:25:21 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 19 Jun 2012 19:25:21 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 19 Jun 2012 19:25:21 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 23:25:24 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview The last assignment message was several weeks ago. You haven't missed anything; secdir assignments just went on walkabout. There are twelve new assignments below as well as a few that have been lingering for some time. Steve Hanna is next in the rotation. For telechat 2012-06-21 Reviewer LC end Draft Tim Polk T 2012-06-04 draft-farrresnickel-ipr-sanctions-06 Vincent Roca T 2012-05-21 draft-ietf-appsawg-media-type-regs-11 For telechat 2012-07-05 Alan DeKok T - draft-ietf-xrblock-rtcp-xr-meas-identity-06 Last calls and special requests: Derek Atkins 2012-06-28 draft-ietf-bliss-shared-appearances-10 Rob Austein 2012-06-26 draft-ietf-bmwg-2544-as-03 Richard Barnes 2012-06-28 draft-ietf-ippm-twamp-value-added-octets-03 Dave Cridland 2012-06-28 draft-ietf-nfsv4-federated-fs-admin-10 Donald Eastlake - draft-zheng-mpls-ldp-hello-crypto-auth-04 Shawn Emery 2012-07-02 draft-melnikov-smtp-priority-tunneling-02 Tobias Gondrom 2012-06-29 draft-sandlund-rfc4996bis-02 Phillip Hallam-Baker 2012-07-11 draft-krishnan-nomcom-tools-01 Magnus Nystrom 2012-05-10 draft-ietf-codec-opus-14 Ondrej Sury 2012-05-31 draft-ietf-dnsext-dnssec-bis-updates-18 Nico Williams - draft-ietf-httpbis-p5-range-19 Nico Williams 2012-07-02 draft-farrell-decade-ni-07 Tom Yu - draft-ietf-httpbis-p6-cache-19 Tom Yu 2012-07-13 draft-hoffman-tao-as-web-page- Glen Zorn - draft-ietf-httpbis-p7-auth-19 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-15 From vincent.roca@inria.fr Wed Jun 20 11:23:37 2012 Return-Path: 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 EBC5421F865C; Wed, 20 Jun 2012 11:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.248 X-Spam-Level: X-Spam-Status: No, score=-110.248 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 26zPd8ql3kgY; Wed, 20 Jun 2012 11:23:36 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0E621F864D; Wed, 20 Jun 2012 11:23:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,445,1336341600"; d="scan'208";a="148277418" Received: from unknown (HELO [10.2.44.87]) ([78.250.170.247]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 20 Jun 2012 20:23:33 +0200 From: Vincent Roca Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 20 Jun 2012 20:23:32 +0200 Message-Id: <7E7DF206-410E-45AE-A21B-914D3184855D@inria.fr> To: The IESG , secdir@ietf.org, draft-ietf-appsawg-media-type-regs.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] Secdir review of draft-ietf-appsawg-media-type-regs-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 18:23:37 -0000 Hello, 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. The document inherits from RFC4288 most of its security considerations discussion (in 4.6) with a few improvements. It's excellent and I don't have any comment. Cheers, Vincent From new-work-bounces@ietf.org Tue Jun 26 09:22:57 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7174B21F8608; Tue, 26 Jun 2012 09:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340727777; bh=T3oAnfTUlBWZGae4FVsDxHJS2bNQKcafRRZCgedkQIU=; h=MIME-Version:From:To:Message-ID:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=orRHBeNNWhey5ww1eEkMSeEhYsyw/GFVDUqJbUNprZn35VzfokgF2ikmYScrx1vAu V420+Jtlp3+RZKZ9jeDjMtnE7JHKKleDck1Lgdz1RcRRiygU6RkDXA6yWs7IBzq4ZR eA2hnrDiLs/wqbH346FcA6IX7K+oPerIQXnAe4Ys= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A5C21F8609; Tue, 26 Jun 2012 09:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.238 X-Spam-Level: X-Spam-Status: No, score=-102.238 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, 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 TaF5W6J+Z0RI; Tue, 26 Jun 2012 09:22:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CBB21F8606; Tue, 26 Jun 2012 09:22:44 -0700 (PDT) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120626162244.16515.97970.idtracker@ietfa.amsl.com> Date: Tue, 26 Jun 2012 09:22:44 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 26 Jun 2012 09:27:49 -0700 Subject: [secdir] [new-work] WG Review: Sip Traversal Required for Applications to Work (straw) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 16:22:57 -0000 A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2012-07-03. Sip Traversal Required for Applications to Work (straw) ------------------------------------------------ Current Status: Proposed Working Group Assigned Area Director: Gonzalo Camarillo Charter of Working Group: Problem Statement: Within the context of the SIP protocol and architecture, a Back-to-Back User Agent (B2BUA) is any SIP device in the logical path between two User Agents performing a role beyond that of a Proxy as defined in RFC 3261. The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA in order to terminate dead sessions by generating BYEs; or it may be a 3PCC-style agent only modifying SDP; or it may be a Session Border Controller performing such functions as in RFC 5853; or it may be an Enterprise PBX terminating REFERs and such; or it may be a complete UAS and UAC implementation with a PRI (Primary Rate Interface) loopback in-between. In its most extreme form, the scope of the SIP protocol ends at the UAS of the B2BUA, and a new SIP protocol scope begins on its UAC side. In practice, however, users expect some SIP protocol aspects to go beyond the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as if the B2BUA was not an end unto itself; this is similar to the expectation that emails work when they cross from POP and IMAP to/from SMTP. It is impossible to normatively define all the behaviors of B2BUAs in general, or even subsets of them such as SBCs (Session Border Controlers)or PBXs (Private Branch Exchanges). Unlike consumer NATs, B2BUAs perform widely varying functions for purposes which may be unique to their environment, unique to their architecture, or unique to the wishes of their administrator. Instead of defining all things a given type of B2BUA must do, a more practical objective would be to define what very few things any B2BUA must do to make a specific SIP mechanism work, and let the market decide whether to do those things. The name of this working group reflects that practical objective: if there were a thin straw between the SIP UAS and UAC of a B2BUA, what must be passed through that straw and used on each side. Or viewed another way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback circuit, and if we could extend ISDN, what information would we carry in ISDN across the PRI for a specific SIP mechanism to work end-to-end. For example, the WG could produce a document which specifies that the Max-Forwards header field value should be copied and decremented across the B2BUA, if the B2BUA wishes to prevent infinite loops. Administrators could then tell their B2BUA vendors to comply with the document, if the administrator so wishes. Objectives: The objectives of the STRAW Working Group are to publish normative documents which define which SIP header fields, parameters, MIME bodies, body content fields/information, or media-plane characteristics are required to traverse between the User Agent "sides" of a B2BUA for specific functions to work. The specific functions covered are expected to relate to already-published RFCs or existing RAI area work, as opposed to all future IETF work. In other words, the Working Group is not meant to be a never-ending source for B2BUA requirements in the RAI area. Deliverables would indicate which types of B2BUAs would apply or not. For example, a document defining the requirements for end-to-end DTLS-SRTP would not apply to B2BUAs which terminate media, such as transcoders or recorders. Milestones: Dec 2012 - A taxonomy document defining role-types of B2BUAs, as a reference for other deliverables submitted to the IESG as Informational Apr 2013 - A document defining the requirements for B2BUAs with respect to loop detection/prevention submitted to the IESG as PS Aug 2013 - A document defining the requirements for B2BUAs to support end-to-end and hop-by-hop media-loopback test calls submitted to the IESG as PS Dec 2013 - A document defining the requirements for B2BUAs to support DTLS-SRTP (RFC 5764) end-to-end submitted to the IESG as PS Dec 2013 - A document defining the requirements for B2BUAs to support STUN message transactions end-to-end submitted to the IESG as PS Dec 2013 - A document defining the requirements for B2BUAs to support RTCP end-to-end submitted to the IESG as PS _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From hallam@gmail.com Wed Jun 27 07:20:28 2012 Return-Path: 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 CCC1021F8778 for ; Wed, 27 Jun 2012 07:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Miruj+vrni-O for ; Wed, 27 Jun 2012 07:20:28 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DFCE321F8795 for ; Wed, 27 Jun 2012 07:20:27 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1054260ghb.31 for ; Wed, 27 Jun 2012 07:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yAWVoeQi8GRIq09q/gBmKpWwmR6HU2O+6Idx4uTDC8k=; b=pnrF9lICr7ZMcSSv5d7NtfNfZGf/nvHe71h24CMSMZD68IrINWOfNxMKP/pY/t2mwe uyLSYDOFzg8R3bBj+N+8PTFQKLFIBXMkv0v4ucS+0PA+x99NA3s3y/MbHRLyTBNVWHi5 NDGRNW9ETFQjRJugY4DvzNO7IhdyUALLtn5ikw/k3E9d+zGZFxD/zDA1VsgS6PjOsbiC O2pmouEVx+B8rZMZ2GNpTj4cGtm9oF8jjZxmG4fqL41iADfiOBm/RwHTe3YKD+c/2PH4 gjDgMxu29WwTGnxBJQ0pH4NzwfIOB2xT7pzMwlhmY3rOWrKsbS84mQI6iw8eQPkGmh3h e3ng== MIME-Version: 1.0 Received: by 10.60.154.232 with SMTP id vr8mr3319576oeb.30.1340806827432; Wed, 27 Jun 2012 07:20:27 -0700 (PDT) Received: by 10.182.64.166 with HTTP; Wed, 27 Jun 2012 07:20:27 -0700 (PDT) Date: Wed, 27 Jun 2012 10:20:27 -0400 Message-ID: From: Phillip Hallam-Baker To: suresh.krishnan@ericsson.com, joel.halpern@ericsson.com, secdir@ietf.org, Russ Housley Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] SECDIR Review of http://tools.ietf.org/html/draft-krishnan-nomcom-tools-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 14:20:29 -0000 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. Surprisingly for a non protocol draft, this one actually is almost completely security requirements. Unfortunately I find it rather hard to tell if the security architecture meets the security goals because they are not separated from each other. I think the document should have a section stating the security goals or reference another document that states them. Presumably these are all derived from the Nomcom RFC. The document specifies creation of a public key but not the algorithm or strength. Given that this is an RFP, I think it would be appropriate to completely and uniquely specify the cipher suite to be supported. -- Website: http://hallambaker.com/ From hartmans@mit.edu Wed Jun 27 12:00:51 2012 Return-Path: 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 D8C1511E8171; Wed, 27 Jun 2012 12:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.038 X-Spam-Level: X-Spam-Status: No, score=-104.038 tagged_above=-999 required=5 tests=[AWL=-1.773, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 eJ3U5sLdRJ3s; Wed, 27 Jun 2012 12:00:51 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A23A211E8172; Wed, 27 Jun 2012 12:00:48 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id DE31A201CC; Wed, 27 Jun 2012 15:00:10 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9A05A41EF; Wed, 27 Jun 2012 15:00:29 -0400 (EDT) From: Sam Hartman To: "t.p." References: <21762_1337814743_q4NNCMPh008981_alpine.BSF.2.00.1205231837020.9762@fledge.watson.org> <1337881837.3279.45.camel@destiny.pc.cs.cmu.edu> <004a01cd4562$b7b338e0$4001a8c0@gateway.2wire.net> Date: Wed, 27 Jun 2012 15:00:29 -0400 In-Reply-To: <004a01cd4562$b7b338e0$4001a8c0@gateway.2wire.net> (t. p.'s message of "Fri, 8 Jun 2012 11:37:27 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: , draft-sakane-dhc-dhcpv6-kdc-option@tools.ietf.org, ietf , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 19:00:52 -0000 >>>>> "t" == t p writes: t> Just to make public what I have hinted at privately, I think that steps t> in section 4.1 may be somewhat underspecified. t> A related issue is that section 4.1 prefers DNS to DHCP for Kerberos t> information but the Security Considerations stress the weakness of t> DHCP and recommend authenticating DHCP. What if DHCP is secure t> and DNS is not? Should DNS still be preferred? Yes probably. DNS has been and will continue to be the dominant way to discover KDCs. I see this as a specialized DHCP option for certain deployments, not something you'll see in the enterprise for desktops or laptops as an example. I mean some people may deploy it, but I suspect that you won't see it in most situations where DNS works well today. So, basically in all cases, including preconfigured DNS servers, I'd expect DNS to be preferred. Note that choosing the right KDC does impact availability--if you have the wrong KDC it won't work. In general though, choosing the wrong KDC does not compromise authentication. It's a bit more complex than that, but KDC location has not generally been considered security sensitive. From derek@ihtfp.com Wed Jun 27 19:21:41 2012 Return-Path: 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 To: iesg@ietf.org, secdir@ietf.org Date: Wed, 27 Jun 2012 22:21:33 -0400 Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From weiler+secdir@watson.org Thu Jun 28 03:10:29 2012 Return-Path: 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 803E721F8818 for ; Thu, 28 Jun 2012 03:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 Kbyg5iu+0Kti for ; Thu, 28 Jun 2012 03:10:22 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3C79F21F88CC for ; Thu, 28 Jun 2012 02:01:55 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.5/8.14.5) with ESMTP id q5S91sJx080319 for ; Thu, 28 Jun 2012 05:01:54 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.5/8.14.5/Submit) with ESMTP id q5S91sIe080315 for ; Thu, 28 Jun 2012 05:01:54 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 28 Jun 2012 05:01:53 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 28 Jun 2012 05:01:54 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 10:10:29 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Russ Mundy is next in the rotation. For telechat 2012-07-05 Reviewer LC end Draft Alan DeKok T - draft-ietf-xrblock-rtcp-xr-meas-identity-07 Dan Harkins T - draft-ietf-6man-lineid-05 Stephen Kent T - draft-ietf-intarea-ipv4-id-update-05 For telechat 2012-07-19 Paul Hoffman T - draft-ietf-appsawg-received-state-04 Last calls and special requests: Rob Austein 2012-06-26 draft-ietf-bmwg-2544-as-04 Richard Barnes 2012-06-28 draft-ietf-ippm-twamp-value-added-octets-03 Dave Cridland 2012-06-28 draft-ietf-nfsv4-federated-fs-admin-11 Donald Eastlake - draft-zheng-mpls-ldp-hello-crypto-auth-04 Shawn Emery 2012-07-02 draft-melnikov-smtp-priority-tunneling-02 Tobias Gondrom 2012-06-29 draft-sandlund-rfc4996bis-02 Steve Hanna 2012-07-11 draft-ietf-6lowpan-btle-08 Sam Hartman 2012-07-10 draft-ietf-abfab-gss-eap-08 Jeffrey Hutzelman 2012-07-10 draft-ietf-behave-lsn-requirements-07 Leif Johansson 2012-07-04 draft-ietf-cdni-use-cases-08 Charlie Kaufman 2012-07-11 draft-ietf-dnsext-dnssec-algo-imp-status-03 Scott Kelly 2012-07-11 draft-ietf-dnsext-dnssec-registry-update-03 Tero Kivinen 2012-07-11 draft-ietf-oauth-urn-sub-ns-05 Warren Kumari - draft-ietf-oauth-v2-threatmodel-06 Julien Laganier 2012-07-06 draft-ietf-ospf-prefix-hiding-04 Matt Lepinski 2012-07-11 draft-ietf-v6ops-6204bis-09 Chris Lonvick - draft-ietf-geopriv-dhcp-lbyr-uri-option-15 Catherine Meadows - draft-ietf-idr-rfc4893bis-07 Alexey Melnikov - draft-ietf-krb-wg-kdc-model-12 Kathleen Moriarty - draft-ietf-v6ops-ra-guard-implementation-04 Nico Williams - draft-ietf-httpbis-p5-range-19 Nico Williams 2012-07-02 draft-farrell-decade-ni-08 Tom Yu - draft-ietf-httpbis-p6-cache-19 Tom Yu 2012-07-13 draft-hoffman-tao-as-web-page-02 Glen Zorn - draft-ietf-httpbis-p7-auth-19 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-15 From tobias.gondrom@gondrom.org Thu Jun 28 05:14:55 2012 Return-Path: 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 B2B6821F84E2 for ; Thu, 28 Jun 2012 05:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.855 X-Spam-Level: X-Spam-Status: No, score=-99.855 tagged_above=-999 required=5 tests=[AWL=-3.078, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, 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 N5i846xjP0Mg for ; Thu, 28 Jun 2012 05:14:54 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 0619E21F84DE for ; Thu, 28 Jun 2012 05:14:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=ZIPULGAMq9H+7mDivVW7GkMq8N2vC+LoBVRKKAuDeNoqrUuknfxBuDLUHJNTj37yMNAEMYtG2mhg/tJqxx9BabD49aUPYK9vK6i5GTFKaDP82Mhq0b7CxCR7Ar1zGlL2; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type; Received: (qmail 15828 invoked from network); 28 Jun 2012 14:14:44 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.71?) (94.194.102.93) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 28 Jun 2012 14:14:44 +0200 Message-ID: <4FEC4AB3.7070202@gondrom.org> Date: Thu, 28 Jun 2012 13:14:43 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org, draft-sandlund-rfc4996bis.all@tools.ietf.org Content-Type: multipart/alternative; boundary="------------040200080606010604000107" Subject: [secdir] Secdir review of draft-sandlund-rfc4996bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 12:14:55 -0000 This is a multi-part message in MIME format. --------------040200080606010604000107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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. Please note that due to the fact that this is an update to 4996, this review covers only the diffs to RFC4996 and not the whole overall standard. As far as I could see the accumulated verified errata have been included successfully. Furthermore, to my understanding the proposed updates/changes do not require any new security considerations. Best regards, Tobias --------------040200080606010604000107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
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.

Please note that due to the fact that this is an update to 4996, this review covers only the diffs to RFC4996 and not the whole overall standard.

As far as I could see the accumulated verified errata have been included successfully.
Furthermore, to my understanding the proposed updates/changes do not require any new security considerations.

Best regards, Tobias
--------------040200080606010604000107-- From rbarnes@bbn.com Fri Jun 29 13:17:04 2012 Return-Path: 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 F2EAD21F88EA; Fri, 29 Jun 2012 13:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 GE5bkSPDgQe6; Fri, 29 Jun 2012 13:17:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 529E621F8857; Fri, 29 Jun 2012 13:17:02 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:55457) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Skhch-0004ne-OG; Fri, 29 Jun 2012 16:16:59 -0400 From: Richard L. Barnes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jun 2012 16:16:59 -0400 Message-Id: <41B942F7-5BD0-46ED-9C47-748DB2A36308@bbn.com> To: The IESG , SECDIR , draft-ietf-ippm-twamp-value-added-octets.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [secdir] secdir review of draft-ietf-ippm-twamp-value-added-octets-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 20:17:04 -0000 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 defines "value-added" octets that can cause TWAMP peers to = enable some additional services, for example, multiplexing multiple = TWAMP measurements into a single session. These value-added octets are = inserted into the packet as padding octets, so that an unaware host will = simply ignore them. Thus, the major new risk (relative to TWAMP) is = that some of the additional features require more buffering than normal = TWAMP, and can thus lead to DOS if not constrained. The Security = Considerations section correctly notes this risk; it would be helpful if = it included a little more detail on how the DOS conditions could arise. --Richard= From suresh.krishnan@ericsson.com Fri Jun 29 17:45:16 2012 Return-Path: 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 1F85621F8540 for ; Fri, 29 Jun 2012 17:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ReOkyDFdtRvl for ; Fri, 29 Jun 2012 17:45:15 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8165C21F8526 for ; Fri, 29 Jun 2012 17:45:15 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q5U0jDH0025904; Fri, 29 Jun 2012 19:45:14 -0500 Received: from [142.133.112.108] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.264.0; Fri, 29 Jun 2012 20:45:07 -0400 Message-ID: <4FEE4C12.6040208@ericsson.com> Date: Fri, 29 Jun 2012 20:45:06 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Joel Halpern , "secdir@ietf.org" Subject: Re: [secdir] SECDIR Review of http://tools.ietf.org/html/draft-krishnan-nomcom-tools-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 00:45:16 -0000 Hi Phil, Thanks for the review. Please find responses inline. On 06/27/2012 10:20 AM, Phillip Hallam-Baker wrote: > 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. > > > Surprisingly for a non protocol draft, this one actually is almost > completely security requirements. Unfortunately I find it rather hard > to tell if the security architecture meets the security goals because > they are not separated from each other. > > I think the document should have a section stating the security goals > or reference another document that states them. Presumably these are > all derived from the Nomcom RFC. The goals are derived from RFC3777 * Section 3 Rule 6 " All deliberations and supporting information that relates to specific nominees, candidates, and confirmed candidates are confidential." * Section 5 Rule 16 " The nominating committee should archive the information it has collected or produced for a period of time not to exceed its term. ... The implementation of the archive should make every reasonable effort to ensure that the confidentiality of the information it contains is maintained." > > > The document specifies creation of a public key but not the algorithm > or strength. Given that this is an RFP, I think it would be > appropriate to completely and uniquely specify the cipher suite to be > supported. As stated in the draft, the key is generated by the Nomcom chair out of band and not by the tool. In the example provided in Appendix A (based on what I actually did as chair), the key used is a RSA 2048-bit key. Since I am not even remotely close to a security expert :-), it would be great if you can provide suggestions to put in here for future Nomcom chairs. Thanks Suresh From dharkins@lounge.org Sat Jun 30 10:49:02 2012 Return-Path: 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 BC6C121F85B6; Sat, 30 Jun 2012 10:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.406 X-Spam-Level: X-Spam-Status: No, score=-4.406 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] 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 g6RZJ2OBpPIC; Sat, 30 Jun 2012 10:49:02 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 091B821F84FE; Sat, 30 Jun 2012 10:49:02 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C75AB1022400A; Sat, 30 Jun 2012 10:49:02 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 30 Jun 2012 10:49:02 -0700 (PDT) Message-ID: <3f40470e03a3da0a21dcf09e26f1a723.squirrel@www.trepanning.net> Date: Sat, 30 Jun 2012 10:49:02 -0700 (PDT) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-ietf-6man-lineid.all@tools.ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [secdir] secdir review of draft-ietf-6man-lineid X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 17:49:02 -0000 Hello, 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 draft defines a new destination option for IPv6 datagrams that tunnel router solicitation and router advertisement messages. The purpose of the option is to allow an edge router in a broadband subscriber network to identify a particular subscriber that comes up. I found the draft a bit confusing. Terms are referred to before they are defined and once defined are not consistently used. There were several paragraphs that I had to re-read a couple times to figure out what was being intended. I would suggest the following editorial changes: - in section 1.1, move definition of GPON and RG up before they are referred to (AN, and Edge Router, respectively) - in section 5.3, pick either AN or "access node" and stick to it. By sometimes referring to the entity by acronym and sometimes by full name, the casual reader (me) does not immediately tie them together and creates 2 entities in his mind as he's putting the described behavior together. - in section 6.2 it talks about creating a new IPv6 datagram, then about adding the option to it and how to determine the contents of this datagram, and then it says a new IPv6 datagram is created. Wait, so there's 2 IPv6 datagrams or is this the same one? I had to read this a few times to figure out what's going on. There is an apparent technical problem in section 7 where the new option is laid out. The option type is an octet and the option length is also an octet (whose length does not include the option type or itself). Then follows the a field for the length of the lineID and the lineID itself. But the length of the lineID is 2 octets implying that a lineID can be more than 255 octets long. How does this work? If the lineID itself is greater than 253 octets then the length required to be encoded in the option length would be greater than 255 which cannot be described with a single octet. Either there is the possibility of a valid but unparsable option that would likely make the rest of the packet unparsable too (which is bad) or the lineID can never be greater than 253 octets which then makes me ask why the field to encode its length has to be 2 octets? The other option is, of course, that I'm completely missing something. If that's the case, forgive my ignorance but please do enlighten me. I found no security issues with the draft that require the attention of the ADs. The Security Considerations mention that this is all unauthenticated and should only be used on a network where the communicating entities are already trusted, which seems reasonable for the way this will be deployed. regards, Dan.