From derek@ihtfp.com Tue Oct 1 08:34:22 2013 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 4ABAC21E8153; Tue, 1 Oct 2013 08:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, 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 MLweEfQifEyd; Tue, 1 Oct 2013 08:34:17 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 73C8D21E8085; Tue, 1 Oct 2013 08:34:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 496F626029C; Tue, 1 Oct 2013 11:34:05 -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 11250-05; Tue, 1 Oct 2013 11:34:04 -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 0566B260299; Tue, 1 Oct 2013 11:34:04 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.5/Submit) id r91FXrT6009484; Tue, 1 Oct 2013 11:33:53 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Tue, 01 Oct 2013 11:33:53 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: krehor@cisco.com, andrew.hutton@siemens-enterprise.com, leon.portman@gmail.com, siprec-chairs@tools.ietf.org, rajnish.jain@outlook.com Subject: [secdir] sec-dir review of draft-ietf-siprec-architecture-08 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, 01 Oct 2013 15:34:22 -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. Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions in an environment which is based on the Session Initiation Protocol (SIP). Retrieving recorded media is a potential Key Management problem which this document completely ignores (and even claims is out of scope). The key used to encrypt the recorded media (whether or not the media is re-encrypted) must be stored and retrieved as part of the media retrieval. How this important data is stored and retrieved is left out, leaving an implementation with no guidance on how to protect that valuable asset. In fact the document completely elides the question of how a retriever obtains the data encryption key. Even if it's just additional guidance the Security Considerations should at least explain the problem even if it doesn't provide a solution. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From bew@cisco.com Tue Oct 1 17:10:10 2013 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 DE0331F0D4F; Tue, 1 Oct 2013 17:10:10 -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 jLfpZuDCEW5u; Tue, 1 Oct 2013 17:09:59 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A73C31F0D5E; Tue, 1 Oct 2013 17:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5570; q=dns/txt; s=iport; t=1380672586; x=1381882186; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=5/zVV3QfOpnw6Cnqx3TqmNEDR80V303u5EcUQVbTSHY=; b=YeRhTsyv3mm9TRVCf3hEny1JkYbIJfKFlt2DyPlHjqgXWk8fZ+o7TZzf ev9Xmba6v0pIhH/iu126dak0l6yly+QdzXM8you7VVurqlFeTDh774e0J sEB2NCsn7ci/8P8I+l1qiEsoc9eursDXID8jMjRHfu9gXnHXiC5fi6Gng g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FALNjS1KrRDoI/2dsb2JhbABYgwfCFoEqFnSCZjgHgT4BiBe9S49RgyaBAwOJOY5GhjOLR4NEHIEsJA X-IronPort-AV: E=Sophos;i="4.90,1015,1371081600"; d="scan'208";a="93688083" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 02 Oct 2013 00:09:40 +0000 Received: from [10.154.161.207] ([10.154.161.207]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9209dAi019877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Oct 2013 00:09:39 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Oct 2013 17:09:36 -0700 Message-Id: <0BAD1ACB-F918-476D-9F73-9D1DCBC47B11@cisco.com> To: "secdir@ietf.org" , The IESG Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: draft-ietf-p2psip-drr-10.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-p2psip-drr-10 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, 02 Oct 2013 00:10:11 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the=20 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 a routing mechanism for Peer-to-Peer Session = Initiation Protocol (P2PSIP). The routing mechanism in the base P2PSIP = protocol specifies an initiator sending a request message hop by hop = through a DHT to a responder, with the responder returning a reply using = the reverse path. The alternative routing method defined in this I-D = describes a shortcut for the response message. The response is returned = directly to the initiator using an IP address provided by the initiator. = This shortcut method is described as an optimization that is useful in = private networks where a self-reported IP address is likely to be = reliable (i.e., no NAT). The Security Considerations of this I-D depends entirely upon the = Security Considerations of the base document = (draft-ietf-p2psip-base-26). It should probably be expanded to include = some more discussion on DRR so that it is clear. I have some questions = to start a discussion to help understand what might need to be added. 1. The Security Considerations section states=20 "According to section 13 of the base drat[sic] the forwarding header = MUST be digitally signed protecting the DRR routing information."=20 I hope it's actually true that the entire DRR message is signed. If so I = would recommend stating this something like "According to section 13 of = the base draft the entire routing message MUST be digitally signed, = including the forwarding header that specifies the DRR routing = information". 2. My interpretation reading Section 13 of draft-ietf-p2psip-base-26 is = that all routing messages must also be protected. For example, Section = 13.6.3 in the base document says: "... whenever a peer establishes a direct connection to another peer it = authenticates via certificate-based mutual authentication. All messages = between peers are sent over this protected channel and therefore the = peers can verify the data origin of the last hop peer for requests and = responses without further cryptography." I don't believe that DRR messages should be any exception, since the DRR = request messages would be subject to the Eclipse and Sybil attacks = described in the base document. The Security Considerations section in = this I-D does not say that, even though it makes an effort to point out = that the messages are digitally signed. This I-D should also say that = the messages are sent over a protected channel, or else the section = needs to have a good justification as to why the DRR request messages do = not require the same protection as SRR messages. I can't think of what = that justification would be though! 3. Table 1 and the preceding paragraph are a little confusing because = sometimes it says the messages are DTLS protected and sometimes they are = not. If all of the routing messages are required to be encrypted then = I'm not sure what the point of this comparison. The "No. of Hops" and = "No. of Msgs" fields in Table 1 are also confusing because they seem to = be comparing cases where sometimes DTLS messages are included in the = counts and sometimes they are not. - If it's true that SRR messages must always be protected by DTLS (or a = similar protocol) then why isn't setting up the DTLS session included in = the number of messages in the SRR row? Is that because the DLTS sessions = are persistent between the hops and are assumed to have already been = setup? So are you then including the DLTS setup messages in DRR(DTLS) = because you assume they had not previously setup? - The DRR rows shows 1 hop in the No. of Hops column, but that doesn't = seem to be quite right because of the asymmetric nature of the DRR = protocol. Shouldn't it really be "log(N) + 1" to indicate the DRR = request is log(N) hops and the DRR reply is one hop? Overall this section needs to be clarify these things so a reader = understands the relationship between the DRR routing messages and the = DTLS secure connections. 4. When an intermediate peer receives a DRR message with the = IGNORE-STATE-KEEPING flag in the header, is it supposed to not maintain = any security state or just not maintain routing state? 5. Section 4.2 says: "using DRR SHOULD be discouraged in the open Internet or if the = administrator does not feel he have enough information about the overlay = network topology."=20 Is this due to any security reason, or just because the initiator's = address reported in the Destination structure might be wrong? 6. Section 5.1 says: "Note that establishing (D)TLS secure connections for P2P overlay is not = optimal in some cases, e.g. direct response routing where (D)TLS is = heavy for temporary connections. Instead, some alternate security = techniques, e.g. using public keys of the destination to encrypt the = messages, and signing timestamps to prevent reply attacks can be = adopted."=20 It is not valuable to speculate on alternative security technique in = this section, because the I-D does not define that security technique. = If you think an alternative to DTLS is useful, then I think that = discussion belongs in a new draft. Hope that helps, Brian= From bew@cisco.com Tue Oct 1 17:16:59 2013 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 A50381F0D07; Tue, 1 Oct 2013 17:16:59 -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 QV3vxwB41ugM; Tue, 1 Oct 2013 17:16:48 -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 A926721F9BB5; Tue, 1 Oct 2013 17:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5595; q=dns/txt; s=iport; t=1380672993; x=1381882593; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=TX6z9vqhDm+eIlVCYOjlZZu9jEIQCNBwaqQLUZfc/7E=; b=i4ejDsTH0JIhynq9Nft/adBxcQR4rhoPQCyVWR4Nz2YSLwRu7IBCzf3b ksBCvs5gjVCu2qEMSQflw9SojrHuOWJQgFl54Pcf/BV2TBOvUm4aKR+vL 7E0TuQmIGcHMDT6Fum+ZyTZfG2AUvjL3h+HMlaIDpeOg//U//YRdw6Lxl Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAFdlS1KrRDoI/2dsb2JhbABYgwfCFoEqFnSCZjgHgT4BiBe9TY9RgyaBAwOJOY5GhjOLR4NEHIEsJA X-IronPort-AV: E=Sophos;i="4.90,1015,1371081600"; d="scan'208";a="90394919" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 02 Oct 2013 00:16:33 +0000 Received: from [10.154.161.207] ([10.154.161.207]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r920GWbr022709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Oct 2013 00:16:32 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Oct 2013 17:16:29 -0700 Message-Id: <6340B78E-38C7-4B25-8CDD-36DC67C49A21@cisco.com> To: "secdir@ietf.org" , The IESG Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: draft-ietf-p2psip-drr.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-p2psip-drr-10 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, 02 Oct 2013 00:16:59 -0000 [Resent with proper cc] I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the=20 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 a routing mechanism for Peer-to-Peer Session = Initiation Protocol (P2PSIP). The routing mechanism in the base P2PSIP = protocol specifies an initiator sending a request message hop by hop = through a DHT to a responder, with the responder returning a reply using = the reverse path. The alternative routing method defined in this I-D = describes a shortcut for the response message. The response is returned = directly to the initiator using an IP address provided by the initiator. = This shortcut method is described as an optimization that is useful in = private networks where a self-reported IP address is likely to be = reliable (i.e., no NAT). The Security Considerations of this I-D depends entirely upon the = Security Considerations of the base document = (draft-ietf-p2psip-base-26). It should probably be expanded to include = some more discussion on DRR so that it is clear. I have some questions = to start a discussion to help understand what might need to be added. 1. The Security Considerations section states=20 "According to section 13 of the base drat[sic] the forwarding header = MUST be digitally signed protecting the DRR routing information."=20 I hope it's actually true that the entire DRR message is signed. If so I = would recommend stating this something like "According to section 13 of = the base draft the entire routing message MUST be digitally signed, = including the forwarding header that specifies the DRR routing = information". 2. My interpretation reading Section 13 of draft-ietf-p2psip-base-26 is = that all routing messages must also be protected. For example, Section = 13.6.3 in the base document says: "... whenever a peer establishes a direct connection to another peer it = authenticates via certificate-based mutual authentication. All messages = between peers are sent over this protected channel and therefore the = peers can verify the data origin of the last hop peer for requests and = responses without further cryptography." I don't believe that DRR messages should be any exception, since the DRR = request messages would be subject to the Eclipse and Sybil attacks = described in the base document. The Security Considerations section in = this I-D does not say that, even though it makes an effort to point out = that the messages are digitally signed. This I-D should also say that = the messages are sent over a protected channel, or else the section = needs to have a good justification as to why the DRR request messages do = not require the same protection as SRR messages. I can't think of what = that justification would be though! 3. Table 1 and the preceding paragraph are a little confusing because = sometimes it says the messages are DTLS protected and sometimes they are = not. If all of the routing messages are required to be encrypted then = I'm not sure what the point of this comparison. The "No. of Hops" and = "No. of Msgs" fields in Table 1 are also confusing because they seem to = be comparing cases where sometimes DTLS messages are included in the = counts and sometimes they are not. - If it's true that SRR messages must always be protected by DTLS (or a = similar protocol) then why isn't setting up the DTLS session included in = the number of messages in the SRR row? Is that because the DLTS sessions = are persistent between the hops and are assumed to have already been = setup? So are you then including the DLTS setup messages in DRR(DTLS) = because you assume they had not previously setup? - The DRR rows shows 1 hop in the No. of Hops column, but that doesn't = seem to be quite right because of the asymmetric nature of the DRR = protocol. Shouldn't it really be "log(N) + 1" to indicate the DRR = request is log(N) hops and the DRR reply is one hop? Overall this section needs to be clarify these things so a reader = understands the relationship between the DRR routing messages and the = DTLS secure connections. 4. When an intermediate peer receives a DRR message with the = IGNORE-STATE-KEEPING flag in the header, is it supposed to not maintain = any security state or just not maintain routing state? 5. Section 4.2 says: "using DRR SHOULD be discouraged in the open Internet or if the = administrator does not feel he have enough information about the overlay = network topology."=20 Is this due to any security reason, or just because the initiator's = address reported in the Destination structure might be wrong? 6. Section 5.1 says: "Note that establishing (D)TLS secure connections for P2P overlay is not = optimal in some cases, e.g. direct response routing where (D)TLS is = heavy for temporary connections. Instead, some alternate security = techniques, e.g. using public keys of the destination to encrypt the = messages, and signing timestamps to prevent reply attacks can be = adopted."=20 It is not valuable to speculate on alternative security technique in = this section, because the I-D does not define that security technique. = If you think an alternative to DTLS is useful, then I think that = discussion belongs in a new draft. Hope that helps, Brian= From jsalowey@cisco.com Tue Oct 1 17:32:57 2013 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 498921F0ED6; Tue, 1 Oct 2013 17:32:57 -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 XEFQXuE68d8V; Tue, 1 Oct 2013 17:32:45 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id DE2E61F0D1A; Tue, 1 Oct 2013 17:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2520; q=dns/txt; s=iport; t=1380673965; x=1381883565; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XqMJP0soofef0BbNInNexvLO+/DQs1LLTFzCojUTjDw=; b=We5dCJwNajgwFpOf6VWOctt0Nwk31H1Nhw1ndaNLGIWdr1zxrFDuSeGq m9VFj9xvWhzjnCIBsQX4Lbn2YEgxYmNM6WCXrt11Gb6q1C1bRV4EvkunS NzMtHTGi7PruxA62up2w9EHKzx/JmsJwKQYfVFSKSj6KRKOue3iuxfylt A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAF9oS1KtJXG//2dsb2JhbABYgweBCsEMgSoWdIIlAQEBAwF5BQsCAQgiJDIlAgQOBQiHeAa9RY8eAjEHgx+BAwOJAaB4gySCKg X-IronPort-AV: E=Sophos;i="4.90,1016,1371081600"; d="scan'208";a="266956969" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 02 Oct 2013 00:32:44 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r920Wi6v016231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Oct 2013 00:32:44 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.23]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 1 Oct 2013 19:32:43 -0500 From: "Joseph Salowey (jsalowey)" To: Stephen Kent Thread-Topic: [secdir] Secdir review of draft-ietf-sidr-bgpsec-threats-06 Thread-Index: AQHOuOtQNP014ejpdES76SMyLe+X85ne2RaAgAIWtAA= Date: Wed, 2 Oct 2013 00:32:43 +0000 Message-ID: References: <5249A91F.6020003@bbn.com> In-Reply-To: <5249A91F.6020003@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.127] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <06B1CFA6B1161E41A4C1D6C79A184512@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: The IESG , "draft-ietf-sidr-bgpsec-threats-06.all@tools.ietf.org" , "" Subject: Re: [secdir] Secdir review of draft-ietf-sidr-bgpsec-threats-06 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, 02 Oct 2013 00:32:57 -0000 On Sep 30, 2013, at 9:38 AM, Stephen Kent wrote: > Joe, >=20 >> Some issues: >>=20 >> 1. I found it difficult to link the threats in section 3 to the attack= s in section 4. This is more of a consistency of terminology issue and is= probably just a nit. > There is not 1-to-1 correspondence between threats and attacks. So, for = each attacks in > Section 4, there may be more than one threat that is motivated and capabl= e of effecting > the attack. [Joe] OK >> 2. The attacks in sections 4.1, 4.2, and 4.3 seem to be largely discou= nted as out of scope, yet they seem to impact the goals of PATHSEC. Is it= assumed that there are countermeasures in place such as link protection be= tween RGP peers? If other countermeasures besides PATHSEC are expected t= o be in place this should probably be mentioned in the security considerati= ons. > The text in 4.1, 4.2, and 4.3 does not say that those attacks are out of = scope. In 4.1, > there is little text because the attacks are not specific to the RPKI/PAT= HSEC context. > Countermeasures are generic for IP and TCP layer attacks, as noted in the= requirements > doc. In 4.2 and 4.3 we give a number of examples of these classes of atta= cks, which > is what this doc is intended to do. (Recall, it is not a requirements doc= .) [Joe] OK >> 3. I found the argument against not including 'route leakage' a bit we= ak since the documents seems to be able to define what it means. Wouldn't= 'route leakage' be a mechanism to realize one or more of the threats in se= ction 3? > There is not yet an accepted definition of route leak that represents a v= iolation of BGP > specs. The GROW WG is supposed to look into this issue. If it develops a = suitable proposal, then IDR may elect to modify the BGP spec to address the= concern. If IDR does so, SIDR's charter could be modified to develop coun= termeasures for the concern. But, for now, this is out of scope. So I disag= ree with the comment that the argument is weak. Also, your use of the term = "threat" in the last sentence above is not consistent with the way the term= is defined and used in Section 3; you seem to have switched "threat" and "= attack" as well as section numbers. >=20 [Joe] As long as the issue is not being dropped then much of my concern is= addressed. If it turns out to be something of concern to BGP then mechan= isms can be modified or developed to address it.=20 > Steve From kivinen@iki.fi Thu Oct 3 04:26:22 2013 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 3C4D221F9EDB for ; Thu, 3 Oct 2013 04:26:22 -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 SC-KK4WfOmCY for ; Thu, 3 Oct 2013 04:26:14 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id A898221F999B for ; Thu, 3 Oct 2013 04:21:59 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r93BLucD018184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 3 Oct 2013 14:21:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r93BLsuC017768; Thu, 3 Oct 2013 14:21:54 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21069.21330.485392.538767@fireball.kivinen.iki.fi> Date: Thu, 3 Oct 2013 14:21:54 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 1 min 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, 03 Oct 2013 11:26:22 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview David Harrington is next in the rotation. For telechat 2013-10-10 Reviewer LC end Draft Rob Austein T 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Jeffrey Hutzelman T 2013-07-16 draft-yusef-dispatch-ccmp-indication-06 Ben Laurie T 2013-09-23 draft-ietf-idr-rfd-usable-03 Matt Lepinski T 2013-09-24 draft-ietf-l2vpn-pbb-vpls-interop-05 Kathleen Moriarty T 2013-10-01 draft-resnick-retire-std1-01 Sandy Murphy TR2013-09-20 draft-ietf-6man-ext-transmit-04 Ondrej Sury T 2013-09-27 draft-ietf-ecrit-psap-callback-12 Glen Zorn T 2013-09-27 draft-ietf-sipcore-rfc4244bis-callflows-06 Last calls and special requests: Rob Austein 2013-10-16 draft-kolkman-proposed-standards-clarified-03 Dave Cridland - draft-ietf-httpbis-p5-range-24 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Dave Cridland 2013-10-03 draft-ietf-dhc-option-guidelines-14 Alan DeKok 2013-10-18 draft-hethmon-mcmurray-ftpext-ftp-hosts-03 Donald Eastlake 2013-10-10 draft-mcgrew-tls-aes-ccm-ecc-07 Shawn Emery 2013-10-20 draft-ietf-tictoc-security-requirements-05 Tobias Gondrom 2013-10-16 draft-ietf-6man-oversized-header-chain-08 Phillip Hallam-Baker 2013-10-16 draft-ietf-ccamp-gmpls-ospf-g709v3-09 Steve Hanna 2013-10-16 draft-ietf-manet-smf-mib-08 Dan Harkins 2013-10-16 draft-ietf-mpls-tp-rosetta-stone-12 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-04 Julien Laganier - draft-ietf-avtcore-rtp-security-options-06 Julien Laganier - draft-ietf-websec-key-pinning-08 Alexey Melnikov - draft-ietf-payload-rtp-howto-07 Magnus Nystrom 2013-09-24 draft-ietf-insipid-session-id-reqts-08 Vincent Roca 2013-09-24 draft-ietf-mmusic-duplication-grouping-03 Carl Wallace 2013-09-30 draft-ietf-hip-reload-instance-09 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-13 Sam Weiler 2013-09-30 draft-ietf-opsec-ip-options-filtering-05 Brian Weis 2013-10-05 draft-ietf-radext-dtls-06 Tom Yu 2013-10-01 draft-ietf-sidr-origin-ops-21 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 -- kivinen@iki.fi From benl@google.com Thu Oct 3 04:51:17 2013 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 A3BD021F852A for ; Thu, 3 Oct 2013 04:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-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 Gdvv1p+pt1t2 for ; Thu, 3 Oct 2013 04:51:17 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 01EDF21F8613 for ; Thu, 3 Oct 2013 04:43:49 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id as1so4859910iec.7 for ; Thu, 03 Oct 2013 04:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IM7dIwCTATpPicmyzZim4RjUGZwsVOvqsEYLD9oA8ik=; b=MmbMVwVqMgRSWs0K/+AGkVR3wyn3uOyY7C7WIvGVEZL5+QjN+tcJHiHG2d/pt1m0/y pad8YnVJtYABbRyckg9B7YzAjMqcvDpX9kVQQ+eWsKOzASwA5D+lsKl93BeIE4wB8+EF lMhQNkc+/0vsyI1B3Ja6pq/AyEJE41wHAFIOY4JKjw6WBHDBLbTMz4eYp9/IAywTW4eX s/azICLKnBpLm2Ix/A9UA7jrOtEXCZ0BAPiao5UpOTK86t+aEzeEAOwBQwztDU6Iqsa6 WcoB+SGQtMLzMn2G2ol6nsoPEIW4Pb6MWLh+4TBmdHFNO/lRcyGaUYU5wjbYT/LIjpVs Cy2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=IM7dIwCTATpPicmyzZim4RjUGZwsVOvqsEYLD9oA8ik=; b=ODRulT15yhBwBhxWSKfoQTCEjWUkXouTuzhzUeWnCjVixa8TVX634L+84jEptW3xFL baSAxRLf16CDdi7HuDGdyrqANxZ35VNIdyobi7c1TdigOJlMkEwrV/65w+r3EGyTMiaX FPP/nl006vn0lEOskSOtixo59ppA5RFGYZ1C9lHH7B2wMZkm9QuVDWK5MyUDlpwWRsRA sflNPXpN2uPRTPwWqsjcSOevLnWYDWHdZA6v7fjsl1Aq1JXIUGVTkwMxX6wdQFUF1fc/ rAq+oGYdBWY1MnRT0BCsBembNCrdCZgn2AvLvfzYyHdySLVYDzi6TFDMqY5nvsT87VRY nhsg== X-Gm-Message-State: ALoCoQnc7XSmXNYNJZlLfxxw7pVQ5b0OadBIekDgfdhR9njAnenide3WwGnTxs8VNQlqCCATQxZGOwCutS3ICpjpuu63xbtelWG5M09tt3yD9Y6BSEbYd3m1kPRNbdaAjbaM+bZIOXrshwBnXbrySaGTiBMQ6dp3o1ejAKI0AdG3GN83kNa/CaAOgDpb06nnMukNHvesyrAT MIME-Version: 1.0 X-Received: by 10.43.60.139 with SMTP id ws11mr4730654icb.12.1380800629281; Thu, 03 Oct 2013 04:43:49 -0700 (PDT) Received: by 10.64.31.100 with HTTP; Thu, 3 Oct 2013 04:43:49 -0700 (PDT) Date: Thu, 3 Oct 2013 12:43:49 +0100 Message-ID: From: Ben Laurie To: The IESG , "secdir@ietf.org" , draft-ietf-idr-rfd-usable.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] Security review of draft-ietf-idr-rfd-usable-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: Thu, 03 Oct 2013 11:51:17 -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. Summary: draft is ready. Whilst I accept the authors' assertion that this I-D does not introduce any new security issues, the fact that an attacker can introduce fake flap suggests that the underlying protocols need more robust security mechanisms. From new-work-bounces@ietf.org Thu Oct 3 08:52:21 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B05FB21E80DA; Thu, 3 Oct 2013 08:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1380815541; bh=8jXcsIWKC8fpKdqeX59k/DLIHzaOwX8B6VFBd8PkkwA=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=AA/yAjK9OihyIIn0JG3jZ8+sPILDegj/bBLuBjeVoLFfBmtmyo9T5PAAHCciKXjS0 ATVc5eR8MiLlohn0y5UKNKmxegDDgvxQ8YLjpHgDliPOP8yfL3RbSyoCr5VXcLFMHw Jv+FVkV+cx8T2ChZCr1u//nPsDsAoiPwqxTkzTPc= 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 0889321E80D8; Thu, 3 Oct 2013 08:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 phzQuvfFbTcJ; Thu, 3 Oct 2013 08:52:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7235E11E80FB; Thu, 3 Oct 2013 08:43:29 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131003154328.13078.31840.idtracker@ietfa.amsl.com> Date: Thu, 03 Oct 2013 08:43:28 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 03 Oct 2013 09:54:38 -0700 Subject: [secdir] [new-work] WG Review: Extensions for Scalable DNS Service Discovery (dnssd) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 15:52:22 -0000 A new IETF working group has been proposed in the Internet 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 2013-10-10. Extensions for Scalable DNS Service Discovery (dnssd) ------------------------------------------------ Current Status: Proposed WG Chairs: Ralph Droms Tim Chown Assigned Area Director: Ted Lemon Mailing list Address: dnssdext@ietf.org To Subscribe: dnssdext-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/dnssdext Charter: Background ---------- Zero configuration networking protocols are currently well suited to discover services within the scope of a single link. In particular, the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes referred to using Apple Computer Inc.'s trademark, Bonjour) are widely used for DNS-based service discovery and host name resolution on a single link. The DNS-SD/mDNS protocol suite is used in many scenarios including home, campus, and enterprise networks. However, the zero configuration mDNS protocol is constrained to link-local multicast scope by design, and therefore cannot be used to discover services on remote links. In a home network that consists of a single (possibly bridged) link, users experience the expected discovery behavior; available services appear because all devices share a common link. However, in multi-link home networks (as envisaged by the homenet WG) or in routed campus or enterprise networks, devices and users can only discover services on the same link, which is a significant limitation. This has led to calls, such as the Educause petition, to develop an appropriate service discovery solution to span multiple links or to perform discovery across a wide area, not necessarily on directly connected links. In addition, the "Smart Energy Profile 2 Application Protocol Standard", published by ZigBee Alliance and HomePlug Powerline Alliance specifies the DNS-SD/mDNS protocol suite as the basis for its method of zero configuration service discovery. However, its use of wireless mesh multi-link subnets in conjunction with traditional routed networks will require extensions to the DNS-SD/mDNS protocols to allow operation across multiple links. The scenarios in which multi-link service discovery is required may be zero configuration environments, environments where administrative configuration is supported, or a mixture of the two. As demand for service discovery across wider area routed networks grows, some vendors are beginning to ship proprietary solutions. It is thus both timely and important that efforts to develop improved, scalable, autonomous service discovery solutions for routed networks are coordinated towards producing a single, standards-based solution. The WG will consider the tradeoffs between reusing/extending existing protocols and developing entirely new ones. It is highly desirable that any new solution is backwardly compatible with existing DNS-SD/mDNS deployments. Any solution developed by the dnssd WG must not conflict or interfere with the operation of other zero-configuration service and naming protocols such as uPnP or LLMNR. Integration with such protocols is out of scope for this WG. The focus of the WG is to develop a solution for extended, scalable DNS-SD. This work is likely to highlight problems and challenges with naming protocols, as some level of coexistence will be required between local zero configuration name services and those forming part of the global DNS. It is important that these issues are captured and documented for further analysis; solving those problems is however not within the scope of this WG. Working Group Description ------------------------- To that end, the primary goals of the dnssd WG are as follows: 1. To document a set of requirements for scalable, autonomous DNS-based service discovery in routed, multi-link networks in the following five scenarios: (A) Personal Area networks, e.g., one laptop and one printer. This is the simplest example of a service discovery network, and may or may not have external connectivity. (B) Home networks, as envisaged by the homenet WG, consisting of one or more exit routers, with one or more upstream providers or networks, and an arbitrary internal topology with heterogeneous media where routing is automatically configured. The home network would typically be a single zero configuration administrative domain with a relatively limited number of devices. (C) Wireless 'hotspot' networks, which may include wireless networks made available in public places, or temporary or permanent infrastructures targeted towards meeting or conference style events, e.g., as provided for IETF meetings. In such environments other devices may be more likely to be 'hostile' to the user. (D) Enterprise networks, consisting of larger routed networks, with large numbers of devices, which may be deployments spanning over multiple sites with multiple upstreams, and one more more administrative domains (depending on internal administrative delegation). The large majority of the forwarding and security devices are configured. These may be commercial or academic networks, with differing levels of administrative control over certain devices on the network, and BYOD devices commonplace in the campus scenario. (E) Mesh networks such as RPL/6LoWPAN, with one or more links per routable prefix, which may or may not have external connectivity. The topology may use technologies including 802.11 wireless, HomePlug AV and GP, and ZigBee IP. In the above scenarios, the aim is to facilitate service discovery across the defined site. It is also desirable that a user or device, when away from such a site, is still able to discover services within that site, e.g. a user discovering services in their home network while remote from it. It is also desirable that multiple discovery scopes are supported, from the point of view of announcements and discovery, be the scope 'site', 'building', or 'room'. A user for example may only be interested in devices in the same room. 2. To develop an improved, scalable solution for service discovery that can operate in multi-link networks, where devices may be in neighboring or non-neighboring links, applicable to the scenarios above. The solution will consider tradeoffs between reusing/extending existing protocols and developing entirely new protocols. The solution should include documentation or definition of the interfaces that can be implemented, separately to transport of the information. 3. To document challenges and problems encountered in the coexistence of zero configuration and global DNS name services in such multi-link networks, including consideration of both the name resolution mechanism and the namespace. It is important that the dnssd WG takes input from stakeholders in the scenarios it is considering. For example, the homenet WG is currently evaluating its own requirements for naming and service discovery; it is up to the homenet WG as to whether it wishes to recommend adoption of the solution developed in the dnssd WG, but coordination between the WGs is desirable. Deliverables: The WG will produce three documents: an Informational RFC on the requirements for service discovery protocols operating on potentially non-neighboring multi-link networks as described above; a Standards Track RFC documenting an extended, scalable service discovery solution that is applicable to those scenarios; and an Informational RFC describing the problems arising when developing the extended SD solution and how it affects the integration of local zero configuration and global DNS name services. Milestones: Sep 2013 - Formation of the WG Oct 2013 - Adopt requirements draft as WG document Jan 2014 - Submit requirements draft to the IESG as an Informational RFC Mar 2014 - Adopt wide-area service discovery solution draft as WG document Mar 2014 - Adopt Informational document on the problems and challenges arising for zeroconf and unicast DNS name services Sep 2014 - Submit wide-area service discovery solution draft to the IESG as Standards Track RFC Sep 2014 - Submit the zeroconf and unicast DNS "problems and challenges" draft to the IESG as Informational. _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From andrew.g.malis@verizon.com Thu Oct 3 12:33:15 2013 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 8E7C921F9C83; Thu, 3 Oct 2013 12:33:15 -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 rD4-m4jOV8Aa; Thu, 3 Oct 2013 12:33:02 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4106721F93BA; Thu, 3 Oct 2013 12:15:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe02.verizon.com with ESMTP; 03 Oct 2013 19:14:57 +0000 From: "Malis, Andrew G (Andy)" X-IronPort-AV: E=Sophos;i="4.90,1027,1371081600"; d="scan'208";a="561343071" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi03.verizon.com with ESMTP; 03 Oct 2013 19:14:57 +0000 Received: from fhdp1lumxc7v22.us.one.verizon.com ([166.68.59.158]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Thu, 3 Oct 2013 15:14:57 -0400 To: Alexey Melnikov , IESG , "draft-ietf-pwe3-vccv-impl-survey-results.all@tools.ietf.org" , "secdir@ietf.org" Date: Thu, 3 Oct 2013 15:14:55 -0400 Thread-Topic: Secdir review of draft-ietf-pwe3-vccv-impl-survey-results-02 Thread-Index: Ac7AbNix+BMqvgz9TUuoVIKtL2//KA== Message-ID: In-Reply-To: <522CA828.1010103@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 03 Oct 2013 12:36:59 -0700 Cc: "Malis, Andrew G \(Andy\)" Subject: Re: [secdir] Secdir review of draft-ietf-pwe3-vccv-impl-survey-results-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, 03 Oct 2013 19:33:15 -0000 Alexey, Thanks for your review, and sorry for the delay. Stewart shared with me an email conversation about the draft and I'll be updating the draft to include the results of that conversation. Cheers, Andy On 9/8/2013 12:39 , "Alexey Melnikov" wrote: 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. -- Most pseudowire Emulation Edge-to-Edge (PWE3) encapsulations mandate the use of the Control Word (CW) to carry information essential to the emulation, to inhibit Equal-Cost Multipath (ECMP) behavior, and to discriminate Operations, Administration, and Maintenance (OAM) from Pseudowire (PW) packets. However, some encapsulations treat the Control Word as optional. As a result, implementations of the CW, for encapsulations for which it is optional, vary by equipment manufacturer, equipment model and service provider network. Similarly, Virtual Circuit Connectivity Verification (VCCV) supports three Control Channel (CC) types and multiple Connectivity Verification (CV) Types. This flexibility has led to reports of interoperability issues within deployed networks and associated drafts to attempt to remedy the situation. This survey of the PW/ VCCV user community was conducted to determine implementation trends. The survey and results are presented in this document. As the document is a survey of what existing implementations do in this area, I agree with editors that it doesn't introduce new security concerns. Editors also clarified that they took precautions to ensure the validity of the sample and the data, in particular they verified email addresses of respondents and that they are representing different companies, not including equipment vendors. I don't have any concerns about security considerations for this document. With no disrespect to document editors, the WG and the shepherding AD, I am however concerns that this document doesn't contain information that is useful for publishing as an RFC. I would be happy to be proven wrong on this. Best Regards, Alexey From new-work-bounces@ietf.org Thu Oct 3 14:18:25 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCA821E80E6; Thu, 3 Oct 2013 14:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1380835105; bh=NgYMsxXwxoWvh3t2UEuvmTrRf6tzs2It2DcDI5+Tk+4=; h=Date:To:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=MNvrSfcU1oumpZ17Vckk/kt7/rMkwus6PkG03Kf6A9TL1GNazCr/mItugg8jwr99B 9SKhQgOJTeeSNhdapTFKou++W+bP0drl2AfU6ulLzj/e8GfZ/YzPR4Rz4Tsd05iUU3 0vtoc08NWc/4Yvf1ksK2pwZ3EJnFF+SlLrd/iZvo= 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 3349D21E80E6 for ; Thu, 3 Oct 2013 14:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 od1X1k-lE9lG for ; Thu, 3 Oct 2013 14:18:12 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 2254921E80BF for ; Thu, 3 Oct 2013 14:08:31 -0700 (PDT) Received: from bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1VRq8L-000081-VY for new-work@ietf.org; Thu, 03 Oct 2013 17:08:30 -0400 Date: Thu, 03 Oct 2013 23:08:29 +0200 To: new-work@ietf.org MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Thu, 03 Oct 2013 14:22:03 -0700 Subject: [secdir] [new-work] W3C Web Speech Working Group will not be created X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 21:18:26 -0000 Hello, I wrote [1] in January to inform you that the W3C Advisory Committee Representatives received a Proposal to revise the Voice Browser Activity, including a draft charter for the Web Speech Working Group [2]. In the AC review, we did not receive the support and indications of participation we feel would be required to start this group successfully at this point. Interested parties were encouraged to revisit this proposal before June 2014. Thank you, Coralie Mercier, W3C Communications [1] http://lists.w3.org/Archives/Public/public-new-work/2013Jan/0003.html [2] https://www.w3.org/2012/12/speech-charter.html -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +33643220001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From Tina.Tsou.Zouting@huawei.com Thu Oct 3 22:37:40 2013 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 B192021F9473; Thu, 3 Oct 2013 22:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.766 X-Spam-Level: X-Spam-Status: No, score=-5.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666] 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 aVYWo6olM+Rh; Thu, 3 Oct 2013 22:37:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 32EDC21F8F07; Thu, 3 Oct 2013 22:37:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYO56871; Fri, 04 Oct 2013 05:37:26 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 4 Oct 2013 06:37:07 +0100 Received: from SJCEML402-HUB.china.huawei.com (10.212.94.43) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 4 Oct 2013 06:37:23 +0100 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.42]) by sjceml402-hub.china.huawei.com ([10.212.94.43]) with mapi id 14.03.0146.000; Thu, 3 Oct 2013 22:37:18 -0700 From: Tina TSOU To: "draft-ietf-ecrit-unauthenticated-access@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: SecDir Review of draft-ietf-ecrit-unauthenticated-access-07 Thread-Index: Ac671O5/aaM/A3W3Ty2ARse4ihsI+gE7tu1U Date: Fri, 4 Oct 2013 05:37:18 +0000 Message-ID: <4E704CFA-0D3B-475C-98D5-3F09CD5218E8@huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E704CFA0D3B475C98D53F09CD5218E8huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [secdir] SecDir Review of draft-ietf-ecrit-unauthenticated-access-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, 04 Oct 2013 05:37:40 -0000 --_000_4E704CFA0D3B475C98D53F09CD5218E8huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Some other nits: * Section 1, page 2: to PSAP URI by offering LoST [RFC5222] services. Please expand the acronymns. * Section 1, page 4: help may find himself/herself in, for example, a NAA and NASP situation, as explained in more details in Figure 1. s/details/detail/? * Section 1, page 4: We discuss each case in more details in Section 3. s/detail/details/ * Section 5, page 8: As an initial step the devices attaches to the network as shown in step (1). * Section 5, page 8: o When the link layer network attachment procedure is completed the end host learns basic IP configuration information using DHCP from the ISP, as shown in step (2). Does this assume IPv4? (DHCPv6 is not mandatory for IPv6.) * Section 5.1.3, page 10: The description in Section 6.5 and 6.6 of [RFC6881] regarding the interaction between the device and the LIS applies to this document. s/6.6/Section 6.6/ -- this e.g. allows the html version of this document to contain an hyperlink to the corresponding section of such RFC. Section 6.1, page 13: o Dependency on the specific access network architecture. Access authorization and policy decisions typically happen at a different layers of the protocol stack and in different entities than those terminating the link-layer signaling. s/different layers/different layer/ Thank you, Tina On Sep 27, 2013, at 3:57 PM, "Tina TSOU" > wrote: Dear all, 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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. Draft-ietf-ecrit-unauthenticated-access-07 provides extensions to the emerg= ency services architecture described in other documents to allow emergency = services calling to proceed even when the caller is unauthenticated and una= uthorized. The draft is particularly relevant to mobile devices, where such= a situation is most likely to arise. It assumes separate entities provide = network access and process calls at the application level, and based on tha= t, deals with three cases, not necessarily mutually exclusive: -- no access authentication; -- no application service provider reachable; -- subscribed application service provider reachable but ordinary service denied because of zero credit balance or other reasons. Full understanding of this document required review of RFC 5069 (security r= equirements specifically for emergency call marking and mapping), RFC 6443,= the emergency calling framework, and RFC 6881, a BCP specifying requiremen= ts for various components of the emergency calling system beginning with th= e subscriber device. The draft states that it is forward-looking, and is input for other SDOs. O= ne example of this is the reliance on DHCP provisioning, which is at this p= oint little-implemented in cellular devices. General remark: the document is very heavy on abbreviations, which makes se= rious demands on the novice reader at some points. The terminology and abbr= eviations are introduced quite properly at the beginning of the document, b= ut the authors might still ease the reader's task by spelling out at least = the less-used abbreviations either whenever used (if only two or three time= s) or perhaps once per section. General assessment: The document is basically ready, but lacks a statement = of the specific points in RFCs 6443 and 6881 that need to be changed due to= lack of authentication or authorization. As a result, the NASP and NAA sec= tions are unmotivated. Editorial: Section 7 in a few places does not quite seem to say what I thin= k it means, hence the following suggestions: Suggestion, sec. 7, fourth para, first sentence: Currently: "We only illustrate a possible model." Suggested: "We illustrate just one possible model for obtaining the destina= tion addresses to which emergency callers should be restricted in the NAA c= ase." In the next sentence, missing some words: "... as well as the address of the LoST server itself." ^^^^^^^^^^^^^^ Suggestion, sec. 7, fifth para, first sentence: Currently: "For the ZBP case the additional aspect of fraud has to be consi= dered." Suggested: "The additional aspect of fraud also has to be considered for th= e ZBP case." Typos: Typo, sec. 5, first bullet: devices -> device Typo, sec. 7, second para, last sentence: lead -> led Typo, sec. 7, third para, fourth line: fraudulent -> fraudulently Thank you, Tina --_000_4E704CFA0D3B475C98D53F09CD5218E8huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear all,
Some other nits:
* Section 1, page 2:
to PSAP UR= I by offering LoST [RFC5222] services.

Please expand the acronymns.


* Section 1, page 4:
 &nbs= p;help may find himself/herself in, for example, a NAA and NASP
 &nbs= p;situation, as explained in more details in Figure 1.
s/details/detail/?


* Section 1, page 4:
We discuss= each case in more details in Section 3.

s/detail/details/


* Section 5, page 8:
As an init= ial step the devices attaches to the network as shown in
 &nbs= p;   step (1).


* Section 5, page 8:
 &nbs= p;o  When the link layer network attachment procedure is completed the=
 &nbs= p;   end host learns basic IP configuration information usin= g DHCP from
 &nbs= p;   the ISP, as shown in step (2).
Does this assume IPv4? (DHCPv6 is not mandatory for IPv6.)


* Section 5.1.3, page 10:
The descri= ption in Section 6.5 and 6.6
 &nbs= p;of [RFC6881] regarding the interaction between the device and the LIS
 &nbs= p;applies to this document.

s/6.6/Section 6.6/ -- this e.g. allows the html version of this document to contain an hyperlink to the corresponding section of such RFC.


Section 6.1, page 13:
 &nbs= p;o  Dependency on the specific access network architecture.  Acc= ess
 &nbs= p;   authorization and policy decisions typically happen at = a different
 &nbs= p;   layers of the protocol stack and in different entities = than those
 &nbs= p;   terminating the link-layer signaling.
s/different layers/different layer/

Thank you,
Tina

On Sep 27, 2013, at 3:57 PM, "Tina TSOU" <Tina.Tsou.Zouting@huawei.com> wrote:

Dear all,

I have reviewed this document as part of the securit= y directorate's ongoing effort to review all IETF documents being processed= by the IESG.  These comments were written primarily for the benefit o= f the security area directors.  Document editors and WG chairs should treat these comments just like any other last= call comments.

 

Draft-ietf-ecrit-unauthenticated-access-07 provides = extensions to the emergency services architecture described in other docume= nts to allow emergency services calling to proceed even when the caller is = unauthenticated and unauthorized. The draft is particularly relevant to mobile devices, where such a situati= on is most likely to arise. It assumes separate entities provide network ac= cess and process calls at the application level, and based on that, deals w= ith three cases, not necessarily mutually exclusive:

   -- no access authentication;=

   -- no application service provider reac= hable;

   -- subscribed application service provi= der reachable but ordinary

      service denied becaus= e of zero credit balance or other reasons.

Full understanding of this document required review = of RFC 5069 (security requirements specifically for emergency call marking = and mapping), RFC 6443, the emergency calling framework, and RFC 6881, a BC= P specifying requirements for various components of the emergency calling system beginning with the subscriber d= evice.

 

The draft states that it is forward-looking, and is = input for other SDOs. One example of this is the reliance on DHCP provision= ing, which is at this point little-implemented in cellular devices.

 

General remark: the document is very heavy on abbrev= iations, which makes serious demands on the novice reader at some points. T= he terminology and abbreviations are introduced quite properly at the begin= ning of the document, but the authors might still ease the reader's task by spelling out at least the less-used = abbreviations either whenever used (if only two or three times) or perhaps = once per section.

 

General assessment: The document is basically ready,= but lacks a statement of the specific points in RFCs 6443 and 6881 that ne= ed to be changed due to lack of authentication or authorization. As a resul= t, the NASP and NAA sections are unmotivated.

 

Editorial: Section 7 in a few places does not quite = seem to say what I think it means, hence the following suggestions:

 

Suggestion, sec. 7, fourth para, first sentence:

Currently: "We only illustrate a possible model= ."

Suggested: "We illustrate just one possible mod= el for obtaining the destination addresses to which emergency callers shoul= d be restricted in the NAA case."

 

In the next sentence, missing some words: "... = as well

    as the address of the LoST server= itself."

       ^^^^^^^^^^^^^^<= o:p>

 

Suggestion, sec. 7, fifth para, first sentence:=

Currently: "For the ZBP case the additional asp= ect of fraud has to be considered."

Suggested: "The additional aspect of fraud also= has to be considered for the ZBP case."

 

 

Typos:

 

Typo, sec. 5, first bullet: devices -> device

 

Typo, sec. 7, second para, last sentence: lead ->= led

 

Typo, sec. 7, third para, fourth line: fraudulent -&= gt; fraudulently

 

Thank you,

Tina

 

--_000_4E704CFA0D3B475C98D53F09CD5218E8huaweicom_-- From magnusn@gmail.com Thu Oct 3 23:05:24 2013 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 61CE421F99E7; Thu, 3 Oct 2013 23:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-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 1ZzXofPrlTNd; Thu, 3 Oct 2013 23:05:15 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id C827321F99FB; Thu, 3 Oct 2013 23:04:44 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hv10so1485334vcb.22 for ; Thu, 03 Oct 2013 23:04:44 -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:cc:content-type; bh=GKZTVa7MgFN9y3YBWbJRJcFJw88wz4DkFhqyERE2v6A=; b=jolwFNwvwZ4+fHGI7VE8ko7GgO+3/S6arS8KemN48YffcavJ5UstifpFAygDFSsbQf lkoNYsEFiuZ/TtFh/dkOzkFELpiUKSOt/Y+3OnpI8gRikaOLjeiQt3O/JdsWbKRgfgRZ IPNny2209zHlLH2oxb6+RqFAYssq5Sf1jJrArR3BqQMwl5HxrTMKGJgBrSBALPGcLS9E FjkxnxZyt7FdGjJ9kyZySxV7CnscKpExC+ZWFCt+KlIoaFtMEM8fRWBO5w2z3cUlJiVe MJdHRbv32mknTrv5AIZByHfFJYqPNdv4xwoAXTfJhkJ2OyFqnxaX6Bm5FcQ6Vlhsxun1 Mnpg== MIME-Version: 1.0 X-Received: by 10.58.133.66 with SMTP id pa2mr10947454veb.18.1380866684186; Thu, 03 Oct 2013 23:04:44 -0700 (PDT) Received: by 10.52.178.9 with HTTP; Thu, 3 Oct 2013 23:04:44 -0700 (PDT) Date: Thu, 3 Oct 2013 23:04:44 -0700 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: "secdir@ietf.org" , draft-ietf-insipid-session-id-reqts@tools.ietf.org Content-Type: multipart/alternative; boundary=047d7b67317e31760104e7e41492 Cc: "iesg@ietf.org" Subject: [secdir] Security directorate review of draft-ietf-insipid-session-id-reqts-08 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, 04 Oct 2013 06:05:25 -0000 --047d7b67317e31760104e7e41492 Content-Type: text/plain; charset=ISO-8859-1 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 insipid document describes requirements on an end-to-end session identifier for IP-based multimedia transports. End-to-end identifiers that meet the criteria defined in this document may well raise privacy concerns. The authors do note this and has included a reasonable discussion around potential mitigations etc. in the Security Considerations section. It remains to be seen if actual identifier definitions will be able to mitigate these concerns. An editorial comment: In Section 4.6, should the first use of "restrictive" instead read "permissive"? -- Magnus --047d7b67317e31760104e7e41492 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security= directorate's ongoing effort to review all IETF documents being proces= sed by the IESG. These comments were written primarily for the benefit of t= he security area directors. Document editors and WG chairs should treat the= se comments just like any other last call comments.

This insipid document describes requirements on an end-to-end session i= dentifier for IP-based multimedia transports. End-to-end identifiers that m= eet the criteria defined in this document may well raise privacy concerns. = The authors do note this and has included a reasonable discussion around po= tential mitigations etc. in the Security Considerations section. It remains= to be seen if actual identifier definitions will be able to mitigate these= concerns.

An editorial comment: In Section 4.6, should the first use of &qu= ot;restrictive" instead read "permissive"?

-- Magnus
--047d7b67317e31760104e7e41492-- From bew@cisco.com Fri Oct 4 19:45:55 2013 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 A275521F9E02; Fri, 4 Oct 2013 19:45:55 -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 G9EmDYZJcGV7; Fri, 4 Oct 2013 19:45:50 -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 1D9E021F9E39; Fri, 4 Oct 2013 19:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6553; q=dns/txt; s=iport; t=1380941134; x=1382150734; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=wfXf3A8G+jN2AOyjHtHOUmeUtENNC03gkL6wMCsSAX4=; b=GI9/RdV7ISMHp0qtXfpYnK5HQCkKTrXD+T7ldQFj0o/HDhuhaSNJP4b3 tmmwN6MPIVC2S1+GtBez1BGzL8HKASR2DFHj1YF7KP1EG9+8adKIfGiyF gcNdDwhj9pYmBXF3vIYnvMYsxo4TKAGq+osZ+NRneTUBBj0jRC3mPcVDi Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAIl8T1KrRDoH/2dsb2JhbABZgwfCJIEWFnSCZi0SgT4BiBe8W49RgyaBBAOJOY5IkX+DRByBLiQ X-IronPort-AV: E=Sophos;i="4.90,1037,1371081600"; d="scan'208";a="91379258" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 05 Oct 2013 02:45:26 +0000 Received: from stealth-10-32-244-211.cisco.com (stealth-10-32-244-211.cisco.com [10.32.244.211]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r952jPwT014040; Sat, 5 Oct 2013 02:45:25 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Oct 2013 19:45:24 -0700 Message-Id: <43CA5AEB-DCB8-46FE-9176-D62CD511BADC@cisco.com> To: "secdir@ietf.org" , The IESG Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: draft-ietf-radext-dtls.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-radext-dtls-06 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, 05 Oct 2013 02:45:55 -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 describes requirements and implementation details = regarding using DTLS as a transport layer for RADIUS packets. It is a = companion to RFC 6614 ("TLS Encryption for RADIUS"), and this I-D = references many of the sections in that RFC rather than re-defining = them. While the security considerations of encapsulating RADIUS in TLS = and DTLS are very similar there are a number of operational issues where = a UDP protocol is more advantageous than a TCP, and vice versa. Both = documents are worth specifying; providing more secure alternatives to = the simple RADIUS MD5 integrity checks is critical. I have the following suggestions to tighten up the document. 1. Section 2.1, bottom of page 6. It is surprising that RADIUS/DTLS = would cause a change to the RADIUS data packet handling. If item (1) is = referring to the checks described in the RADIUS Length description = (Section 3 of RFC 2865), I don't understand why the RADIUS description = would change. RFC 2865 seems to clearly say that the RADIUS length check = only covers bytes within the RADIUS data packet, and so the length = carried in the UDP packet would not be relevant to RADIUS. If a RADIUS = packet is decapsulated from DTLS I would expect exactly the same = situation. Is the use of a UDP packet length actually an implementation = issue, or is there another RADIUS length check that I'm missing? (Note = that if a change is made to this text, it might also need to be = reflected in Section 2.2.1.) 2. Section 2.2.1, top of page 8. Is the statement "Client identities can = be determined from TLS parameters" strong enough? Using the TLS = parameters seems to be a much stronger statement, especially in the = wildcarding case mentioned in the Security Considerations. Perhaps s/can = be/SHOULD be/.=20 3. Section 2.2.1. There's no comment on whether RFC 6614 Section 3.4 = item (2) applies to RADIUS/DTLS. It would be good to be consistent and = add something here. 4. Section 3.2. The second paragraph says: "Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports. Early drafts of this specification permitted this behavior. It is forbidden here, as it depended on behavior in DTLS which may change without notice." This is in line with WG consensus, so is correct. But there are some = other sections that seem to conflict with this and probably need to be = updated as well: - Section 2.2.1 has three instances of "When DTLS is used over the = existing RADIUS/UDP ports ...", which seems to be forbidden now. Should = these all just say "Section 3.4 item (N) applies to RADIUS/DTLS"? - Section 5.1.1 says "The requirement to accept RADIUS/UDP and = RADIUS/DTLS on the same port makes this recommendation difficult to = implement in practice." This seems out of date. - Section 10 says " "The main portion of the specification that could have security implications is a servers ability to accept both RADIUS and DTLS packets on the same port. The filter that disambiguates the two protocols is simple, and is just a check for the value of one octet. We do not expect this check to have any security issues." I assume this should be removed since accepting both on one port is = forbidden.=20 5. Section 5. I understand that RADIUS/DTLS creates connections where = RADIUS/UDP had none, so there are some new considerations around keeping = track of connections. But the section begins by saying that = implementations are free to choose their method. Since the = implementation details of this section aren't vital to understanding = RADIUS/DTLS, and are frankly quite complex, it might be better = organization to put the text in Section 6 ("Implementation Guidelines"). = This would make it easier to understand the protocol details. 6. Section 5.1. Why is this a MUST? Is it required for interoperability? = If not, I think it should be a recommendation. "A RADIUS/DTLS server MUST track ongoing DTLS client connections based on a key composed of the following 4-tuple...." 7. Section 5.1.1, bottom of page 11. What does the term "failed = security" mean? Is there a more precise way to say this?=20 8. Section 5.2.2, top of page 12. I assume the errors mentioned here are = errors in the decrypted RADIUS data packet. Why is it necessary to = mention these? Aren't they also necessary checks for RADIUS/UDP? 9. Section 6. Can you cite a rationale for choosing these PSK key sizes? = Do they represent a particular strength? 10. Section 10. Having a fixed key always comes with threats. It would = be helpful to mention that if the RADIUS/DTLS session becomes a = RADIUS/UDP session due to configuration or implementation error, that = the fixed RADIUS MD5 key would provide no security since the key was = trivially known. 11. Section 10.1. It would be fair to say that using either RADIUS/DTLS = or RADIUS/TLS is recommended. I suggest adding "or RFC 6614" to the end = of the 2nd sentence. 12. Section 10.4. I don't think this document can make normative = requirements on previous RFCs so "NOT RECOMMENDED" should probably be in = lower case. I would also reword the second paragraph something like this = to get the point across better: "The use of RADIUS/DTLS can allow for = the safe usage of wildcards. When RADIUS/DTLS is used with wildcards = clients MUST be uniquely identified using TLS parameters, and any = certificate or PSK used MUST be unique to each client". 13. Section 10.5. The first paragraph says "This requirement is due to = security considerations.". Could you state them please? 14. Section 10.5. The second paragraph says: "Similarly, any RADIUS traffic failing validation means that two parties do not share the same security parameters, and the session is therefore a security risk." Aren't the security parameters all in DTLS? This seems like a security = consideration of the normal operation of DTLS. DTLS is going to detect = if there's a mismatch between the two endpoints and so there won't be a = security risk. I think this sentence should be omitted. Hope that helps, Brian= From mlepinski.ietf@gmail.com Fri Oct 4 19:52:24 2013 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 9A71521F9D9A; Fri, 4 Oct 2013 19:52:23 -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, HTML_MESSAGE=0.001, NO_RELAYS=-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 ZTqDhBDq5Fxg; Fri, 4 Oct 2013 19:52:22 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0229421F9E44; Fri, 4 Oct 2013 19:52:20 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id n9so3342751qcw.5 for ; Fri, 04 Oct 2013 19:52:20 -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:cc:content-type; bh=WFjuHYnKXBFj9m2OkSfq+JOfjBYLmBkbeGTilhteidM=; b=rQ8Xd0e83Q7rm1klbVI6PJycNPAD6jWzuUKH12X/u8CrDf9Pyes9l7jXxtzO/l2w5N Ys8osQfLb1YgZ8Thth60U/ZHxIywzOt+Syif0nvMFFb27H831jDHK61fUn6SoR2v0CCK HVKyE8ifwkePSMtxLsrG0lpocjPAqlHahyT2dNJSyKM0txTdANdSSSkEgbW5lZmfhLmA OyvaVdb8jPgv3PcYACIoK460PWhHOG/1a7JeEjBr7ktMve0DsKup5mt1hWmMwD92GRZt agsw+d04hSDHUEl5KlcbqnzqmTmngwEQ8SARguHYdO7FlICovUcNE1SyvtMV1vXckH7Y CIpw== MIME-Version: 1.0 X-Received: by 10.224.126.197 with SMTP id d5mr22656795qas.1.1380941540500; Fri, 04 Oct 2013 19:52:20 -0700 (PDT) Received: by 10.49.81.9 with HTTP; Fri, 4 Oct 2013 19:52:20 -0700 (PDT) Date: Fri, 4 Oct 2013 22:52:20 -0400 Message-ID: From: Matthew Lepinski To: "secdir@ietf.org" , "iesg@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f13ea9afa29af04e7f5816d Cc: draft-ietf-l2vpn-pbb-vpls-interop.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-l2vpn-pbb-vpls-interop-05 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, 05 Oct 2013 02:52:27 -0000 --e89a8f13ea9afa29af04e7f5816d Content-Type: text/plain; charset=ISO-8859-1 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. Summary: With the exception of the minor editorial issues below, I believe this document is ready to publish This is an informational document that describes how to use Hierarchical Virtual Private LAN Service (H-VPLS) [RFC 4762] with the IEEE's 802.1ah specification for Provider Backbone Bridging. In particular, the document lays out four deployment scenarios and describes how the two technologies inter-operate in each scenario (to achieve better scaling propertires than one would get without use of 802.1ah). The authors claim that the use of 802.1ah introduces no security concerns beyond the general considerations in any H-VPLS deployment, which are documented in RFC 4762 (and RFC 4111). I am inclined to agree. Although I don't have a deep enough knowledge of H-VPLS to be certain, I think that some of the security concerns documents in RFC 4762 (e.g., traffic isolation and certain kinds of denial of service attacks) are actually somewhat alleviated through the use of Provider Backbone Bridging. EDITORIAL COMMENTS: As someone who does not ordinarily read L2VPN documents, I would find it very helpful if you could expand each acronym the first time it is used. In particular, I would have found it very helpful if you had expanded VPLS when it appears in the first sentence of the introduction. (I also would have found it quite helpful to include a reference to 4762 early in the introduction as well.) Additionally, In understanding the security considerations for this document, I personally found it very useful to read portions of RFC 4111. RFC 4111 is referenced by RFC 4762, but I think it would be helpful to provide a direct reference to RFC 4111 in the security considerations for this document. (As opposed to just referencing RFC 4762.) This is a small editorial point, but as a reader, I would prefer a direct link to a document that is likely to be of interest, as opposed to following a sequence of references. --e89a8f13ea9afa29af04e7f5816d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's o= ngoing effort to review all IETF documents being processed by the=A0= IESG. =A0These = comments were written primarily for the benefit of the security area direct= ors. =A0Document editors and WG chairs should treat these comments just lik= e any other last call comments.

Sum= mary: With the exception of the minor editorial issues below, I believe thi= s document is ready to publish

This is an informational docum= ent that describes how to use=A0Hierarchical Virtual Private LAN Service (H= -VPLS) [RFC 4762] with the IEEE's 802.1ah specification for Provider Ba= ckbone Bridging. In particular, the document lays out four deployment scena= rios and describes how the two technologies=A0inter-operate=A0in each scena= rio (to achieve better scaling propertires than one would get without use o= f 802.1ah).

The authors claim that the use of 802.1ah introduces no s= ecurity concerns beyond the general considerations in any H-VPLS deployment= , which are documented in RFC 4762 (and RFC 4111). I am inclined to agree. = Although I don't have a deep enough knowledge of H-VPLS to be certain, = I think that some of the security concerns documents in RFC 4762 (e.g., tra= ffic isolation and certain kinds of denial of service attacks) are actually= somewhat=A0alleviated=A0through the use of Provider Backbone Bridging.=A0<= /font>

EDITORIAL COMMENTS:
As someone who does not ordin= arily read L2VPN documents, I would find it very helpful if you could expan= d each=A0acronym=A0the first time it is used. In particular, I would have f= ound it very helpful if you had expanded VPLS when it appears in the first = sentence of the introduction. (I also would have found it quite helpful to = include a reference to 4762 early in the introduction as well.)

Additionally, In understanding the security consideration= s for this document, I personally found it very useful to read portions of = RFC 4111. RFC 4111 is referenced by RFC 4762, but I think it would be helpf= ul to provide a direct reference to RFC 4111 in the security considerations= for this document. (As opposed to just referencing RFC 4762.) This is a sm= all editorial point, but as a reader, I would prefer a direct link to a doc= ument that is likely to be of interest, as opposed to following a sequence = of references.
--e89a8f13ea9afa29af04e7f5816d-- From aland@deployingradius.com Sat Oct 5 18:34:21 2013 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 C80DD21F9DC9; Sat, 5 Oct 2013 18:34:21 -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 3uDeJzVNnE4E; Sat, 5 Oct 2013 18:34:15 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA6F21F9DCF; Sat, 5 Oct 2013 18:34:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 2ED2E2240107; Sun, 6 Oct 2013 03:34:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve-gNvOiU7xc; Sun, 6 Oct 2013 03:34:07 +0200 (CEST) Received: from Thor-2.local (bas1-ottawa11-1176121002.dsl.bell.ca [70.26.46.170]) by power.freeradius.org (Postfix) with ESMTPSA id D24A922400F0; Sun, 6 Oct 2013 03:34:06 +0200 (CEST) Message-ID: <5250BE14.2000005@deployingradius.com> Date: Sat, 05 Oct 2013 21:34:12 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Brian Weis References: <43CA5AEB-DCB8-46FE-9176-D62CD511BADC@cisco.com> In-Reply-To: <43CA5AEB-DCB8-46FE-9176-D62CD511BADC@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-radext-dtls.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-radext-dtls-06 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, 06 Oct 2013 01:34:21 -0000 Brian Weis wrote: > I have the following suggestions to tighten up the document. > > 1. Section 2.1, bottom of page 6. It is surprising that RADIUS/DTLS would cause a change to the RADIUS data packet handling. If item (1) is referring to the checks described in the RADIUS Length description (Section 3 of RFC 2865), I don't understand why the RADIUS description would change. RFC 2865 seems to clearly say that the RADIUS length check only covers bytes within the RADIUS data packet, and so the length carried in the UDP packet would not be relevant to RADIUS. DTLS is replacing UDP as a transport later for RADIUS. So any text referring to UDP decapsulation should be replaced with DTLS decapsulation. RFC 2865 Section 3, top of page 15 says: ... Octets outside the range of the Length field MUST be treated as padding and ignored on reception. i.e. a UDP packet of 8K may only carry 32 octets of valid RADIUS data. The extra 8K-32 octets are discarded by the RADIUS layer. > If a RADIUS packet is decapsulated from DTLS I would expect exactly the same situation. Is the use of a UDP packet length actually an implementation issue, or is there another RADIUS length check that I'm missing? (Note that if a change is made to this text, it might also need to be reflected in Section 2.2.1.) The text guides implementors to not be lazy. The length of a RADIUS packet is determined by the RADIUS header, and *not* by the amount of data read from it's encapsulating protocol. > 2. Section 2.2.1, top of page 8. Is the statement "Client identities can be determined from TLS parameters" strong enough? Using the TLS parameters seems to be a much stronger statement, especially in the wildcarding case mentioned in the Security Considerations. Perhaps s/can be/SHOULD be/. Good point. I'll make it SHOULD. > 3. Section 2.2.1. There's no comment on whether RFC 6614 Section 3.4 item (2) applies to RADIUS/DTLS. It would be good to be consistent and add something here. It does apply. I'll add text to that effect. > 4. Section 3.2. The second paragraph says: > > "Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports. > Early drafts of this specification permitted this behavior. It is > forbidden here, as it depended on behavior in DTLS which may change > without notice." > > This is in line with WG consensus, so is correct. But there are some other sections that seem to conflict with this and probably need to be updated as well: > > - Section 2.2.1 has three instances of "When DTLS is used over the existing RADIUS/UDP ports ...", which seems to be forbidden now. Should these all just say "Section 3.4 item (N) applies to RADIUS/DTLS"? Yes. I'll fix it. > - Section 5.1.1 says "The requirement to accept RADIUS/UDP and RADIUS/DTLS on the same port makes this recommendation difficult to implement in practice." This seems out of date. I've deleted the old text, and fixed the surrounding text. > - Section 10 says " > "The main portion of the specification that could have security > implications is a servers ability to accept both RADIUS and DTLS > packets on the same port. The filter that disambiguates the two > protocols is simple, and is just a check for the value of one octet. > We do not expect this check to have any security issues." > I assume this should be removed since accepting both on one port is forbidden. Yes. > 5. Section 5. I understand that RADIUS/DTLS creates connections where RADIUS/UDP had none, so there are some new considerations around keeping track of connections. But the section begins by saying that implementations are free to choose their method. Since the implementation details of this section aren't vital to understanding RADIUS/DTLS, and are frankly quite complex, it might be better organization to put the text in Section 6 ("Implementation Guidelines"). This would make it easier to understand the protocol details. Arguably yes. I'm inclined to leave it as-is. The existing text motivates and frames the discussion of connection management. > 6. Section 5.1. Why is this a MUST? Is it required for interoperability? If not, I think it should be a recommendation. > > "A RADIUS/DTLS server MUST track ongoing DTLS client connections based > on a key composed of the following 4-tuple...." I'm willing to make that change. I'm curious as to how else the connections would be tracked. Would a single DTLS session send packets using multiple source IPs / ports? If so, how would the peer correlated a random packet to a particular session? > 7. Section 5.1.1, bottom of page 11. What does the term "failed security" mean? Is there a more precise way to say this? Perhaps "failing security requirements". When a connection doesn't meet the security configurations set by the host, the connection should not be accepted. > 8. Section 5.2.2, top of page 12. I assume the errors mentioned here are errors in the decrypted RADIUS data packet. Why is it necessary to mention these? Aren't they also necessary checks for RADIUS/UDP? When a RADIUS/UDP packet is malformed, it just means that the packet gets discarded. When you've set up a DTLS connection with someone, and he then sends you a malformed RADIUS packet, it means the entire DTLS session should be discarded. There was some discussion in the WG about this. In the end, I can't see any reason to maintain a DTLS session when the other end isn't sending RADIUS packets inside of it. > 9. Section 6. Can you cite a rationale for choosing these PSK key sizes? Do they represent a particular strength? They come from the WG discussion, if I recall. > 10. Section 10. Having a fixed key always comes with threats. It would be helpful to mention that if the RADIUS/DTLS session becomes a RADIUS/UDP session due to configuration or implementation error, that the fixed RADIUS MD5 key would provide no security since the key was trivially known. I'll add some text. > 11. Section 10.1. It would be fair to say that using either RADIUS/DTLS or RADIUS/TLS is recommended. I suggest adding "or RFC 6614" to the end of the 2nd sentence. OK. > 12. Section 10.4. I don't think this document can make normative requirements on previous RFCs so "NOT RECOMMENDED" should probably be in lower case. I would also reword the second paragraph something like this to get the point across better: "The use of RADIUS/DTLS can allow for the safe usage of wildcards. When RADIUS/DTLS is used with wildcards clients MUST be uniquely identified using TLS parameters, and any certificate or PSK used MUST be unique to each client". OK. > 13. Section 10.5. The first paragraph says "This requirement is due to security considerations.". Could you state them please? The next paragraph explains. > 14. Section 10.5. The second paragraph says: > > "Similarly, any RADIUS traffic failing validation > means that two parties do not share the same security parameters, and > the session is therefore a security risk." > > Aren't the security parameters all in DTLS? This seems like a security consideration of the normal operation of DTLS. DTLS is going to detect if there's a mismatch between the two endpoints and so there won't be a security risk. I think this sentence should be omitted. Someone may allow administrator configuration of the shared secret inside of DTLS, instead of fixing it as "radius/dtls". The two paragraphs should say: Section 5.1.1, above, requires that DTLS sessions be closed when the transported RADIUS packets are malformed, or fail the authenticator checks. The reason is that the connection is expected to be used for transport of RADIUS packets only. Any non-RADIUS traffic on that connection means the other party is misbehaving, and a potential security risk. Similarly, any RADIUS traffic failing validation means that two parties do not have a common same shared secret, and the session is therefore unauthenticated. I'll issue a new draft ASAP. From jouni.nospam@gmail.com Sun Oct 6 21:45:43 2013 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 75DB521E8145; Sun, 6 Oct 2013 21:45:41 -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 ykUh7cUk5CkP; Sun, 6 Oct 2013 21:45:40 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 215FD21E8151; Sun, 6 Oct 2013 21:45:30 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id ep20so5172717lab.29 for ; Sun, 06 Oct 2013 21:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iAKrCfqDT+UPrMihpY1JJcag6Heidh10UqSiITCRV0g=; b=r1KVFW99lHZy5FSLiermZSY9v5rhk2LwgldbR6lE/hvBJNvzS8L85BwPouNMhlqwxp g1BEcbKfeldZKFqjRuY9qw6Rwc5HU3WntMkXHdQ6nvyMFMoncK4ib0sJGZLjcbKka2bV taAv/P0Fr4zxNliSeJE0aNxeRDSwvaV4UCFK5ZmmFLvbaaBUuPnTamTrLMMD1AbZkgnC RVT0oOa1hpnDJ1IHS5l5JMFku97ortud45oBa8H4We+F0+Y9qdvTCuv9BvbJEJZEzMui bDH7Nt89v7V/6y5UaWOvezRwXiMGmCWeqG7P3lX3jM1wJe9q8oJTAWNeRnhiGOW83n3a XW2Q== X-Received: by 10.112.0.242 with SMTP id 18mr23500734lbh.18.1381121130060; Sun, 06 Oct 2013 21:45:30 -0700 (PDT) Received: from [10.37.184.110] ([77.95.242.69]) by mx.google.com with ESMTPSA id b1sm23491459lah.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Oct 2013 21:45:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <43CA5AEB-DCB8-46FE-9176-D62CD511BADC@cisco.com> Date: Mon, 7 Oct 2013 07:45:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5BF97336-DD0D-4D5D-8CB1-D40CD9B7D9AF@gmail.com> References: <43CA5AEB-DCB8-46FE-9176-D62CD511BADC@cisco.com> To: Brian Weis X-Mailer: Apple Mail (2.1510) Cc: draft-ietf-radext-dtls.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-radext-dtls-06 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, 07 Oct 2013 04:45:44 -0000 Thanks Brian for a thorough review. We'll look into these comments and = propose a resolution (as Alan has already started to do). - Jouni On Oct 5, 2013, at 5:45 AM, Brian Weis 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. >=20 > This document describes requirements and implementation details = regarding using DTLS as a transport layer for RADIUS packets. It is a = companion to RFC 6614 ("TLS Encryption for RADIUS"), and this I-D = references many of the sections in that RFC rather than re-defining = them. While the security considerations of encapsulating RADIUS in TLS = and DTLS are very similar there are a number of operational issues where = a UDP protocol is more advantageous than a TCP, and vice versa. Both = documents are worth specifying; providing more secure alternatives to = the simple RADIUS MD5 integrity checks is critical. >=20 > I have the following suggestions to tighten up the document. >=20 > 1. Section 2.1, bottom of page 6. It is surprising that RADIUS/DTLS = would cause a change to the RADIUS data packet handling. If item (1) is = referring to the checks described in the RADIUS Length description = (Section 3 of RFC 2865), I don't understand why the RADIUS description = would change. RFC 2865 seems to clearly say that the RADIUS length check = only covers bytes within the RADIUS data packet, and so the length = carried in the UDP packet would not be relevant to RADIUS. If a RADIUS = packet is decapsulated from DTLS I would expect exactly the same = situation. Is the use of a UDP packet length actually an implementation = issue, or is there another RADIUS length check that I'm missing? (Note = that if a change is made to this text, it might also need to be = reflected in Section 2.2.1.) >=20 > 2. Section 2.2.1, top of page 8. Is the statement "Client identities = can be determined from TLS parameters" strong enough? Using the TLS = parameters seems to be a much stronger statement, especially in the = wildcarding case mentioned in the Security Considerations. Perhaps s/can = be/SHOULD be/.=20 >=20 > 3. Section 2.2.1. There's no comment on whether RFC 6614 Section 3.4 = item (2) applies to RADIUS/DTLS. It would be good to be consistent and = add something here. >=20 > 4. Section 3.2. The second paragraph says: >=20 > "Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports. > Early drafts of this specification permitted this behavior. It is > forbidden here, as it depended on behavior in DTLS which may change > without notice." >=20 > This is in line with WG consensus, so is correct. But there are some = other sections that seem to conflict with this and probably need to be = updated as well: >=20 > - Section 2.2.1 has three instances of "When DTLS is used over the = existing RADIUS/UDP ports ...", which seems to be forbidden now. Should = these all just say "Section 3.4 item (N) applies to RADIUS/DTLS"? >=20 > - Section 5.1.1 says "The requirement to accept RADIUS/UDP and = RADIUS/DTLS on the same port makes this recommendation difficult to = implement in practice." This seems out of date. >=20 > - Section 10 says " > "The main portion of the specification that could have security > implications is a servers ability to accept both RADIUS and DTLS > packets on the same port. The filter that disambiguates the two > protocols is simple, and is just a check for the value of one octet. > We do not expect this check to have any security issues." > I assume this should be removed since accepting both on one port is = forbidden.=20 >=20 > 5. Section 5. I understand that RADIUS/DTLS creates connections where = RADIUS/UDP had none, so there are some new considerations around keeping = track of connections. But the section begins by saying that = implementations are free to choose their method. Since the = implementation details of this section aren't vital to understanding = RADIUS/DTLS, and are frankly quite complex, it might be better = organization to put the text in Section 6 ("Implementation Guidelines"). = This would make it easier to understand the protocol details. >=20 > 6. Section 5.1. Why is this a MUST? Is it required for = interoperability? If not, I think it should be a recommendation. >=20 > "A RADIUS/DTLS server MUST track ongoing DTLS client connections = based > on a key composed of the following 4-tuple...." >=20 > 7. Section 5.1.1, bottom of page 11. What does the term "failed = security" mean? Is there a more precise way to say this?=20 >=20 > 8. Section 5.2.2, top of page 12. I assume the errors mentioned here = are errors in the decrypted RADIUS data packet. Why is it necessary to = mention these? Aren't they also necessary checks for RADIUS/UDP? >=20 > 9. Section 6. Can you cite a rationale for choosing these PSK key = sizes? Do they represent a particular strength? >=20 > 10. Section 10. Having a fixed key always comes with threats. It would = be helpful to mention that if the RADIUS/DTLS session becomes a = RADIUS/UDP session due to configuration or implementation error, that = the fixed RADIUS MD5 key would provide no security since the key was = trivially known. >=20 > 11. Section 10.1. It would be fair to say that using either = RADIUS/DTLS or RADIUS/TLS is recommended. I suggest adding "or RFC 6614" = to the end of the 2nd sentence. >=20 > 12. Section 10.4. I don't think this document can make normative = requirements on previous RFCs so "NOT RECOMMENDED" should probably be in = lower case. I would also reword the second paragraph something like this = to get the point across better: "The use of RADIUS/DTLS can allow for = the safe usage of wildcards. When RADIUS/DTLS is used with wildcards = clients MUST be uniquely identified using TLS parameters, and any = certificate or PSK used MUST be unique to each client". >=20 > 13. Section 10.5. The first paragraph says "This requirement is due to = security considerations.". Could you state them please? >=20 > 14. Section 10.5. The second paragraph says: >=20 > "Similarly, any RADIUS traffic failing validation > means that two parties do not share the same security parameters, = and > the session is therefore a security risk." >=20 > Aren't the security parameters all in DTLS? This seems like a = security consideration of the normal operation of DTLS. DTLS is going to = detect if there's a mismatch between the two endpoints and so there = won't be a security risk. I think this sentence should be omitted. >=20 > Hope that helps, > Brian From zongning@huawei.com Mon Oct 7 23:19:08 2013 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 1DE3B11E8188; Mon, 7 Oct 2013 23:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 QQXIz519ZcIW; Mon, 7 Oct 2013 23:19:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0C05F11E8173; Mon, 7 Oct 2013 23:19:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYR84844; Tue, 08 Oct 2013 06:19:01 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 8 Oct 2013 07:18:21 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 8 Oct 2013 07:18:42 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.141]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0146.000; Tue, 8 Oct 2013 14:18:34 +0800 From: Zongning To: Brian Weis , "secdir@ietf.org" , The IESG Thread-Topic: Secdir review of draft-ietf-p2psip-drr-10 Thread-Index: AQHOvwS1/Rrc37LnZkOfnB5X4Y79y5nqV8bQ Date: Tue, 8 Oct 2013 06:18:33 +0000 Message-ID: References: <6340B78E-38C7-4B25-8CDD-36DC67C49A21@cisco.com> In-Reply-To: <6340B78E-38C7-4B25-8CDD-36DC67C49A21@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Tue, 08 Oct 2013 08:05:31 -0700 Cc: "draft-ietf-p2psip-drr.all@tools.ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-p2psip-drr-10 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, 08 Oct 2013 06:19:08 -0000 Hi, Brian, Thanks for your review. For the 1st and 2nd comments, we agree that Section 13.6 of the base draft = does not provide normative language and we didn't mean to change any of the= normative security recommendation of the base draft. Therefore, it maybe g= ood to add the following line "The security recommendations of Section 13 o= f base draft [] are applicable to this document" in the beginning of the se= curity section of DRR draft since Section 13.2 of the base draft provides t= he normative language you proposed. For the rest of the comments, please see inline. > -----Original Message----- > From: Brian Weis [mailto:bew@cisco.com] > Sent: Wednesday, October 02, 2013 8:16 AM > To: secdir@ietf.org; The IESG > Cc: draft-ietf-p2psip-drr.all@tools.ietf.org > Subject: Secdir review of draft-ietf-p2psip-drr-10 >=20 > [Resent with proper cc] >=20 > I have reviewed this document as part of the security directorate's ongoi= ng > effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the secur= ity > area directors. Document editors and WG chairs should treat these commen= ts > just like any other last call comments. >=20 > This document describes a routing mechanism for Peer-to-Peer Session Init= iation > Protocol (P2PSIP). The routing mechanism in the base P2PSIP protocol spec= ifies > an initiator sending a request message hop by hop through a DHT to a > responder, with the responder returning a reply using the reverse path. T= he > alternative routing method defined in this I-D describes a shortcut for t= he > response message. The response is returned directly to the initiator usin= g an IP > address provided by the initiator. This shortcut method is described as a= n > optimization that is useful in private networks where a self-reported IP = address > is likely to be reliable (i.e., no NAT). >=20 > The Security Considerations of this I-D depends entirely upon the Securit= y > Considerations of the base document (draft-ietf-p2psip-base-26). It shoul= d > probably be expanded to include some more discussion on DRR so that it is= clear. > I have some questions to start a discussion to help understand what might= need > to be added. >=20 > 1. The Security Considerations section states >=20 > "According to section 13 of the base drat[sic] the forwarding header MUST= be > digitally signed protecting the DRR routing information." >=20 > I hope it's actually true that the entire DRR message is signed. If so I = would > recommend stating this something like "According to section 13 of the bas= e > draft the entire routing message MUST be digitally signed, including the > forwarding header that specifies the DRR routing information". >=20 > 2. My interpretation reading Section 13 of draft-ietf-p2psip-base-26 is t= hat all > routing messages must also be protected. For example, Section 13.6.3 in t= he > base document says: >=20 > "... whenever a peer establishes a direct connection to another peer it > authenticates via certificate-based mutual authentication. All messages > between peers are sent over this protected channel and therefore the peer= s > can verify the data origin of the last hop peer for requests and response= s > without further cryptography." >=20 > I don't believe that DRR messages should be any exception, since the DRR > request messages would be subject to the Eclipse and Sybil attacks descri= bed in > the base document. The Security Considerations section in this I-D does n= ot say > that, even though it makes an effort to point out that the messages are d= igitally > signed. This I-D should also say that the messages are sent over a protec= ted > channel, or else the section needs to have a good justification as to why= the DRR > request messages do not require the same protection as SRR messages. I ca= n't > think of what that justification would be though! >=20 > 3. Table 1 and the preceding paragraph are a little confusing because > sometimes it says the messages are DTLS protected and sometimes they are = not. > If all of the routing messages are required to be encrypted then I'm not = sure > what the point of this comparison. The "No. of Hops" and "No. of Msgs" fi= elds in > Table 1 are also confusing because they seem to be comparing cases where > sometimes DTLS messages are included in the counts and sometimes they are > not. >=20 > - If it's true that SRR messages must always be protected by DTLS (or a s= imilar > protocol) then why isn't setting up the DTLS session included in the numb= er of > messages in the SRR row? Is that because the DLTS sessions are persistent > between the hops and are assumed to have already been setup? So are you > then including the DLTS setup messages in DRR(DTLS) because you assume th= ey > had not previously setup? [Ning] Section 5.1 provides comparison of the No. of messages between diffe= rent routing modes. DTLS session is persistent and there maybe cases where other security mecha= nisms will be used. So, the table compares the different options. >=20 > - The DRR rows shows 1 hop in the No. of Hops column, but that doesn't se= em to > be quite right because of the asymmetric nature of the DRR protocol. Shou= ldn't > it really be "log(N) + 1" to indicate the DRR request is log(N) hops and = the DRR > reply is one hop? [Ning] Section 5.1 discuss only the routing of the response message. That's= why in DRR it goes through one hop. >=20 > Overall this section needs to be clarify these things so a reader underst= ands the > relationship between the DRR routing messages and the DTLS secure > connections. >=20 > 4. When an intermediate peer receives a DRR message with the > IGNORE-STATE-KEEPING flag in the header, is it supposed to not maintain a= ny > security state or just not maintain routing state? [Ning] This flag is about routing state. >=20 > 5. Section 4.2 says: >=20 > "using DRR SHOULD be discouraged in the open Internet or if the administr= ator > does not feel he have enough information about the overlay network topolo= gy." >=20 > Is this due to any security reason, or just because the initiator's addre= ss > reported in the Destination structure might be wrong? [Ning] This is routing decision in order to verify that the initiator can s= upply a routable address. >=20 > 6. Section 5.1 says: >=20 > "Note that establishing (D)TLS secure connections for P2P overlay is not = optimal > in some cases, e.g. direct response routing where (D)TLS is heavy for tem= porary > connections. Instead, some alternate security techniques, e.g. using publ= ic keys > of the destination to encrypt the messages, and signing timestamps to pre= vent > reply attacks can be adopted." >=20 > It is not valuable to speculate on alternative security technique in this= section, > because the I-D does not define that security technique. If you think an > alternative to DTLS is useful, then I think that discussion belongs in a = new draft. [NIng] We agree that the line starting with "Instead" doesn't provide any v= alue in this section, then we can delete it. >=20 > Hope that helps, > Brian From sajassi@cisco.com Tue Oct 8 13:58:59 2013 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 A727B21F9E83; Tue, 8 Oct 2013 13:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 bVP5stxzV4qv; Tue, 8 Oct 2013 13:58:54 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 872A121F9FA4; Tue, 8 Oct 2013 13:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10128; q=dns/txt; s=iport; t=1381265933; x=1382475533; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=0QLMHvqPrKeLlHGR9jUavxG3JW7CCiWynP1lHYRPm8c=; b=cjw2LuKlkA5KCpAL9rxoN8/oxWpe4UdylhGmrvfnKIW2hFhEOvWt8LYv eGZFussFFwCZumE4mpkcBE0FKdHFdV/QJWI9HMNkFSwjxmDJLnZIKkG9/ YoglKBR5In9/mg86sk4O4whIsBomrOwEoYZz1p5Fwiqumt7zIoge63I6d g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAK9xVFKtJV2a/2dsb2JhbABZgkMjIYEKwSeBJRZ0giUBAQEEeRIBCA4DAwECCx0oERQJCAIEAQ0FCIdsAw8BsEsNiWuMV4I6IBEHgx+BBAOWGI4zhTaDJIIq X-IronPort-AV: E=Sophos;i="4.90,1058,1371081600"; d="scan'208,217";a="269690490" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 08 Oct 2013 20:58:45 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r98KwjAW014134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Oct 2013 20:58:45 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 8 Oct 2013 15:58:44 -0500 From: "Ali Sajassi (sajassi)" To: Matthew Lepinski , "secdir@ietf.org" , "iesg@ietf.org" Thread-Topic: Secdir review of draft-ietf-l2vpn-pbb-vpls-interop-05 Thread-Index: AQHOwXX52ozvjzTagE+RqVrPZ6vifpnrLeyA Date: Tue, 8 Oct 2013 20:58:44 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B215BDA3C@xmb-aln-x13.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.128.2.47] Content-Type: multipart/alternative; boundary="_000_69670F7146898C4583F56DA9AD32F77B215BDA3Cxmbalnx13ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 08 Oct 2013 14:01:16 -0700 Cc: "draft-ietf-l2vpn-pbb-vpls-interop.all@tools.ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-l2vpn-pbb-vpls-interop-05 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, 08 Oct 2013 20:58:59 -0000 --_000_69670F7146898C4583F56DA9AD32F77B215BDA3Cxmbalnx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Matthew, Thanks for your comments. I have incorporated them into rev06 of this docum= ent. Cheers, Ali From: Matthew Lepinski > Date: Friday, October 4, 2013 10:52 PM To: "secdir@ietf.org" >, "iesg@ietf.org" > Cc: "draft-ietf-l2vpn-pbb-vpls-interop.all@tools.ietf.org" > Subject: Secdir review of draft-ietf-l2vpn-pbb-vpls-interop-05 Resent-From: > Resent-To: >, >, >, Cisco Employee >, = >, > Resent-Date: Friday, October 4, 2013 10:52 PM 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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. Summary: With the exception of the minor editorial issues below, I believe = this document is ready to publish This is an informational document that describes how to use Hierarchical Vi= rtual Private LAN Service (H-VPLS) [RFC 4762] with the IEEE's 802.1ah speci= fication for Provider Backbone Bridging. In particular, the document lays o= ut four deployment scenarios and describes how the two technologies inter-o= perate in each scenario (to achieve better scaling propertires than one wou= ld get without use of 802.1ah). The authors claim that the use of 802.1ah introduces no security concerns b= eyond the general considerations in any H-VPLS deployment, which are docume= nted in RFC 4762 (and RFC 4111). I am inclined to agree. Although I don't h= ave a deep enough knowledge of H-VPLS to be certain, I think that some of t= he security concerns documents in RFC 4762 (e.g., traffic isolation and cer= tain kinds of denial of service attacks) are actually somewhat alleviated t= hrough the use of Provider Backbone Bridging. EDITORIAL COMMENTS: As someone who does not ordinarily read L2VPN documents, I would find it ve= ry helpful if you could expand each acronym the first time it is used. In p= articular, I would have found it very helpful if you had expanded VPLS when= it appears in the first sentence of the introduction. (I also would have f= ound it quite helpful to include a reference to 4762 early in the introduct= ion as well.) Additionally, In understanding the security considerations for this documen= t, I personally found it very useful to read portions of RFC 4111. RFC 4111= is referenced by RFC 4762, but I think it would be helpful to provide a di= rect reference to RFC 4111 in the security considerations for this document= . (As opposed to just referencing RFC 4762.) This is a small editorial poin= t, but as a reader, I would prefer a direct link to a document that is like= ly to be of interest, as opposed to following a sequence of references. --_000_69670F7146898C4583F56DA9AD32F77B215BDA3Cxmbalnx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Matthew,

Thanks for your comments. I have incorporated them into rev06 of this = document.

Cheers,
Ali

From: Matthew Lepinski <mlepinski.ietf@gmail.com>
Date: Friday, October 4, 2013 10:52= PM
To: "secdir@ietf.org" <= secdir@ietf.org>, "iesg@ietf.o= rg" <iesg@ietf.org>
Cc: "draft-ietf-l2vpn-pbb-vpls-in= terop.all@tools.ietf.org" <draft-ietf-l2vpn-pbb-vpls-interop.all@t= ools.ietf.org>
Subject: Secdir review of draft-iet= f-l2vpn-pbb-vpls-interop-05
Resent-From: <draft-alias-bounces@tools.ietf.org&= gt;
Resent-To: <florin.balus@alcatel-lucent.com>, <= ;giheron@cisco.com>, <nabil.n.bitar@verizon.com>, Cisco Employee <sajassi@cisco.com<= /a>>, <ssalam@cisco.com>, = <stewart@g3ysx.org.uk> Resent-Date: Friday, October 4, 201= 3 10:52 PM

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 securit= y area directors.  Document editors and WG chairs should treat these c= omments just like any other last call comments.

Summ= ary: With the exception of the minor editorial issues below, I believe this= document is ready to publish

This is an informational document that= describes how to use Hierarchical Virtual Private LAN Service (H-VPLS= ) [RFC 4762] with the IEEE's 802.1ah specification for Provider Backbone Br= idging. In particular, the document lays out four deployment scenarios and describes how the two technologies = inter-operate in each scenario (to achieve better scaling propertires = than one would get without use of 802.1ah).

The authors claim that the use of 802.= 1ah introduces no security concerns beyond the general considerations in an= y H-VPLS deployment, which are documented in RFC 4762 (and RFC 4111). I am = inclined to agree. Although I don't have a deep enough knowledge of H-VPLS to be certain, I think that some of= the security concerns documents in RFC 4762 (e.g., traffic isolation and c= ertain kinds of denial of service attacks) are actually somewhat allev= iated through the use of Provider Backbone Bridging. 

EDITORIAL COMMENTS:
As someone who does not ordinarily rea= d L2VPN documents, I would find it very helpful if you could expand each&nb= sp;acronym the first time it is used. In particular, I would have foun= d it very helpful if you had expanded VPLS when it appears in the first sentence of the introduction. (I also would have f= ound it quite helpful to include a reference to 4762 early in the introduct= ion as well.)

Additionally, In understanding the sec= urity considerations for this document, I personally found it very useful t= o read portions of RFC 4111. RFC 4111 is referenced by RFC 4762, but I thin= k it would be helpful to provide a direct reference to RFC 4111 in the security considerations for this docum= ent. (As opposed to just referencing RFC 4762.) This is a small editorial p= oint, but as a reader, I would prefer a direct link to a document that is l= ikely to be of interest, as opposed to following a sequence of references.
 --_000_69670F7146898C4583F56DA9AD32F77B215BDA3Cxmbalnx13ciscoc_-- From randy@psg.com Wed Oct 9 15:47:10 2013 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 9F60F21E8220; Wed, 9 Oct 2013 15:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 ldo9ofDpijxa; Wed, 9 Oct 2013 15:47:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6FF21E81C2; Wed, 9 Oct 2013 15:47:08 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VU2X4-0006ox-Qt; Wed, 09 Oct 2013 22:47:07 +0000 Date: Thu, 10 Oct 2013 07:47:05 +0900 Message-ID: From: Randy Bush To: Ben Laurie In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Wed, 09 Oct 2013 15:55:03 -0700 Cc: draft-ietf-idr-rfd-usable.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] Security review of draft-ietf-idr-rfd-usable-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: Wed, 09 Oct 2013 22:47:10 -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. > > Summary: draft is ready. thank you for the review > Whilst I accept the authors' assertion that this I-D does not > introduce any new security issues, the fact that an attacker can > introduce fake flap suggests that the underlying protocols need more > robust security mechanisms. indeed. and this is a serious problem with no progress in sight. randy From kivinen@iki.fi Thu Oct 10 01:33:50 2013 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 0854421E80E3 for ; Thu, 10 Oct 2013 01:33:50 -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 yzk1iLAU4hiQ for ; Thu, 10 Oct 2013 01:33:48 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 78C4B21E80E7 for ; Thu, 10 Oct 2013 01:33:47 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9A8Xifk023867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Oct 2013 11:33:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9A8XiXU009219; Thu, 10 Oct 2013 11:33:44 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21078.26216.454698.140022@fireball.kivinen.iki.fi> Date: Thu, 10 Oct 2013 11:33:44 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 2 min X-Total-Time: 2 min 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, 10 Oct 2013 08:33:50 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Charlie Kaufman is next in the rotation. For telechat 2013-10-10 Reviewer LC end Draft Rob Austein T 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Dave Cridland T 2013-10-03 draft-ietf-dhc-option-guidelines-14 Jeffrey Hutzelman T 2013-07-16 draft-yusef-dispatch-ccmp-indication-07 Kathleen Moriarty T 2013-10-01 draft-resnick-retire-std1-01 Sandy Murphy TR2013-09-20 draft-ietf-6man-ext-transmit-04 Ondrej Sury T 2013-09-27 draft-ietf-ecrit-psap-callback-12 Carl Wallace T 2013-09-30 draft-ietf-hip-reload-instance-09 Glen Zorn T 2013-09-27 draft-ietf-sipcore-rfc4244bis-callflows-06 For telechat 2013-10-24 Alan DeKok T 2013-10-18 draft-hethmon-mcmurray-ftpext-ftp-hosts-03 Donald Eastlake T 2013-10-10 draft-mcgrew-tls-aes-ccm-ecc-07 Last calls and special requests: Rob Austein 2013-10-16 draft-kolkman-proposed-standards-clarified-03 Dave Cridland - draft-ietf-httpbis-p5-range-24 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Shawn Emery 2013-10-20 draft-ietf-tictoc-security-requirements-05 Tobias Gondrom 2013-10-16 draft-ietf-6man-oversized-header-chain-08 Phillip Hallam-Baker 2013-10-16 draft-ietf-ccamp-gmpls-ospf-g709v3-09 Steve Hanna 2013-10-16 draft-ietf-manet-smf-mib-08 Dan Harkins 2013-10-16 draft-ietf-mpls-tp-rosetta-stone-12 David Harrington 2013-10-22 draft-ietf-avtext-multiple-clock-rates-10 Sam Hartman 2013-10-23 draft-ietf-ipfix-data-link-layer-monitoring-06 Paul Hoffman 2013-10-22 draft-ietf-mile-sci-09 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-04 Jeffrey Hutzelman 2013-11-04 draft-resnick-on-consensus-05 Leif Johansson 2013-11-04 draft-sin-sdnrg-sdn-approach-04 Simon Josefsson 2013-11-04 draft-trammell-ipfix-tcpcontrolbits-revision-04 Julien Laganier - draft-ietf-avtcore-rtp-security-options-07 Julien Laganier - draft-ietf-websec-key-pinning-08 Alexey Melnikov - draft-ietf-payload-rtp-howto-07 Vincent Roca 2013-09-24 draft-ietf-mmusic-duplication-grouping-03 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-13 Sam Weiler 2013-09-30 draft-ietf-opsec-ip-options-filtering-05 Tom Yu 2013-10-01 draft-ietf-sidr-origin-ops-22 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 -- kivinen@iki.fi From albert.cabellos@gmail.com Thu Oct 10 08:40:15 2013 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 2AD7B11E81E0 for ; Thu, 10 Oct 2013 08:40:15 -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, HTML_MESSAGE=0.001, NO_RELAYS=-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 hOlefM09pNXb for ; Thu, 10 Oct 2013 08:40:08 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id E7E2111E81DF for ; Thu, 10 Oct 2013 08:40:06 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id q8so2207203lbi.25 for ; Thu, 10 Oct 2013 08:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OkXdsYXhQ83mkyb2qsc0k8qW7ylnCOdmAdDTu6If0I0=; b=c8Oj86t9y1enTY11Nfeih1CeWGN+bq0kyAq2h1EeCPdVg7VwQKz9tJB3cMtWBCPc5C DTUJah8QwUoyNdIXmMrv0t8l5DuxCUUjIY/ov7/YELr+McnjHitrPkedOUqDhKZj1ZKV 8XWhhMupDR0mufjwAEphN9TtUMm9OtyTWcXBT8qCpmrhwb0MkuiBfbSzmwe9o5ZIqUN2 1bWLUSNewqOmuXu2ZGtEGTrB1Bn7fph7PZfy762Sd0IsdDn+ohBDRyq2MG+DVJFHLfPi /Li4f3ZdSmCP3uA1BD2t96VFe3Xjp+273V8FRvrw1SqqUiQp7IM+i9FFc2A9I4lSdFw4 xP8A== MIME-Version: 1.0 X-Received: by 10.152.243.42 with SMTP id wv10mr2104790lac.39.1381419605751; Thu, 10 Oct 2013 08:40:05 -0700 (PDT) Received: by 10.112.163.68 with HTTP; Thu, 10 Oct 2013 08:40:05 -0700 (PDT) In-Reply-To: <01D946E4-348D-4A3D-ABF8-B7DBD6F74F6E@kumari.net> References: <01D946E4-348D-4A3D-ABF8-B7DBD6F74F6E@kumari.net> Date: Thu, 10 Oct 2013 17:40:05 +0200 Message-ID: From: Albert Cabellos To: Warren Kumari Content-Type: multipart/alternative; boundary=001a1134290ce2fad004e864d07f X-Mailman-Approved-At: Thu, 10 Oct 2013 08:47:15 -0700 Cc: draft-ietf-lisp-deployment.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] SecDir Review of draft-ietf-lisp-deployment X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: acabello@ac.upc.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 15:44:26 -0000 --001a1134290ce2fad004e864d07f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Warren, See my replies inline, please let me know if the suggested changes address your comments, On Sat, Aug 24, 2013 at 1:19 AM, Warren Kumari 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 are= a > directors. Document editors and WG chairs should treat these comments jus= t > like any other last call comments. > > This draft describes LISP deployment scenarios. It represents current > thinking and is expected to change (I guess be obsoleted / replaced?) as > more experience is gained with deployment. > > Summary: I'm not sure what to do here. > > The document is very well written, and the authors seem to have taken car= e > to consider the implications of various deployment scenarios. > In spite of knowing very little about LISP I found the document to be > accessible and easily understood. It clearly lays out the considerations > for different deployments, and provides some guidance as to how to select= . > Thanks! > > > However, the security considerations section simply says: > "Security implications of LISP deployments are to be discussed in > separate documents. [I-D.ietf-lisp-threats ] gives an overview of > LISP threat models, while securing mapping lookups is discussed in > [I-D.ietf-lisp-sec]." > > This is a deployment document, and so this may be perfectly acceptable; > the "separate documents" may completely cover everything. Or not. > I am unclear if the authors mean that I-D.ietf-lisp-threats and > I-D.ietf-lisp-sec cover all security considerations, or if the implicatio= n > is that there will be other documents that cover the security implication= s. > http://i.imgur.com/5rTHfRs.jpg > > > What we try to explain is that both [I-D.ietf-lisp-threats] and [I-D.ietf-lisp-sec] cover all security considerations. As far as I know there are no plans to detail LISP security considerations in other documents. We suggest to rephrase this sentence to: "*All* security implications of LISP deployments are to be discussed in separate documents. [I-D.ietf-lisp-threats ] gives an overview of LISP threat models, while securing mapping lookups is discussed in [I-D.ietf-lisp-sec]" > > Section 2.4. "Inter-Service Provider Traffic Engineering" says: > "Failure to follow these recommendations may lead to operational and > security issues when deploying this scenario." > I think that a (short) explanation of what the security issues are if you > don't follow the recommendations would be nice. > > > Not following such recommendations means requiring participating ISPs to register prefixes they do not own, this in turn requires complex authentication mechanisms or facing traffic redirection attacks. We suggest to rephrase the paragraph from: "Second, the scenario is only recommended for ISPs providing connectivity to LISP sites, such that source RLOCs of packets to be recursively encapsulated belong to said ISP. Otherwise the participating ISPs must register prefixes they do not own in the above mentioned private mapping system. Failure to follow these recommendations may lead to operational and security issues when deploying this scenario." to "Second, the scenario is only recommended for ISPs providing connectivity to LISP sites, such that source RLOCs of packets to be recursively encapsulated belong to said ISP. Otherwise the participating ISPs must register prefixes they do not own in the above mentioned private mapping system. *This results in either requiring complex authentication mechanisms or enabling simple traffic redirection attacks.* Failure to follow these recommendations may lead to operational security issues when deploying this scenario" > Nits: > Section 4.2: > "For more details on P-ETRs see the [RFC6832] draft." -- I think that thi= s > could be better worded as "For more details on P-ETRs see [RFC6832]" (thi= nk > this was written while RFC6832 was still a draft). > > Right, thanks! > ID NITs complains about use of RFC2119 language ("It is NOT RECOMMENDED > for deployment"), but no RFC2119 reference / boilerplate. > I'm scraping the bottom of the barrel here, 'tis well written.. > Thanks for catching this, we=B4ll add a reference to RFC2119. > -- > It is impossible to sharpen a pencil with a blunt axe. It is equally vai= n > to try to do it with ten blunt axes instead. > -- E.W Dijkstra, 1930-2002 > > > > --001a1134290ce2fad004e864d07f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Warren,

See my replies inline, ple= ase let me know if the suggested changes address your comments,


On Sat, Aug 24, 201= 3 at 1:19 AM, Warren Kumari <warren@kumari.net> wrote:
I have reviewed this document as part of the security dire= ctorate's ongoing effort to review all IETF documents being processed b= y 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 describes LISP deployment scenarios. It represents current think= ing and is expected to change (I guess be obsoleted / replaced?) as more ex= perience is gained with deployment.

Summary: I'm not sure what to do here.

The document is very well written, and the authors seem to have taken care = to consider the implications of various deployment scenarios.
In spite of knowing very little about LISP I found the document to be acces= sible and easily understood. It clearly lays out the considerations for dif= ferent deployments, and provides some guidance as to how to select.

Thanks!
=A0


However, the security considerations section simply says:
"Security implications of LISP deployments are to be discussed in
=A0 =A0separate documents. =A0[I-D.ietf-lisp-threats ] gives an overview of=
=A0 =A0LISP threat models, while securing mapping lookups is discussed in =A0 =A0[I-D.ietf-lisp-sec]."

This is a deployment document, and so this may be perfectly acceptable; the= "separate documents" may completely cover everything. Or not. I am unclear if the authors mean that I-D.ietf-lisp-threats and I-D.ietf-li= sp-sec cover all security considerations, or if the implication is that the= re will be other documents that cover the security implications.
http://i.imgur= .com/5rTHfRs.jpg



What we try to explain is that both [I= -D.ietf-lisp-threats] and [I-D.ietf-lisp-sec] cover all security considerat= ions. As far as I know there are no plans to detail LISP security considera= tions in other documents. We suggest to rephrase this sentence to:

"*All* security implications of LISP deployments a= re to be discussed in
=A0 =A0separate documents. =A0[I-D.ietf-lisp-threa= ts ] gives an overview of
=A0 =A0LISP threat models, while securing mapp= ing lookups is discussed in
=A0 =A0[I-D.ietf-lisp-sec]"

=A0

Section 2.4. =A0"Inter-Service Provider Traffic Engineering" says= :
"Failure to follow these recommendations may lead to operational and s= ecurity issues when deploying this scenario."
I think that a (short) explanation of what the security issues are if you d= on't follow the recommendations would be nice.



Not following such recommendations mea= ns requiring participating ISPs to register prefixes they do not own, this = in turn requires complex authentication mechanisms or facing traffic redire= ction attacks. We suggest to rephrase the paragraph from:

&qu= ot;Second, the scenario is only recommended for ISPs providing
   connectivity to LISP sites, such that source RLOCs of packets to be
   recursively encapsulated belong to said ISP.  Otherwise the


   participating ISPs must register prefixes they do n=
ot own in the
   above mentioned private mapping system.  Failure to follow these
   recommendations may lead to operational and security issues when
   deploying this scenario."

to

"Second, the scenario is only recommended for = ISPs providing connectivity to LISP sites, such that source RLOCs of packet= s to be recursively encapsulated belong to said ISP. Otherwise the particip= ating ISPs must register prefixes they do not own in the above mentioned pr= ivate mapping system. *This results in either requiring complex authenticat= ion mechanisms or enabling simple traffic redirection attacks.* Failure to = follow these recommendations may lead to operational security issues when d= eploying this scenario"
=A0
Nits:
Section 4.2:
"For more details on P-ETRs see the [RFC6832] draft." -- I think = that this could be better worded as "For more details on P-ETRs see [R= FC6832]" (think this was written while RFC6832 was still a draft).


Right, thanks!
=A0
ID NITs complains about use of RFC2119 language ("It is NOT RECOMMENDE= D for deployment"), but no RFC2119 reference / boilerplate.
I'm scraping the bottom of the barrel here, 'tis well written..
=

Thanks for catching this, we=B4ll add a re= ference to=A0RFC2119.


--
It is impossible to sharpen a pencil with a blunt axe. =A0It is equally vai= n
to try to do it with ten blunt axes instead.
=A0 =A0 -- =A0E.W Dijkstra, 1930-2002




--001a1134290ce2fad004e864d07f-- From bew@cisco.com Thu Oct 10 09:00:09 2013 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 E421021E813B; Thu, 10 Oct 2013 09:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.103 X-Spam-Level: X-Spam-Status: No, score=-110.103 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 8r3rQ1Jd7HBk; Thu, 10 Oct 2013 09:00:01 -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 AB65121E8137; Thu, 10 Oct 2013 09:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9133; q=dns/txt; s=iport; t=1381420801; x=1382630401; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=jxukZeDOnqdjjuaKJ1Zq2FXh+sYEL6Di6Dg4mPs+hCo=; b=lElvY9ojRe0wH9i4NsmlilmL5kLIhc02ka7zEV+Qdn/pbQVCqoKI/R1S G9+gZs+0B5PXXCo1wPyNJvD+QEwq5TCuzzrxMG1UU1V+6yhAs08+cH0XE WR4sVYbslES7O+MvTm+zfwoUF4yMZAboVW4jAzNyYQvNaTQs3EIFo1wuZ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAFnOVlKrRDoH/2dsb2JhbABZgwfCM4EjFnSCJQEBAQMBZxIFCwsYLlcGE4gABbopjxQzB4MfgQQDiTyOSYY4i0qDRByBLiQ X-IronPort-AV: E=Sophos;i="4.90,1072,1371081600"; d="scan'208";a="94346945" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 10 Oct 2013 15:59:52 +0000 Received: from [10.154.161.207] ([10.154.161.207]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9AFxpbb004972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Oct 2013 15:59:51 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Weis In-Reply-To: <5250BE14.2000005@deployingradius.com> Date: Wed, 9 Oct 2013 20:38:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3385D735-1078-4DC4-8F39-91458BFE3907@cisco.com> References: <43CA5AEB-DCB8-46FE-9176-D62CD511BADC@cisco.com> <5250BE14.2000005@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.1508) Cc: draft-ietf-radext-dtls.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-radext-dtls-06 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, 10 Oct 2013 16:00:09 -0000 Hi Alan, The new draft looks good. I just have one comment below. On Oct 5, 2013, at 6:34 PM, Alan DeKok = wrote: > Brian Weis wrote: >> I have the following suggestions to tighten up the document. >>=20 >> 1. Section 2.1, bottom of page 6. It is surprising that RADIUS/DTLS = would cause a change to the RADIUS data packet handling. If item (1) is = referring to the checks described in the RADIUS Length description = (Section 3 of RFC 2865), I don't understand why the RADIUS description = would change. RFC 2865 seems to clearly say that the RADIUS length check = only covers bytes within the RADIUS data packet, and so the length = carried in the UDP packet would not be relevant to RADIUS. >=20 > DTLS is replacing UDP as a transport later for RADIUS. So any text > referring to UDP decapsulation should be replaced with DTLS = decapsulation. >=20 > RFC 2865 Section 3, top of page 15 says: >=20 > ... Octets outside the range of the Length field > MUST be treated as padding and ignored on reception. >=20 > i.e. a UDP packet of 8K may only carry 32 octets of valid RADIUS = data. > The extra 8K-32 octets are discarded by the RADIUS layer. >=20 >> If a RADIUS packet is decapsulated from DTLS I would expect exactly = the same situation. Is the use of a UDP packet length actually an = implementation issue, or is there another RADIUS length check that I'm = missing? (Note that if a change is made to this text, it might also need = to be reflected in Section 2.2.1.) >=20 > The text guides implementors to not be lazy. The length of a RADIUS > packet is determined by the RADIUS header, and *not* by the amount of > data read from it's encapsulating protocol. Thanks for the explanation. Would it also be accurate to say this? (1) The Length checks defined in [RFC2865] Section 3 MUST treat the decrypted DTLS data octets outside the range of the Length field as padding and ignore it on reception. I think something like that would be a lot clearer. Thanks, Brian >> 2. Section 2.2.1, top of page 8. Is the statement "Client identities = can be determined from TLS parameters" strong enough? Using the TLS = parameters seems to be a much stronger statement, especially in the = wildcarding case mentioned in the Security Considerations. Perhaps s/can = be/SHOULD be/.=20 >=20 > Good point. I'll make it SHOULD. >=20 >> 3. Section 2.2.1. There's no comment on whether RFC 6614 Section 3.4 = item (2) applies to RADIUS/DTLS. It would be good to be consistent and = add something here. >=20 > It does apply. I'll add text to that effect. >=20 >> 4. Section 3.2. The second paragraph says: >>=20 >> "Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports. >> Early drafts of this specification permitted this behavior. It is >> forbidden here, as it depended on behavior in DTLS which may change >> without notice." >>=20 >> This is in line with WG consensus, so is correct. But there are some = other sections that seem to conflict with this and probably need to be = updated as well: >>=20 >> - Section 2.2.1 has three instances of "When DTLS is used over the = existing RADIUS/UDP ports ...", which seems to be forbidden now. Should = these all just say "Section 3.4 item (N) applies to RADIUS/DTLS"? >=20 > Yes. I'll fix it. >=20 >> - Section 5.1.1 says "The requirement to accept RADIUS/UDP and = RADIUS/DTLS on the same port makes this recommendation difficult to = implement in practice." This seems out of date. >=20 > I've deleted the old text, and fixed the surrounding text. >=20 >> - Section 10 says " >> "The main portion of the specification that could have security >> implications is a servers ability to accept both RADIUS and DTLS >> packets on the same port. The filter that disambiguates the two >> protocols is simple, and is just a check for the value of one = octet. >> We do not expect this check to have any security issues." >> I assume this should be removed since accepting both on one port is = forbidden.=20 >=20 > Yes. >=20 >> 5. Section 5. I understand that RADIUS/DTLS creates connections where = RADIUS/UDP had none, so there are some new considerations around keeping = track of connections. But the section begins by saying that = implementations are free to choose their method. Since the = implementation details of this section aren't vital to understanding = RADIUS/DTLS, and are frankly quite complex, it might be better = organization to put the text in Section 6 ("Implementation Guidelines"). = This would make it easier to understand the protocol details. >=20 > Arguably yes. I'm inclined to leave it as-is. The existing text > motivates and frames the discussion of connection management. >=20 >> 6. Section 5.1. Why is this a MUST? Is it required for = interoperability? If not, I think it should be a recommendation. >>=20 >> "A RADIUS/DTLS server MUST track ongoing DTLS client connections = based >> on a key composed of the following 4-tuple...." >=20 > I'm willing to make that change. I'm curious as to how else the > connections would be tracked. Would a single DTLS session send = packets > using multiple source IPs / ports? If so, how would the peer = correlated > a random packet to a particular session? >=20 >> 7. Section 5.1.1, bottom of page 11. What does the term "failed = security" mean? Is there a more precise way to say this?=20 >=20 > Perhaps "failing security requirements". When a connection doesn't > meet the security configurations set by the host, the connection = should > not be accepted. >=20 >> 8. Section 5.2.2, top of page 12. I assume the errors mentioned here = are errors in the decrypted RADIUS data packet. Why is it necessary to = mention these? Aren't they also necessary checks for RADIUS/UDP? >=20 > When a RADIUS/UDP packet is malformed, it just means that the packet > gets discarded. >=20 > When you've set up a DTLS connection with someone, and he then sends > you a malformed RADIUS packet, it means the entire DTLS session should > be discarded. >=20 > There was some discussion in the WG about this. In the end, I can't > see any reason to maintain a DTLS session when the other end isn't > sending RADIUS packets inside of it. >=20 >> 9. Section 6. Can you cite a rationale for choosing these PSK key = sizes? Do they represent a particular strength? >=20 > They come from the WG discussion, if I recall. >=20 >> 10. Section 10. Having a fixed key always comes with threats. It = would be helpful to mention that if the RADIUS/DTLS session becomes a = RADIUS/UDP session due to configuration or implementation error, that = the fixed RADIUS MD5 key would provide no security since the key was = trivially known. >=20 > I'll add some text. >=20 >> 11. Section 10.1. It would be fair to say that using either = RADIUS/DTLS or RADIUS/TLS is recommended. I suggest adding "or RFC 6614" = to the end of the 2nd sentence. >=20 > OK. >=20 >> 12. Section 10.4. I don't think this document can make normative = requirements on previous RFCs so "NOT RECOMMENDED" should probably be in = lower case. I would also reword the second paragraph something like this = to get the point across better: "The use of RADIUS/DTLS can allow for = the safe usage of wildcards. When RADIUS/DTLS is used with wildcards = clients MUST be uniquely identified using TLS parameters, and any = certificate or PSK used MUST be unique to each client". >=20 > OK. >=20 >> 13. Section 10.5. The first paragraph says "This requirement is due = to security considerations.". Could you state them please? >=20 > The next paragraph explains. >=20 >=20 >> 14. Section 10.5. The second paragraph says: >>=20 >> "Similarly, any RADIUS traffic failing validation >> means that two parties do not share the same security parameters, = and >> the session is therefore a security risk." >>=20 >> Aren't the security parameters all in DTLS? This seems like a = security consideration of the normal operation of DTLS. DTLS is going to = detect if there's a mismatch between the two endpoints and so there = won't be a security risk. I think this sentence should be omitted. >=20 > Someone may allow administrator configuration of the shared secret > inside of DTLS, instead of fixing it as "radius/dtls". >=20 > The two paragraphs should say: >=20 >=20 > Section 5.1.1, above, requires that DTLS sessions be closed when the > transported RADIUS packets are malformed, or fail the authenticator > checks. The reason is that the connection is expected to be used for > transport of RADIUS packets only. >=20 > Any non-RADIUS traffic on that connection means the other party is > misbehaving, and a potential security risk. Similarly, any RADIUS > traffic failing validation means that two parties do not have a common > same shared secret, and the session is therefore unauthenticated. >=20 >=20 > I'll issue a new draft ASAP. From new-work-bounces@ietf.org Fri Oct 11 09:38:50 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 203E721E8203; Fri, 11 Oct 2013 09:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1381509530; bh=KqejQKBeZBrwofa8DigooPKjJfiN6cA+O9o53IGA2fU=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=NLEds9B+/ywmC1k5mylah4ABghs69jq4ic9gw/xv4nnseCZbP7icoRrv1c+q4hgQo KIzwx4tEK3kkiEawx4t3Lu0Zmp9GYfFXaEEsUHVrycoklQM7DTOFQ32i4sqNDvS+3t 2lnu1hHnqMJAPYKOe0iLdbJi7Rv12M2RoQsGjJOU= 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 7D9AF21E8202; Fri, 11 Oct 2013 09:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 FJFV4wfmFZSZ; Fri, 11 Oct 2013 09:38:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D2A21E814A; Fri, 11 Oct 2013 09:38:36 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131011163836.4914.71265.idtracker@ietfa.amsl.com> Date: Fri, 11 Oct 2013 09:38:36 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 09:39:36 -0700 Subject: [secdir] [new-work] WG Review: IPv6 Maintenance (6man) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 16:38:50 -0000 The IPv6 Maintenance (6man) working group in the Internet Area of the IETF is undergoing rechartering. 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 2013-10-21. IPv6 Maintenance (6man) ------------------------------------------------ Current Status: Active WG Chairs: Robert Hinden Ole Troan Assigned Area Director: Brian Haberman Mailing list Address: ipv6@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipv6 Archive: http://www.ietf.org/mail-archive/web/ipv6 Charter: The 6man working group is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture. It is not chartered to develop major changes or additions to the IPv6 specifications. The working group will address protocol limitations/issues discovered during deployment and operation. It will also serve as a venue for discussing the proper location for working on IPv6-related issues within the IETF. 6man is the design authority for extensions and modifications to the IPv6 protocol. The working group may at its discretion, review any document extending or modifying the protocol, carried out in another working group, and may determine that 6man working group consensus is needed before any of those documents can progress for publication. Milestones: Done - Submit RH0 Deprecation specification to IESG as a Proposed Standard Done - Submit PPP Compression Negotiation specification to IESG as a Proposed Standard Done - Determine way forward for ULA-C specification Nov 2013 - Resolve open issues with "U/G" bits in Interface Identifiers Mar 2014 - Develop approach for IPv6 Fragmentation Mar 2014 - Develop approaches for IPv6 Extension Headers (Hop-by-Hop and Destination) Jul 2014 - Advance IPv6 core specifications to Internet standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From aland@deployingradius.com Fri Oct 11 11:02:45 2013 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 04C8221F9EAD; Fri, 11 Oct 2013 11:02:45 -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=[AWL=0.000, 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 pmQ922hpMuOz; Fri, 11 Oct 2013 11:02:39 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6240621F9EA2; Fri, 11 Oct 2013 11:02:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 27B7322401D3; Fri, 11 Oct 2013 20:01:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I67pPHZoWtPX; Fri, 11 Oct 2013 20:01:32 +0200 (CEST) Received: from Thor-2.local (bas1-ottawa11-1176121002.dsl.bell.ca [70.26.46.170]) by power.freeradius.org (Postfix) with ESMTPSA id 7706322400E3; Fri, 11 Oct 2013 20:01:31 +0200 (CEST) Message-ID: <52583CFF.207@deployingradius.com> Date: Fri, 11 Oct 2013 14:01:35 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Brian Weis References: <43CA5AEB-DCB8-46FE-9176-D62CD511BADC@cisco.com> <5250BE14.2000005@deployingradius.com> <3385D735-1078-4DC4-8F39-91458BFE3907@cisco.com> In-Reply-To: <3385D735-1078-4DC4-8F39-91458BFE3907@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-radext-dtls.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-radext-dtls-06 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, 11 Oct 2013 18:02:45 -0000 Brian Weis wrote: > Thanks for the explanation. Would it also be accurate to say this? > > (1) The Length checks defined in [RFC2865] Section 3 MUST treat the > decrypted DTLS data octets outside the range of the Length field > as padding and ignore it on reception. > > I think something like that would be a lot clearer. OK. I'll add that in. From paul.hoffman@vpnc.org Sun Oct 13 16:59:32 2013 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 01B8021F9D1B for ; Sun, 13 Oct 2013 16:59:31 -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=[AWL=0.000, 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 RWxM4Dba8bCN for ; Sun, 13 Oct 2013 16:59:31 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DFD6021F9AA8 for ; Sun, 13 Oct 2013 16:59:21 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id r9DNxKIg018160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 13 Oct 2013 16:59:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sun, 13 Oct 2013 16:59:20 -0700 To: secdir Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [secdir] Secdir review of draft-ietf-mile-sci 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, 13 Oct 2013 23:59:32 -0000 draft-ietf-mile-sci, "IODEF-extension for structured cybersecurity = information", describes extensions to the IODEF format to describe = "cybersecurity information" such as types of attacks, vulnerabilities, = and so on. This extension allows systems exchanging IODEF information to = use a more standardized way to describe these specific types of = information in XML. The security considerations section basically says "when you transport = sensitive cybersecurity information, do so carefully" which is probably = sufficient because there are already standardized ways of securely = transporting IODEF items, particularly RID. Nothing in this document = warrants more security than what is already being transported in IODEF = messages today. --Paul Hoffman= From new-work-bounces@ietf.org Mon Oct 14 02:44:29 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6299721F9C4A; Mon, 14 Oct 2013 02:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1381743869; bh=4JjaZX1J+7u0/V+ytOqhiINGwaToQRInhb/2D9VmBQU=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=fLC5YXjfz61wgkEkqHZNkYUScp7JI2Do8+kcpy2co0suxO3eivERSgg+WIFdk2ggZ efvbnlPX48O3yuh4zsmDXDnGEA191/W0SPJlqDX6TfxjVUhW5B3jTo1AI36puk3CNw Bm0JL0OppX3VsRIuZeHpmhRZmN0y2G7/Umo8dGdk= 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 937D921F9FF3 for ; Mon, 14 Oct 2013 02:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.854 X-Spam-Level: X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=0.745, 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 p9+hpnbX+M4n for ; Mon, 14 Oct 2013 02:44:14 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 3B25D21F9B35 for ; Mon, 14 Oct 2013 02:42:37 -0700 (PDT) Received: from bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1VVefc-0004qd-9W for new-work@ietf.org; Mon, 14 Oct 2013 05:42:36 -0400 To: new-work@ietf.org Date: Mon, 14 Oct 2013 11:42:35 +0200 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 14 Oct 2013 03:47:36 -0700 Subject: [secdir] [new-work] Proposed W3C Charters: 'Data on the Web Best Practices Working Group' and 'CSV on the Web Working Group' (until 2013-11-24) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 09:44:30 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to create the Data Activity (see the W3C Process Document description of Activity Proposals [1]). The planned work subsumes and expands upon the work done in the Semantic Web and eGovernment Activities. This proposal includes two draft charters: Data on the Web Best Practices Working Group: http://www.w3.org/2013/05/odbp-charter.html CSV on the Web Working Group http://www.w3.org/2013/05/lcsv-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 2013-11-24 on the proposed charters. 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 Phil Archer, Team contact . Thank you, Coralie Mercier, W3C Communications [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +33643220001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Oct 15 09:47:14 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EF721E815D; Tue, 15 Oct 2013 09:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1381855634; bh=1IFrDpF02ZY1TFqM/vDsQ2+WSJhiUyS3BjVkCxc4LW4=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=WeRRrTdyiB6K4/o96hboqKGdtXXXDwUTgku2Rph4NlPoZ5H6+9AZJIBoapjc/c8lJ LE6XVdNhms44goIoizT4dZGUZICwVGx+AwkXDfr86NZ2n/qwelqSS9sx9L/iamCVOk nFWmneq1A6CF+aKjlYee+a0hxkEmbR7puVfJoCNU= 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 A4DF321E80DA; Tue, 15 Oct 2013 09:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 BTYjR02i7PMH; Tue, 15 Oct 2013 09:47:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F1021E809E; Tue, 15 Oct 2013 09:46:57 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131015164656.2118.65970.idtracker@ietfa.amsl.com> Date: Tue, 15 Oct 2013 09:46:56 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 09:51:57 -0700 Subject: [secdir] [new-work] WG Review: Source Packet Routing in Networking (spring) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 16:47:14 -0000 A new IETF working group has been proposed in the Routing 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 2013-10-22. Source Packet Routing in Networking (spring) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Stewart Bryant Mailing list Address: status@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/status Archive: http://www.ietf.org/mail-archive/web/status/current/maillist.html Charter: The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions, for example: o Some types of network virtualization, including multi- topology networks and the partitioning of network resources for VPNs o Network path and node protection such as fast re-route o Network programmability o New OAM techniques o Simplification and reduction of network signalling components o Load balancing and traffic engineering Source-based routing mechanisms have previously been specified for network protocols, but have not seen widespread adoption other than in MPLS traffic engineering. These applications may require greater flexibility and per packet source imposed routing than can be achieved through the use of the previously defined methods. The SPRING working group will define procedures that will allow a node to steer a packet along an explicit route using information attached to the packet and without the need for per-path state information to be held at transit nodes. Full explicit control (through loose or strict path specification) can be achieved in a network comprising only SPRING nodes, however SPRING must inter-operate through loose routing in existing networks and may find it advantageous to use loose routing for for other network applications. The initial data planes that will be considered are MPLS and IPv6. There is an assumed trust model such that any node imposing an explicit route on a packet is assumed to be allowed to do so, however administrative and trust boundaries may strip explicit routes from a packet. For each data plane technology that SPRING specifies, a security analysis must be provided showing how protection is provided against an attacker disrupting the network by for example, maliciously injecting SPRING packets. There are a number of serious security concerns with source routing at the IP layer [RFC 5095]. As a part of its work, the working group will define the new IPv6-based routing header in way that blind attacks are never possible, i.e., attackers will be unable to send source routed packets that get successfully processed, without being part of the negotiation for setting up the source routes or being able to eavesdrop legitimate source routed packets. In some networks this base level security may be complemented with other mechanisms, such as packet filtering, cryptographic security, etc. Initial work will focus on SPRING within in a single AS, however design decisions must not preclude operation of SPRING across AS boundaries. SPRING should support both centralised and distributed path computation. The SPRING WG should provide OAM and the management needed to manage SPRING enabled networks. The SPRING protocol itself may also be used as a tool for OAM in SPRING enabled networks. SPRING should avoid modification to existing data planes that would make them incompatible with existing deployments. Where possible, existing control and management plane protocols must be used within existing architectures to implement the SPRING function. Any modification of or extension to existing architectures, data planes, or control or management plane protocols must be carried out in the working groups responsible for the architecture, data plane, or control or management plane protocol being modified and in co-ordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible Area Directors. The SPRING working group is chartered for the following list of items: o Identification and evaluation of use cases for SPRING. These use cases must include a definition of the data plane for the environment in which they are to be deployed. o Definition of requirements and/or any new data plane encodings and procedures, required to implement the use cases. Such procedures must include the necessary security considerations. o Definition of requirements and/or any new control plane mechanism needed to enable the use cases. o Definition of requirements and/or management plane mechanism needed to manage and operate a SPRING enabled network. The SPRING working group will not work on any mechanisms for use in networks that forward IPv4 packets. [ Following to be replaced by milestones before final review] The working group will develop the following documents: o One or more documents describing SPRING use cases. o Specification of a high-level abstract architecture for SPRING and requirements for modifications to existing architecture to support SPRING use cases. o Specification of any required new procedures to support SPRING use cases. o One or more data plane extension requirements documents, including documenting the impact on existing deployments of the existing data plane. o One or more control protocol extensions requirements documents. o Publish SPRING management requirements document. o Specify the OAM mechanisms needed to support SPRING. o Document inter-working and co-existence between the new procedures and the existing signalling and routing protocols. o Inter-operability reports pertaining to the implementation of extensions supporting SPRING. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Oct 15 09:52:28 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0348821E8176; Tue, 15 Oct 2013 09:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1381855948; bh=xyNBD0EbfAqtEbzUbw0AzpQoYZaKzalvn5rx3THWSjE=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=D1tkOYh26EiitxuG9j4kO42HzA33EE6966uaFVfdVZYQSNwhX4GnklesTfyu3BEOJ S8cphOzgvus8+Bml+SzQs8YzBPjWMPyGXe4GIh4A4NiUUmIn+mVrfpN1usyo7pAI4K Jas668hW5W3SKwJp/czjhL4Rsv3ykP3KaMcRyUOA= 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 3295621E8176; Tue, 15 Oct 2013 09:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 ebya+AVteaWl; Tue, 15 Oct 2013 09:52:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C8F21E8162; Tue, 15 Oct 2013 09:52:25 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131015165225.2154.40859.idtracker@ietfa.amsl.com> Date: Tue, 15 Oct 2013 09:52:25 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 09:54:18 -0700 Subject: [secdir] [new-work] WG Review: Operational Security Capabilities for IP Network Infrastructure (opsec) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 16:52:28 -0000 The Operational Security Capabilities for IP Network Infrastructure (opsec) working group in the Operations and Management Area of the IETF is undergoing rechartering. 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 2013-10-22. Operational Security Capabilities for IP Network Infrastructure (opsec) ------------------------------------------------ Current Status: Active WG Chairs: Warren Kumari Gunter Van de Velde KK Chittimaneni Assigned Area Director: Joel Jaeggli Mailing list Address: opsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/opsec Archive: http://www.ietf.org/mail-archive/web/opsec/ Charter: Goals: The OPSEC WG will document operational issues and best current practices with regard to network security.In particular, the working group will clarify the rationale of supporting current operational practice, addressing gaps in currently understood best practices, and clarifying liabilities inherent in security practices where they exist. Scope: The scope of the OPSEC WG includes the protection and secure operation of the forwarding, control and management planes. Documentation of operational issues, revision of existing operational security practices documents and proposals for new approaches to operational challenges related to network security are in scope. Method: The work will result in the publication of informational or BCP RFCs. Taxonomy or problem statement documents may provide a basis for such documents. Informational or Best Current Practices Documents For each topic addressed, the working group will produce a document that captures common practices related to secure network operation. will be produced. This will be primarily based on operational experience. A document might convey: * a threat or threats to be addressed * current practices for addressing the threat * protocols, tools and technologies extant at the time of writing that are used to address the threat * the possibility that a solution does not exist within existing tools or technologies Taxonomy and Problem Statement Documents These are documents that describe the scope of particular operational security challenges or problem spaces without necessarily coming to conclusions or proposing solutions. Such a document might be the precusor to an informational or best current practices document. While the principal input of the working group is operational experience and needs, the output should be directed towards providing guidance to the operators community, other working groups that develop protocols or the protocol development community. Non-Goals: The OPSEC WG is will not write or modify protocols. New protocol work must be addressed through a working group chartered for that work, or via one of the individual submission processes. The OPSEC WG may take on documents related to the practices of using such work. Milestones: Done - Complete Charter Done - First draft of Framework Document as Internet Draft Done - First draft of Standards Survey Document as Internet Draft Done - First draft of Packet Filtering Capabilities Done - First draft of Event Logging Capabilities Done - First draft of Network Operator Current Security Practices Done - First draft of In-Band management capabilities Done - First draft of Out-of-Band management capabilities Done - First draft of Configuration and Management Interface Capabilities Done - Submit Network Operator Current Security Practices to IESG Dec 2012 - WG Adoption of 'BGP operations and security' document Dec 2012 - WG Adoption of 'Network Reconnaissance in IPv6 Networks' document Dec 2012 - WG Adoption of 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document Dec 2012 - WG Adoption of 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks' document Jan 2013 - WG Last Call for 'Operational Security Considerations for IPv6 Networks' document Jan 2013 - WG Last Call for 'Recommendations for filtering ICMP messages' document Jan 2013 - WG Last Call for 'Recommendations on filtering of IPv4 packets containing IPv4 options' document Jan 2013 - WG Last Call for 'Security Implications of IPv6 on IPv4 networks' document Mar 2013 - WG Last Call for 'Using Only Link-Local Addressing Inside an IPv6 Network' document Mar 2013 - Submit 'Recommendations for filtering ICMP messages' document to IESG Mar 2013 - Submit 'Recommendations on filtering of IPv4 packets containing IPv4 options' document to IESG Mar 2013 - Submit 'Operational Security Considerations for IPv6 Networks' document to IESG Mar 2013 - Submit 'Recommendations for filtering ICMP messages' document to IESG May 2013 - Submit 'Using Only Link-Local Addressing Inside an IPv6 Network' document to IESG Jul 2013 - WG Last Call for 'BGP operations and security' document Jul 2013 - WG Last Call for 'Network Reconnaissance in IPv6 Networks' document Jul 2013 - WG Last Call for 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document Jul 2013 - WG Last Call for 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks' document Sep 2013 - Submit 'BGP operations and security' document to IESG Sep 2013 - Submit 'Network Reconnaissance in IPv6 Networks' document to IESG Sep 2013 - Submit 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document to IESG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From andrew.hutton@unify.com Wed Oct 16 07:20:31 2013 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 59F1821F9C4A; Wed, 16 Oct 2013 07:20:31 -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 KN507Gb+tdA4; Wed, 16 Oct 2013 07:20:26 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id DE89721F9CAD; Wed, 16 Oct 2013 07:20:23 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 5536E23F055F; Wed, 16 Oct 2013 16:20:22 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.31]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Wed, 16 Oct 2013 16:19:41 +0200 From: "Hutton, Andrew" To: Derek Atkins , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: sec-dir review of draft-ietf-siprec-architecture-08 Thread-Index: AQHOvrubMf93F21HCEGJjMCkxJ10v5n3ZzNg Date: Wed, 16 Oct 2013 14:20:21 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17BF527F@MCHP04MSX.global-ad.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 16 Oct 2013 07:26:11 -0700 Cc: "krehor@cisco.com" , "leon.portman@gmail.com" , "siprec-chairs@tools.ietf.org" , "rajnish.jain@outlook.com" Subject: Re: [secdir] sec-dir review of draft-ietf-siprec-architecture-08 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, 16 Oct 2013 14:20:31 -0000 Hi Derek, Thanks for your comment and sorry for taking a while to get back to you. The security considerations section contains the following text: " It is the responsibility of the Session Recording Server to protect the Replicated Media and Recording Metadata once it has been received and archived. The mechanism for protecting the storage and retrieval from the SRS is out of scope of this work." Personally I think this is reasonable as we never say anything in SIP relat= ed specifications what a UA should do with the media once it has been recei= ved and this work is all about delivering the media and related metadata to= the recording system not what it does with it afterwards. Is it really necessary to go any further than this? Regards Andy (SIPREC Co-Chair). > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: 01 October 2013 16:34 > To: iesg@ietf.org; secdir@ietf.org > Cc: siprec-chairs@tools.ietf.org; krehor@cisco.com; > rajnish.jain@outlook.com; leon.portman@gmail.com; Hutton, Andrew > Subject: sec-dir review of draft-ietf-siprec-architecture-08 >=20 > Hi, >=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 > Session recording is a critical requirement in many communications > environments such as call centers and financial trading. In some of > these environments, all calls must be recorded for regulatory, > compliance, and consumer protection reasons. Recording of a session > is typically performed by sending a copy of a media stream to a > recording device. This document describes architectures for > deploying session recording solutions in an environment which is > based on the Session Initiation Protocol (SIP). >=20 > Retrieving recorded media is a potential Key Management problem which > this document completely ignores (and even claims is out of scope). > The key used to encrypt the recorded media (whether or not the media > is re-encrypted) must be stored and retrieved as part of the media > retrieval. How this important data is stored and retrieved is left > out, leaving an implementation with no guidance on how to protect that > valuable asset. In fact the document completely elides the question > of how a retriever obtains the data encryption key. Even if it's just > additional guidance the Security Considerations should at least > explain the problem even if it doesn't provide a solution. >=20 > -derek >=20 > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From tobias.gondrom@gondrom.org Wed Oct 16 14:09:09 2013 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 E3C1511E82B4 for ; Wed, 16 Oct 2013 14:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.99 X-Spam-Level: X-Spam-Status: No, score=-94.99 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddjxeQVra07O for ; Wed, 16 Oct 2013 14:09:04 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1691011E81D7 for ; Wed, 16 Oct 2013 14:08:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=B32CdyjXkz64U0tG6N2MB4CLMJ7olVXd7yJP7wKQsypC75E0sn7fWrK1VvtE20GJdcF7FY9pTBMVckhrWXE0PkI93GUUPkRC4+WxL/8/Qxys0oEoKLu9UiIU+ByfYun6; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 13726 invoked from network); 16 Oct 2013 23:08:51 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.100?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 Oct 2013 23:08:51 +0200 Message-ID: <525F0063.202@gondrom.org> Date: Wed, 16 Oct 2013 22:08:51 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: secdir@ietf.org, iesg@ietf.org, draft-ietf-6man-oversized-header-chain.all@tools.ietf.org References: <51D41722.8080900@gondrom.org> In-Reply-To: <51D41722.8080900@gondrom.org> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------060207080108070808050904" Subject: [secdir] secdir review of draft-ietf-6man-oversized-header-chain-08 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, 16 Oct 2013 21:09:10 -0000 This is a multi-part message in MIME format. --------------060207080108070808050904 Content-Type: text/plain; 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 ust like any other last call comments. This ID is Standards Track and and updates RFC 2460 such that the first fragment of a packet MUST contain the entire IPv6 header chain. The security considerations section is good. In fact the whole draft's objective is to solve a potential security problem with super-large IPv6 header chains and enable reliable stateless packet filtering for IPv6. COMMENTS: 1. A question, less from a security, but interoperability perspective: is there any deplyoment data on any potential backwards compatibility issues with current IPv6 deployments? Namely are there noteworthy deployments with large IPv6 header chains beyond the first fragment currently in deployment? 2. section 5 third paragraph: I wonder whether we should be more strict and replace the "MAY" with a "SHOULD"? This would make intermediate behavior consistent with the host from the previous paragraph and should avoid inconsistencies within the network topology? Best regards, Tobias --------------060207080108070808050904 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 ust like any other last call comments.

This ID is Standards Track and and updates RFC 2460 such that the first fragment of a packet MUST contain the entire IPv6 header chain.

The security considerations section is good. In fact the whole draft's objective is to solve a potential security problem with super-large IPv6 header chains and enable reliable stateless packet filtering for IPv6.

COMMENTS:
1. A question, less from a security, but interoperability perspective: is there any deplyoment data on any potential backwards compatibility issues with current IPv6 deployments? Namely are there noteworthy deployments with large IPv6 header chains beyond the first fragment currently in deployment?

2. section 5 third paragraph:
I wonder whether we should be more strict and replace the "MAY" with a "SHOULD"?
This would make intermediate behavior consistent with the host from the previous paragraph and should avoid inconsistencies within the network topology?

Best regards, Tobias
--------------060207080108070808050904-- From fgont@si6networks.com Wed Oct 16 15:12:28 2013 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 9B71611E82ED; Wed, 16 Oct 2013 15:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 DCC9M7tmDI4R; Wed, 16 Oct 2013 15:12:28 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9118C11E82F2; Wed, 16 Oct 2013 15:12:24 -0700 (PDT) Received: from 17-153-16-190.fibertel.com.ar ([190.16.153.17] helo=[192.168.1.166]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VWZKE-0001IY-4L; Thu, 17 Oct 2013 00:12:21 +0200 Message-ID: <525F0F35.9010706@si6networks.com> Date: Wed, 16 Oct 2013 19:12:05 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Tobias Gondrom , secdir@ietf.org, iesg@ietf.org, draft-ietf-6man-oversized-header-chain.all@tools.ietf.org References: <51D41722.8080900@gondrom.org> <525F0063.202@gondrom.org> In-Reply-To: <525F0063.202@gondrom.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] secdir review of draft-ietf-6man-oversized-header-chain-08 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, 16 Oct 2013 22:12:28 -0000 Hi, Tobias, Thanks so much for your review! -- Please find my comments in-line... On 10/16/2013 06:08 PM, Tobias Gondrom wrote: > 1. A question, less from a security, but interoperability perspective: > is there any deplyoment data on any potential backwards compatibility > issues with current IPv6 deployments? Namely are there noteworthy > deployments with large IPv6 header chains beyond the first fragment > currently in deployment? No. > 2. section 5 third paragraph: > I wonder whether we should be more strict and replace the "MAY" with a > "SHOULD"? > This would make intermediate behavior consistent with the host from the > previous paragraph and should avoid inconsistencies within the network > topology? IIRC, the "intermmediate systems MAY drop" is so that intermmediate systems are not required to process the entire header chain. -- i.e.: "If you want to drop such packets, you're free to... but we don't require e.g. routers to process the entire IPv6 header chain to find whether the entire header chain is present and then decide whether to drop or not". OTOH, the "MAY send an ICMPv6 error message" could be changed to "if you drop, you SHOULD send an ICMPv6 error message", I guess. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From tobias.gondrom@gondrom.org Wed Oct 16 15:34:53 2013 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 1DF2F11E8195 for ; Wed, 16 Oct 2013 15:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.037 X-Spam-Level: X-Spam-Status: No, score=-95.037 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4I8xoqzXL5f for ; Wed, 16 Oct 2013 15:34:47 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id DFD6D11E8204 for ; Wed, 16 Oct 2013 15:34:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=HUZvC4AyhdWX73xa3uF0vG3kPY+KG8S9Gs7BE3mvqMzE9tT5ZMZ+IxbP88fyE/FDlzfntTgQxPF4mIM9cKgjfnyEVQ/Bc3bwemlvTmMoPYsv97cwvyGT056XyAk3rbgd; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 15370 invoked from network); 17 Oct 2013 00:34:41 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.100?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Oct 2013 00:34:41 +0200 Message-ID: <525F1481.4020001@gondrom.org> Date: Wed, 16 Oct 2013 23:34:41 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: fgont@si6networks.com, secdir@ietf.org, iesg@ietf.org, draft-ietf-6man-oversized-header-chain.all@tools.ietf.org References: <51D41722.8080900@gondrom.org> <525F0063.202@gondrom.org> <525F0F35.9010706@si6networks.com> In-Reply-To: <525F0F35.9010706@si6networks.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] secdir review of draft-ietf-6man-oversized-header-chain-08 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, 16 Oct 2013 22:34:53 -0000 On 16/10/13 23:12, Fernando Gont wrote: > Hi, Tobias, > > Thanks so much for your review! -- Please find my comments in-line... > > On 10/16/2013 06:08 PM, Tobias Gondrom wrote: >> 1. A question, less from a security, but interoperability perspective: >> is there any deplyoment data on any potential backwards compatibility >> issues with current IPv6 deployments? Namely are there noteworthy >> deployments with large IPv6 header chains beyond the first fragment >> currently in deployment? > No. Does this "No" mean: (1) there are no noteworthey deployments or does it only mean (2) we have no data at all and therefore don't know what we will break with the update? >> 2. section 5 third paragraph: >> I wonder whether we should be more strict and replace the "MAY" with a >> "SHOULD"? >> This would make intermediate behavior consistent with the host from the >> previous paragraph and should avoid inconsistencies within the network >> topology? > IIRC, the "intermmediate systems MAY drop" is so that intermmediate > systems are not required to process the entire header chain. -- i.e.: > "If you want to drop such packets, you're free to... but we don't > require e.g. routers to process the entire IPv6 header chain to find > whether the entire header chain is present and then decide whether to > drop or not". > > OTOH, the "MAY send an ICMPv6 error message" could be changed to "if you > drop, you SHOULD send an ICMPv6 error message", I guess. > > Thanks, I see. Actually I meant both, but let's look at them separately: 1. "intermmediate systems MAY drop" Actually a "SHOULD" does not require them either, but substantially encourages more than the "MAY". Question: I assume from your answer, most intermediate systems just pass through without checking that the header conform to updated 2460, i.e. header ends within the first fragment? In the end, I have no strong feelings about this, i.e. ok with both (MAY and SHOULD). 2. For the ICMPv6 error message, you are right that should be a "SHOULD" not a "MAY" as it is on the condition of the dropped packet. Best regards, Tobias From fgont@si6networks.com Wed Oct 16 19:19:48 2013 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 72B6611E8226; Wed, 16 Oct 2013 19:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 jSI0r759AknA; Wed, 16 Oct 2013 19:19:47 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 0608111E822C; Wed, 16 Oct 2013 19:19:12 -0700 (PDT) Received: from 17-153-16-190.fibertel.com.ar ([190.16.153.17] helo=[192.168.1.166]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VWdB7-0000IK-7C; Thu, 17 Oct 2013 04:19:09 +0200 Message-ID: <525F3669.20102@si6networks.com> Date: Wed, 16 Oct 2013 21:59:21 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Tobias Gondrom , secdir@ietf.org, iesg@ietf.org, draft-ietf-6man-oversized-header-chain.all@tools.ietf.org References: <51D41722.8080900@gondrom.org> <525F0063.202@gondrom.org> <525F0F35.9010706@si6networks.com> <525F1481.4020001@gondrom.org> In-Reply-To: <525F1481.4020001@gondrom.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] secdir review of draft-ietf-6man-oversized-header-chain-08 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, 17 Oct 2013 02:19:48 -0000 On 10/16/2013 07:34 PM, Tobias Gondrom wrote: >>> 1. A question, less from a security, but interoperability perspective: >>> is there any deplyoment data on any potential backwards compatibility >>> issues with current IPv6 deployments? Namely are there noteworthy >>> deployments with large IPv6 header chains beyond the first fragment >>> currently in deployment? >> No. > > Does this "No" mean: > (1) there are no noteworthey deployments or does it only mean > (2) we have no data at all and therefore don't know what we will break > with the update? There are no specified use cases for such oversized header chains (for instance, look at the extension header types and options specified so far). Besides, what I've seen and what others have indicated is the same: with the addition that any intentional use of extension headers typically leads to packet drops (see draft-ietf-6man-ext-transmit-05.txt). >>> 2. section 5 third paragraph: >>> I wonder whether we should be more strict and replace the "MAY" with a >>> "SHOULD"? >>> This would make intermediate behavior consistent with the host from the >>> previous paragraph and should avoid inconsistencies within the network >>> topology? >> IIRC, the "intermmediate systems MAY drop" is so that intermmediate >> systems are not required to process the entire header chain. -- i.e.: >> "If you want to drop such packets, you're free to... but we don't >> require e.g. routers to process the entire IPv6 header chain to find >> whether the entire header chain is present and then decide whether to >> drop or not". >> >> OTOH, the "MAY send an ICMPv6 error message" could be changed to "if you >> drop, you SHOULD send an ICMPv6 error message", I guess. >> >> Thanks, > > I see. Actually I meant both, but let's look at them separately: > > 1. "intermmediate systems MAY drop" > Actually a "SHOULD" does not require them either, but substantially > encourages more than the "MAY". An implementation that does not follow SHOULDs is said to be "conditionally complaint" where in our case, we deem a middle-box that doesn't drop such packets as fully-cumpliant hence the "MAY". If a middle-box does not really need to look at the upper-layer header, then requiring (SHOULD) it to look at the header chain just to drop the offending packets is rather overkill. > Question: I assume from your answer, > most intermediate systems just pass through without checking that the > header conform to updated 2460, Well, packets that do not contain the entire IPv6 header chain in the first fragment are currently RFC2460-compliant -- that's exactly why we're pushing this document. > 2. For the ICMPv6 error message, you are right that should be a "SHOULD" > not a "MAY" as it is on the condition of the dropped packet. I will change this unless anyone objects (or points out something I may have missed). Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From tobias.gondrom@gondrom.org Thu Oct 17 01:17:08 2013 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 7052111E810B for ; Thu, 17 Oct 2013 01:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.102 X-Spam-Level: X-Spam-Status: No, score=-95.102 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzPVlKxwsmCr for ; Thu, 17 Oct 2013 01:17:02 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 20F9321F9A50 for ; Thu, 17 Oct 2013 01:17:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=kqxKUvjnrWJnjMCyCM3sYdUAD7HpJW3t5zHprbwI8EhZN+UsVupo4Om1TZAlbVwHCkPNoXA1T4FqY1ugz25Zit5WYw2Ezaqqk1JYE8uZFwxWIRFG66QHOP8LV5POPKtc; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 1143 invoked from network); 17 Oct 2013 10:16:57 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.100?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Oct 2013 10:16:57 +0200 Message-ID: <525F9CF8.4060905@gondrom.org> Date: Thu, 17 Oct 2013 09:16:56 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: fgont@si6networks.com, secdir@ietf.org, iesg@ietf.org, draft-ietf-6man-oversized-header-chain.all@tools.ietf.org References: <51D41722.8080900@gondrom.org> <525F0063.202@gondrom.org> <525F0F35.9010706@si6networks.com> <525F1481.4020001@gondrom.org> <525F3669.20102@si6networks.com> In-Reply-To: <525F3669.20102@si6networks.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] secdir review of draft-ietf-6man-oversized-header-chain-08 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, 17 Oct 2013 08:17:08 -0000 Thank you for your answers. All the best, Tobias On 17/10/13 01:59, Fernando Gont wrote: > On 10/16/2013 07:34 PM, Tobias Gondrom wrote: >>>> 1. A question, less from a security, but interoperability perspective: >>>> is there any deplyoment data on any potential backwards compatibility >>>> issues with current IPv6 deployments? Namely are there noteworthy >>>> deployments with large IPv6 header chains beyond the first fragment >>>> currently in deployment? >>> No. >> Does this "No" mean: >> (1) there are no noteworthey deployments or does it only mean >> (2) we have no data at all and therefore don't know what we will break >> with the update? > There are no specified use cases for such oversized header chains (for > instance, look at the extension header types and options specified so far). > > Besides, what I've seen and what others have indicated is the same: with > the addition that any intentional use of extension headers typically > leads to packet drops (see draft-ietf-6man-ext-transmit-05.txt). > > >>>> 2. section 5 third paragraph: >>>> I wonder whether we should be more strict and replace the "MAY" with a >>>> "SHOULD"? >>>> This would make intermediate behavior consistent with the host from the >>>> previous paragraph and should avoid inconsistencies within the network >>>> topology? >>> IIRC, the "intermmediate systems MAY drop" is so that intermmediate >>> systems are not required to process the entire header chain. -- i.e.: >>> "If you want to drop such packets, you're free to... but we don't >>> require e.g. routers to process the entire IPv6 header chain to find >>> whether the entire header chain is present and then decide whether to >>> drop or not". >>> >>> OTOH, the "MAY send an ICMPv6 error message" could be changed to "if you >>> drop, you SHOULD send an ICMPv6 error message", I guess. >>> >>> Thanks, >> I see. Actually I meant both, but let's look at them separately: >> >> 1. "intermmediate systems MAY drop" >> Actually a "SHOULD" does not require them either, but substantially >> encourages more than the "MAY". > An implementation that does not follow SHOULDs is said to be > "conditionally complaint" where in our case, we deem a middle-box that > doesn't drop such packets as fully-cumpliant hence the "MAY". > > If a middle-box does not really need to look at the upper-layer header, > then requiring (SHOULD) it to look at the header chain just to drop the > offending packets is rather overkill. > > >> Question: I assume from your answer, >> most intermediate systems just pass through without checking that the >> header conform to updated 2460, > Well, packets that do not contain the entire IPv6 header chain in the > first fragment are currently RFC2460-compliant -- that's exactly why > we're pushing this document. > > > >> 2. For the ICMPv6 error message, you are right that should be a "SHOULD" >> not a "MAY" as it is on the condition of the dropped packet. > I will change this unless anyone objects (or points out something I may > have missed). > > Thanks! > > Best regards, From kivinen@iki.fi Thu Oct 17 04:55:29 2013 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 1513011E81AC for ; Thu, 17 Oct 2013 04:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 GHV7ZbKeIKUh for ; Thu, 17 Oct 2013 04:55:28 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id B324711E817C for ; Thu, 17 Oct 2013 04:55:27 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9HBtQ40024192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 17 Oct 2013 14:55:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9HBtQ3X010658; Thu, 17 Oct 2013 14:55:26 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21087.53294.127213.840653@fireball.kivinen.iki.fi> Date: Thu, 17 Oct 2013 14:55:26 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 2 min X-Total-Time: 1 min 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, 17 Oct 2013 11:55:29 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Warren Kumari is next in the rotation. For telechat 2013-10-24 Reviewer LC end Draft Alan DeKok T 2013-10-18 draft-hethmon-mcmurray-ftpext-ftp-hosts-03 Donald Eastlake T 2013-10-10 draft-mcgrew-tls-aes-ccm-ecc-07 For telechat 2013-11-21 Scott Kelly T 2013-10-29 draft-ietf-appsawg-malformed-mail-09 Last calls and special requests: Rob Austein 2013-10-16 draft-kolkman-proposed-standards-clarified-03 Dave Cridland - draft-ietf-httpbis-p5-range-24 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Shawn Emery - draft-ietf-tictoc-security-requirements-05 Phillip Hallam-Baker 2013-10-16 draft-ietf-ccamp-gmpls-ospf-g709v3-09 Steve Hanna 2013-10-16 draft-ietf-manet-smf-mib-08 Dan Harkins 2013-10-16 draft-ietf-mpls-tp-rosetta-stone-12 David Harrington 2013-10-22 draft-ietf-avtext-multiple-clock-rates-10 Sam Hartman 2013-10-23 draft-ietf-ipfix-data-link-layer-monitoring-06 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-04 Jeffrey Hutzelman 2013-11-04 draft-resnick-on-consensus-05 Leif Johansson 2013-11-04 draft-sin-sdnrg-sdn-approach-04 Simon Josefsson 2013-11-04 draft-trammell-ipfix-tcpcontrolbits-revision-04 Charlie Kaufman - draft-ietf-mpls-in-udp-03 Stephen Kent 2013-10-25 draft-ietf-ipfix-mediation-protocol-07 Tero Kivinen 2013-10-24 draft-ietf-roll-trickle-mcast-05 Julien Laganier - draft-ietf-avtcore-rtp-security-options-07 Julien Laganier - draft-ietf-websec-key-pinning-08 Alexey Melnikov - draft-ietf-payload-rtp-howto-08 Vincent Roca 2013-09-24 draft-ietf-mmusic-duplication-grouping-03 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-14 Sam Weiler 2013-09-30 draft-ietf-opsec-ip-options-filtering-05 Tom Yu 2013-10-01 draft-ietf-sidr-origin-ops-22 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 -- kivinen@iki.fi From kent@bbn.com Thu Oct 17 10:24:02 2013 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 D05C711E82C5 for ; Thu, 17 Oct 2013 10:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.503 X-Spam-Level: X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 CwwPYLcaRS9F for ; Thu, 17 Oct 2013 10:23:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id AF98A11E82B9 for ; Thu, 17 Oct 2013 10:23:43 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54554) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VWrIF-000M47-Og; Thu, 17 Oct 2013 13:23:27 -0400 Message-ID: <52601D0F.9030702@bbn.com> Date: Thu, 17 Oct 2013 13:23:27 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: secdir , bclaise@cisco.com, akoba@nttv6.net, Brian Trammell , n.brownlee@auckland.ac.nz, quittek@neclab.eu Content-Type: multipart/alternative; boundary="------------070001060109050006020308" Subject: [secdir] SECDIR review of draft-ietf-ipfix-mediation-protocol-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: Thu, 17 Oct 2013 17:24:03 -0000 This is a multi-part message in MIME format. --------------070001060109050006020308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I 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 describes how IPFIX (IP Flow Information Export) operates in the context of IPFIX "mediators." In the IPFIX context, a mediator is an entity that processes data received from an "exporter" (e.g., a router), before passing the data to a consuming entity (e.g., a network management system), in theb IPFIX format. A mediator can perform various types of processing on IPFIX data, e.g., aggregation, correlation, and anonymizing, in addition to format conversion. The security considerations section in this document is brief, just three paragraphs. It cites the corresponding sections of RFC 7011 (the base IPFIX specification) and RFC 5655 (the IPFIX file specification). It also addresses two considerations that the authors view as specific to the mediator context. Specifically, the authors note that a mediator is an MITM, and thus the confidentiality and integrity of the IP flow data that traverses a mediator can be affected. The authors note although one can use certificates to identify upstream source of processing entities (supported by data elements defined in RFC 5655), this does not provide secure, end-to-end assertions about the upstream entities.Both of these considerations are accurate an well-described here. I briefly examined the security considerations sections of the cited RFCs. I was impressed by the scope of the security discussion in RFC 7011; it mandates support for TLS (v1.1 or later) and DTLS, and calls for (SHOULD) use of certificates in support of mutual authentication of IPFIX entities. There is even a DoS discussion. Good job! The security considerations section of RFC 5655 is shorter, but also appropriate for its context. 5655 calls for (SHOULD) use of CMS (vs. TLS and DTLS) for IPFIX files. It also examines additional security issues relevant to the files. (I have one minor quibble with the text here; it refers to using TLS to "sign" data, which is not correct. The integrity and authentication mechanisms offered by TLS do not include signatures.) Citing the security considerations sections of these other RFcs was appropriate. I wish more I-Ds did as good a job as this one (and its predecessor RFCs) with respect to security considerations sections. --------------070001060109050006020308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit


 

I 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 describes how IPFIX (IP Flow Information Export) operates in the context of IPFIX “mediators.” In the IPFIX context, a mediator is an entity that processes data received from an “exporter” (e.g., a router), before passing the data to a consuming entity (e.g., a network management system), in theb IPFIX format. A mediator can perform various types of processing on IPFIX data, e.g., aggregation, correlation, and anonymizing, in addition to format conversion.

 

The security considerations section in this document is brief, just three paragraphs. It cites the corresponding sections of RFC 7011 (the base IPFIX specification) and RFC 5655 (the IPFIX file specification). It also addresses two considerations that the authors view as specific to the mediator context. Specifically, the authors note that a mediator is an MITM, and thus the confidentiality and integrity of the IP flow data that traverses a mediator can be affected. The authors note although one can use certificates to identify upstream source of processing entities (supported by data elements defined in RFC 5655), this does not provide secure, end-to-end assertions about the upstream entities.  Both of these considerations are accurate an well-described here.


I briefly examined the security considerations sections of the cited RFCs. I was impressed by the scope of the security discussion in RFC 7011; it mandates support for TLS (v1.1 or later) and DTLS, and calls for (SHOULD) use of certificates in support of mutual authentication of IPFIX entities. There is even a DoS discussion. Good job!


The security considerations section of RFC 5655 is shorter, but also appropriate for its context. 5655 calls for (SHOULD) use of CMS (vs. TLS and DTLS) for IPFIX files. It also examines additional security issues relevant to the files. (I have one minor quibble with the text here; it refers to using TLS to “sign” data, which is not correct. The integrity and authentication mechanisms offered by TLS do not include signatures.) Citing the security considerations sections of these other RFcs was appropriate.

 

I wish more I-Ds did as good a job as this one (and its predecessor RFCs) with respect to security considerations sections.

--------------070001060109050006020308-- From ietfdbh@comcast.net Thu Oct 17 11:50:17 2013 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 99D6D11E81BB for ; Thu, 17 Oct 2013 11:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pjgwz6QO-wgz for ; Thu, 17 Oct 2013 11:50:11 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 4F34221F992B for ; Thu, 17 Oct 2013 11:50:09 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta06.westchester.pa.mail.comcast.net with comcast id eF3K1m0051ZXKqc56Jq98H; Thu, 17 Oct 2013 18:50:09 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta21.westchester.pa.mail.comcast.net with comcast id eJq81m00L2yZEBF3hJq8Lf; Thu, 17 Oct 2013 18:50:08 +0000 From: "ietfdbh" To: , , References: In-Reply-To: Date: Thu, 17 Oct 2013 14:50:07 -0400 Message-ID: <03ad01cecb69$b3630a20$1a291e60$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7KjG5sG8+TSU2tRzOncUzVPQmd5wA262Gg Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382035809; bh=49DCFDS+wzFWvz2k1aDUWIOBWXCWAR/pZfY6nw3G8YI=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=iRX2QMKoq/jPWx7ZqmnRTp/WhcbLnedYjMvn2vQawo7tyuGTFKqiVDTknCZQSN53h Sk5rj0UQ5+KrMPAhjNVv3q/ztYQ+0y1zbfaiJgHQLlPxSk0DxfWb62Jf++w2/oB4Mg iGlOfmkohgZZNqT9X5IPyKaVwbVhRpZfVsKMytxFs3rblL8hOAuDiJCj+rwl/qm3Xp CldDtQT/IQqT9JQKw5DSCYUp8EsN51gZh5J4N91fwhfwuhmV74GHzKN8HJJpj8JM4O Zy0WKUGL2nb69Wu0kuXdwfFHwPvkKz7IESBnKOfrdwls2HbwEWwzg8IZqDc6M6kCIh /K45XEIQsVeGQ== Subject: [secdir] FW: secdir review of draft-ietf-avtext-multiple-clock-rates-10 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, 17 Oct 2013 18:50:17 -0000 Hi, Whoops. I forgot to copy this beyond the draft-ietf-avtext-multiple-clock-rates@ expansion. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: ietfdbh [mailto:ietfdbh@comcast.net] > Sent: Wednesday, October 16, 2013 1:11 PM > To: 'draft-ietf-avtext-multiple-clock-rates@tools.ietf.org' > Subject: secdir review of draft-ietf-avtext-multiple-clock-rates-10 >=20 > Hi, >=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 clarifies the RTP specification when different clock > rates are used in an RTP session. It also provides guidance on how > to interoperate with legacy RTP implementations that use multiple > clock rates. It updates RFC 3550. >=20 > The security considerations section says " This document is not = believed to > effect the security of the RTP > sessions described here in any way." >=20 > I have a concern. >=20 > RFC3550 section 9.1 describes an encryption approach, and discusses = the > weakness of the encryption method because of poor randomness of > timestamp offsets, and the potential for manipulation of the SSRC. >=20 > Section 4 of the current document changes how SSRCs should be (must = be) > manipulated for different scenarios, and recommends, but does not = require, > different SSRCs for each clock rate. It also modifies how timestamps = are > calculated. >=20 > Since timestamps and SSRC manipulation are weaknesses of the = encryption > approach in RFC 3550, section 9.1, I would expect more discussion of = the > potential impact, or non-impact, of these changes to SSRCs and = timestamps > vis-=E0-vis the encryption strength. >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 From shanna@juniper.net Thu Oct 17 17:28:54 2013 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 3588A11E823D; Thu, 17 Oct 2013 17:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.017 X-Spam-Level: X-Spam-Status: No, score=-105.017 tagged_above=-999 required=5 tests=[AWL=1.582, 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 CFcyfwv78THN; Thu, 17 Oct 2013 17:28:48 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2693B11E82E2; Thu, 17 Oct 2013 17:28:41 -0700 (PDT) Received: from mail203-co9-R.bigfish.com (10.236.132.240) by CO9EHSOBE022.bigfish.com (10.236.130.85) with Microsoft SMTP Server id 14.1.225.22; Fri, 18 Oct 2013 00:28:40 +0000 Received: from mail203-co9 (localhost [127.0.0.1]) by mail203-co9-R.bigfish.com (Postfix) with ESMTP id 0ABF48A00E3; Fri, 18 Oct 2013 00:28:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zz4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail203-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(164054003)(63696002)(76576001)(66066001)(76176001)(80976001)(59766001)(54316002)(56776001)(77982001)(76786001)(76796001)(76482001)(74662001)(47446002)(56816003)(83322001)(65816001)(79102001)(80022001)(31966008)(77096001)(74502001)(83072001)(33646001)(74366001)(81342001)(54356001)(53806001)(74876001)(85306002)(81686001)(81542001)(81816001)(50986001)(47976001)(4396001)(46102001)(74706001)(74316001)(69226001)(49866001)(51856001)(47736001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB323; H:BLUPR05MB323.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail203-co9 (localhost.localdomain [127.0.0.1]) by mail203-co9 (MessageSwitch) id 1382056117915399_11376; Fri, 18 Oct 2013 00:28:37 +0000 (UTC) Received: from CO9EHSMHS013.bigfish.com (unknown [10.236.132.240]) by mail203-co9.bigfish.com (Postfix) with ESMTP id 9FC3958004D; Fri, 18 Oct 2013 00:28:37 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS013.bigfish.com (10.236.130.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 18 Oct 2013 00:28:34 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com (10.141.24.26) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 18 Oct 2013 00:28:34 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com (10.141.24.26) by BLUPR05MB323.namprd05.prod.outlook.com (10.141.24.26) with Microsoft SMTP Server (TLS) id 15.0.785.10; Fri, 18 Oct 2013 00:28:33 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com ([169.254.6.200]) by BLUPR05MB323.namprd05.prod.outlook.com ([169.254.6.200]) with mapi id 15.00.0785.001; Fri, 18 Oct 2013 00:28:32 +0000 From: Stephen Hanna To: The IESG , "secdir@ietf.org" , "draft-ietf-manet-smf-mib.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-manet-smf-mib-08 Thread-Index: Ac7LmPjydxpNTDH1RCq+bXu7cbCCRQ== Date: Fri, 18 Oct 2013 00:28:32 +0000 Message-ID: <13b56319a7fc41d0a5f93caa4978af73@BLUPR05MB323.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 00032065B2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [secdir] secdir review of draft-ietf-manet-smf-mib-08 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, 18 Oct 2013 00:28:54 -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. While I am not an expert in SNMP, SMF, or MANET, I found this document to be well-written and easy to understand. More relevant to this review, the security of the protocol is adequate and the Security Considerations section is exemplary. I did notice two typos: * In the Security Considerations section, the commentary on smfConfiguredOpMode includes the words "this writable configuration objects define". This should end in "object define", I think. * In the Security Considerations section, the commentary on smfNhdpRssaMesgTLVIncluded includes the words "the the". Of course, that should be just "the". With these corrections, I think the document is ready to publish. Thanks, Steve From hannes.tschofenig@gmx.net Fri Oct 18 02:06:12 2013 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 44A6121F995A for ; Fri, 18 Oct 2013 02:06:12 -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 SMB3rKSF5pN9 for ; Fri, 18 Oct 2013 02:06:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 72C1421F9D7A for ; Fri, 18 Oct 2013 02:05:56 -0700 (PDT) Received: from [172.16.254.200] ([80.92.116.76]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MVJze-1VEp9o2gG6-00YgLZ for ; Fri, 18 Oct 2013 11:05:55 +0200 Message-ID: <5260FA10.7080801@gmx.net> Date: Fri, 18 Oct 2013 11:06:24 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Yaron Sheffer , IETF Security Directorate , The IESG , draft-ietf-tls-oob-pubkey.all@tools.ietf.org References: <520137EC.2030607@gmail.com> In-Reply-To: <520137EC.2030607@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:65gKxikoo9ZqQbhfah82YrGgorF2lDsRZta3xNGSQtBjGNW9kkA QPHdaLnyUlMBzHKdPObI2tspukprUBqOg2p8gMv/P59pKsENWmDyyvYvMDrlPuEzgKUeXSM aiKvgnl2FSlGHxNoIrmpVQS/33U0TlQMJAOFsUB//GmwPONbC9jPkkcRdpQMlsLiPE9J3tl dX4DbS08pUyO5UvvBHiIw== Subject: Re: [secdir] SecDir review of draft-ietf-tls-oob-pubkey-09 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, 18 Oct 2013 09:06:12 -0000 Hi Yaron, thanks for the review. A few remarks below. On 08/06/2013 07:52 PM, Yaron Sheffer 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. > > This document adds into TLS support for bare public keys (as opposed to > keys wrapped in certificates). The main use case cited is constrained > devices that get their trust anchors in an out-of-band manner (e.g. - > horror - embedded in their software) as a set of trusted public keys. > > Summary: this document is almost ready for publication, but needs > several clarifications and text improvements. Since some of the missing > pieces revolve around authentication, we may even need another last call > if (as discussed in Berlin) the document is to be merged or coordinated > with the Channel ID work. > > Details > > • 1: "an out-of-band mechanism is also used to bind the public key to > the entity presenting the key" - this text is strange. Obtaining the > public key can be OOB, but binding to the TLS identity is part of the > protocol negotiation. This sentence sounds as if we're trying to avoid a > "MUST authenticate". That's the best wording I came up with. I believe the term "authentication" does not really capture some of the scenarios well enough. Take the definition of authentication (from the handbook of applied cryptography): " Entity authentication is the process whereby one party is assured (through acquisition of corroborative evidence) of the identity of a second party involved in a protocol, and that the second has actually participated (i.e., is active at, or immediately prior to, the time the evidence is acquired). " For example, think about many of the cases where a fingerprint is printed on the back of your device. There, a human verifies it (out-of-band) but I am not sure I would call this 'identity'. But maybe I am interpreting the term 'authentication' a bit too strictly here. > • More generally, if the peer has an OOB way to obtain the public key > (it has to have one, otherwise it wouldn't be able to bind it to an > identity), why are we sending the full public key in the handshake, > rather than only a fingerprint? Reading further (in the Acknowledgements > section) it would appear this question has already been discussed in the > WG. Shouldn't this option, or the interaction with "cached info", be > mentioned here? I added a note about this aspect into the introduction and 'yes' this issue was discussed and the group made the decision to put the functionality into two separate documents. I would see it as a document management type of action. The argument was that the fingerprinting approach was broader applicability beyond just raw public key and that's obviously correct. > • 3, Fig. 1: why do we support a sequence of public keys? What is the > semantics? If the semantics is that you can authenticate using *one* of > the provided keys, then why not support mixing public keys and > certificates, or RSA with ECDSA public keys? The description may be a bit misleading. The message of Figure 1 is that we carry the raw public key in the Certificate payload. We have to carry it somewhere and that's what we do. In fact, that's not what we came up with but this was already done by prior work on the PGP stuff. You could call this part of the write-up background material but I had to include it since otherwise we have this dependency with the PGP document, which we wanted to avoid. I did, however, change the writeup of the section to improve readability. I hope it is clearer now. > • 3: "These extension MUST be omitted if the client only supports X.509 > certificates" (note the typo, should be "this") - this is IMO > overspecified, especially since the client can send a list of length 1 > containing only the X.509 identifier. You are right. I have been wondering myself whether I had gone a bit too far here. > • "The 'server_certificate_type' in the client hello indicates the type > of certificates" - this is probably a typo, and should be "types", i.e. > a list. Good catch. Yes, it should be types. > • In the two paragraphs discussing the semantics of the extensions, the > word "supported" is used very loosely, sometimes referring to what you > can send and sometimes to what you can accept. I suggest to clarify this > point, and I suspect that the last sentence ("if the server does not > send...") which is currently unclear will have to be corrected. I changed the wording in an attempt to improve clarity. > • 4.1: " MUST include the 'client_certificate_type' and > 'server_certificate_type' extensions" - do you really have to include > both extensions? What if only the server presents a public key? I changed it. Yes, it is not useful to send an empty extension. > • 4.2, bullet #2: does the server need to have a cert type in common > with the client, or just in common with the types that the client > specified in the "server cert type" extension? Bullet 2 talks about certificate type. For example, if the server only supports X.509 certificates and the client only raw public keys then there is obviously a problem. > • 5, Fig. 8: does the client really have to indicate support of the > server sending an X.509 cert? What if the client omits the > server_certificate_type extension? As currently specified, it has to indicate the supported certificate types (even if it is a X.509 certificate). Of course, we could say that if the client only supports an X.509 certificate for the server_certificate_type extension then it can be omitted. > • 6: what exactly is meant by "to check the status of that binding"? With X.509 certificates the binding between the public key and the identity is accomplished with the cert and the revocation mechanism. Since this is now done out-of-band the security ADs wanted to have a sentence added that this binding has to be fresh. Does this make sense? > • 7: at least in the HTML version of this draft, the > value/description/reference lines appear *before* the introductory > sentence. You are right. Interesting. It is correct in the TXT version. Ciao Hannes > > Thanks, > Yaron > From robert.g.cole.civ@mail.mil Fri Oct 18 05:38:12 2013 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 116D011E81B7; Fri, 18 Oct 2013 05:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 EPLs-Q520zri; Fri, 18 Oct 2013 05:38:05 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.13]) by ietfa.amsl.com (Postfix) with ESMTP id B337321F9FC6; Fri, 18 Oct 2013 05:38:05 -0700 (PDT) Received: from UCOLHP3E.easf.csd.disa.mil (131.64.100.144) by edge-cols.mail.mil (131.64.100.13) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Oct 2013 12:38:02 +0000 Received: from UCOLHP9H.easf.csd.disa.mil ([169.254.4.51]) by UCOLHP3E.easf.csd.disa.mil ([131.64.100.144]) with mapi id 14.03.0158.002; Fri, 18 Oct 2013 12:38:00 +0000 From: "Cole, Robert G CIV USARMY CERDEC (US)" To: Stephen Hanna , The IESG , "secdir@ietf.org" , "draft-ietf-manet-smf-mib.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-manet-smf-mib-08 (UNCLASSIFIED) Thread-Index: AQHOy/7gi3hywsAh60OUdEaIh2FpVw== Date: Fri, 18 Oct 2013 12:37:57 +0000 Message-ID: References: <13b56319a7fc41d0a5f93caa4978af73@BLUPR05MB323.namprd05.prod.outlook.com> In-Reply-To: <13b56319a7fc41d0a5f93caa4978af73@BLUPR05MB323.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 18 Oct 2013 06:02:48 -0700 Subject: Re: [secdir] secdir review of draft-ietf-manet-smf-mib-08 (UNCLASSIFIED) 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, 18 Oct 2013 12:38:12 -0000 Classification: UNCLASSIFIED Caveats: NONE Steve, thanks for your review. I'll fix. Bob US Army CERDEC QUEST Program, S&TCD APG, MD (c) 443.910.4420 (o) 443.395.8744 robert.g.cole@us.army.mil -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net]=20 Sent: Thursday, October 17, 2013 8:29 PM To: The IESG; secdir@ietf.org; draft-ietf-manet-smf-mib.all@tools.ietf.org Subject: secdir review of draft-ietf-manet-smf-mib-08 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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. While I am not an expert in SNMP, SMF, or MANET, I found this document to b= e well-written and easy to understand. More relevant to this review, the se= curity of the protocol is adequate and the Security Considerations section = is exemplary. I did notice two typos: * In the Security Considerations section, the commentary on smfConfiguredOpMode includes the words "this writable configuration objects define". This should end in "object define", I think. * In the Security Considerations section, the commentary on smfNhdpRssaMesgTLVIncluded includes the words "the the". Of course, that should be just "the". With these corrections, I think the document is ready to publish. Thanks, Steve Classification: UNCLASSIFIED Caveats: NONE From charliek@microsoft.com Mon Oct 21 16:10:19 2013 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 D366411E829D; Mon, 21 Oct 2013 16:10:19 -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 XbjjUW3+7V5p; Mon, 21 Oct 2013 16:10:14 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0151.outbound.protection.outlook.com [207.46.163.151]) by ietfa.amsl.com (Postfix) with ESMTP id 5B45C11E82A2; Mon, 21 Oct 2013 16:10:14 -0700 (PDT) Received: from BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) by BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) with Microsoft SMTP Server (TLS) id 15.0.785.10; Mon, 21 Oct 2013 23:10:12 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com ([169.254.11.86]) by BL2PR03MB592.namprd03.prod.outlook.com ([169.254.11.200]) with mapi id 15.00.0785.001; Mon, 21 Oct 2013 23:10:12 +0000 From: Charlie Kaufman To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-mpls-in-udp.all@tools.ietf.org" Thread-Topic: [secdir] secdir review of draft-ietf-mpls-in-udp-03 Thread-Index: Ac7Oq6NDCRIoApIoSR6dWI4QBbTnKQ== Date: Mon, 21 Oct 2013 23:10:11 +0000 Message-ID: <3cd3b247cdaa451f95757b3eb6cf3ff4@BL2PR03MB592.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] x-forefront-prvs: 00064751B6 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(74876001)(69226001)(74706001)(33646001)(74662001)(74502001)(47446002)(63696002)(83072001)(80022001)(65816001)(46102001)(49866001)(47736001)(54356001)(50986001)(81342001)(4396001)(51856001)(81542001)(53806001)(74366001)(47976001)(54316002)(80976001)(56776001)(81816001)(81686001)(74316001)(76786001)(76796001)(85306002)(79102001)(76176001)(56816003)(77096001)(77982001)(76482001)(76576001)(83322001)(59766001)(31966008)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB592; H:BL2PR03MB592.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::3; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: [secdir] secdir review of draft-ietf-mpls-in-udp-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, 21 Oct 2013 23:10:20 -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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document defines an encapsulation format for MPLS over UDP. There are = already specifications for MPLS over GRE and MPLS over IP. The motivation t= o add this third encapsulation format is to allow better path splitting of = the various substreams within the tunnel. It does this with a clever (and s= ome would say abusive) use of the UDP Source Port field. Because existing r= outers know to identify different streams based on the five tuple of source= -IP, destination-IP, source-port, destination-port, and protocol, this enca= psulation attempts to preserve that entropy by setting the source port equa= l to a hash of those 5 values of the encapsulated packet. There is another possible motivation (which I'm surprised the specification= does not mention), which is that some firewalls are willing to pass UDP bu= t not GRE or MPLS packets. The Security Considerations correctly notes that this encapsulation format = does not provide any integrity or confidentiality protection, and that if s= uch protection were to be provided with IPsec in transport mode then the ad= vantage of better path splitting of the various substreams would be lost. A= similar design could be used when encapsulating IPsec over UDP at the cost= of leaking information about the substreams to traffic analysis. But that = would belong in some other spec that specified an alternate IPsec over UDP = format (almost certainly using a different UDP port). My only complaint - and it is a minor one - is with the "Congestion Conside= rations" section. There, I expected to see something about the handling of = the congestion-experienced bits (though the correct processing is obvious, = probably covered by "Common Procedures" in RFC4023, and perhaps not worth m= entioning). The spec says that if the tunneled traffic is not known to be T= CP friendly and if the flow runs across an unprovisioned path that could po= tentially be congested, then the *application* MUST employ additional mecha= nisms to ensure that the offered load is reduced appropriately during perio= ds of congestion. My complaint is that there is no way for the routers doin= g the encapsulation/decapsulation to participate in the congestion mitigati= on process and therefore no way for an implementation of this specification= to be influenced by this requirement. I believe the spec would be equivale= nt and more clear had it said that the tunneled traffic MUST be TCP friendl= y. Even then, this seems more like operational guidance than a normative pa= rt of the specification. I mention these only as suggestions to the community. From a security stand= point, I believe the document is just fine as is. --Charlie From turners@ieca.com Wed Oct 23 10:07:01 2013 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 C9D7611E8436 for ; Wed, 23 Oct 2013 10:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.369 X-Spam-Level: X-Spam-Status: No, score=-101.369 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_05=-1.11, 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 GUEng9bjCKp0 for ; Wed, 23 Oct 2013 10:06:54 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.41.248.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7620C11E8455 for ; Wed, 23 Oct 2013 10:06:38 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id 6A0E1A4E3A136; Wed, 23 Oct 2013 12:06:35 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 520BFA4E3A0FB for ; Wed, 23 Oct 2013 12:06:35 -0500 (CDT) Received: from [96.231.225.44] (port=50755 helo=thunderfish.local) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VZ1tC-0002pn-PG for secdir@ietf.org; Wed, 23 Oct 2013 12:06:34 -0500 Message-ID: <5268021A.6040108@ieca.com> Date: Wed, 23 Oct 2013 13:06:34 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040704050100060301070008" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.225.44]:50755 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 7 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Subject: [secdir] secdir lunch 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, 23 Oct 2013 17:07:01 -0000 This is a cryptographically signed message in MIME format. --------------ms040704050100060301070008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I've reserved a room for our usual secdir lunch on Tuesday. The room=20 number has not been assigned and I will let you know when it is assigned.= spt --------------ms040704050100060301070008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCC BHwwggJkoAMCAQICCQCdWMxKNutUeTANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzET MBEGA1UEChMKSUVDQSwgSW5jLjAeFw0xMzA0MDMxNDUxMThaFw0xNDA0MDMxNDUxMThaMDgx CzAJBgNVBAYTAlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5l cjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOpCGCRptT1m+bIpLTmbahZLZ0Qe 4X99f8SgTQ7QISvUfpmntfOD1oA1AttXlOULEERYubzvDnUTXvstFomQx0XTA67IaV+mw9OD RtG1hPN/erdKX6sU6rH4tsEbba3Drr/I0HT3YVvD3SjWtGXjF12XLvTP6+LfMIIDTCAPiEd9 KPG23D7skVu/4BvvmdLFI96OARhgwQ86M+lTIn83KRJlbbfAeIevbRx/rUB7D+uvMdWxOzR0 KZJhd6dEeTXVwBXZG4rnQ4uFM+mRSiD4rxDCyOuIuOzR07tnOyCRio6sRipOZvwQUWttdsgM Es6IxLdWsaTXcs1HjCsxrdedovMCAwEAAaOBnjCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0j BBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYDVR0RBBQwEoEQVHVybmVyU0BpZWNhLmNv bTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3LmllY2EuY29tL2NybHMvaWVjYS5jcmww FwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEBCwUAA4ICAQAimDYm77ppTi4v K6qJSUhyvCDMGb8mngiEXEYKxsfdHPWoDO7+06j7dAZ8sDD9/FtEkiUMyoNGSUmKHR+tGper VnNiM/Zk6WwCJv8dYZwhGXNQeEGzeys/UkFv7CFX7uDSn8GQeB8sOAZ1N1hxV/TvT8qXvcRx P5+aWTAGAq3TKtCQxZjuU74L3st2hZiOhJlhjhqz0K5FIwWzXUK9uwhZe1thGUpDbRustVgm KN2Xa0pzwqI1VUO0jnWt24A4u59xo6DJQXzQVMhCx0xhpemuT9BrsBDTX8eJdI1iWv9wp3iv SrfHjKXp8y8OGD+usiG40HCjj0W9C+dH0VfbgrB6QOI4vA9+kTg4mANth1cxyxwPYOSJv0zi 1qR0eDIGI//2v2/s6TmGuNqbnRa26Ldv5gGqS7xj32Fiaby6UOXs4+aAIWGZEOH+BXjozcvE eGBwjU/VRQYu6itR28PaNhNVji4D5ITaGxWWiycqK1EUaFraWHtk7W100ROX69xTeFVZP86D 2ymi/aohl5Vb1vlYHdqlbgqjDRl9dPbTxVCXEHf+jkexcuwlLTvr7F+5DIN6c/EbCpRqQx3e dy193L48OGyRDh1/Wmzpew0VWWAWOSXGl/P9VzXf3Z6GPt7flN/V9iEJAa3Mo+w+eIdzJkHB WR+yJcqQcCRMMSyishMwLDGCAqcwggKjAgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoT CklFQ0EsIEluYy4CCQCdWMxKNutUeTAJBgUrDgMCGgUAoIIBTTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzEwMjMxNzA2MzRaMCMGCSqGSIb3DQEJBDEW BBRcnn49iTFQn8oKEALi5Xj3BoDtKjA+BgkrBgEEAYI3EAQxMTAvMCIxCzAJBgNVBAYTAlVT MRMwEQYDVQQKEwpJRUNBLCBJbmMuAgkAnVjMSjbrVHkwQAYLKoZIhvcNAQkQAgsxMaAvMCIx CzAJBgNVBAYTAlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuAgkAnVjMSjbrVHkwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG 9w0BAQEFAASCAQBSTr49PZCk6K17ir5nHc4aVIl3yRmm2vAZVUOsDats7v6BnjKuwoORHiyk OkyyUEuqhI6RjGtKIJaWDcPQKJK9RsG16THKjgm8A/xB2QKhwrL16fYCr+q2qR5mhY+x5K7W gW89u6kRhN/Rc7IhAV8kChkBkfMB0y/TYcepaVnDTa2KfBd05XI1nFLurByZFhMZIuIBgn2a XCmbtberXKe93IeTrfQPiNVjttvDblxN4YzZ786PCLgGoP3Lj9RtOmLOVFbAlAjjs+PTRU1I IGeIeCX0XPRnnfLL3oT16xlnoNp10t4tfZRHUpdW2vZ9rxO8CF0GNNCYzvlc9rdz69K8AAAA AAAA --------------ms040704050100060301070008-- From hartmans@mit.edu Wed Oct 23 11:23:53 2013 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 E0B8611E814F; Wed, 23 Oct 2013 11:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.918 X-Spam-Level: X-Spam-Status: No, score=-101.918 tagged_above=-999 required=5 tests=[AWL=0.681, 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 RFmU7Qqj0wtS; Wed, 23 Oct 2013 11:23:48 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id F124411E8126; Wed, 23 Oct 2013 11:23:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id D6EB82020C; Wed, 23 Oct 2013 14:21:48 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5PKZCFsBEyv; Wed, 23 Oct 2013 14:21:48 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 23 Oct 2013 14:21:48 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ED00482A4F; Wed, 23 Oct 2013 14:23:44 -0400 (EDT) From: Sam Hartman To: iesg@ietf.org,secdir@ietf.org Date: Wed, 23 Oct 2013 14:23:44 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [secdir] secdir review of draft-ietf-ipfix-data-link-layer-monitoring-06 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, 23 Oct 2013 18:23:54 -0000 This document describes IPFIX information elements needed for data link monitoring, including carrier ethernet and datacenter virtual ethernets. There don't seem to be any new security considerations and the security considerations section points to the existing specs. --Sam From xuxiaohu@huawei.com Thu Oct 24 02:49:43 2013 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 D098511E8306; Thu, 24 Oct 2013 02:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 RgbxTaCzTUd3; Thu, 24 Oct 2013 02:49:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DAD5811E8153; Thu, 24 Oct 2013 02:49:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZK55766; Thu, 24 Oct 2013 09:49:36 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Oct 2013 10:49:15 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Oct 2013 10:49:19 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.24]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0146.000; Thu, 24 Oct 2013 17:49:12 +0800 From: Xuxiaohu To: Charlie Kaufman , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-mpls-in-udp.all@tools.ietf.org" Thread-Topic: [secdir] secdir review of draft-ietf-mpls-in-udp-03 Thread-Index: Ac7Oq6NDCRIoApIoSR6dWI4QBbTnKQB8m0KA Date: Thu, 24 Oct 2013 09:49:11 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0821B20F@NKGEML512-MBS.china.huawei.com> References: <3cd3b247cdaa451f95757b3eb6cf3ff4@BL2PR03MB592.namprd03.prod.outlook.com> In-Reply-To: <3cd3b247cdaa451f95757b3eb6cf3ff4@BL2PR03MB592.namprd03.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Thu, 24 Oct 2013 02:51:26 -0700 Subject: Re: [secdir] secdir review of draft-ietf-mpls-in-udp-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: Thu, 24 Oct 2013 09:49:43 -0000 SGkgQ2hhcmxpZSwNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIFNlY2RpciByZXZpZXcgb2YgdGhp cyBkcmFmdC4gV2Ugd2lsbCBpbmNvcnBvcmF0ZSB5b3VyIGNvbW1lbnRzIGluIHRoZSBuZXh0IHJl dmlzaW9uLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0N Cj4gt6K8/sjLOiBDaGFybGllIEthdWZtYW4gW21haWx0bzpjaGFybGlla0BtaWNyb3NvZnQuY29t XQ0KPiC3osvNyrG85DogMjAxM8TqMTDUwjIyyNUgNzoxMA0KPiDK1bz+yMs6IGllc2dAaWV0Zi5v cmc7IHNlY2RpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC5hbGxAdG9vbHMuaWV0 Zi5vcmcNCj4g1vfM4jogW3NlY2Rpcl0gc2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLW1wbHMt aW4tdWRwLTAzDQo+IA0KPiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9m IHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcNCj4gZWZmb3J0IHRvIHJldmlldyBh bGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAgVGhlc2UNCj4g Y29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNl Y3VyaXR5IGFyZWEgZGlyZWN0b3JzLg0KPiBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMg c2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkNCj4gb3RoZXIgbGFzdCBj YWxsIGNvbW1lbnRzLg0KPiANCj4gVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFuIGVuY2Fwc3VsYXRp b24gZm9ybWF0IGZvciBNUExTIG92ZXIgVURQLiBUaGVyZSBhcmUNCj4gYWxyZWFkeSBzcGVjaWZp Y2F0aW9ucyBmb3IgTVBMUyBvdmVyIEdSRSBhbmQgTVBMUyBvdmVyIElQLiBUaGUgbW90aXZhdGlv biB0bw0KPiBhZGQgdGhpcyB0aGlyZCBlbmNhcHN1bGF0aW9uIGZvcm1hdCBpcyB0byBhbGxvdyBi ZXR0ZXIgcGF0aCBzcGxpdHRpbmcgb2YgdGhlDQo+IHZhcmlvdXMgc3Vic3RyZWFtcyB3aXRoaW4g dGhlIHR1bm5lbC4gSXQgZG9lcyB0aGlzIHdpdGggYSBjbGV2ZXIgKGFuZCBzb21lDQo+IHdvdWxk IHNheSBhYnVzaXZlKSB1c2Ugb2YgdGhlIFVEUCBTb3VyY2UgUG9ydCBmaWVsZC4gQmVjYXVzZSBl eGlzdGluZyByb3V0ZXJzDQo+IGtub3cgdG8gaWRlbnRpZnkgZGlmZmVyZW50IHN0cmVhbXMgYmFz ZWQgb24gdGhlIGZpdmUgdHVwbGUgb2Ygc291cmNlLUlQLA0KPiBkZXN0aW5hdGlvbi1JUCwgc291 cmNlLXBvcnQsIGRlc3RpbmF0aW9uLXBvcnQsIGFuZCBwcm90b2NvbCwgdGhpcyBlbmNhcHN1bGF0 aW9uDQo+IGF0dGVtcHRzIHRvIHByZXNlcnZlIHRoYXQgZW50cm9weSBieSBzZXR0aW5nIHRoZSBz b3VyY2UgcG9ydCBlcXVhbCB0byBhIGhhc2ggb2YNCj4gdGhvc2UgNSB2YWx1ZXMgb2YgdGhlIGVu Y2Fwc3VsYXRlZCBwYWNrZXQuDQo+IA0KPiBUaGVyZSBpcyBhbm90aGVyIHBvc3NpYmxlIG1vdGl2 YXRpb24gKHdoaWNoIEknbSBzdXJwcmlzZWQgdGhlIHNwZWNpZmljYXRpb24gZG9lcw0KPiBub3Qg bWVudGlvbiksIHdoaWNoIGlzIHRoYXQgc29tZSBmaXJld2FsbHMgYXJlIHdpbGxpbmcgdG8gcGFz cyBVRFAgYnV0IG5vdCBHUkUNCj4gb3IgTVBMUyBwYWNrZXRzLg0KPiANCj4gVGhlIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zIGNvcnJlY3RseSBub3RlcyB0aGF0IHRoaXMgZW5jYXBzdWxhdGlvbiBm b3JtYXQgZG9lcw0KPiBub3QgcHJvdmlkZSBhbnkgaW50ZWdyaXR5IG9yIGNvbmZpZGVudGlhbGl0 eSBwcm90ZWN0aW9uLCBhbmQgdGhhdCBpZiBzdWNoDQo+IHByb3RlY3Rpb24gd2VyZSB0byBiZSBw cm92aWRlZCB3aXRoIElQc2VjIGluIHRyYW5zcG9ydCBtb2RlIHRoZW4gdGhlDQo+IGFkdmFudGFn ZSBvZiBiZXR0ZXIgcGF0aCBzcGxpdHRpbmcgb2YgdGhlIHZhcmlvdXMgc3Vic3RyZWFtcyB3b3Vs ZCBiZSBsb3N0LiBBDQo+IHNpbWlsYXIgZGVzaWduIGNvdWxkIGJlIHVzZWQgd2hlbiBlbmNhcHN1 bGF0aW5nIElQc2VjIG92ZXIgVURQIGF0IHRoZSBjb3N0IG9mDQo+IGxlYWtpbmcgaW5mb3JtYXRp b24gYWJvdXQgdGhlIHN1YnN0cmVhbXMgdG8gdHJhZmZpYyBhbmFseXNpcy4gQnV0IHRoYXQgd291 bGQNCj4gYmVsb25nIGluIHNvbWUgb3RoZXIgc3BlYyB0aGF0IHNwZWNpZmllZCBhbiBhbHRlcm5h dGUgSVBzZWMgb3ZlciBVRFAgZm9ybWF0DQo+IChhbG1vc3QgY2VydGFpbmx5IHVzaW5nIGEgZGlm ZmVyZW50IFVEUCBwb3J0KS4NCj4gDQo+IE15IG9ubHkgY29tcGxhaW50IC0gYW5kIGl0IGlzIGEg bWlub3Igb25lIC0gaXMgd2l0aCB0aGUgIkNvbmdlc3Rpb24NCj4gQ29uc2lkZXJhdGlvbnMiIHNl Y3Rpb24uIFRoZXJlLCBJIGV4cGVjdGVkIHRvIHNlZSBzb21ldGhpbmcgYWJvdXQgdGhlIGhhbmRs aW5nDQo+IG9mIHRoZSBjb25nZXN0aW9uLWV4cGVyaWVuY2VkIGJpdHMgKHRob3VnaCB0aGUgY29y cmVjdCBwcm9jZXNzaW5nIGlzIG9idmlvdXMsDQo+IHByb2JhYmx5IGNvdmVyZWQgYnkgIkNvbW1v biBQcm9jZWR1cmVzIiBpbiBSRkM0MDIzLCBhbmQgcGVyaGFwcyBub3Qgd29ydGgNCj4gbWVudGlv bmluZykuIFRoZSBzcGVjIHNheXMgdGhhdCBpZiB0aGUgdHVubmVsZWQgdHJhZmZpYyBpcyBub3Qg a25vd24gdG8gYmUgVENQDQo+IGZyaWVuZGx5IGFuZCBpZiB0aGUgZmxvdyBydW5zIGFjcm9zcyBh biB1bnByb3Zpc2lvbmVkIHBhdGggdGhhdCBjb3VsZCBwb3RlbnRpYWxseQ0KPiBiZSBjb25nZXN0 ZWQsIHRoZW4gdGhlICphcHBsaWNhdGlvbiogTVVTVCBlbXBsb3kgYWRkaXRpb25hbCBtZWNoYW5p c21zIHRvDQo+IGVuc3VyZSB0aGF0IHRoZSBvZmZlcmVkIGxvYWQgaXMgcmVkdWNlZCBhcHByb3By aWF0ZWx5IGR1cmluZyBwZXJpb2RzIG9mDQo+IGNvbmdlc3Rpb24uIE15IGNvbXBsYWludCBpcyB0 aGF0IHRoZXJlIGlzIG5vIHdheSBmb3IgdGhlIHJvdXRlcnMgZG9pbmcgdGhlDQo+IGVuY2Fwc3Vs YXRpb24vZGVjYXBzdWxhdGlvbiB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgY29uZ2VzdGlvbiBtaXRp Z2F0aW9uIHByb2Nlc3MNCj4gYW5kIHRoZXJlZm9yZSBubyB3YXkgZm9yIGFuIGltcGxlbWVudGF0 aW9uIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiB0byBiZQ0KPiBpbmZsdWVuY2VkIGJ5IHRoaXMgcmVx dWlyZW1lbnQuIEkgYmVsaWV2ZSB0aGUgc3BlYyB3b3VsZCBiZSBlcXVpdmFsZW50IGFuZA0KPiBt b3JlIGNsZWFyIGhhZCBpdCBzYWlkIHRoYXQgdGhlIHR1bm5lbGVkIHRyYWZmaWMgTVVTVCBiZSBU Q1AgZnJpZW5kbHkuIEV2ZW4gdGhlbiwNCj4gdGhpcyBzZWVtcyBtb3JlIGxpa2Ugb3BlcmF0aW9u YWwgZ3VpZGFuY2UgdGhhbiBhIG5vcm1hdGl2ZSBwYXJ0IG9mIHRoZQ0KPiBzcGVjaWZpY2F0aW9u Lg0KPiANCj4gSSBtZW50aW9uIHRoZXNlIG9ubHkgYXMgc3VnZ2VzdGlvbnMgdG8gdGhlIGNvbW11 bml0eS4gRnJvbSBhIHNlY3VyaXR5DQo+IHN0YW5kcG9pbnQsIEkgYmVsaWV2ZSB0aGUgZG9jdW1l bnQgaXMganVzdCBmaW5lIGFzIGlzLg0KPiANCj4gCS0tQ2hhcmxpZQ0KPiANCg0K From kivinen@iki.fi Thu Oct 24 04:59:12 2013 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 4B54E11E8256 for ; Thu, 24 Oct 2013 04:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 P2-0dLu04kz5 for ; Thu, 24 Oct 2013 04:59:11 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 90D9A11E8143 for ; Thu, 24 Oct 2013 04:59:04 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9OBwwoQ014781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 24 Oct 2013 14:58:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9OBww6x013401; Thu, 24 Oct 2013 14:58:58 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21097.2946.312270.189542@fireball.kivinen.iki.fi> Date: Thu, 24 Oct 2013 14:58:58 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 4 min X-Total-Time: 4 min 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, 24 Oct 2013 11:59:12 -0000 The draft-ietf-httpbis-p* documents came to last call now. Some of those have already been assigned for early reviews and some of those early reviews have even been done. Some of those are reviewed only now, and there is some long documents to be reviewed... Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Radia Perlman is next in the rotation. For telechat 2013-10-24 Reviewer LC end Draft Rob Austein T 2013-10-16 draft-kolkman-proposed-standards-clarified-04 Alan DeKok T 2013-10-18 draft-hethmon-mcmurray-ftpext-ftp-hosts-03 Donald Eastlake T 2013-10-10 draft-mcgrew-tls-aes-ccm-ecc-07 Dan Harkins T 2013-10-16 draft-ietf-mpls-tp-rosetta-stone-13 Warren Kumari TR2013-09-19 draft-ietf-ccamp-otn-g709-info-model-12 For telechat 2013-11-21 Jeffrey Hutzelman T 2013-11-04 draft-resnick-on-consensus-05 Scott Kelly T 2013-10-29 draft-ietf-appsawg-malformed-mail-09 Warren Kumari T 2013-11-18 draft-housley-smime-oids-00 Yoav Nir T 2013-11-01 draft-ietf-nfsv4-labreqs-04 Last calls and special requests: Dave Cridland 2013-11-04 draft-ietf-httpbis-p5-range-24 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Shawn Emery - draft-ietf-tictoc-security-requirements-06 Phillip Hallam-Baker 2013-10-16 draft-ietf-ccamp-gmpls-ospf-g709v3-10 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-05 Leif Johansson 2013-11-04 draft-sin-sdnrg-sdn-approach-04 Simon Josefsson 2013-11-04 draft-trammell-ipfix-tcpcontrolbits-revision-04 Stephen Kent R2013-11-04 draft-ietf-httpbis-p7-auth-24 Tero Kivinen R2013-11-04 draft-ietf-httpbis-p6-cache-24 Tero Kivinen 2013-10-24 draft-ietf-roll-trickle-mcast-05 Julien Laganier - draft-ietf-avtcore-rtp-security-options-08 Julien Laganier - draft-ietf-websec-key-pinning-08 Julien Laganier 2013-11-06 draft-ietf-forces-ceha-08 Ben Laurie 2013-11-04 draft-ietf-httpbis-p1-messaging-24 Matt Lepinski 2013-11-04 draft-ietf-httpbis-p2-semantics-24 Chris Lonvick 2013-11-01 draft-ietf-multimob-handover-optimization-05 Catherine Meadows 2013-11-04 draft-ietf-httpbis-authscheme-registrations-08 Alexey Melnikov - draft-ietf-payload-rtp-howto-09 Alexey Melnikov 2013-11-04 draft-ietf-httpbis-method-registrations-13 Kathleen Moriarty 2013-11-06 draft-ietf-mpls-ldp-multi-topology-09 Sandy Murphy 2013-10-31 draft-ietf-netext-pd-pmip-11 Magnus Nystrom 2013-11-06 draft-ietf-pim-explicit-tracking-08 Hilarie Orman 2013-11-18 draft-shore-icmp-aup-06 Vincent Roca 2013-09-24 draft-ietf-mmusic-duplication-grouping-03 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-14 Sam Weiler 2013-09-30 draft-ietf-opsec-ip-options-filtering-05 Klaas Wierenga R2013-11-04 draft-ietf-httpbis-p4-conditional-24 Tom Yu 2013-10-01 draft-ietf-sidr-origin-ops-22 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 -- kivinen@iki.fi From derek@ihtfp.com Thu Oct 24 07:54:58 2013 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 4244211E8330; Thu, 24 Oct 2013 07:54:58 -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 hR9qYiOLGmx2; Thu, 24 Oct 2013 07:54:56 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id 006DE11E833F; Thu, 24 Oct 2013 07:53:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id A277F2602B8; Thu, 24 Oct 2013 10:53:33 -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 05712-05; Thu, 24 Oct 2013 10:53:31 -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 8E6BA260211; Thu, 24 Oct 2013 10:53:31 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.5/Submit) id r9OErRQo014022; Thu, 24 Oct 2013 10:53:27 -0400 From: Derek Atkins To: "Hutton\, Andrew" References: <9F33F40F6F2CD847824537F3C4E37DDF17BF527F@MCHP04MSX.global-ad.net> Date: Thu, 24 Oct 2013 10:53:26 -0400 In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17BF527F@MCHP04MSX.global-ad.net> (Andrew Hutton's message of "Wed, 16 Oct 2013 14:20:21 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: "leon.portman@gmail.com" , "secdir@ietf.org" , "krehor@cisco.com" , "iesg@ietf.org" , "siprec-chairs@tools.ietf.org" , "rajnish.jain@outlook.com" Subject: Re: [secdir] sec-dir review of draft-ietf-siprec-architecture-08 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, 24 Oct 2013 14:54:58 -0000 Hi Andrew, Sorry for the delay in responding. I personally feel that there is a big difference between the interactive, real-time SIP components versus a service that is specifically designed to record and replay content later. The key management of the real-time components is all immediate, there is no storage required, once the keys get to the endpoints you're done and all you do is transmit encrypted content. However a storage system has significantly different requirements. It has to store the keys that protect the content, and it must store those keys securely. It then has to be able to securely distribute those keys only to authorized receipients. So yes, I think it is important to talk about at least the requirements for what the recording agent MUST do, even if you don't necessarily specify HOW the agent must do it. E.g. I think it's okay to say something like "the stored content must be protected using a cipher at least as strong (or stronger) than the original content" -- i.e., you don't need to specify "you MUST use AES-256". Yet I still think you need to talk about the key management requirements of the storage (and more importantly retrieval). Thanks, -derek "Hutton, Andrew" writes: > Hi Derek, > > Thanks for your comment and sorry for taking a while to get back to you. > > The security considerations section contains the following text: > > " It is the responsibility of the Session Recording Server to protect > the Replicated Media and Recording Metadata once it has been received > and archived. The mechanism for protecting the storage and retrieval > from the SRS is out of scope of this work." > > > Personally I think this is reasonable as we never say anything in SIP > related specifications what a UA should do with the media once it has > been received and this work is all about delivering the media and > related metadata to the recording system not what it does with it > afterwards. > > Is it really necessary to go any further than this? > > Regards > Andy (SIPREC Co-Chair). > > > > >> -----Original Message----- >> From: Derek Atkins [mailto:derek@ihtfp.com] >> Sent: 01 October 2013 16:34 >> To: iesg@ietf.org; secdir@ietf.org >> Cc: siprec-chairs@tools.ietf.org; krehor@cisco.com; >> rajnish.jain@outlook.com; leon.portman@gmail.com; Hutton, Andrew >> Subject: sec-dir review of draft-ietf-siprec-architecture-08 >> >> 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. >> >> Session recording is a critical requirement in many communications >> environments such as call centers and financial trading. In some of >> these environments, all calls must be recorded for regulatory, >> compliance, and consumer protection reasons. Recording of a session >> is typically performed by sending a copy of a media stream to a >> recording device. This document describes architectures for >> deploying session recording solutions in an environment which is >> based on the Session Initiation Protocol (SIP). >> >> Retrieving recorded media is a potential Key Management problem which >> this document completely ignores (and even claims is out of scope). >> The key used to encrypt the recorded media (whether or not the media >> is re-encrypted) must be stored and retrieved as part of the media >> retrieval. How this important data is stored and retrieved is left >> out, leaving an implementation with no guidance on how to protect that >> valuable asset. In fact the document completely elides the question >> of how a retriever obtains the data encryption key. Even if it's just >> additional guidance the Security Considerations should at least >> explain the problem even if it doesn't provide a solution. >> >> -derek >> >> -- >> Derek Atkins 617-623-3745 >> derek@ihtfp.com www.ihtfp.com >> Computer and Internet Security Consultant > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From d3e3e3@gmail.com Thu Oct 24 08:29:47 2013 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 B83B911E8311; Thu, 24 Oct 2013 08:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-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 hUiisrCOSAG3; Thu, 24 Oct 2013 08:29:47 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id BE3B511E8333; Thu, 24 Oct 2013 08:29:43 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id wo20so2492825obc.11 for ; Thu, 24 Oct 2013 08:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=hAQEod7nX2zey8v2vWBwlTtGyZLbL/u0VFce2ZFJFd4=; b=pptdZiivX4tsr97q7rXOBpaQoTSynTwvfSNT7Za7bVHV0mwK3OPMUOtldB0i0m09eR F21hlNysVqKPcXoU/DEVsUeN3aImbc/DVIA3QmEIch7tfIFdmW/9FIcFqi12McEhBKjT 010NJWGiGnJa97XeZ+B/YZdU/XT8luXphAdy1ywd6HYoXZ+HzrY6Myk7RS/0WaQezYg3 bZPOcRHl3dLBRYjxczslWamjWeOAGP60J9iaBjNaeehxTkPQtkNwNHlNda0BswkLjWvq tRE4knTyPTvMkZv/jMiJ7yOaGRgzQnS2zBelY9VaFrWEKgj5aqhD4AJnMvuQcQMz8sY1 ixAA== X-Received: by 10.182.80.196 with SMTP id t4mr2629383obx.1.1382628583375; Thu, 24 Oct 2013 08:29:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.33.102 with HTTP; Thu, 24 Oct 2013 08:29:23 -0700 (PDT) From: Donald Eastlake Date: Thu, 24 Oct 2013 11:29:23 -0400 Message-ID: To: "iesg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-mcgrew-tls-aes-ccm-ecc.all@tools.ietf.org, "secdir@ietf.org" Subject: [secdir] draft-mcgrew-tls-aes-ccm-ecc SECDIR Review 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, 24 Oct 2013 15:29:47 -0000 My apologies. I don't know that a review this late is useful but I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. This document specifies the use of AES and ECC in CBC-MAC Mode (CCM) for TLS 1.2. Further, it uses Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) to establish keys. The document is pretty short and to the point. The Security Considerations section just mentions the benefit of "perfect forward secrecy", the burden that the counter in AES-CCM never be reused, and how that burden is met. I believe that, overall, the document adequately covers needed security considerations when one also takes into account material outside of the Security Considerations section. Question: There are a number of SHOULDs in this draft with no indication of when you might not do what is specified. For example "The client SHOULD offer the elliptic_curves extension" If the specified crypto depends on ECC, what happens if the client doesn't do that? Trivia: In standards track documents, I prefer to use "specifies" rather than "describes", for example in the abstract and introduction. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From andrew.hutton@unify.com Thu Oct 24 08:38:04 2013 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 B962611E8342; Thu, 24 Oct 2013 08:38:04 -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 fGGyKxMZfYDQ; Thu, 24 Oct 2013 08:38:00 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id EA43E11E8357; Thu, 24 Oct 2013 08:36:59 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 9EE0923F0482; Thu, 24 Oct 2013 17:36:57 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.31]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Thu, 24 Oct 2013 17:36:57 +0200 From: "Hutton, Andrew" To: Derek Atkins Thread-Topic: sec-dir review of draft-ietf-siprec-architecture-08 Thread-Index: AQHO0MjSFpuNNNCQs06E2FZPbdmFCZoD+qYw Date: Thu, 24 Oct 2013 15:36:57 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C078BD@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF17BF527F@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec-chairs@tools.ietf.org" , "secdir@ietf.org" , "krehor@cisco.com" , "iesg@ietf.org" , "leon.portman@gmail.com" , "rajnish.jain@outlook.com" Subject: Re: [secdir] sec-dir review of draft-ietf-siprec-architecture-08 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, 24 Oct 2013 15:38:04 -0000 Hi Derek, I am ok with putting something in the security considerations to say the ke= y management requirements for storage and retrieval is something that the r= ecording system will need to consider but I would still say that saying any= thing more than that is out of scope. What do others think? Andy > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: 24 October 2013 15:53 > To: Hutton, Andrew > Cc: Derek Atkins; iesg@ietf.org; secdir@ietf.org; siprec- > chairs@tools.ietf.org; krehor@cisco.com; rajnish.jain@outlook.com; > leon.portman@gmail.com > Subject: Re: sec-dir review of draft-ietf-siprec-architecture-08 >=20 > Hi Andrew, >=20 > Sorry for the delay in responding. >=20 > I personally feel that there is a big difference between the > interactive, real-time SIP components versus a service that is > specifically designed to record and replay content later. The key > management of the real-time components is all immediate, there is no > storage required, once the keys get to the endpoints you're done and > all > you do is transmit encrypted content. >=20 > However a storage system has significantly different requirements. It > has to store the keys that protect the content, and it must store those > keys securely. It then has to be able to securely distribute those > keys > only to authorized receipients. >=20 > So yes, I think it is important to talk about at least the requirements > for what the recording agent MUST do, even if you don't necessarily > specify HOW the agent must do it. E.g. I think it's okay to say > something like "the stored content must be protected using a cipher at > least as strong (or stronger) than the original content" -- i.e., you > don't need to specify "you MUST use AES-256". Yet I still think you > need to talk about the key management requirements of the storage (and > more importantly retrieval). >=20 > Thanks, >=20 > -derek >=20 > "Hutton, Andrew" writes: >=20 > > Hi Derek, > > > > Thanks for your comment and sorry for taking a while to get back to > you. > > > > The security considerations section contains the following text: > > > > " It is the responsibility of the Session Recording Server to protect > > the Replicated Media and Recording Metadata once it has been > received > > and archived. The mechanism for protecting the storage and > retrieval > > from the SRS is out of scope of this work." > > > > > > Personally I think this is reasonable as we never say anything in SIP > > related specifications what a UA should do with the media once it has > > been received and this work is all about delivering the media and > > related metadata to the recording system not what it does with it > > afterwards. > > > > Is it really necessary to go any further than this? > > > > Regards > > Andy (SIPREC Co-Chair). > > > > > > > > > >> -----Original Message----- > >> From: Derek Atkins [mailto:derek@ihtfp.com] > >> Sent: 01 October 2013 16:34 > >> To: iesg@ietf.org; secdir@ietf.org > >> Cc: siprec-chairs@tools.ietf.org; krehor@cisco.com; > >> rajnish.jain@outlook.com; leon.portman@gmail.com; Hutton, Andrew > >> Subject: sec-dir review of draft-ietf-siprec-architecture-08 > >> > >> 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. > >> > >> Session recording is a critical requirement in many > communications > >> environments such as call centers and financial trading. In some > of > >> these environments, all calls must be recorded for regulatory, > >> compliance, and consumer protection reasons. Recording of a > session > >> is typically performed by sending a copy of a media stream to a > >> recording device. This document describes architectures for > >> deploying session recording solutions in an environment which is > >> based on the Session Initiation Protocol (SIP). > >> > >> Retrieving recorded media is a potential Key Management problem > which > >> this document completely ignores (and even claims is out of scope). > >> The key used to encrypt the recorded media (whether or not the media > >> is re-encrypted) must be stored and retrieved as part of the media > >> retrieval. How this important data is stored and retrieved is left > >> out, leaving an implementation with no guidance on how to protect > that > >> valuable asset. In fact the document completely elides the question > >> of how a retriever obtains the data encryption key. Even if it's > just > >> additional guidance the Security Considerations should at least > >> explain the problem even if it doesn't provide a solution. > >> > >> -derek > >> > >> -- > >> Derek Atkins 617-623-3745 > >> derek@ihtfp.com www.ihtfp.com > >> Computer and Internet Security Consultant > > > > >=20 > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From warren@kumari.net Thu Oct 24 08:59:06 2013 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 EC5C011E839A for ; Thu, 24 Oct 2013 08:58:24 -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 w1mE7kaTFDqL for ; Thu, 24 Oct 2013 08:58:11 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65D811E82DA for ; Thu, 24 Oct 2013 08:53:49 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.103]) by vimes.kumari.net (Postfix) with ESMTPSA id A24ED1B40316; Thu, 24 Oct 2013 11:53:48 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Oct 2013 11:53:44 -0400 Message-Id: <40CBA122-50DD-423A-B93B-B4EE2E473429@kumari.net> To: "secdir@ietf.org" , draft-housley-smime-oids@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [secdir] SecDir Review of draft-housley-smime-oids 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, 24 Oct 2013 15:59:18 -0000 Summary: It's all good. 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 transfers control of an object identifier arc to IANA, and = establishes allocation policies for future assignments within that arc. Security concerns: None=85. Well, I *guess* someone at the IANA could forget his / her car = keys while updating the registry, and someone might steal them[0]. W=20 [0]: I dislike claiming that there are no security concerns at all, and = so I just made up some contrived example.=20 -- Some people are like Slinkies......Not really good for anything but they = still bring a smile to your face when you push them down the stairs. From jhutz@cmu.edu Thu Oct 24 10:13:01 2013 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 96F1D11E81B9; Thu, 24 Oct 2013 10:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.74 X-Spam-Level: X-Spam-Status: No, score=-104.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 TjTXhrRkqIjm; Thu, 24 Oct 2013 10:12:55 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC6911E81BE; Thu, 24 Oct 2013 10:11:02 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r9OHAY0F008087 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 24 Oct 2013 13:10:34 -0400 (EDT) Message-ID: <1382634633.4490.21.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: iesg@ietf.org, secdir@ietf.org, draft-resnick-on-consensus.all@tools.ietf.org Date: Thu, 24 Oct 2013 13:10:33 -0400 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: jhutz@cmu.edu Subject: [secdir] secdir review of draft-resnick-on-consensus 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, 24 Oct 2013 17:13:01 -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 is an Informational document which, to quote the abstract, examines "what rough consensus is, how we have gotten away from it, and the things we can do in order to really achieve rough consensus." It's an excellent treatment of that issue, and one I look forward to being able to cite as a reference when trying to explain to people what rough consensus is and what it is not. Like Pete, I've noticed a growing trend toward voting and things that smell like voting, with sometimes unfortunate results. Hopefully this will prove an effective tool in opposing that trend. Publish this, please. -- Jeff From rajnish.jain@outlook.com Thu Oct 24 10:51:45 2013 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 0816611E81DE; Thu, 24 Oct 2013 10:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 OOMTxwhxXOdk; Thu, 24 Oct 2013 10:51:24 -0700 (PDT) Received: from bay0-omc3-s24.bay0.hotmail.com (bay0-omc3-s24.bay0.hotmail.com [65.54.190.162]) by ietfa.amsl.com (Postfix) with ESMTP id 66CED11E8370; Thu, 24 Oct 2013 10:47:46 -0700 (PDT) Received: from BAY168-W92 ([65.54.190.189]) by bay0-omc3-s24.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Oct 2013 10:47:46 -0700 X-TMN: [nlQ8V74ZHZq03v1J9GLaGnCqeHlGOWRd] X-Originating-Email: [rajnish.jain@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_4e700fd4-c116-462d-9386-aa3881da5d52_" From: Raj Jain To: "Hutton, Andrew" , Derek Atkins Date: Thu, 24 Oct 2013 13:47:45 -0400 Importance: Normal In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C078BD@MCHP04MSX.global-ad.net> References: , <9F33F40F6F2CD847824537F3C4E37DDF17BF527F@MCHP04MSX.global-ad.net>, , <9F33F40F6F2CD847824537F3C4E37DDF17C078BD@MCHP04MSX.global-ad.net> MIME-Version: 1.0 X-OriginalArrivalTime: 24 Oct 2013 17:47:46.0279 (UTC) FILETIME=[25EC5F70:01CED0E1] X-Mailman-Approved-At: Thu, 24 Oct 2013 10:57:28 -0700 Cc: Leon Portman , "krehor@cisco.com" , "iesg@ietf.org" , "siprec-chairs@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] sec-dir review of draft-ietf-siprec-architecture-08 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, 24 Oct 2013 17:52:22 -0000 --_4e700fd4-c116-462d-9386-aa3881da5d52_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think Andy's approach to addressing this is appropriate. The way recordin= g systems deal with the security issues of archived media content seems out= of scope of SIPREC. A statement can be made to clarify this the way Andy i= s proposing. =20 > From: andrew.hutton@unify.com > To: derek@ihtfp.com > CC: iesg@ietf.org=3B secdir@ietf.org=3B siprec-chairs@tools.ietf.org=3B k= rehor@cisco.com=3B rajnish.jain@outlook.com=3B leon.portman@gmail.com > Subject: RE: sec-dir review of draft-ietf-siprec-architecture-08 > Date: Thu=2C 24 Oct 2013 15:36:57 +0000 >=20 > Hi Derek=2C >=20 > I am ok with putting something in the security considerations to say the = key management requirements for storage and retrieval is something that the= recording system will need to consider but I would still say that saying a= nything more than that is out of scope. >=20 > What do others think? >=20 > Andy >=20 >=20 > > -----Original Message----- > > From: Derek Atkins [mailto:derek@ihtfp.com] > > Sent: 24 October 2013 15:53 > > To: Hutton=2C Andrew > > Cc: Derek Atkins=3B iesg@ietf.org=3B secdir@ietf.org=3B siprec- > > chairs@tools.ietf.org=3B krehor@cisco.com=3B rajnish.jain@outlook.com= =3B > > leon.portman@gmail.com > > Subject: Re: sec-dir review of draft-ietf-siprec-architecture-08 > >=20 > > Hi Andrew=2C > >=20 > > Sorry for the delay in responding. > >=20 > > I personally feel that there is a big difference between the > > interactive=2C real-time SIP components versus a service that is > > specifically designed to record and replay content later. The key > > management of the real-time components is all immediate=2C there is no > > storage required=2C once the keys get to the endpoints you're done and > > all > > you do is transmit encrypted content. > >=20 > > However a storage system has significantly different requirements. It > > has to store the keys that protect the content=2C and it must store tho= se > > keys securely. It then has to be able to securely distribute those > > keys > > only to authorized receipients. > >=20 > > So yes=2C I think it is important to talk about at least the requiremen= ts > > for what the recording agent MUST do=2C even if you don't necessarily > > specify HOW the agent must do it. E.g. I think it's okay to say > > something like "the stored content must be protected using a cipher at > > least as strong (or stronger) than the original content" -- i.e.=2C you > > don't need to specify "you MUST use AES-256". Yet I still think you > > need to talk about the key management requirements of the storage (and > > more importantly retrieval). > >=20 > > Thanks=2C > >=20 > > -derek > >=20 > > "Hutton=2C Andrew" writes: > >=20 > > > Hi Derek=2C > > > > > > Thanks for your comment and sorry for taking a while to get back to > > you. > > > > > > The security considerations section contains the following text: > > > > > > " It is the responsibility of the Session Recording Server to protect > > > the Replicated Media and Recording Metadata once it has been > > received > > > and archived. The mechanism for protecting the storage and > > retrieval > > > from the SRS is out of scope of this work." > > > > > > > > > Personally I think this is reasonable as we never say anything in SIP > > > related specifications what a UA should do with the media once it has > > > been received and this work is all about delivering the media and > > > related metadata to the recording system not what it does with it > > > afterwards. > > > > > > Is it really necessary to go any further than this? > > > > > > Regards > > > Andy (SIPREC Co-Chair). > > > > > > > > > > > > > > >> -----Original Message----- > > >> From: Derek Atkins [mailto:derek@ihtfp.com] > > >> Sent: 01 October 2013 16:34 > > >> To: iesg@ietf.org=3B secdir@ietf.org > > >> Cc: siprec-chairs@tools.ietf.org=3B krehor@cisco.com=3B > > >> rajnish.jain@outlook.com=3B leon.portman@gmail.com=3B Hutton=2C Andr= ew > > >> Subject: sec-dir review of draft-ietf-siprec-architecture-08 > > >> > > >> Hi=2C > > >> > > >> 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. > > >> > > >> Session recording is a critical requirement in many > > communications > > >> environments such as call centers and financial trading. In some > > of > > >> these environments=2C all calls must be recorded for regulatory= =2C > > >> compliance=2C and consumer protection reasons. Recording of a > > session > > >> is typically performed by sending a copy of a media stream to a > > >> recording device. This document describes architectures for > > >> deploying session recording solutions in an environment which is > > >> based on the Session Initiation Protocol (SIP). > > >> > > >> Retrieving recorded media is a potential Key Management problem > > which > > >> this document completely ignores (and even claims is out of scope). > > >> The key used to encrypt the recorded media (whether or not the media > > >> is re-encrypted) must be stored and retrieved as part of the media > > >> retrieval. How this important data is stored and retrieved is left > > >> out=2C leaving an implementation with no guidance on how to protect > > that > > >> valuable asset. In fact the document completely elides the question > > >> of how a retriever obtains the data encryption key. Even if it's > > just > > >> additional guidance the Security Considerations should at least > > >> explain the problem even if it doesn't provide a solution. > > >> > > >> -derek > > >> > > >> -- > > >> Derek Atkins 617-623-3745 > > >> derek@ihtfp.com www.ihtfp.com > > >> Computer and Internet Security Consultant > > > > > > > >=20 > > -- > > Derek Atkins 617-623-3745 > > derek@ihtfp.com www.ihtfp.com > > Computer and Internet Security Consultant = --_4e700fd4-c116-462d-9386-aa3881da5d52_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I think Andy's approach to addre= ssing this is appropriate. =3BThe way =3Brecording systems deal wit= h the security issues of archived media content seems out of scope of SIPRE= C. A statement can be made to clarify this the way Andy is proposing.
 =3B
>=3B From: andrew.hutton@unify.com
>=3B To: derek= @ihtfp.com
>=3B CC: iesg@ietf.org=3B secdir@ietf.org=3B siprec-chairs@= tools.ietf.org=3B krehor@cisco.com=3B rajnish.jain@outlook.com=3B leon.port= man@gmail.com
>=3B Subject: RE: sec-dir review of draft-ietf-siprec-ar= chitecture-08
>=3B Date: Thu=2C 24 Oct 2013 15:36:57 +0000
>=3B <= br>>=3B Hi Derek=2C
>=3B
>=3B I am ok with putting something i= n the security considerations to say the key management requirements for st= orage and retrieval is something that the recording system will need to con= sider but I would still say that saying anything more than that is out of s= cope.
>=3B
>=3B What do others think?
>=3B
>=3B Andy<= br>>=3B
>=3B
>=3B >=3B -----Original Message-----
>=3B= >=3B From: Derek Atkins [mailto:derek@ihtfp.com]
>=3B >=3B Sent: = 24 October 2013 15:53
>=3B >=3B To: Hutton=2C Andrew
>=3B >= =3B Cc: Derek Atkins=3B iesg@ietf.org=3B secdir@ietf.org=3B siprec-
>= =3B >=3B chairs@tools.ietf.org=3B krehor@cisco.com=3B rajnish.jain@outloo= k.com=3B
>=3B >=3B leon.portman@gmail.com
>=3B >=3B Subject: = Re: sec-dir review of draft-ietf-siprec-architecture-08
>=3B >=3B >=3B >=3B Hi Andrew=2C
>=3B >=3B
>=3B >=3B Sorry for t= he delay in responding.
>=3B >=3B
>=3B >=3B I personally fee= l that there is a big difference between the
>=3B >=3B interactive= =2C real-time SIP components versus a service that is
>=3B >=3B spec= ifically designed to record and replay content later. The key
>=3B &g= t=3B management of the real-time components is all immediate=2C there is no=
>=3B >=3B storage required=2C once the keys get to the endpoints yo= u're done and
>=3B >=3B all
>=3B >=3B you do is transmit encr= ypted content.
>=3B >=3B
>=3B >=3B However a storage system = has significantly different requirements. It
>=3B >=3B has to store= the keys that protect the content=2C and it must store those
>=3B >= =3B keys securely. It then has to be able to securely distribute those
= >=3B >=3B keys
>=3B >=3B only to authorized receipients.
>= =3B >=3B
>=3B >=3B So yes=2C I think it is important to talk abou= t at least the requirements
>=3B >=3B for what the recording agent M= UST do=2C even if you don't necessarily
>=3B >=3B specify HOW the ag= ent must do it. E.g. I think it's okay to say
>=3B >=3B something l= ike "the stored content must be protected using a cipher at
>=3B >= =3B least as strong (or stronger) than the original content" -- i.e.=2C you=
>=3B >=3B don't need to specify "you MUST use AES-256". Yet I stil= l think you
>=3B >=3B need to talk about the key management requirem= ents of the storage (and
>=3B >=3B more importantly retrieval).
&= gt=3B >=3B
>=3B >=3B Thanks=2C
>=3B >=3B
>=3B >=3B= -derek
>=3B >=3B
>=3B >=3B "Hutton=2C Andrew" <=3Bandrew.= hutton@unify.com>=3B writes:
>=3B >=3B
>=3B >=3B >=3B Hi= Derek=2C
>=3B >=3B >=3B
>=3B >=3B >=3B Thanks for your c= omment and sorry for taking a while to get back to
>=3B >=3B you.>=3B >=3B >=3B
>=3B >=3B >=3B The security considerations s= ection contains the following text:
>=3B >=3B >=3B
>=3B >= =3B >=3B " It is the responsibility of the Session Recording Server to pr= otect
>=3B >=3B >=3B the Replicated Media and Recording Metadat= a once it has been
>=3B >=3B received
>=3B >=3B >=3B and= archived. The mechanism for protecting the storage and
>=3B >=3B r= etrieval
>=3B >=3B >=3B from the SRS is out of scope of this wo= rk."
>=3B >=3B >=3B
>=3B >=3B >=3B
>=3B >=3B >= =3B Personally I think this is reasonable as we never say anything in SIP>=3B >=3B >=3B related specifications what a UA should do with the = media once it has
>=3B >=3B >=3B been received and this work is al= l about delivering the media and
>=3B >=3B >=3B related metadata t= o the recording system not what it does with it
>=3B >=3B >=3B aft= erwards.
>=3B >=3B >=3B
>=3B >=3B >=3B Is it really neces= sary to go any further than this?
>=3B >=3B >=3B
>=3B >=3B = >=3B Regards
>=3B >=3B >=3B Andy (SIPREC Co-Chair).
>=3B &g= t=3B >=3B
>=3B >=3B >=3B
>=3B >=3B >=3B
>=3B >= =3B >=3B
>=3B >=3B >=3B>=3B -----Original Message-----
>= =3B >=3B >=3B>=3B From: Derek Atkins [mailto:derek@ihtfp.com]
>= =3B >=3B >=3B>=3B Sent: 01 October 2013 16:34
>=3B >=3B >=3B= >=3B To: iesg@ietf.org=3B secdir@ietf.org
>=3B >=3B >=3B>=3B C= c: siprec-chairs@tools.ietf.org=3B krehor@cisco.com=3B
>=3B >=3B >= =3B>=3B rajnish.jain@outlook.com=3B leon.portman@gmail.com=3B Hutton=2C A= ndrew
>=3B >=3B >=3B>=3B Subject: sec-dir review of draft-ietf-s= iprec-architecture-08
>=3B >=3B >=3B>=3B
>=3B >=3B >=3B= >=3B Hi=2C
>=3B >=3B >=3B>=3B
>=3B >=3B >=3B>=3B I = have reviewed this document as part of the security directorate's
>=3B= >=3B >=3B>=3B ongoing effort to review all IETF documents being proc= essed by the
>=3B >=3B >=3B>=3B IESG. These comments were writt= en primarily for the benefit of the
>=3B >=3B >=3B>=3B security = area directors. Document editors and WG chairs should
>=3B >=3B tre= at
>=3B >=3B >=3B>=3B these comments just like any other last ca= ll comments.
>=3B >=3B >=3B>=3B
>=3B >=3B >=3B>=3B = Session recording is a critical requirement in many
>=3B >=3B commu= nications
>=3B >=3B >=3B>=3B environments such as call center= s and financial trading. In some
>=3B >=3B of
>=3B >=3B >= =3B>=3B these environments=2C all calls must be recorded for regulator= y=2C
>=3B >=3B >=3B>=3B compliance=2C and consumer protection= reasons. Recording of a
>=3B >=3B session
>=3B >=3B >=3B&= gt=3B is typically performed by sending a copy of a media stream to a>=3B >=3B >=3B>=3B recording device. This document describes a= rchitectures for
>=3B >=3B >=3B>=3B deploying session recordi= ng solutions in an environment which is
>=3B >=3B >=3B>=3B ba= sed on the Session Initiation Protocol (SIP).
>=3B >=3B >=3B>=3B=
>=3B >=3B >=3B>=3B Retrieving recorded media is a potential Key= Management problem
>=3B >=3B which
>=3B >=3B >=3B>=3B th= is document completely ignores (and even claims is out of scope).
>=3B= >=3B >=3B>=3B The key used to encrypt the recorded media (whether or= not the media
>=3B >=3B >=3B>=3B is re-encrypted) must be store= d and retrieved as part of the media
>=3B >=3B >=3B>=3B retrieva= l. How this important data is stored and retrieved is left
>=3B >= =3B >=3B>=3B out=2C leaving an implementation with no guidance on how t= o protect
>=3B >=3B that
>=3B >=3B >=3B>=3B valuable asse= t. In fact the document completely elides the question
>=3B >=3B &g= t=3B>=3B of how a retriever obtains the data encryption key. Even if it'= s
>=3B >=3B just
>=3B >=3B >=3B>=3B additional guidance t= he Security Considerations should at least
>=3B >=3B >=3B>=3B ex= plain the problem even if it doesn't provide a solution.
>=3B >=3B &= gt=3B>=3B
>=3B >=3B >=3B>=3B -derek
>=3B >=3B >=3B>= =3B
>=3B >=3B >=3B>=3B --
>=3B >=3B >=3B>=3B D= erek Atkins 617-623-3745
>=3B >=3B >=3B>=3B = derek@ihtfp.com www.ihtfp.com
>=3B >=3B >=3B>=3B = Computer and Internet Security Consultant
>=3B >=3B >=3B>=3B >=3B >=3B
>=3B >=3B
>=3B >=3B --
>=3B >= =3B Derek Atkins 617-623-3745
>=3B >=3B = derek@ihtfp.com www.ihtfp.com
>=3B >=3B Compute= r and Internet Security Consultant
= --_4e700fd4-c116-462d-9386-aa3881da5d52_-- From scott@hyperthought.com Mon Oct 28 19:38:15 2013 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 15A4421E80D2 for ; Mon, 28 Oct 2013 19:38:15 -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 5gLTdn99PUVt for ; Mon, 28 Oct 2013 19:38:05 -0700 (PDT) Received: from smtp98.iad3a.emailsrvr.com (smtp98.iad3a.emailsrvr.com [173.203.187.98]) by ietfa.amsl.com (Postfix) with ESMTP id 1C88B21E80AC for ; Mon, 28 Oct 2013 19:36:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 780CDA80FF; Mon, 28 Oct 2013 22:36:24 -0400 (EDT) X-Virus-Scanned: OK Received: from app8.wa-webapps.iad3a (relay.iad3a.rsapps.net [172.27.255.110]) by smtp5.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 5F8F3A80C3; Mon, 28 Oct 2013 22:36:24 -0400 (EDT) Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app8.wa-webapps.iad3a (Postfix) with ESMTP id 4F23D280042; Mon, 28 Oct 2013 22:36:24 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Mon, 28 Oct 2013 19:36:24 -0700 (PDT) Date: Mon, 28 Oct 2013 19:36:24 -0700 (PDT) From: "Scott G. Kelly" To: draft-ietf-appsawg-malformed-mail.all@tools.ietf.org, "secdir@ietf.org" , "iesg@ietf.org" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1383014184.320726214@apps.rackspace.com> X-Mailer: webmail7.0 Subject: [secdir] secdir review of draft-ietf-appsawg-malformed-mail-09 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, 29 Oct 2013 02:38:15 -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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments.=0A=0AFrom the abstract and introduction, this i= nformational document includes a collection of the best advice available re= garding a variety of common malformed mail situations, to be used as implem= entation guidance. Much (most?) of the guidance is aimed at improving secur= ity, and the security considerations section says this.=0A=0AI have not car= efully reviewed every section of the document. If it has not yet been revie= wed by someone from the security area with expertise in this area, it may b= e worth sanity checking. Based on my quick read, I saw no obvious issues.= =0A=0A--Scott=0A From shawn.emery@oracle.com Tue Oct 29 00:17:27 2013 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 A7C4811E815C; Tue, 29 Oct 2013 00:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 X5iDAWmUDlRm; Tue, 29 Oct 2013 00:17:20 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 92D7621E809F; Tue, 29 Oct 2013 00:17:11 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9T7H9q4016938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Oct 2013 07:17:10 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9T7H8gT000125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 07:17:08 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9T7H7bq000071; Tue, 29 Oct 2013 07:17:08 GMT Received: from [10.159.89.115] (/10.159.89.115) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Oct 2013 00:17:07 -0700 Message-ID: <526F612D.1020005@oracle.com> Date: Tue, 29 Oct 2013 01:18:05 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20130718 Thunderbird/17.0.6 MIME-Version: 1.0 To: secdir@ietf.org References: <51CAA254.6040303@oracle.com> In-Reply-To: <51CAA254.6040303@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: draft-ietf-tictoc-security-requirements.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-tictoc-security-requirements-05 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, 29 Oct 2013 07:17:28 -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 internet-draft describes the threat analysis for time protocols, such as Precision Time Protocol (PTP) and the Network Time Protocol (NTP). The draft itself discusses security considerations. I believe the draft adequately covers the various threats and how to mitigate such attacks. I just have a few comments below: In regards to this paragraph in section 5.1.3: Authentication of slaves prevents unauthorized clocks from receiving time services. Preventing the master from serving unauthorized clocks can help in mitigating DoS attacks against the master. Note that the authentication of slaves might put a higher load on the master than serving the unauthorized clock, and hence this requirement is a SHOULD. I think that this requirement of whether to allow for unauthorized clocks should be a MAY (as does the prior text in this section) and should state that the decision to do this should be based on the environment in which the master and slaves are deployed. In regards to this paragraph in section 5.2.1: The requirement level of the first requirement is 'SHOULD' since in the presence of recursive authentication (Section 5.1.2.) this requirement may be redundant. This should state that this is the "second requirement", not the "first requirement". In section 5.5.1 what's the difference between a replay and playback attack? If there is such a difference then playback needs to be defined. In section 5.8, interception attacks is never explicitly described. I don't understand this sentence: The erroneous time may expose cryptographic algorithms that rely on time to prevent replay attacks. Does this mean to say "security protocols" instead of "cryptographic algorithms"? General comments: None. Editorial comments: s/if a slave is/if a slave/ s/(Section 3.2.4. )/(Section 3.2.4.)/ s/Additional measure/Additional measures/ Looks like this sentence was truncated: The requirements in this subsection address MITM attacks such as the 3.2.1.). s/necessarily possible/possible/ s/5.1. ,/Section 5.1.,/ s/in the literature/in literature/ s/in [1588IPsec] and [Tunnel]/[1588IPsec] and [Tunnel]/ Shawn. -- From kent@bbn.com Tue Oct 29 12:36:07 2013 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 8355211E828A for ; Tue, 29 Oct 2013 12:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.513 X-Spam-Level: X-Spam-Status: No, score=-106.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 C3PG4J-xCA-M for ; Tue, 29 Oct 2013 12:36:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8869311E8294 for ; Tue, 29 Oct 2013 12:35:28 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50972) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VbF48-0007ZX-CI; Tue, 29 Oct 2013 15:35:00 -0400 Message-ID: <52700DE4.8020208@bbn.com> Date: Tue, 29 Oct 2013 15:35:00 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: secdir , fielding@gbiv.com, julian.reschke@greenbytes.de, mnot@pobox.com, Barry Leiba , Pete Resnick , "Mankin, Allison" Content-Type: multipart/alternative; boundary="------------070100040502030300040200" Subject: [secdir] SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 29 Oct 2013 19:36:07 -0000 This is a multi-part message in MIME format. --------------070100040502030300040200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I 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, WG chairs and ADs should treat these comments just like any other last call comments. The document obsoletes RFC 2616 and updates 2617. It says that it "defines HTTP/1.1 access control and authentication." I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context. I see that "ought" is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here. Also on page 6 it appears that the phrase "receipt of" was omitted in two places: Upon *<> *a request for a protected resource that omits credentials Likewise, upon *<>* a request that requires authentication by proxies Later on page 6 the text says: The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication.Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information.However, such additional mechanisms are not defined by this specification. Encryption is not, per se, an authentication mechanism. Please revise this text. In Section 2.2 the text says: The protection space determines the domain over which credentials can be automatically applied.If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference. I'm not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user. The end of Section 2.2 includes the word "might" but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context. In Section 4.3, the text says: A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request. If, as stated here, a set of proxies cooperatively authenticate a request, then isn't this a MUST vs. a MAY? In Section 4.4 the text says: Note: The challenge grammar production uses the list syntax as well.Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges.In practice, this ambiguity does not affect the semantics of the header field value Should "both" be "either" in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously? Section 5.1.2 uses "ought" when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase "need to" twice, where MUST seems appropriate. The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized. The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure. I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic. --------------070100040502030300040200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

I 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, WG chairs and ADs should treat these comments just like any other last call comments.

 

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

 

I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.

 

Also on page 6 it appears that the phrase “receipt of” was omitted in two places:

 

      Upon <> a request for a protected resource that omits credentials

 

      Likewise, upon <> a request that requires authentication by proxies

 

Later on page 6 the text says:

 

   The HTTP protocol does not restrict applications to this simple

   challenge-response framework for access authentication.  Additional

   mechanisms MAY be used, such as encryption at the transport level or

   via message encapsulation, and with additional header fields

   specifying authentication information.  However, such additional

   mechanisms are not defined by this specification.

 

Encryption is not, per se, an authentication mechanism. Please revise this text.

 

In Section 2.2 the text says:

 

   The protection space determines the domain over which credentials can

   be automatically applied.  If a prior request has been authorized,

   the user agent MAY reuse the same credentials for all other requests

   within that protection space for a period of time determined by the

   authentication scheme, parameters, and/or user preference. 

 

 

I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.

 

The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.

 

In Section 4.3, the text says:

 

    A proxy MAY relay

   the credentials from the client request to the next proxy if that is

   the mechanism by which the proxies cooperatively authenticate a given

   request.

 

If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?

 

In Section 4.4 the text says:

 

      Note: The challenge grammar production uses the list syntax as

      well.  Therefore, a sequence of comma, whitespace, and comma can

      be considered both as applying to the preceding challenge, or to

      be an empty entry in the list of challenges.  In practice, this

      ambiguity does not affect the semantics of the header field value

 

Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?

 

Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term. The same section also uses the phrase “need to” twice, where MUST seems appropriate.

 

The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.

 

The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.

 

I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.

--------------070100040502030300040200-- From julian.reschke@gmx.de Wed Oct 30 06:10:19 2013 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 9015F11E818D for ; Wed, 30 Oct 2013 06:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.933 X-Spam-Level: X-Spam-Status: No, score=-103.933 tagged_above=-999 required=5 tests=[AWL=-1.334, 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 g8-YV7TdXeGu for ; Wed, 30 Oct 2013 06:10:04 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 82AFF21E80B6 for ; Wed, 30 Oct 2013 06:09:55 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MVNWU-1VAgc23AEA-00Ykif for ; Wed, 30 Oct 2013 14:09:54 +0100 Message-ID: <5271051E.4040908@gmx.de> Date: Wed, 30 Oct 2013 14:09:50 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Stephen Kent , secdir , fielding@gbiv.com, mnot@pobox.com, Barry Leiba , Pete Resnick , "Mankin, Allison" , HTTP Working Group References: <52700DE4.8020208@bbn.com> In-Reply-To: <52700DE4.8020208@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:Mnbgqz+z/i2Rq8IW9yCpvebn765Hrc5EBqymnYydJaSVd1YylA2 csev4HxroTP39ihhB/Acz1dvpUFnT9EYmfb+rzmUKlUsW3xYcAT5AXXkRTCAg9Sv5QBd+pP tKbgbSEUCqmwUrhu3DekUDZ2BImFHp9XwjuHGUCnuDG6rMBrI5IxqWbgccQbtj+wLRZyyY/ TgUQNkbVYmjqEtbyiyCow== Subject: [secdir] RFC2119 vs "ought" etc, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 30 Oct 2013 13:10:19 -0000 Stephen, thanks for the feedback. On 2013-10-29 20:35, Stephen Kent wrote: > ... > I see that “ought” is used in two places on page 6, but not in uppercase > as per RFC 6919. The authors should revisit the use of this term here. > ... > The end of Section 2.2 includes the word “might” but not uppercase, as > per RFC 6919. I again suggest that the authors reconsider using this > term in this context. > ... > Section 5.1.2 uses “ought” when discussing definitions for new > authentication schemes. See comments above re use of this term.The same > section also uses the phrase “need to” twice, where MUST seems appropriate. > ... We use "ought", "might" etc to disambiguate from RFC2119 keywords. As such it's intentional that they are not uppercased, and that we do not reference RFC 6919 (which, by the way, is dated April 1st). Best regards, Julian From julian.reschke@gmx.de Wed Oct 30 06:41:07 2013 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 8E35021F9E99 for ; Wed, 30 Oct 2013 06:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.958 X-Spam-Level: X-Spam-Status: No, score=-103.958 tagged_above=-999 required=5 tests=[AWL=-1.359, 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 Y1lg1sfFPj1o for ; Wed, 30 Oct 2013 06:41:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 34C6421F9928 for ; Wed, 30 Oct 2013 06:40:52 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LpsmR-1W7qHr2zJP-00ffoL for ; Wed, 30 Oct 2013 14:40:47 +0100 Message-ID: <52710C5A.9040705@gmx.de> Date: Wed, 30 Oct 2013 14:40:42 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Stephen Kent , secdir , fielding@gbiv.com, mnot@pobox.com, Barry Leiba , Pete Resnick , "Mankin, Allison" , HTTP Working Group References: <52700DE4.8020208@bbn.com> In-Reply-To: <52700DE4.8020208@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:WBN8v9K3gQS+fmtN0TAj06+D1HRI1gDPAW/AdgbtQaErN8pV2c2 MhA4pzZlzsOkVbYBKpxlXu3/hMNaasuzE/cyDdhsOA5jYz1xulQ8FO1C1V9fUnmh0nvzO0L fWkUFhmBwUiBZxbXeOMB9GBtQFx7W8HVOxpwBg+eNHeLRXS+CKVq55xnSGLRishDTBvVKa/ vfuYFWFs2hkSEldGamZuA== Subject: Re: [secdir] SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 30 Oct 2013 13:41:07 -0000 Stephen, On 2013-10-29 20:35, Stephen Kent wrote: > ... > The Security Considerations section (6) is about one page in length. It > references the SC sections in two in I-Ds: > draft-ietf-httpbis-p1-messaging-24 and > draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial > SC sections, but one cannot say that this document has an acceptable SC > section until those documents are finalized. They are both normative > references, so this doc will nor progress independently, but there will > still be a need to revisit this SC when those SCs are finalized. These two other documents are in IETF LC as well. > The SC section here addresses only two issues: purging credentials in > clients and user agents, and protection spaces. The discussion of the > former topic does not discuss how credential purging applies to proxies. As per httpbis-p1, a proxy is a client as well ('An HTTP "client" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests.' -- ). Does this address your comment? > Also, it is not clear that a user control for credential purging will > have the desired effect given a potentially complex GUI environment. The Any proposal for enhancing the text? > discussion of protection spaces provides useful suggestions on how to > minimize credential exposure. > > I was a bit surprised that there was no advice deprecating the use of > passwords as credentials, if only to make a statement on this topic. This document just defines the HTTP authentication framework. It's not intended to give general guidelines about the security of new authentication schemes. But then, if you have some concrete proposal for additional text, we're all ears. Best regards, Julian From rlb@ipv.sx Wed Oct 30 06:42:37 2013 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 EF53E11E8221 for ; Wed, 30 Oct 2013 06:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-0.755, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 0eDzr5lWJ3j7 for ; Wed, 30 Oct 2013 06:42:30 -0700 (PDT) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id 41DAF11E8220 for ; Wed, 30 Oct 2013 06:42:15 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id wp4so1404628obc.40 for ; Wed, 30 Oct 2013 06:42:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1T+qs5w6M+If+4LPWST8QqZtP5LbU1LU7OF6mj0GOC4=; b=OPf5anBvtuQbb1GNE1Q1e21/BeaeByab+CiBRzoU2tIBJt6hwiwG9sTke4lslfOBOe z46h0L3VeTn2iPzlZRaUErDVq4wGcR/hLxDVmtJo3IIbPDL8r4FSlniROes+uaRDZVU7 ikU1wEMiPQF5/1tE1bK3DtCgwGGyfi1pr6/Xw2nGtl5GnO20o4mGSXf+aoV3T80cFGod MVuZrLbzLk/kBKhzHa29ZOCjgY/0qFMAz4RH1mKHap4ryEfLfwHYy83Iz3rZjEAzatr5 JTKvQ4BwOF+GHPajYqoC77pmk2hhUscYMrJKYg8wmprsxCMTTsX5K20xUym00r8VeZwW 7Lwg== X-Gm-Message-State: ALoCoQkPndN/2G63Ka3Tyb0WiA1UJIwg7C/yXOJ5LBjkrMDpf4YfvgX1T8Aj6a6YyasJ/oZmwuH5 MIME-Version: 1.0 X-Received: by 10.60.99.37 with SMTP id en5mr335743oeb.78.1383140534554; Wed, 30 Oct 2013 06:42:14 -0700 (PDT) Received: by 10.76.101.10 with HTTP; Wed, 30 Oct 2013 06:42:14 -0700 (PDT) In-Reply-To: <5271051E.4040908@gmx.de> References: <52700DE4.8020208@bbn.com> <5271051E.4040908@gmx.de> Date: Wed, 30 Oct 2013 09:42:14 -0400 Message-ID: From: Richard Barnes To: Julian Reschke Content-Type: multipart/alternative; boundary=047d7b33d7e43ca2a804e9f58083 Cc: secdir , Pete Resnick , "fielding@gbiv.com" , "Mankin, Allison" , HTTP Working Group , Barry Leiba , "mnot@pobox.com" Subject: Re: [secdir] RFC2119 vs "ought" etc, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 30 Oct 2013 13:42:37 -0000 --047d7b33d7e43ca2a804e9f58083 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wednesday, October 30, 2013, Julian Reschke wrote: > Stephen, > > thanks for the feedback. > > On 2013-10-29 20:35, Stephen Kent wrote: > >> ... >> I see that =93ought=94 is used in two places on page 6, but not in upper= case >> as per RFC 6919. The authors should revisit the use of this term here. >> ... >> The end of Section 2.2 includes the word =93might=94 but not uppercase, = as >> per RFC 6919. I again suggest that the authors reconsider using this >> term in this context. >> ... >> Section 5.1.2 uses =93ought=94 when discussing definitions for new >> authentication schemes. See comments above re use of this term.The same >> section also uses the phrase =93need to=94 twice, where MUST seems >> appropriate. >> ... >> > > We use "ought", "might" etc to disambiguate from RFC2119 keywords. As suc= h > it's intentional that they are not uppercased, and that we do not referen= ce > RFC 6919 (which, by the way, is dated April 1st). > > Do you mean that your intent was ought=3D=3Dshould and might=3D=3Dmay? Why do you feel the need to avoid SHOULD and MAY here? They don't place any more burden on implementors than "ought" and "might". --Richard > Best regards, Julian > ______________________________**_________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/**listinfo/secdir > wiki: http://tools.ietf.org/area/**sec/trac/wiki/SecDirReview > --047d7b33d7e43ca2a804e9f58083 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Wednesday, October 30, 2013, Julian Reschke wrote:
Stephen,

thanks for the feedback.

On 2013-10-29 20:35, Stephen Kent wrote:
...
I see that =93ought=94 is used in two places on page 6, but not in uppercas= e
as per RFC 6919. The authors should revisit the use of this term here.
...
The end of Section 2.2 includes the word =93might=94 but not uppercase, as<= br> per RFC 6919. I again suggest that the authors reconsider using this
term in this context.
...
Section 5.1.2 uses =93ought=94 when discussing definitions for new
authentication schemes. See comments above re use of this term.The same
section also uses the phrase =93need to=94 twice, where MUST seems appropri= ate.
...

We use "ought", "might" etc to disambiguate from RFC211= 9 keywords. As such it's intentional that they are not uppercased, and = that we do not reference RFC 6919 (which, by the way, is dated April 1st).<= br>

Do you mean that your intent was ought= =3D=3Dshould and might=3D=3Dmay?

Why do you feel t= he need to avoid SHOULD and MAY here? =A0They don't=A0place any more bu= rden on implementors=A0than "ought" and "might".=A0
=A0
--Richard



Best regards, Julian
_______________________________________________
secdir mailing list
secdir@ietf.org
= https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview=
--047d7b33d7e43ca2a804e9f58083-- From julian.reschke@gmx.de Wed Oct 30 06:58:01 2013 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 4070221E80DE for ; Wed, 30 Oct 2013 06:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.978 X-Spam-Level: X-Spam-Status: No, score=-103.978 tagged_above=-999 required=5 tests=[AWL=-1.379, 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 ne7zoKM0nuVM for ; Wed, 30 Oct 2013 06:57:55 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id A3A8121E8098 for ; Wed, 30 Oct 2013 06:57:51 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Li1hG-1VyE3C33Ja-00nDWh for ; Wed, 30 Oct 2013 14:57:50 +0100 Message-ID: <5271105A.10105@gmx.de> Date: Wed, 30 Oct 2013 14:57:46 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Richard Barnes References: <52700DE4.8020208@bbn.com> <5271051E.4040908@gmx.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:g9SX398O8M4dr1Pn9PFsCdFF1OS3qmPpgXCR/HxB5wjh9Pphb8Y UBsz7GtGcv2GjpAYnVat79lKbbH3riUXzA15nbqMr2+xixAwh8QgEnX/fwsVTUJSeDCkK+J By+A/w9OvPOXzk4ydwwvl27h5iT9cU8R6APPQYGiB6YOyOEmqNDL9d5d7YeJIkujlWfBkyh 9qhwSOPnii3j77g0klHOw== Cc: secdir , Pete Resnick , "fielding@gbiv.com" , "Mankin, Allison" , HTTP Working Group , Barry Leiba , "mnot@pobox.com" Subject: Re: [secdir] RFC2119 vs "ought" etc, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 30 Oct 2013 13:58:01 -0000 On 2013-10-30 14:42, Richard Barnes wrote: > ... > Do you mean that your intent was ought==should and might==may? > > Why do you feel the need to avoid SHOULD and MAY here? They don't place > any more burden on implementors than "ought" and "might". > --Richard > ... I believe in following the guidance in RFC 2119: > 6. Guidance in the use of these Imperatives > > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability. I also note that there clearly is no community consensus about what the right degree of 2119 usage is. Until there is such thing, I recommend that we focus on 2119 keywords being used when they are needed, and not bike-shed over the other instances as long as the specification is consistent with respect to this. Best regards, Julian From kent@bbn.com Wed Oct 30 07:04:31 2013 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 5FD5F21E8100 for ; Wed, 30 Oct 2013 07:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.515 X-Spam-Level: X-Spam-Status: No, score=-106.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 NXbsQtRrpeAQ for ; Wed, 30 Oct 2013 07:04:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id AC75521E80FA for ; Wed, 30 Oct 2013 07:04:23 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:51810) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VbWNL-0004VS-0v; Wed, 30 Oct 2013 10:03:59 -0400 Message-ID: <527111CF.2050707@bbn.com> Date: Wed, 30 Oct 2013 10:03:59 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Julian Reschke , secdir , fielding@gbiv.com, mnot@pobox.com, Barry Leiba , Pete Resnick , "Mankin, Allison" , HTTP Working Group References: <52700DE4.8020208@bbn.com> <5271051E.4040908@gmx.de> In-Reply-To: <5271051E.4040908@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [secdir] RFC2119 vs "ought" etc, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 30 Oct 2013 14:04:31 -0000 Julian, As a coauthor of 6919 I am aware of its status, and the suggestions to uppercase these words was a joke. Nonetheless, I feel that the terms in question are not good choices for an RFC, i.e., what is an implementer supposed to do based on these terms? Steve > On 2013-10-29 20:35, Stephen Kent wrote: >> ... >> I see that “ought” is used in two places on page 6, but not in uppercase >> as per RFC 6919. The authors should revisit the use of this term here. >> ... >> The end of Section 2.2 includes the word “might” but not uppercase, as >> per RFC 6919. I again suggest that the authors reconsider using this >> term in this context. >> ... >> Section 5.1.2 uses “ought” when discussing definitions for new >> authentication schemes. See comments above re use of this term.The same >> section also uses the phrase “need to” twice, where MUST seems >> appropriate. >> ... > > We use "ought", "might" etc to disambiguate from RFC2119 keywords. As > such it's intentional that they are not uppercased, and that we do not > reference RFC 6919 (which, by the way, is dated April 1st). > > > Best regards, Julian > From julian.reschke@gmx.de Wed Oct 30 07:22:40 2013 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 7623411E8222 for ; Wed, 30 Oct 2013 07:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.042 X-Spam-Level: X-Spam-Status: No, score=-104.042 tagged_above=-999 required=5 tests=[AWL=-1.443, 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 TFY9gpv1AJuR for ; Wed, 30 Oct 2013 07:22:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2C611E8221 for ; Wed, 30 Oct 2013 07:22:34 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M5tzh-1VqqiP1nL7-00xsaO for ; Wed, 30 Oct 2013 15:22:19 +0100 Message-ID: <52711616.1060008@gmx.de> Date: Wed, 30 Oct 2013 15:22:14 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Stephen Kent , secdir , fielding@gbiv.com, mnot@pobox.com, Barry Leiba , Pete Resnick , "Mankin, Allison" , HTTP Working Group References: <52700DE4.8020208@bbn.com> In-Reply-To: <52700DE4.8020208@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:iGA6vx7vdP3JAoGEFWc3T0o/2hOntq448/B9kWW6fDTlo3fwfGr uSIyTBFlB/Y1gMRUfxZmaXnf3EASo/Am23Meur18lqELN+X81/OGxdpGXETshoc/Rl3xn+k SSRgwhqSOUuC7HOwBRCAtF+vHK4jJTbn6j8GZdF3d6/dRLKcZNgdJPSEE1JMjoBKqg21MZP DQTUhftSzp2xdjvAhxhlA== Subject: [secdir] WWW-Authenticate parsing quirks, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 30 Oct 2013 14:22:40 -0000 On 2013-10-29 20:35, Stephen Kent wrote: > ... > In Section 4.4 the text says: > > Note: The challenge grammar production uses the list syntax as > > well.Therefore, a sequence of comma, whitespace, and comma can > > be considered both as applying to the preceding challenge, or to > > be an empty entry in the list of challenges.In practice, this > > ambiguity does not affect the semantics of the header field value > > Should “both” be “either” in the above text? Does the potentially > ... Yes (done) > ambiguous construct ever take on both meanings simultaneously? > ... Yes, but these two meanings do not affect the semantics of the header field as a whole (it's either an empty entry in the list of auth parameters, or an empty challenge value). Best regards, Julian From kent@bbn.com Wed Oct 30 07:32:59 2013 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 7EA2121F9ECE for ; Wed, 30 Oct 2013 07:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.516 X-Spam-Level: X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 cQHK7Ag6vfg5 for ; Wed, 30 Oct 2013 07:32:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C61A011E830A for ; Wed, 30 Oct 2013 07:32:38 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:51818) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VbWoo-0004j6-3W; Wed, 30 Oct 2013 10:32:22 -0400 Message-ID: <52711876.1000808@bbn.com> Date: Wed, 30 Oct 2013 10:32:22 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Julian Reschke , secdir , fielding@gbiv.com, mnot@pobox.com, Barry Leiba , Pete Resnick , "Mankin, Allison" , HTTP Working Group References: <52700DE4.8020208@bbn.com> <52710C5A.9040705@gmx.de> In-Reply-To: <52710C5A.9040705@gmx.de> Content-Type: multipart/alternative; boundary="------------080906030704090803020802" Subject: Re: [secdir] SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 30 Oct 2013 14:32:59 -0000 This is a multi-part message in MIME format. --------------080906030704090803020802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/30/13 9:40 AM, Julian Reschke wrote: > Stephen, > > On 2013-10-29 20:35, Stephen Kent wrote: >> ... >> The Security Considerations section (6) is about one page in length. It >> references the SC sections in two in I-Ds: >> draft-ietf-httpbis-p1-messaging-24 and >> draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial >> SC sections, but one cannot say that this document has an acceptable SC >> section until those documents are finalized. They are both normative >> references, so this doc will nor progress independently, but there will >> still be a need to revisit this SC when those SCs are finalized. > > These two other documents are in IETF LC as well. OK. Then I suggest that whoever reviews them (hopefully not me) do so with the SC section for this I-D in mind. > >> The SC section here addresses only two issues: purging credentials in >> clients and user agents, and protection spaces. The discussion of the >> former topic does not discuss how credential purging applies to proxies. > > As per httpbis-p1, a proxy is a client as well ('An HTTP "client" is a > program that establishes a connection to a server for the purpose of > sending one or more HTTP requests.' -- > ). > Does this address your comment? yes, but it might be clearer to note this, parenthetically, in this doc. For example, page 5 includes the following text: The 407 (Proxy Authentication Required) response message is used by a proxy to challenge the authorization of a client and MUST include a Proxy-Authenticate header field containing at least one challenge applicable to the proxy for the requested resource. The use of the terms "proxy" and "client" here suggest that they are distinct notions, not that a proxy is also considered a client. > >> Also, it is not clear that a user control for credential purging will >> have the desired effect given a potentially complex GUI environment. The > > Any proposal for enhancing the text? User agents that cache credentials are encouraged to provide a readily accessible mechanism for discarding cached credentials under user control. *We recognize that this may not be a trivial task.** ** Designing a UI that will encourage users to purge credentials when** ** appropriate, but not cause them to prematurely do so may be difficult.* > >> discussion of protection spaces provides useful suggestions on how to >> minimize credential exposure. >> >> I was a bit surprised that there was no advice deprecating the use of >> passwords as credentials, if only to make a statement on this topic. > > This document just defines the HTTP authentication framework. It's not > intended to give general guidelines about the security of new > authentication schemes. But then, if you have some concrete proposal > for additional text, we're all ears. This doc does provide guidance for new auth schemes, in 5.1.2. However, I agree that the guidance there focuses on syntactic issues and compatibility, rather than security. So, if you don't want to address this issue, OK. Steve --------------080906030704090803020802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/30/13 9:40 AM, Julian Reschke wrote:
Stephen,

On 2013-10-29 20:35, Stephen Kent wrote:
...
The Security Considerations section (6) is about one page in length. It
references the SC sections in two in I-Ds:
draft-ietf-httpbis-p1-messaging-24 and
draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial
SC sections, but one cannot say that this document has an acceptable SC
section until those documents are finalized. They are both normative
references, so this doc will nor progress independently, but there will
still be a need to revisit this SC when those SCs are finalized.

These two other documents are in IETF LC as well.
OK. Then I suggest that whoever reviews them (hopefully not me) do so with
the SC section for this I-D in mind.

The SC section here addresses only two issues: purging credentials in
clients and user agents, and protection spaces. The discussion of the
former topic does not discuss how credential purging applies to proxies.

As per httpbis-p1, a proxy is a client as well ('An HTTP "client" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests.' -- <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-24.html#rfc.section.2.1>). Does this address your comment?
yes, but it might be clearer to note this, parenthetically, in this doc.
For example, page 5 includes the following text:

   The 407 (Proxy Authentication Required) response message is used by a

   proxy to challenge the authorization of a client and MUST include a

   Proxy-Authenticate header field containing at least one challenge

   applicable to the proxy for the requested resource.


The use of the terms "proxy" and "client" here suggest that they are distinct notions,
not that a proxy is also considered a client.

Also, it is not clear that a user control for credential purging will
have the desired effect given a potentially complex GUI environment. The

Any proposal for enhancing the text?

   User agents that cache credentials are encouraged to provide a

   readily accessible mechanism for discarding cached credentials under

   user control. We recognize that this may not be a trivial task.
   Designing a UI that will encourage users to purge credentials when
   appropriate, but not cause them to prematurely do so may be difficult.


discussion of protection spaces provides useful suggestions on how to
minimize credential exposure.

I was a bit surprised that there was no advice deprecating the use of
passwords as credentials, if only to make a statement on this topic.

This document just defines the HTTP authentication framework. It's not intended to give general guidelines about the security of new authentication schemes. But then, if you have some concrete proposal for additional text, we're all ears.

This doc does provide guidance for new auth schemes, in 5.1.2. However, I agree that the guidance
there focuses on syntactic issues and compatibility, rather than security. So, if you don't want
to address this issue, OK.

Steve
--------------080906030704090803020802-- From julian.reschke@gmx.de Wed Oct 30 07:45:31 2013 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 97E0121E80F1 for ; Wed, 30 Oct 2013 07:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.059 X-Spam-Level: X-Spam-Status: No, score=-104.059 tagged_above=-999 required=5 tests=[AWL=-1.460, 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 opfIvY99DwOj for ; Wed, 30 Oct 2013 07:45:25 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 036C311E8232 for ; Wed, 30 Oct 2013 07:45:24 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M2cDB-1VuAId47qn-00sPXT for ; Wed, 30 Oct 2013 15:45:21 +0100 Message-ID: <52711B7C.80906@gmx.de> Date: Wed, 30 Oct 2013 15:45:16 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Stephen Kent , secdir , fielding@gbiv.com, mnot@pobox.com, Barry Leiba , Pete Resnick , "Mankin, Allison" , HTTP Working Group References: <52700DE4.8020208@bbn.com> <52710C5A.9040705@gmx.de> <52711876.1000808@bbn.com> In-Reply-To: <52711876.1000808@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:S62ct4HP0r56PVf/ZtkrV+9YQXoyvAK/6fjP+nBcmpUUvKeCbEs bhhSsAiR9jwn/TYiOiX3h3qsmkDygOyMEW/USd28mpY3y93GmEBUgdhcQu5NQFWlyI34Bc0 oCRtt9/fIwiXHmEOQhbsKvpGjuYIKRGKy7FhhqOgQ8Jn2oYAZucWwTrXTSuyHmWJafjIQBF t/k9kIsrqkmHs7qmR9tMg== Subject: Re: [secdir] SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 30 Oct 2013 14:45:31 -0000 Hi Stephen, On 2013-10-30 15:32, Stephen Kent wrote: > ... >>> The SC section here addresses only two issues: purging credentials in >>> clients and user agents, and protection spaces. The discussion of the >>> former topic does not discuss how credential purging applies to proxies. >> >> As per httpbis-p1, a proxy is a client as well ('An HTTP "client" is a >> program that establishes a connection to a server for the purpose of >> sending one or more HTTP requests.' -- >> ). >> Does this address your comment? > yes, but it might be clearer to note this, parenthetically, in this doc. > For example, page 5 includes the following text: > > The 407 (Proxy Authentication Required) response message is used by a > > proxy to challenge the authorization of a client and MUST include a > > Proxy-Authenticate header field containing at least one challenge > > applicable to the proxy for the requested resource. > > > The use of the terms "proxy" and "client" here suggest that they are > distinct notions, > not that a proxy is also considered a client. In the context of this paragraph, the proxy is indeed the server. >>> Also, it is not clear that a user control for credential purging will >>> have the desired effect given a potentially complex GUI environment. The >> >> Any proposal for enhancing the text? > > User agents that cache credentials are encouraged to provide a > > readily accessible mechanism for discarding cached credentials under > > user control. *We recognize that this may not be a trivial task.** > ** Designing a UI that will encourage users to purge credentials when** > ** appropriate, but not cause them to prematurely do so may be difficult.* In my experience, the implementers of browsers are very aware of the problems with coming up with a good UI. I really don't think that adding more prose here will help at all. (But hey, I asked for a proposal and you sent one; thanks for that!). > ... Best regards, Julian From rlb@ipv.sx Wed Oct 30 07:47:18 2013 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 9CFE711E8180 for ; Wed, 30 Oct 2013 07:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.892 X-Spam-Level: X-Spam-Status: No, score=-2.892 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 RA92aqSyTBcT for ; Wed, 30 Oct 2013 07:47:12 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB68011E8221 for ; Wed, 30 Oct 2013 07:47:11 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id l20so1547279oag.3 for ; Wed, 30 Oct 2013 07:47:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iXRPR1n8zTI9DKYJTcLV5r4MjjAUaP46keIs99tZGMs=; b=Agf1pl/pzP4lpPSkWb+qdGqdhGK0fzGShZo3oCu4MktBIicNG1FxOr3GFPI1J65qC5 97m6OeUIrGDQyIoxWF/i4QUnyBOpS8FU1boiy2VDJ3AAEer5rHKSSpvNDR3iXTp85kXU 48wzIxWdcqj1bYCq0lIRH+YWlMGh1LXnRNAXAUdVvaVMbrrY0ryAVlqR9tG7Tqo2VFb9 outDNM2wEq+af1ej5y/+iZpiaWwtU6jbJH5S3nV9JkcPfYE73B6YB6Wf2Bhg5jF3yy0y EwGYPifJz5c/zmkGW44ZcId0RvBNkPTGA507yb9iPkZFy3YQRgrNv9grljaWlbr69esR Tx2Q== X-Gm-Message-State: ALoCoQlE/eICM7P7AfOYLeJyZ9YQoYuR25xYgEUkCEPj153Bkz5Q4BHJOs5gFLwnDPkp8rnfax85 MIME-Version: 1.0 X-Received: by 10.182.229.163 with SMTP id sr3mr556097obc.79.1383144431290; Wed, 30 Oct 2013 07:47:11 -0700 (PDT) Received: by 10.76.101.10 with HTTP; Wed, 30 Oct 2013 07:47:11 -0700 (PDT) In-Reply-To: <5271105A.10105@gmx.de> References: <52700DE4.8020208@bbn.com> <5271051E.4040908@gmx.de> <5271105A.10105@gmx.de> Date: Wed, 30 Oct 2013 10:47:11 -0400 Message-ID: From: Richard Barnes To: Julian Reschke Content-Type: multipart/alternative; boundary=001a1136221e8021cd04e9f668a2 Cc: secdir , Pete Resnick , "fielding@gbiv.com" , "Mankin, Allison" , HTTP Working Group , Barry Leiba , "mnot@pobox.com" Subject: Re: [secdir] RFC2119 vs "ought" etc, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 30 Oct 2013 14:47:18 -0000 --001a1136221e8021cd04e9f668a2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 30, 2013 at 9:57 AM, Julian Reschke wrote: > On 2013-10-30 14:42, Richard Barnes wrote: > >> ... >> >> Do you mean that your intent was ought==should and might==may? >> >> Why do you feel the need to avoid SHOULD and MAY here? They don't place >> any more burden on implementors than "ought" and "might". >> --Richard >> ... >> > > I believe in following the guidance in RFC 2119: > > 6. Guidance in the use of these Imperatives >> >> Imperatives of the type defined in this memo must be used with care >> and sparingly. In particular, they MUST only be used where it is >> actually required for interoperation or to limit behavior which has >> potential for causing harm (e.g., limiting retransmisssions) For >> example, they must not be used to try to impose a particular method >> on implementors where the method is not required for >> interoperability. >> > > I also note that there clearly is no community consensus about what the > right degree of 2119 usage is. Until there is such thing, I recommend that > we focus on 2119 keywords being used when they are needed, and not > bike-shed over the other instances as long as the specification is > consistent with respect to this. > The key word there, though, is "imperatives". Nothing we're talking about here is an imperative, just a recommendation (or RECOMMENDATION). Skimming through the instances of "ought to" in the document, it seems like they all meet the definition of "SHOULD" in 2119, i.e., things that implementations should only diverge from if they have a good reason. (In fact, there are some that seem like they should be "MUST", but that's a different topic.) --Richard > Best regards, Julian > > > --001a1136221e8021cd04e9f668a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Oct 30, 2013 at 9:57 AM, Julian Reschke &= lt;julian.reschk= e@gmx.de> wrote:
On 2013-10-30 14:42, Richard Barnes wrote:
...

Do you mean that your intent was ought=3D=3Dshould and might=3D=3Dmay?

Why do you feel the need to avoid SHOULD and MAY here? =A0They don't pl= ace
any more burden on implementors than "ought" and "might"= ;.
--Richard
...

I believe in following the guidance in RFC 2119:

6. Guidance in the use of these Imperatives

=A0 =A0Imperatives of the type defined in this memo must be used with care<= br> =A0 =A0and sparingly. =A0In particular, they MUST only be used where it is<= br> =A0 =A0actually required for interoperation or to limit behavior which has<= br> =A0 =A0potential for causing harm (e.g., limiting retransmisssions) =A0For<= br> =A0 =A0example, they must not be used to try to impose a particular method<= br> =A0 =A0on implementors where the method is not required for
=A0 =A0interoperability.

I also note that there clearly is no community consensus about what the rig= ht degree of 2119 usage is. Until there is such thing, I recommend that we = focus on 2119 keywords being used when they are needed, and not bike-shed o= ver the other instances as long as the specification is consistent with res= pect to this.

The key word there, though, is "imper= atives".=A0 Nothing we're talking about here is an imperative, jus= t a recommendation (or RECOMMENDATION).=A0 Skimming through the instances o= f "ought to" in the document, it seems like they all meet the def= inition of "SHOULD" in 2119, i.e., things that implementations sh= ould only diverge from if they have a good reason.=A0 (In fact, there are s= ome that seem like they should be "MUST", but that's a differ= ent topic.)

--Richard

=A0
Best regards, Julian



--001a1136221e8021cd04e9f668a2-- From barryleiba@gmail.com Wed Oct 30 08:04:23 2013 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 1E2C811E8267 for ; Wed, 30 Oct 2013 08:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.953 X-Spam-Level: X-Spam-Status: No, score=-101.953 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-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 XmtKJnVUxULl for ; Wed, 30 Oct 2013 08:04:22 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3784D21F9D15 for ; Wed, 30 Oct 2013 08:04:06 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id ii20so3776569qab.18 for ; Wed, 30 Oct 2013 08:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2Mp7ePHlaMQUXjGhW/l8RtqTgoU4lMWEPjeV8mkoCKQ=; b=bp38qjw7ALo7lXcR5OLC5hop43t/yzEAfmEzvf1orQMilb03EaZxMKG6/2Q9A+2k9F nHeZRMEuJat/tFMY0GpZ6/RVw/ADbBgVwOJA017ayV1zCAMVtOA+HP+CR8iyJfyPEvWl 9zV1/ZCacPQXi0DQp/m23/1ekHCTJ9ocXZbj7JWIl26RKwc1uSV2Bd8U1FTt377ee3eV u+yoH8DlmjkgaikOu2ob/XM2q99eIc1Xh5ZbAdmU7V2nK5X+HCNHPE8gciQ1M6jfxZL4 KEl2Ch3hnnIdx23iVtc3IOVHH7tX+BSMtZq66S5baSsmmiS3qsQnKc25Wgi5NDaX6Y+O 5gYg== MIME-Version: 1.0 X-Received: by 10.49.94.72 with SMTP id da8mr7086364qeb.67.1383145445691; Wed, 30 Oct 2013 08:04:05 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.67.130 with HTTP; Wed, 30 Oct 2013 08:04:05 -0700 (PDT) In-Reply-To: References: <52700DE4.8020208@bbn.com> <5271051E.4040908@gmx.de> <5271105A.10105@gmx.de> Date: Wed, 30 Oct 2013 11:04:05 -0400 X-Google-Sender-Auth: EGS89iv12Cn1o2oUfThjkPZwHAc Message-ID: From: Barry Leiba To: Richard Barnes Content-Type: text/plain; charset=ISO-8859-1 Cc: Pete Resnick , secdir , Julian Reschke , "fielding@gbiv.com" , "Mankin, Allison" , HTTP Working Group , "mnot@pobox.com" Subject: Re: [secdir] RFC2119 vs "ought" etc, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 30 Oct 2013 15:04:23 -0000 >>> Why do you feel the need to avoid SHOULD and MAY here? They don't place >>> any more burden on implementors than "ought" and "might". >>> --Richard >> >> I believe in following the guidance in RFC 2119: > > The key word there, though, is "imperatives". Nothing we're talking about > here is an imperative, just a recommendation (or RECOMMENDATION). Skimming > through the instances of "ought to" in the document, it seems like they all > meet the definition of "SHOULD" in 2119, i.e., things that implementations > should only diverge from if they have a good reason. (In fact, there are > some that seem like they should be "MUST", but that's a different topic.) First: I think it's a good idea, in a document that defines protocol, to separate the requirements for the protocol from the recommendations for implementation aspects that speak to quality of implementation and user experience, but that don't affect protocol operation (and interoperation). Second, because the use of "should", "must", "may", and "recommended" in lower case is controversial (for reasons that I don't agree with, but never-you-mind that), I think using alternatives (as, for example, proposed here, which was not intended for 1 April publication: http://tools.ietf.org/html/draft-hansen-nonkeywords-non2119 ) is a fine thing. Third, these situations in the httpbis documents *are* things that don't affect the protocol. How should a browser treat [whatever]? Well, a browser that makes bad choices could be considered a crummy browser, so giving advice is good and useful. But the server won't know nor care, so this isn't a protocol issue. I don't think, therefore, that in a protocol document we should use 2119 language for that. Save the 2119 language for the protocol. Fourth, this is starting to get into nitty wordsmithing (the part about whether "ought" is a good word... not the part about whether it's normative or not), which I don't think is really appropriate at this stage of document development. That is, it's fine to bring it up editorial things for the editors to consider, but pushing on them at the expense of time spent on substantive issues doesn't seem wise at this stage. Barry From julian.reschke@gmx.de Wed Oct 30 09:25:25 2013 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 5E71821E80B6 for ; Wed, 30 Oct 2013 09:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.187 X-Spam-Level: X-Spam-Status: No, score=-104.187 tagged_above=-999 required=5 tests=[AWL=-1.588, 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 iarsBOZorsYn for ; Wed, 30 Oct 2013 09:25:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1C86511E8253 for ; Wed, 30 Oct 2013 09:25:13 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Mcgur-1VJkiC2KSv-00HtBJ for ; Wed, 30 Oct 2013 17:25:11 +0100 Message-ID: <527132E3.3000001@gmx.de> Date: Wed, 30 Oct 2013 17:25:07 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Stephen Kent , secdir , fielding@gbiv.com, mnot@pobox.com, Barry Leiba , Pete Resnick , "Mankin, Allison" , HTTP Working Group References: <52700DE4.8020208@bbn.com> In-Reply-To: <52700DE4.8020208@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:rc87J+KtFtQUTrR5dfVTVHT+zUDE/CzU947cKJ2q4DciGmw1jvO bpvU7dV+h7rgCadpGh0FlW5AEVX3mcRvbwM16DsuNPSK86iDWmh2qm09lW5+6/1eFRcB3YG fyJV0Sn59bLCNGmk7ycUCkVY8f1CRXZ95Y0SzfeYaRxom/e4zj06aVZcLnChLgnqZLrqAih hYGS2zrRqzJ8RpEd38OMw== Subject: [secdir] Reuse of credentials per realm, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 30 Oct 2013 16:25:25 -0000 On 2013-10-29 20:35, Stephen Kent wrote: > ... > In Section 2.2 the text says: > > The protection space determines the domain over which credentials can > > be automatically applied.If a prior request has been authorized, > > the user agent MAY reuse the same credentials for all other requests > > within that protection space for a period of time determined by the > > authentication scheme, parameters, and/or user preference. > > I’m not clear how user preferences fit into this process. It would seem > that the server would decide whether a prior authorization is valid for > later requests, not a user. > ... Of course it's up to the server to accept or reject it. The text you cite is about the user agent deciding whether it can try to use the credentials. Does this require a clarification? Best regards, Julian From kent@bbn.com Wed Oct 30 09:52:26 2013 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 DAC6B21F9CAD for ; Wed, 30 Oct 2013 09:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.521 X-Spam-Level: X-Spam-Status: No, score=-106.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 HFxXMTsgSKqy for ; Wed, 30 Oct 2013 09:52:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id EF06611E819D for ; Wed, 30 Oct 2013 09:52:06 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:52573) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VbYzj-00065h-0g; Wed, 30 Oct 2013 12:51:47 -0400 Message-ID: <52713922.2020803@bbn.com> Date: Wed, 30 Oct 2013 12:51:46 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Julian Reschke , secdir , fielding@gbiv.com, mnot@pobox.com, Barry Leiba , Pete Resnick , "Mankin, Allison" , HTTP Working Group References: <52700DE4.8020208@bbn.com> <527132E3.3000001@gmx.de> In-Reply-To: <527132E3.3000001@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [secdir] Reuse of credentials per realm, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 30 Oct 2013 16:52:44 -0000 Julian, Since, as you note, the server ultimately accepts or rejects the credentials, it was not clear under what circumstances "user preferences" are a valid factor in deciding when to stop using the same set of credentials. If you could elaborate that would be useful. Steve > On 2013-10-29 20:35, Stephen Kent wrote: >> ... >> In Section 2.2 the text says: >> >> The protection space determines the domain over which credentials can >> >> be automatically applied.If a prior request has been authorized, >> >> the user agent MAY reuse the same credentials for all other requests >> >> within that protection space for a period of time determined by the >> >> authentication scheme, parameters, and/or user preference. >> >> I’m not clear how user preferences fit into this process. It would seem >> that the server would decide whether a prior authorization is valid for >> later requests, not a user. >> ... > > Of course it's up to the server to accept or reject it. The text you > cite is about the user agent deciding whether it can try to use the > credentials. > > Does this require a clarification? > > Best regards, Julian > From andrew.hutton@unify.com Wed Oct 30 10:39:36 2013 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 8C91311E8248; Wed, 30 Oct 2013 10:39:35 -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 STKsA07z28ro; Wed, 30 Oct 2013 10:39:25 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC4311E823A; Wed, 30 Oct 2013 10:39:24 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id E485B23F048B; Wed, 30 Oct 2013 18:39:16 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Wed, 30 Oct 2013 18:39:16 +0100 From: "Hutton, Andrew" To: Derek Atkins Thread-Topic: sec-dir review of draft-ietf-siprec-architecture-08 Thread-Index: AQHO0MjSFpuNNNCQs06E2FZPbdmFCZoNjFGQ Date: Wed, 30 Oct 2013 17:39:16 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C26825@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF17BF527F@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec-chairs@tools.ietf.org" , "secdir@ietf.org" , "krehor@cisco.com" , "iesg@ietf.org" , "leon.portman@gmail.com" , "rajnish.jain@outlook.com" Subject: Re: [secdir] sec-dir review of draft-ietf-siprec-architecture-08 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, 30 Oct 2013 17:39:43 -0000 Hi Derek, Would the following change in the security considerations section resolve y= our issue: "It is the responsibility of the SRS to protect the Replicated Media and Re= cording Metadata once it has been received and archived. The mechanism for = protecting the storage and retrieval from the SRS is out of scope of this w= ork" To=20 "It is the responsibility of the SRS to protect the Replicated Media and Re= cording Metadata once it has been received and archived. The stored content= must be protected using a cipher at least as strong (or stronger) than the= original content however the mechanism for protecting the storage and retr= ieval from the SRS is out of scope of this work" Regards Andy > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: 24 October 2013 15:53 > To: Hutton, Andrew > Cc: Derek Atkins; iesg@ietf.org; secdir@ietf.org; siprec- > chairs@tools.ietf.org; krehor@cisco.com; rajnish.jain@outlook.com; > leon.portman@gmail.com > Subject: Re: sec-dir review of draft-ietf-siprec-architecture-08 >=20 > Hi Andrew, >=20 > Sorry for the delay in responding. >=20 > I personally feel that there is a big difference between the > interactive, real-time SIP components versus a service that is > specifically designed to record and replay content later. The key > management of the real-time components is all immediate, there is no > storage required, once the keys get to the endpoints you're done and > all > you do is transmit encrypted content. >=20 > However a storage system has significantly different requirements. It > has to store the keys that protect the content, and it must store those > keys securely. It then has to be able to securely distribute those > keys > only to authorized receipients. >=20 > So yes, I think it is important to talk about at least the requirements > for what the recording agent MUST do, even if you don't necessarily > specify HOW the agent must do it. E.g. I think it's okay to say > something like "the stored content must be protected using a cipher at > least as strong (or stronger) than the original content" -- i.e., you > don't need to specify "you MUST use AES-256". Yet I still think you > need to talk about the key management requirements of the storage (and > more importantly retrieval). >=20 > Thanks, >=20 > -derek >=20 > "Hutton, Andrew" writes: >=20 > > Hi Derek, > > > > Thanks for your comment and sorry for taking a while to get back to > you. > > > > The security considerations section contains the following text: > > > > " It is the responsibility of the Session Recording Server to protect > > the Replicated Media and Recording Metadata once it has been > received > > and archived. The mechanism for protecting the storage and > retrieval > > from the SRS is out of scope of this work." > > > > > > Personally I think this is reasonable as we never say anything in SIP > > related specifications what a UA should do with the media once it has > > been received and this work is all about delivering the media and > > related metadata to the recording system not what it does with it > > afterwards. > > > > Is it really necessary to go any further than this? > > > > Regards > > Andy (SIPREC Co-Chair). > > > > > > > > > >> -----Original Message----- > >> From: Derek Atkins [mailto:derek@ihtfp.com] > >> Sent: 01 October 2013 16:34 > >> To: iesg@ietf.org; secdir@ietf.org > >> Cc: siprec-chairs@tools.ietf.org; krehor@cisco.com; > >> rajnish.jain@outlook.com; leon.portman@gmail.com; Hutton, Andrew > >> Subject: sec-dir review of draft-ietf-siprec-architecture-08 > >> > >> 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. > >> > >> Session recording is a critical requirement in many > communications > >> environments such as call centers and financial trading. In some > of > >> these environments, all calls must be recorded for regulatory, > >> compliance, and consumer protection reasons. Recording of a > session > >> is typically performed by sending a copy of a media stream to a > >> recording device. This document describes architectures for > >> deploying session recording solutions in an environment which is > >> based on the Session Initiation Protocol (SIP). > >> > >> Retrieving recorded media is a potential Key Management problem > which > >> this document completely ignores (and even claims is out of scope). > >> The key used to encrypt the recorded media (whether or not the media > >> is re-encrypted) must be stored and retrieved as part of the media > >> retrieval. How this important data is stored and retrieved is left > >> out, leaving an implementation with no guidance on how to protect > that > >> valuable asset. In fact the document completely elides the question > >> of how a retriever obtains the data encryption key. Even if it's > just > >> additional guidance the Security Considerations should at least > >> explain the problem even if it doesn't provide a solution. > >> > >> -derek > >> > >> -- > >> Derek Atkins 617-623-3745 > >> derek@ihtfp.com www.ihtfp.com > >> Computer and Internet Security Consultant > > > > >=20 > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From benl@google.com Wed Oct 30 10:41:20 2013 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 A9B7911E8248 for ; Wed, 30 Oct 2013 10:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-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 w+p0qSD1n-KG for ; Wed, 30 Oct 2013 10:41:20 -0700 (PDT) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id DFC7621F9FB7 for ; Wed, 30 Oct 2013 10:41:19 -0700 (PDT) Received: by mail-vb0-f52.google.com with SMTP id f13so1234624vbg.25 for ; Wed, 30 Oct 2013 10:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+RuQIFZS35zDGwGUfHvVzKq/wbiAb6cB/rRfzRufoFQ=; b=Th94RB5BewV/hfkXM8Xa6tiLy+pSWVKV/Xi5eoNo3EguY3GuFiMJw2GX8i7wdi5RvM AITRAVn4YKYCSKGyGg8vVPD4i1d6FHbRvaotNHhP8wzsHEuWL5R5I7p6gfb5OVhfELD9 rpRrto7/JMXarP7Uozh/ULzMCs4WZq40voQ9G/b58z4+Zd/H/vmrt7MxRpTrzv/okOmU /HqROwO21COZdVKYB+9GFl7d00tbjQZcTqg5EoYq5Y3HxpbdRur5zrLRX/5aJ/bzejCQ tUbS7fZU/8+clTd+64k8Y55tURgfj3CC3H7PjsTtpHLTjFRa19nOiJgeanNBmPrbwh77 xx1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=+RuQIFZS35zDGwGUfHvVzKq/wbiAb6cB/rRfzRufoFQ=; b=epMFGEirfDCEnVSrhdET+1bwDNEe78sRkebTF9Q6snv5ZBlBnsOWx9Hy7gIMegI+ms JjNF/OTZs1qO7sC9egLHr5UrDlUjOhQtvx4HiIRTjWIAKtsCWaQYShW7NYh+niSM1WHX lxDK/FGRuWk4oc9nhKF0jlXkp5tUTJ1JoHiuB8liA3u1iXBB/RAOpkZRDns7EBG7QlDt mvVDPimXuIDsZfcKokkeuQ6ePMrWP9sR5s6vWx2QXuDPZ+e7tsmtBDiXKDAIZQ4+Umic 5prjqerij8SS67/AWwpBtbP8qsZHD+QsmMr4N+z9zNi03tYuVbl54+ckHAaGz/tAIyGO yFSA== X-Gm-Message-State: ALoCoQkBgLFnE7N4WtqtR4rZdfLCBmmC5qox/fGDY1qmzHbqZ90PI9zW535Nn9nptKdwASxqCN6kaB+Jfjp3zJpiy/jcu/V0hy8ki2krawfsgpN+9caYgzrzCuKWT4YEpx+00iRb82v08VmyFLx1H8TMwUhvMaiM7odJom+keHzYHiV4+h+KMSw9s+paKbpKK64Mg2rAjoO7 MIME-Version: 1.0 X-Received: by 10.58.75.164 with SMTP id d4mr48097vew.53.1383154879315; Wed, 30 Oct 2013 10:41:19 -0700 (PDT) Received: by 10.52.183.65 with HTTP; Wed, 30 Oct 2013 10:41:19 -0700 (PDT) Date: Wed, 30 Oct 2013 17:41:19 +0000 Message-ID: From: Ben Laurie To: The IESG , "secdir@ietf.org" , draft-ietf-httpbis-p1-messaging.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] secdir review of draft-ietf-httpbis-p1-messaging-24 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, 30 Oct 2013 17:41:20 -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. Summary: Hopeless. This I-D is a security disaster waiting to happen. It should be thrown away and a radically simpler approach taken. The I-D: part one of an apparently infinite series of documents describing a version of HTTP that is, amazingly, even more complex and impossible to implement than HTTP/1.0. I'm afraid that after the opening sections I decided that further review was a waste of time, but if pushed I might be persuaded. Comments so far: General: way too big. HTTP/1.0 was already far too big, and notoriously impossible to correctly implement. Given how important a piece of infrastructure HTTP is, I'm shocked that a new version seems to not only have failed to simplify the spec, but has grown into a monster that I doubt anyone will ever bother to read, let alone conform to. In my view, the security implications of such a complex spec are severe. We should not be increasing the mess, we should be reducing it. 2.4 Caches As well as poisoning attacks, websites can leave themselves exposed by failing to set appropriate caching values - for example, allowing caches to cache pages containing pesonal information, which is later served to the wrong person. The I-D should discuss this issue and give concrete advice on how to avoid inappropriate caching, whilst still permitting appropriate caching. Likewise, caches can be fooled into serving cached data inappropriaely - for example, in response to a subtly different request. Part 6, which is devoted to caches, appears to give no advice whatsoever. 2.5. Conformance and Error Handling Obviously very important for security. Is littered with vague generalities like "A sender MUST NOT generate protocol elements that convey a meaning that is known by that sender to be false." "Within a given message, a sender MUST NOT generate protocol elements or syntax alternatives that are only allowed to be generated by participants in other roles (i.e., a role that the sender does not have for that message)." "When a received protocol element is parsed, the recipient MUST be able to parse any value of reasonable length that is applicable to the recipient's role and matches the grammar defined by the corresponding ABNF rules." without giving any concrete advice (other than, presumably, "read and memorise the whole xxx pages of RFCs A, B, C ... Z"). Are there matrices of what is allowed, for example? Where? How long is "reasonable"? What do you do if the length is, in fact, "unreasonable"? I could go on, but I'm afraid the tears will damage my keyboard. No mention at all in Security Considerations. BTW: "A recipient MUST interpret a received protocol element according to the semantics defined for it by this specification, including extensions to this specification, unless the recipient has determined (through experience or configuration) that the sender incorrectly implements what is implied by those semantics." Oh. My. God. 2.6. Protocol Versioning "A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions." Seriously? From julian.reschke@gmx.de Wed Oct 30 11:01:59 2013 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 0B0D711E82D6 for ; Wed, 30 Oct 2013 11:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.354 X-Spam-Level: X-Spam-Status: No, score=-103.354 tagged_above=-999 required=5 tests=[AWL=-0.755, 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 DlI0u91ymBop for ; Wed, 30 Oct 2013 11:01:36 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id D142621E8137 for ; Wed, 30 Oct 2013 10:59:32 -0700 (PDT) Received: from [192.168.2.117] ([93.217.127.91]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LfC4q-1VzxUh0Jcu-00olk2 for ; Wed, 30 Oct 2013 18:59:24 +0100 Message-ID: <527148F8.4050909@gmx.de> Date: Wed, 30 Oct 2013 18:59:20 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Stephen Kent , secdir , fielding@gbiv.com, mnot@pobox.com, Barry Leiba , Pete Resnick , "Mankin, Allison" , HTTP Working Group References: <52700DE4.8020208@bbn.com> <527132E3.3000001@gmx.de> <52713922.2020803@bbn.com> In-Reply-To: <52713922.2020803@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:F9X8i+mxj7rapWXCD2bCzY7PferPnmR9TaIa/nhEXZ6mLyscdd0 55WyCB2EwVMCoSopqXl5p/Pz5bvw9WYUCmG26jqb7B2vo4D+3q/xz4B7XL2Smt2Z2AUgV9O GaEbaw5f+x+FzU+HV02WIHpBWD/d2ML1g9pFLOy60aYXv6pNUCav3gbs7MQJEPiQLhot9FQ JDxLzjgHQB7lGv7LTkMig== Subject: Re: [secdir] Reuse of credentials per realm, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 30 Oct 2013 18:01:59 -0000 On 2013-10-30 17:51, Stephen Kent wrote: > Julian, > > Since, as you note, the server ultimately accepts or rejects the > credentials, > it was not clear under what circumstances "user preferences" are a valid > factor > in deciding when to stop using the same set of credentials. If you could > elaborate > that would be useful. Well, that text was written 14 years ago, so I really don't know exactly what the authors had in mind. That being said, here's an example: a user pref defining how long credentials can be sent after a certain time of inactivity. Best regards, Julian From talmi@marvell.com Thu Oct 31 00:58:46 2013 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 4BB8721E80C5; Thu, 31 Oct 2013 00:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=-1.275, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 ydSKZo7qDO8g; Thu, 31 Oct 2013 00:58:40 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6BE11E8133; Thu, 31 Oct 2013 00:58:39 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id r9V7wd2m010998; Thu, 31 Oct 2013 00:58:39 -0700 Received: from sc-owa02.marvell.com ([199.233.58.137]) by mx0b-0016f401.pphosted.com with ESMTP id 1ftb2msafm-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 31 Oct 2013 00:58:39 -0700 Received: from YK-HUB01.marvell.com (10.4.102.51) by sc-owa02.marvell.com (10.93.76.22) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 31 Oct 2013 00:58:38 -0700 Received: from IL-MB01.marvell.com ([10.4.102.53]) by YK-HUB01.marvell.com ([10.4.102.51]) with mapi; Thu, 31 Oct 2013 09:58:34 +0200 From: Tal Mizrahi To: Shawn M Emery , "secdir@ietf.org" Date: Thu, 31 Oct 2013 09:58:31 +0200 Thread-Topic: Review of draft-ietf-tictoc-security-requirements-05 Thread-Index: Ac7UdvBdPGEkt19FQgC7Tmib5nXYMABl808Q Message-ID: <74470498B659FA4687F0B0018C19A89C01B87D833253@IL-MB01.marvell.com> References: <51CAA254.6040303@oracle.com> <526F612D.1020005@oracle.com> In-Reply-To: <526F612D.1020005@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-31_03:2013-10-31, 2013-10-31, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1310310010 Cc: "Yaakov Stein \(yaakov_s@rad.com\)" , "draft-ietf-tictoc-security-requirements.all@tools.ietf.org" , "odonoghue@isoc.org" , "iesg@ietf.org" Subject: Re: [secdir] Review of draft-ietf-tictoc-security-requirements-05 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, 31 Oct 2013 07:58:46 -0000 Hi Shawn. Thanks for your comments.=20 We will accommodate them in the next draft. Thanks, Tal. -----Original Message----- From: Shawn M Emery [mailto:shawn.emery@oracle.com]=20 Sent: Tuesday, October 29, 2013 9:18 AM To: secdir@ietf.org Cc: draft-ietf-tictoc-security-requirements.all@tools.ietf.org; iesg@ietf.o= rg Subject: Review of draft-ietf-tictoc-security-requirements-05 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 internet-draft describes the threat analysis for time protocols, such = as Precision Time Protocol (PTP) and the Network Time Protocol (NTP). The draft itself discusses security considerations. I believe the draft ad= equately covers the various threats and how to mitigate such attacks. I ju= st have a few comments below: In regards to this paragraph in section 5.1.3: Authentication of slaves prevents unauthorized clocks from receiving time services. Preventing the master from serving unauthorized clocks can help in mitigating DoS attacks against the master. Note that the authentication of slaves might put a higher load on the master than serving the unauthorized clock, and hence this requirement is a SHOULD. I think that this requirement of whether to allow for unauthorized clocks s= hould be a MAY (as does the prior text in this section) and should state th= at the decision to do this should be based on the environment in which the = master and slaves are deployed. In regards to this paragraph in section 5.2.1: The requirement level of the first requirement is 'SHOULD' since in the presence of recursive authentication (Section 5.1.2.) this requirement may be redundant. This should state that this is the "second requirement", not the "first req= uirement". In section 5.5.1 what's the difference between a replay and playback attack= ? If there is such a difference then playback needs to be defined. In section 5.8, interception attacks is never explicitly described. I don't understand this sentence: The erroneous time may expose cryptographic algorithms that rely on time to prevent replay attacks. Does this mean to say "security protocols" instead of "cryptographic algori= thms"? General comments: None. Editorial comments: s/if a slave is/if a slave/ s/(Section 3.2.4. )/(Section 3.2.4.)/ s/Additional measure/Additional measures/ Looks like this sentence was truncated: The requirements in this subsection address MITM attacks such as the 3.2.1.). s/necessarily possible/possible/ s/5.1. ,/Section 5.1.,/ s/in the literature/in literature/ s/in [1588IPsec] and [Tunnel]/[1588IPsec] and [Tunnel]/ Shawn. -- From benl@google.com Thu Oct 31 05:04:05 2013 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 B7B5C11E8151 for ; Thu, 31 Oct 2013 05:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-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 VrH2CxkuwFxg for ; Thu, 31 Oct 2013 05:04:05 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2FE11E8320 for ; Thu, 31 Oct 2013 05:04:03 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id oz11so1971408veb.36 for ; Thu, 31 Oct 2013 05:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=v15lhUiS6QM40Mp8qPk0bOrduShQJSngUEqfFeoWrrs=; b=X1cooEY2dSuGyaMXZBdI0O19gEs5LRO6esSZ/L2dKic487Z8WYA8GovpuOy4YzSc+I 6bqoBXUSxXMeBvcduaXc9lGJsoE/mJ/ByA9iAQ3e0s33B30hg34lwNlzz0A+eurBM2sW bNTTiccZKWE7QzyXTxxMrik1Dse5WVphx6bk5O08Eo/whh4542Bpl6LME2ka9pjNVXZZ VbMmEL3veSnplb8iBSpP3jEyD5dHqRJzW6j1U5BvdAzdvbKwowXJPfn+oi3YanNClN/k nifO+dvPRzg38opss5NeTl101vAnulDvXev9odcQOVUwxYLr2LybehZA5QAkrinBTMkj /6Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=v15lhUiS6QM40Mp8qPk0bOrduShQJSngUEqfFeoWrrs=; b=k+byXj/YGrKWJ66GRRxcDuwdFmk2F+7OcpJkgXR/gq/n/5zrsIRQnBeLiRoWWXIu5b BNchAjnc+7ZtZAj7xzIkT3kCOtnOO/8jP5fZIWw0PYe6kjWPtq62SbU7RuINTDLI9W0R teWOZ72GBjNjlM8L1saaZftDyE+q5+6BeGy9JY3zHXJKSoePK/mJTo73EQvDhF4VjkvN AnzDCZLDb5WXv9oUqZAVDBxaCvjaZrr47K81oPSqvtDOF2lsP/ZDf6Akjd1/Tcx4rFLN jZs/3vattmyZ4idHXzux0PZ7qmFfAdey5oDTM4fDNH+turjOxLfOaMgaPwYcbcCGW002 tn4w== X-Gm-Message-State: ALoCoQlbBnRuGM5NY0XC1XUlJXzyn0l+EQ/cEDI5qkBos/TrcYqUe17uXlBJR8EZmhOQNamigHv+9mDJG6zcJL0l2mExAbFO1jpPJ4hPd7yjC90FQndGnp2H0wKa1INBwW9mn6XypILcR+csrNWADOijDB1fdlDnFztwAYM2EmBK3iEdcq6z/bXipRofY18098yza7tG2FmZ MIME-Version: 1.0 X-Received: by 10.220.186.202 with SMTP id ct10mr1749576vcb.14.1383221043335; Thu, 31 Oct 2013 05:04:03 -0700 (PDT) Received: by 10.52.183.65 with HTTP; Thu, 31 Oct 2013 05:04:00 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Oct 2013 12:04:00 +0000 Message-ID: From: Ben Laurie To: The IESG , "secdir@ietf.org" , draft-ietf-httpbis-p1-messaging.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [secdir] secdir review of draft-ietf-httpbis-p1-messaging-24 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, 31 Oct 2013 12:04:05 -0000 Apologies, I managed to confuse myself into thinking this was a revamp of HTTP, rather than an update to the existing spec. I would hope a revamp would address the serious structural issues and hence my harsh criticism. Now that I've realised this is, in fact, a revision of the existing spec to reflect experience, I retract this review. I do feel, however, that the text is lacking in solid actionable advice, and so I will re-review in light of my corrected understanding. Thanks for not flaming me! On 30 October 2013 17:41, Ben Laurie 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. > > Summary: Hopeless. This I-D is a security disaster waiting to happen. > It should be thrown away and a radically simpler approach taken. > > The I-D: part one of an apparently infinite series of documents > describing a version of HTTP that is, amazingly, even more complex and > impossible to implement than HTTP/1.0. > > I'm afraid that after the opening sections I decided that further > review was a waste of time, but if pushed I might be persuaded. > > Comments so far: > > General: way too big. HTTP/1.0 was already far too big, and > notoriously impossible to correctly implement. > > Given how important a piece of infrastructure HTTP is, I'm shocked > that a new version seems to not only have failed to simplify the spec, > but has grown into a monster that I doubt anyone will ever bother to > read, let alone conform to. > > In my view, the security implications of such a complex spec are > severe. We should not be increasing the mess, we should be reducing > it. > > 2.4 Caches > > As well as poisoning attacks, websites can leave themselves exposed by > failing to set appropriate caching values - for example, allowing > caches to cache pages containing pesonal information, which is later > served to the wrong person. The I-D should discuss this issue and give > concrete advice on how to avoid inappropriate caching, whilst still > permitting appropriate caching. > > Likewise, caches can be fooled into serving cached data inappropriaely > - for example, in response to a subtly different request. > > Part 6, which is devoted to caches, appears to give no advice whatsoever. > > 2.5. Conformance and Error Handling > > Obviously very important for security. Is littered with vague > generalities like > > "A sender MUST NOT generate protocol elements that convey a meaning > that is known by that sender to be false." > > "Within a given message, a sender MUST NOT generate protocol elements > or syntax alternatives that are only allowed to be generated by > participants in other roles (i.e., a role that the sender does not > have for that message)." > > "When a received protocol element is parsed, the recipient MUST be > able to parse any value of reasonable length that is applicable to > the recipient's role and matches the grammar defined by the > corresponding ABNF rules." > > without giving any concrete advice (other than, presumably, "read and > memorise the whole xxx pages of RFCs A, B, C ... Z"). Are there > matrices of what is allowed, for example? Where? How long is > "reasonable"? What do you do if the length is, in fact, > "unreasonable"? > > I could go on, but I'm afraid the tears will damage my keyboard. > > No mention at all in Security Considerations. > > BTW: > > "A recipient MUST interpret a received protocol element according to > the semantics defined for it by this specification, including > extensions to this specification, unless the recipient has > determined > (through experience or configuration) that the sender incorrectly > implements what is implied by those semantics." > > Oh. My. God. > > 2.6. Protocol Versioning > > "A client MAY send a lower request version if it is known that the > server incorrectly implements the HTTP specification, but only > after > the client has attempted at least one normal request and determined > from the response status code or header fields (e.g., Server) that > the server improperly handles higher request versions." > > Seriously? From kivinen@iki.fi Thu Oct 31 05:14:35 2013 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 CD36111E8320 for ; Thu, 31 Oct 2013 05:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 uEZXAmx7wDYd for ; Thu, 31 Oct 2013 05:14:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2D211E8282 for ; Thu, 31 Oct 2013 05:14:32 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9VCER79008096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 31 Oct 2013 14:14:27 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9VCEQhG024695; Thu, 31 Oct 2013 14:14:26 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21106.18850.838893.155206@fireball.kivinen.iki.fi> Date: Thu, 31 Oct 2013 14:14:26 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 2 min X-Total-Time: 3 min 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, 31 Oct 2013 12:14:35 -0000 There is quite a lot of rereviews for the 2013-11-21 telechat, mostly because I was too busy to verify if your review comments were taken into account in the new versions of the drafts. So now you need to do it yourself :-) Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Dave Cridland is next in the rotation. For telechat 2013-11-21 Reviewer LC end Draft Chris Lonvick TR2013-10-25 draft-ietf-mmusic-rfc2326bis-38 Yoav Nir T 2013-11-01 draft-ietf-nfsv4-labreqs-04 Radia Perlman TR2013-08-18 draft-ietf-karp-ops-model-09 Vincent Roca T 2013-09-24 draft-ietf-mmusic-duplication-grouping-03 Joe Salowey TR2013-09-23 draft-ietf-sidr-bgpsec-threats-07 Tina TSOU TR2013-09-27 draft-ietf-ecrit-unauthenticated-access-08 Tom Yu T 2013-10-01 draft-ietf-sidr-origin-ops-22 Last calls and special requests: Derek Atkins 2013-11-27 draft-ietf-xrblock-rtcp-xr-qoe-12 Rob Austein 2013-11-27 draft-turner-application-cms-media-type-07 Dave Cridland 2013-11-04 draft-ietf-httpbis-p5-range-24 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Phillip Hallam-Baker 2013-10-16 draft-ietf-ccamp-gmpls-ospf-g709v3-10 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-05 Leif Johansson 2013-11-04 draft-sin-sdnrg-sdn-approach-04 Simon Josefsson 2013-11-04 draft-trammell-ipfix-tcpcontrolbits-revision-04 Tero Kivinen R2013-11-04 draft-ietf-httpbis-p6-cache-24 Tero Kivinen 2013-10-24 draft-ietf-roll-trickle-mcast-05 Julien Laganier - draft-ietf-avtcore-rtp-security-options-08 Julien Laganier - draft-ietf-websec-key-pinning-08 Julien Laganier 2013-11-06 draft-ietf-forces-ceha-08 Matt Lepinski 2013-11-04 draft-ietf-httpbis-p2-semantics-24 Chris Lonvick 2013-11-01 draft-ietf-multimob-handover-optimization-05 Catherine Meadows 2013-11-04 draft-ietf-httpbis-authscheme-registrations-08 Alexey Melnikov - draft-ietf-payload-rtp-howto-09 Alexey Melnikov 2013-11-04 draft-ietf-httpbis-method-registrations-13 Kathleen Moriarty 2013-11-06 draft-ietf-mpls-ldp-multi-topology-09 Sandy Murphy 2013-10-31 draft-ietf-netext-pd-pmip-11 Magnus Nystrom 2013-11-06 draft-ietf-pim-explicit-tracking-08 Hilarie Orman 2013-11-18 draft-shore-icmp-aup-06 Radia Perlman 2013-11-27 draft-housley-ct-keypackage-receipt-n-error-05 Vincent Roca 2013-04-26 draft-ietf-6man-stable-privacy-addresses-14 Joe Salowey 2013-11-27 draft-ietf-clue-telepresence-requirements-06 Yaron Sheffer 2013-11-27 draft-ietf-idr-extcomm-iana-01 Ondrej Sury 2013-11-18 draft-ietf-l2vpn-etree-reqt-05 Tina TSOU 2013-11-27 draft-ietf-l2vpn-evpn-req-05 Carl Wallace 2013-11-27 draft-ietf-mmusic-sdp-g723-g729-04 David Waltermire 2013-09-30 draft-ietf-opsec-ip-options-filtering-05 Brian Weis 2013-11-26 draft-ietf-ospf-rfc6506bis-01 Klaas Wierenga R2013-11-04 draft-ietf-httpbis-p4-conditional-24 Klaas Wierenga 2013-11-27 draft-ietf-pwe3-dynamic-ms-pw-19 Tom Yu 2013-11-27 draft-ietf-sidr-rpki-rtr-impl-04 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 Glen Zorn 2013-11-27 draft-turner-ct-keypackage-receipt-n-error-algs-03 -- kivinen@iki.fi From julian.reschke@greenbytes.de Thu Oct 31 06:44:07 2013 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 C24EA11E832E for ; Thu, 31 Oct 2013 06:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.168 X-Spam-Level: X-Spam-Status: No, score=-4.168 tagged_above=-999 required=5 tests=[AWL=-0.919, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 qCexFOP0NFWy for ; Thu, 31 Oct 2013 06:43:50 -0700 (PDT) Received: from central.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4203611E822C for ; Thu, 31 Oct 2013 06:43:47 -0700 (PDT) Received: from [192.168.1.102] (unknown [217.91.35.233]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by central.greenbytes.de (Postfix) with ESMTPSA id 3AB3610C108E; Thu, 31 Oct 2013 14:43:45 +0100 (CET) Message-ID: <52725E8E.50106@greenbytes.de> Date: Thu, 31 Oct 2013 14:43:42 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Stephen Kent , secdir , fielding@gbiv.com, mnot@pobox.com, Barry Leiba , Pete Resnick , "Mankin, Allison" , HTTP Working Group References: <52700DE4.8020208@bbn.com> In-Reply-To: <52700DE4.8020208@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [secdir] proxies and forwarding of credentials, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 31 Oct 2013 13:44:07 -0000 On 2013-10-29 20:35, Stephen Kent wrote: > ... > In Section 4.3, the text says: > > A proxy MAY relay > > the credentials from the client request to the next proxy if that is > > the mechanism by which the proxies cooperatively authenticate a given > > request. > > If, as stated here, a set of proxies cooperatively authenticate a > request, then isn’t this a MUST vs. a MAY? > ... Maybe. I have no experience with proxy authentication, and this piece of text was copied from . Perhaps this is a case where we should drop the RFC2119 keywords and just make a statement such as: "A proxy can relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request." ? Best regards, Julian From julian.reschke@greenbytes.de Thu Oct 31 06:54:56 2013 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 586DF11E8196 for ; Thu, 31 Oct 2013 06:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.474 X-Spam-Level: X-Spam-Status: No, score=-4.474 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 TIuPhIF++pb9 for ; Thu, 31 Oct 2013 06:54:49 -0700 (PDT) Received: from central.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by ietfa.amsl.com (Postfix) with ESMTP id 16B9911E8177 for ; Thu, 31 Oct 2013 06:54:49 -0700 (PDT) Received: from [192.168.1.102] (unknown [217.91.35.233]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by central.greenbytes.de (Postfix) with ESMTPSA id 7185110C108E; Thu, 31 Oct 2013 14:54:47 +0100 (CET) Message-ID: <52726125.1000802@greenbytes.de> Date: Thu, 31 Oct 2013 14:54:45 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Stephen Kent , secdir , fielding@gbiv.com, mnot@pobox.com, Barry Leiba , Pete Resnick , "Mankin, Allison" , HTTP Working Group References: <52700DE4.8020208@bbn.com> In-Reply-To: <52700DE4.8020208@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] additional mechanisms on top of the auth framework, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 31 Oct 2013 13:54:56 -0000 On 2013-10-29 20:35, Stephen Kent wrote: > ... > Later on page 6 the text says: > > The HTTP protocol does not restrict applications to this simple > > challenge-response framework for access authentication.Additional > > mechanisms MAY be used, such as encryption at the transport level or > > via message encapsulation, and with additional header fields > > specifying authentication information.However, such additional > > mechanisms are not defined by this specification. > > Encryption is not, per se, an authentication mechanism. Please revise > this text. > ... OK. Maybe: "HTTP does not restrict applications to this simple challenge-response framework. Additional mechanisms can be used, such as additional header fields carrying authentication information, or encryption on the transport layer in order to provide confidentiality. However, such additional mechanisms are not defined by this specification." ? Best regards, Julian From kent@bbn.com Thu Oct 31 07:15:31 2013 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 9508F21F9F3A for ; Thu, 31 Oct 2013 07:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.526 X-Spam-Level: X-Spam-Status: No, score=-106.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 sk3nag1lRx9y for ; Thu, 31 Oct 2013 07:15:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E6C9411E8147 for ; Thu, 31 Oct 2013 07:15:20 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49287) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Vbt1S-000ChJ-AH; Thu, 31 Oct 2013 10:14:54 -0400 Message-ID: <527265DE.2030700@bbn.com> Date: Thu, 31 Oct 2013 10:14:54 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Julian Reschke , secdir , fielding@gbiv.com, mnot@pobox.com, Barry Leiba , Pete Resnick , "Mankin, Allison" , HTTP Working Group References: <52700DE4.8020208@bbn.com> <527132E3.3000001@gmx.de> <52713922.2020803@bbn.com> <527148F8.4050909@gmx.de> In-Reply-To: <527148F8.4050909@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [secdir] Reuse of credentials per realm, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 31 Oct 2013 14:15:31 -0000 Julian, Thanks. I suggest including that as an example, for other readers. It's consistent with your later discussion of purging credentials, so you could include a forward pointer to that text. Steve ----- On 10/30/13 1:59 PM, Julian Reschke wrote: > On 2013-10-30 17:51, Stephen Kent wrote: >> Julian, >> >> Since, as you note, the server ultimately accepts or rejects the >> credentials, >> it was not clear under what circumstances "user preferences" are a valid >> factor >> in deciding when to stop using the same set of credentials. If you could >> elaborate >> that would be useful. > > Well, that text was written 14 years ago, so I really don't know > exactly what the authors had in mind. > > That being said, here's an example: a user pref defining how long > credentials can be sent after a certain time of inactivity. > > Best regards, Julian > > From julian.reschke@greenbytes.de Thu Oct 31 07:49:13 2013 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 0233311E81C3 for ; Thu, 31 Oct 2013 07:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.627 X-Spam-Level: X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[AWL=-1.378, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 e+oE1hAApeGM for ; Thu, 31 Oct 2013 07:49:06 -0700 (PDT) Received: from central.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by ietfa.amsl.com (Postfix) with ESMTP id 340AC11E8125 for ; Thu, 31 Oct 2013 07:49:00 -0700 (PDT) Received: from [192.168.1.102] (unknown [217.91.35.233]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by central.greenbytes.de (Postfix) with ESMTPSA id 096EA10C0CDB; Thu, 31 Oct 2013 15:48:58 +0100 (CET) Message-ID: <52726DD8.8080800@greenbytes.de> Date: Thu, 31 Oct 2013 15:48:56 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <52700DE4.8020208@bbn.com> <52726125.1000802@greenbytes.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: secdir , Pete Resnick , "Mankin, Allison" , HTTP Working Group , Barry Leiba Subject: Re: [secdir] additional mechanisms on top of the auth framework, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 31 Oct 2013 14:49:13 -0000 On 2013-10-31 15:44, Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >> On 2013-10-29 20:35, Stephen Kent wrote: >>> ... >>> Later on page 6 the text says: >>> >>> The HTTP protocol does not restrict applications to this simple >>> challenge-response framework for access authentication.Additional >>> mechanisms MAY be used, such as encryption at the transport level or >>> via message encapsulation, and with additional header fields >>> specifying authentication information.However, such additional >>> mechanisms are not defined by this specification. >>> >>> Encryption is not, per se, an authentication mechanism. Please revise >>> this text. >>> ... >> >> OK. Maybe: >> >> "HTTP does not restrict applications to this simple challenge-response >> framework. Additional mechanisms can be used, such as additional header >> fields carrying authentication information, or encryption on the >> transport layer in order to provide confidentiality. However, such >> additional mechanisms are not defined by this specification." >> >> ? > > I think doing s/encryption/authentication/ instead would be better. > There is no reason to discuss confidentiality here. Encryption and other > cryptographic techniques are used in many authentication schemes, like > with client certificates; that may have been the idea behind the text. "authentication on the transport layer"? That wouldn't cover Basic auth (plain text passwords) over https:, which I think this paragraph is hinting at... Best regards, Julian -- bytes GmbH, Hafenweg 16, D-48155 Münster, Germany Amtsgericht Münster: HRB5782 From nico@cryptonector.com Thu Oct 31 07:51:14 2013 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 20E2121E8092 for ; Thu, 31 Oct 2013 07:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 LvHTGDI6Diiz for ; Thu, 31 Oct 2013 07:51:09 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF8721F9CAC for ; Thu, 31 Oct 2013 07:51:09 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 31EB828606F; Thu, 31 Oct 2013 07:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=iC7INnbfQngs01 1wTPB6unFy3aw=; b=fQh4lsjEttzxR3XMPCeT2NpPrh8/riEhxSZHaPpiMtluxX f8Xr3KJ40rszy3ThB1EOiU1yxyw5ZIQHFbgwWVV6J+zC1Tb4BwGei5JENkSK5VGB M1ModK+hguEStLjL+Ytt3XQSLYBjUO6LbTzYPzFfsD9hCIDwHM10UNM4nVho4= Received: from gmail.com (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id E6D6E286058; Thu, 31 Oct 2013 07:51:05 -0700 (PDT) Date: Thu, 31 Oct 2013 09:51:02 -0500 From: Nico Williams To: Julian Reschke Message-ID: <20131031145059.GA29480@gmail.com> References: <52700DE4.8020208@bbn.com> <52726125.1000802@greenbytes.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52726125.1000802@greenbytes.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: secdir , Pete Resnick , fielding@gbiv.com, "Mankin, Allison" , HTTP Working Group , Barry Leiba , mnot@pobox.com Subject: Re: [secdir] additional mechanisms on top of the auth framework, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 31 Oct 2013 14:51:14 -0000 On Thu, Oct 31, 2013 at 02:54:45PM +0100, Julian Reschke wrote: > On 2013-10-29 20:35, Stephen Kent wrote: > >... > > > OK. Maybe: > > "HTTP does not restrict applications to this simple > challenge-response framework. Additional mechanisms can be used, > such as additional header fields carrying authentication > information, or encryption on the transport layer in order to > provide confidentiality. However, such additional mechanisms are not > defined by this specification." Or even -as pretty much all web authentication is done- *above* HTTP. Nico -- From derhoermi@gmx.net Thu Oct 31 07:30:29 2013 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 5234011E8149 for ; Thu, 31 Oct 2013 07:30:29 -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 VsJmjgM0kUW2 for ; Thu, 31 Oct 2013 07:30:25 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id CE98221F9DD5 for ; Thu, 31 Oct 2013 07:30:24 -0700 (PDT) Received: from netb.Speedport_W_700V ([84.180.225.225]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0Mcgur-1VKUpx221B-00Hsno for ; Thu, 31 Oct 2013 15:30:24 +0100 From: Bjoern Hoehrmann To: Julian Reschke Date: Thu, 31 Oct 2013 15:30:22 +0100 Message-ID: <5op4795b77js1jfi5pqfv9jss3ko77vd4a@hive.bjoern.hoehrmann.de> References: <52700DE4.8020208@bbn.com> <52725E8E.50106@greenbytes.de> In-Reply-To: <52725E8E.50106@greenbytes.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:R+c4qbQIQcJmo76fRrccV/pAzxs1PJ/TGTz/iReCHd9LDDKEVni jbjAhWWG1apg6X4cD6ACw8ledb9e81JDBvAovUqhxcbj0N/7G2yvaEtAVODJjxVZgV4uQ5n ma6T5kL47OqjMbhksAHHDw7vbboNMf3FxXWzY2DrGTCx6/F7lHT8OamK+u2Zh1IvXBcIkqb WwNcqGiSlDRvP1KxHz2gw== X-Mailman-Approved-At: Thu, 31 Oct 2013 08:15:22 -0700 Cc: secdir , Pete Resnick , "Mankin, Allison" , HTTP Working Group , Barry Leiba Subject: Re: [secdir] proxies and forwarding of credentials, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 31 Oct 2013 14:30:29 -0000 * Julian Reschke wrote: >On 2013-10-29 20:35, Stephen Kent wrote: >> ... >> In Section 4.3, the text says: >> >> A proxy MAY relay >> >> the credentials from the client request to the next proxy if that is >> >> the mechanism by which the proxies cooperatively authenticate a given >> >> request. >> >> If, as stated here, a set of proxies cooperatively authenticate a >> request, then isn’t this a MUST vs. a MAY? >> ... > >Maybe. I have no experience with proxy authentication, and this piece of >text was copied from >. > >Perhaps this is a case where we should drop the RFC2119 keywords [...] Ordinarily a proxy is not supposed to forward the `Proxy-Authorization` header and an implementation that forwards it by accident fails to meet the requirements of the specification, so use of RFC 2119 keywords seems appropriate to me. I also see nothing wrong with the proxy offering an configuration option to, say, relay the credentials for some users, but not for others, so this cannot be a MUST. I think the text is fine. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From derhoermi@gmx.net Thu Oct 31 07:44:29 2013 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 8F2D821F9EE5 for ; Thu, 31 Oct 2013 07:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 elrgoEbv-apd for ; Thu, 31 Oct 2013 07:44:25 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id A54A711E8125 for ; Thu, 31 Oct 2013 07:44:24 -0700 (PDT) Received: from netb.Speedport_W_700V ([84.180.225.225]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0M3NEK-1VtYpB1QxM-00r2UR for ; Thu, 31 Oct 2013 15:44:24 +0100 From: Bjoern Hoehrmann To: Julian Reschke Date: Thu, 31 Oct 2013 15:44:24 +0100 Message-ID: References: <52700DE4.8020208@bbn.com> <52726125.1000802@greenbytes.de> In-Reply-To: <52726125.1000802@greenbytes.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:3NxLwSYNBDU1cFQhmmVB+cIvCn4YtGBbyq08uzht4GfCkFMmnP1 /GYvwrMHyLSiEA12E3FueSOqaqlwpXQhVLrrGN/tHyLw19VNJxwAWm1ZPMH8XjjSccqR3oj f/AKz+r8U/5B1EI55fOYFSqL9ZSCo8Z1w9q1+OWHkK4XipL6RpywzIiWosOvSjLZSLnqWXC J/fxiWXcY94O4er45nhSw== X-Mailman-Approved-At: Thu, 31 Oct 2013 08:15:22 -0700 Cc: secdir , Pete Resnick , "Mankin, Allison" , HTTP Working Group , Barry Leiba Subject: Re: [secdir] additional mechanisms on top of the auth framework, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 31 Oct 2013 14:44:29 -0000 * Julian Reschke wrote: >On 2013-10-29 20:35, Stephen Kent wrote: > > ... > > Later on page 6 the text says: >> >> The HTTP protocol does not restrict applications to this simple >> challenge-response framework for access authentication.Additional >> mechanisms MAY be used, such as encryption at the transport level or >> via message encapsulation, and with additional header fields >> specifying authentication information.However, such additional >> mechanisms are not defined by this specification. >> >> Encryption is not, per se, an authentication mechanism. Please revise >> this text. >> ... > >OK. Maybe: > >"HTTP does not restrict applications to this simple challenge-response >framework. Additional mechanisms can be used, such as additional header >fields carrying authentication information, or encryption on the >transport layer in order to provide confidentiality. However, such >additional mechanisms are not defined by this specification." > >? I think doing s/encryption/authentication/ instead would be better. There is no reason to discuss confidentiality here. Encryption and other cryptographic techniques are used in many authentication schemes, like with client certificates; that may have been the idea behind the text. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From derhoermi@gmx.net Thu Oct 31 08:05:46 2013 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 0BBCA21E80DA for ; Thu, 31 Oct 2013 08:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.742 X-Spam-Level: X-Spam-Status: No, score=-3.742 tagged_above=-999 required=5 tests=[AWL=-1.143, 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 cJN8P5dvbOMO for ; Thu, 31 Oct 2013 08:05:31 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id DC91F11E8125 for ; Thu, 31 Oct 2013 08:05:30 -0700 (PDT) Received: from netb.Speedport_W_700V ([84.180.225.225]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0LhjeH-1VyFzF1G1x-00mpHw for ; Thu, 31 Oct 2013 16:05:25 +0100 From: Bjoern Hoehrmann To: Julian Reschke Date: Thu, 31 Oct 2013 16:05:21 +0100 Message-ID: References: <52700DE4.8020208@bbn.com> <52726125.1000802@greenbytes.de> <52726DD8.8080800@greenbytes.de> In-Reply-To: <52726DD8.8080800@greenbytes.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:BTyPCp4jE5MDT5q07dttKl2KOBKoiHupWKNPQRfNcMCZ+XW1pdr lLnzd0qrNUqSBEmQ2n3ePMYU3CSsNsQerfQVDtRILAi8kUVQo7wGqMKObHEKp8BEO1bNo86 GfLwzGAcgZaLLZx7mTgu5oITkuLU90vkmoeoDPIGR6b5udJYHHLLKF1QdivQVK4etYJUQPR vB3k7XWig/8xCp5UWghqg== X-Mailman-Approved-At: Thu, 31 Oct 2013 08:15:22 -0700 Cc: secdir , Pete Resnick , "Mankin, Allison" , HTTP Working Group , Barry Leiba Subject: Re: [secdir] additional mechanisms on top of the auth framework, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 31 Oct 2013 15:05:50 -0000 * Julian Reschke wrote: >On 2013-10-31 15:44, Bjoern Hoehrmann wrote: >> I think doing s/encryption/authentication/ instead would be better. >> There is no reason to discuss confidentiality here. Encryption and other >> cryptographic techniques are used in many authentication schemes, like >> with client certificates; that may have been the idea behind the text. > >"authentication on the transport layer"? Applying my suggestion would make the text read, The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as authentication at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification. (The MAY might be better as "can".) >That wouldn't cover Basic auth (plain text passwords) over https:, which >I think this paragraph is hinting at... Transport Layer Security client certificate authentication is an additional authentication mechanism at the transport level that implementations of HTTP actually use. Basic authentication is just the basic application of the challenge-response framework defined in the document, so your interpretation seems unlikely. It might be a good idea to point out that authentication does not imply confidentiality and that TLS can be used for confidentiality, but that should be in a separate paragraph. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From kent@bbn.com Thu Oct 31 08:17:28 2013 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 77E3311E8172 for ; Thu, 31 Oct 2013 08:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.529 X-Spam-Level: X-Spam-Status: No, score=-106.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6UwJCJ5BJM5G for ; Thu, 31 Oct 2013 08:17:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 824F211E8171 for ; Thu, 31 Oct 2013 08:17:22 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49334) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VbtzX-000DTQ-B1; Thu, 31 Oct 2013 11:16:59 -0400 Message-ID: <5272746B.7090501@bbn.com> Date: Thu, 31 Oct 2013 11:16:59 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Julian Reschke , secdir , fielding@gbiv.com, mnot@pobox.com, Barry Leiba , Pete Resnick , "Mankin, Allison" , HTTP Working Group References: <52700DE4.8020208@bbn.com> <52726125.1000802@greenbytes.de> In-Reply-To: <52726125.1000802@greenbytes.de> Content-Type: multipart/alternative; boundary="------------050604010805090302050109" Subject: Re: [secdir] additional mechanisms on top of the auth framework, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 31 Oct 2013 15:17:28 -0000 This is a multi-part message in MIME format. --------------050604010805090302050109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Julian, The revised text you proposed below looks good, with one minor edit: or encryption on the transport layer -> or encryption *at* the transport layer Thanks, Steve ----- On 10/31/13 9:54 AM, Julian Reschke wrote: > On 2013-10-29 20:35, Stephen Kent wrote: > > ... > > Later on page 6 the text says: >> >> The HTTP protocol does not restrict applications to this simple >> >> challenge-response framework for access authentication.Additional >> >> mechanisms MAY be used, such as encryption at the transport level or >> >> via message encapsulation, and with additional header fields >> >> specifying authentication information.However, such additional >> >> mechanisms are not defined by this specification. >> >> Encryption is not, per se, an authentication mechanism. Please revise >> this text. >> ... > > > OK. Maybe: > > "HTTP does not restrict applications to this simple challenge-response > framework. Additional mechanisms can be used, such as additional > header fields carrying authentication information, or encryption on > the transport layer in order to provide confidentiality. However, such > additional mechanisms are not defined by this specification." > > ? > > Best regards, Julian > --------------050604010805090302050109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Julian,

The revised text you proposed below looks good, with one minor edit:

or encryption on the transport layer -> or encryption at the transport layer

Thanks,

Steve
-----
On 10/31/13 9:54 AM, Julian Reschke wrote:
On 2013-10-29 20:35, Stephen Kent wrote:
> ...
> Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple

challenge-response framework for access authentication.Additional

mechanisms MAY be used, such as encryption at the transport level or

via message encapsulation, and with additional header fields

specifying authentication information.However, such additional

mechanisms are not defined by this specification.

Encryption is not, per se, an authentication mechanism. Please revise
this text.
...


OK. Maybe:

"HTTP does not restrict applications to this simple challenge-response framework. Additional mechanisms can be used, such as additional header fields carrying authentication information, or encryption on the transport layer in order to provide confidentiality. However, such additional mechanisms are not defined by this specification."

?

Best regards, Julian


--------------050604010805090302050109-- From julian.reschke@gmx.de Thu Oct 31 08:18:08 2013 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 7D54311E8171 for ; Thu, 31 Oct 2013 08:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.233 X-Spam-Level: X-Spam-Status: No, score=-104.233 tagged_above=-999 required=5 tests=[AWL=-1.634, 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 iCNAh7s4jBmb for ; Thu, 31 Oct 2013 08:18:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5BABA11E8221 for ; Thu, 31 Oct 2013 08:18:02 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MDFB2-1VRxJM2oto-00GcRD for ; Thu, 31 Oct 2013 16:18:01 +0100 Message-ID: <527274A5.9030009@gmx.de> Date: Thu, 31 Oct 2013 16:17:57 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Bjoern Hoehrmann , Julian Reschke References: <52700DE4.8020208@bbn.com> <52726125.1000802@greenbytes.de> <52726DD8.8080800@greenbytes.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:1S5960Sv8BOzgl+fTf3NrDTVVxIwG7EH4MoSYKbra/v2FpQCZ70 PsII/5rNbxxCLB4Lxni1wihrpOakSjS39OzAofZrGszYyvDM2D8/V+I0SZNiVHPzJ1X395V sm4E+2VPelGaPNQbOzU/V+fDilbI4C/7PjPoH2WcpwfvdaIPOuVb0ExDucVsnFxiFv+tJUG JiRIE6WEBh0TQJK4be0gA== Cc: secdir , Pete Resnick , "Mankin, Allison" , HTTP Working Group , Barry Leiba Subject: Re: [secdir] additional mechanisms on top of the auth framework, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 31 Oct 2013 15:18:08 -0000 On 2013-10-31 16:05, Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >> On 2013-10-31 15:44, Bjoern Hoehrmann wrote: >>> I think doing s/encryption/authentication/ instead would be better. >>> There is no reason to discuss confidentiality here. Encryption and other >>> cryptographic techniques are used in many authentication schemes, like >>> with client certificates; that may have been the idea behind the text. >> >> "authentication on the transport layer"? > > Applying my suggestion would make the text read, > > The HTTP protocol does not restrict applications to this simple > challenge-response framework for access authentication. Additional > mechanisms MAY be used, such as authentication at the transport > level or via message encapsulation, and with additional header fields > specifying authentication information. However, such additional > mechanisms are not defined by this specification. > > (The MAY might be better as "can".) "HTTP does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms can be used, such as authentication at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification." WFM. >> That wouldn't cover Basic auth (plain text passwords) over https:, which >> I think this paragraph is hinting at... > > Transport Layer Security client certificate authentication is an > additional authentication mechanism at the transport level that > implementations of HTTP actually use. Basic authentication is just Indeed. > the basic application of the challenge-response framework defined > in the document, so your interpretation seems unlikely. > > It might be a good idea to point out that authentication does not > imply confidentiality and that TLS can be used for confidentiality, > but that should be in a separate paragraph. Maybe. Text welcome :-) Best regards, Julian From barryleiba.mailing.lists@gmail.com Thu Oct 31 11:02:50 2013 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 1722111E8231; Thu, 31 Oct 2013 11:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.954 X-Spam-Level: X-Spam-Status: No, score=-101.954 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-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 Oidji1fbvnC6; Thu, 31 Oct 2013 11:02:49 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 33CF111E817A; Thu, 31 Oct 2013 11:02:49 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id if17so2181856vcb.41 for ; Thu, 31 Oct 2013 11:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=CAwIPIHnKrAdvLE6IsvmuVLKzWhdEcI0O3+Fj+pDncs=; b=yxHeOat20niBIesMd9K21j818q1WYM88Kmw04PwziYb06m0dOy3pM14coaHgZ155ls xe4GZ+Wv/kDy+tnE2IDqp1NhGpeMcu8BnJF622xfoBlSfS1hDt7zhB+U04tLB3MdjFkH /GDNUwrnBA/W9cbuaheVbIIvfjn8zdtDlhcIFLPD6+YVzjiQPi9ATQTnEO2CibnJajBt 05mMzKAOOyKk+kyoihTulYDcJQ5oRYmT+FvS9fw/zgpNc4AZUKc2744CwBI51yf9tFxQ 9LWRdbkGfMKIS0Dzf5/Wa4JzRasAMjBSZ3uFdUWkknUnPDls5qo5ypsKH1sVMg3WNgPZ bYCQ== MIME-Version: 1.0 X-Received: by 10.52.191.162 with SMTP id gz2mr2445432vdc.26.1383242568556; Thu, 31 Oct 2013 11:02:48 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.170.71 with HTTP; Thu, 31 Oct 2013 11:02:48 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Oct 2013 14:02:48 -0400 X-Google-Sender-Auth: pkzFI9YKvP2K1fMRZXE981_CZto Message-ID: From: Barry Leiba To: Ben Laurie Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-httpbis-p1-messaging.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-httpbis-p1-messaging-24 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, 31 Oct 2013 18:02:50 -0000 > Now that I've realised this is, in fact, a revision of the existing > spec to reflect experience, I retract this review. I do feel, however, > that the text is lacking in solid actionable advice, and so I will > re-review in light of my corrected understanding. Thanks, Ben. I know there's a lot of material here, so thanks for taking the time to give it another look. The httpbis working group has two main products, and this is the first: the revision of http 1.1, RFC 2616. The second, the development of http 2.0, is what you'd been hoping that this was. That project is moving along very well, with excellent editors and a great deal of participation and enthusiasm. Barry, the responsible AD for this stuff From kent@bbn.com Thu Oct 31 13:01:44 2013 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 B052911E8190 for ; Thu, 31 Oct 2013 13:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 RWawsO7JT5Aa for ; Thu, 31 Oct 2013 13:01:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 85B8511E8185 for ; Thu, 31 Oct 2013 13:01:36 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50896) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VbyQt-000Hhq-Pr; Thu, 31 Oct 2013 16:01:31 -0400 Message-ID: <5272B71B.1070607@bbn.com> Date: Thu, 31 Oct 2013 16:01:31 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Julian Reschke , secdir , fielding@gbiv.com, mnot@pobox.com, Barry Leiba , Pete Resnick , "Mankin, Allison" , HTTP Working Group References: <52700DE4.8020208@bbn.com> <52725E8E.50106@greenbytes.de> In-Reply-To: <52725E8E.50106@greenbytes.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [secdir] proxies and forwarding of credentials, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 31 Oct 2013 20:01:44 -0000 Julian, I alos don't have personal experience with the proxy situation. I was just commenting on what appeared to be a logical inconsistency in the text. I defer to others, who have such experience, on this detail. Steve > On 2013-10-29 20:35, Stephen Kent wrote: >> ... >> In Section 4.3, the text says: >> >> A proxy MAY relay >> >> the credentials from the client request to the next proxy if that is >> >> the mechanism by which the proxies cooperatively authenticate a given >> >> request. >> >> If, as stated here, a set of proxies cooperatively authenticate a >> request, then isn’t this a MUST vs. a MAY? >> ... > > Maybe. I have no experience with proxy authentication, and this piece > of text was copied from > . > > Perhaps this is a case where we should drop the RFC2119 keywords and > just make a statement such as: > > "A proxy can relay the credentials from the client request to the next > proxy if that is the mechanism by which the proxies cooperatively > authenticate a given request." > > ? > > Best regards, Julian > From mnot@mnot.net Thu Oct 31 15:59:41 2013 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 720EC11E8271 for ; Thu, 31 Oct 2013 15:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.815 X-Spam-Level: X-Spam-Status: No, score=-104.815 tagged_above=-999 required=5 tests=[AWL=-2.216, 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 hDcVTyyqn4k4 for ; Thu, 31 Oct 2013 15:59:36 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id D910211E8274 for ; Thu, 31 Oct 2013 15:59:34 -0700 (PDT) Received: from [192.168.1.72] (unknown [118.209.167.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C3FCF22E1FA; Thu, 31 Oct 2013 18:59:12 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Mark Nottingham In-Reply-To: <5272B71B.1070607@bbn.com> Date: Fri, 1 Nov 2013 09:59:07 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <679A359D-AB27-4DA7-AAD0-59290DA1DF23@mnot.net> References: <52700DE4.8020208@bbn.com> <52725E8E.50106@greenbytes.de> <5272B71B.1070607@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1816) Cc: secdir , Pete Resnick , "Julian F. Reschke" , Mark Nottingham , "Mankin, Allison" , HTTP Working Group , Barry Leiba , Roy Fielding Subject: Re: [secdir] proxies and forwarding of credentials, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 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, 31 Oct 2013 22:59:41 -0000 It entirely depends upon the way that they=92re cooperating=85 sometimes = you=92d want to forward them, sometimes not. If we were defining a proxy = authentication cooperation protocol here, I could understand a MUST = here, but as we=92re not, I don=92t think we want to constrain how one = might operate=85 Cheers, On 1 Nov 2013, at 7:01 am, Stephen Kent wrote: > Julian, >=20 > I alos don't have personal experience with the proxy situation. I was = just commenting on > what appeared to be a logical inconsistency in the text. >=20 > I defer to others, who have such experience, on this detail. >=20 > Steve >> On 2013-10-29 20:35, Stephen Kent wrote: >>> ... >>> In Section 4.3, the text says: >>>=20 >>> A proxy MAY relay >>>=20 >>> the credentials from the client request to the next proxy if that is >>>=20 >>> the mechanism by which the proxies cooperatively authenticate a = given >>>=20 >>> request. >>>=20 >>> If, as stated here, a set of proxies cooperatively authenticate a >>> request, then isn=92t this a MUST vs. a MAY? >>> ... >>=20 >> Maybe. I have no experience with proxy authentication, and this piece = of text was copied from = . >>=20 >> Perhaps this is a case where we should drop the RFC2119 keywords and = just make a statement such as: >>=20 >> "A proxy can relay the credentials from the client request to the = next proxy if that is the mechanism by which the proxies cooperatively = authenticate a given request." >>=20 >> ? >>=20 >> Best regards, Julian >>=20 >=20 -- Mark Nottingham http://www.mnot.net/