From nobody Sun Feb 1 09:56:37 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC6A1A8A7D; Sun, 1 Feb 2015 09:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cf8qjzEBHdJh; Sun, 1 Feb 2015 09:56:31 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 863291A1A22; Sun, 1 Feb 2015 09:56:31 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id k48so35277556wev.9; Sun, 01 Feb 2015 09:56:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=dx0iGSSkJ2EPHowTqD56IXgxQAonATMd5X5IrouwSdA=; b=CmmmdwjqQ+GTiTeT3xmMPfsi3DIhNdQV8SLOgb1bDYpr/rPzSjb1e+wNXklV9pxhnr iyCyj2kmqplNyYhCQAIVX1y7f4Ub3X6uKTMj/HpD7ruspnt4n6OgZ3Mofh8WZglzO0jt bQ75l8hf/Mxtnz9Vai8BgaBLNyVaLxkIYpeJjtB7OjUcThqvCfDH4UMc9VN+LlGuzRMb +Zgiq9GQ9mPngbM/8vBZRKIvaTeHqc1u8/wPTzmMVxzGSvrSUBKCvk/XPTifPsd+LxL5 QAm8dSJadWXVCCp01Zaw3uOoCSHswaW89NseMPGbjtchfkBQp9zydfCAMUp+cUcDC6FS 3raQ== X-Received: by 10.194.234.2 with SMTP id ua2mr34015527wjc.40.1422813390302; Sun, 01 Feb 2015 09:56:30 -0800 (PST) Received: from [10.2.0.130] (93-173-247-187.bb.netvision.net.il. [93.173.247.187]) by mx.google.com with ESMTPSA id s10sm1418051wjs.38.2015.02.01.09.56.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Feb 2015 09:56:29 -0800 (PST) Message-ID: <54CE68CC.2000409@gmail.com> Date: Sun, 01 Feb 2015 19:56:28 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: IETF Security Directorate , The IESG , draft-ietf-tram-turn-third-party-authz.all@tools.ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [secdir] SecDir review of draft-ietf-tram-turn-third-party-authz-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 17:56:33 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a mechanism where a STUN client can present an OAUTH token and get authorized to use a particular STUN server. Summary IMHO, the document is not yet ready to be published. Details • What is the motivation for this authorization? Is it intended to conserve server resources? • What is HMAC-SHA-256-128? Is the output 128 or 256 bits long? Please include a reference. • Maybe I'm confused, but it seems to me that the discussion immediately following Fig. 2 mixes the hash algorithm that signs the token itself with the algorithm that integrity-protects STUN messages. If they must be the same for some reason, please state it clearly. • 4.1: there are obvious benefits to using an asymmetric key here, and in fact this can be done efficiently using elliptic curves (ECDSA). So I think the "MUST establish a symmetric key" is misguided. • 4.1.1: the derivation of both keys seems to be the same, so are they identical?! • 4.1.2: this interaction (a simple REST query to get a long-term key) is by default insecure, so I'm surprised to see it here with no comments about the need to encrypt it an authenticate the client. • 4.1.3: please provide a reference for AES_256_CBC_HMAC_SHA_512. • 6.1, last sentence: so an attacker who can disrupt communication to the AS can force the client to switch to 1st party authentication, which is easily susceptible to dictionary attacks? • 6.2: the timestamp value is strange, specifically the fractional part. Why are fractions needed, do we think this improves security? • 6.2 example: when using AES-256-CBC something must be said about padding and about the IV. • 6.2, last sentence: the length of the nonce surely depends on the selected algorithm, and cannot be a constant 12. • 8: Is the MESAGE INTEGRITY attribute itself mandatory? The client should reject messages if this attribute is not included. • 9: if the server is allowed to cache access tokens, there must be a way for the client to refer to a token by name. Otherwise there may be confusion when tokens are expired and replaced by new ones, especially in the presence of dropped messages. • 10: is the server required to cache old transaction IDs to avoid replay attacks? If this is the case, you need to mandate it explicitly. • App. A: the mac_key as included in the token should be binary IMO, and not as shown here, encoded in base64. • I suggest to rename "long term password" to "long term key" (and again, it should be binary). • Similarly, the nonce should be binary. Thanks, Yaron From nobody Sun Feb 1 10:49:39 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEDE1A901E; Sun, 1 Feb 2015 10:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGrzh-Kn64fA; Sun, 1 Feb 2015 10:49:35 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D734D1A9005; Sun, 1 Feb 2015 10:49:34 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-93-54ce753c029e Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F1.1A.04076.C357EC45; Sun, 1 Feb 2015 19:49:32 +0100 (CET) Received: from [131.160.126.10] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.210.2; Sun, 1 Feb 2015 19:49:31 +0100 Message-ID: <54CE753A.1090904@ericsson.com> Date: Sun, 1 Feb 2015 20:49:30 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Yaron Sheffer , IETF Security Directorate , The IESG , References: <54CE68CC.2000409@gmail.com> In-Reply-To: <54CE68CC.2000409@gmail.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+Jvja5N6bkQg/cXJSw+rV3NZDHjz0Rm iw8LH7JYrLo/g92BxWPnrLvsHkuW/GTy+HL5M1sAcxSXTUpqTmZZapG+XQJXxrL1uQXrpCo+ Xr3H2sB4U6SLkZNDQsBEYvufP+wQtpjEhXvr2boYuTiEBI4wSrSfbmOHcFYzSrzZcYgRpIpX QFviyskXLF2MHBwsAioS804rgoTZBCwktty6zwJiiwpEScw+/4AVolxQ4uTMJywgc0QENjJK XO18yAySEBZwl5j4dgtYkZCAhsSHN/uYQGxOAU2JrV9ug+1iFjCQOLJoDiuELS/RvHU2M0S9 tsTyZy0sExgFZiHZMQtJyywkLQsYmVcxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBAbtwS2/ rXYwHnzueIhRgINRiYfXgP1ciBBrYllxZe4hRmkOFiVxXjvjQyFCAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGJelfXh25lyBrIV0JJ9qkuH6mXKrnWS1l/w2ruvju8NhfPH5lh31s/KY5xm4 LrmsMtknQ7LMvf9OvdOv7PJrL77u5X0rMP+Ea2bu9OutGTXrk43T3JazahtqMceqKLPaljyt 2xcbvCytM9jdPvWXcfsE5hCd9pxVjh1uLW6zXnc9XOj0kX+FEktxRiJQR1FxIgAbcvnFOwIA AA== Archived-At: Subject: Re: [secdir] SecDir review of draft-ietf-tram-turn-third-party-authz-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 18:49:37 -0000 Thanks for your review, Yaron. Authors, please provide Yaron with responses to the comments below. Also, please involve the WG if you need to make a significant change in order to address any of the comments. Cheers, Gonzalo On 01/02/2015 7:56 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 defines a mechanism where a STUN client can present an > OAUTH token and get authorized to use a particular STUN server. > > Summary > > IMHO, the document is not yet ready to be published. > > Details > > • What is the motivation for this authorization? Is it intended to > conserve server resources? > > • What is HMAC-SHA-256-128? Is the output 128 or 256 bits long? Please > include a reference. > > • Maybe I'm confused, but it seems to me that the discussion immediately > following Fig. 2 mixes the hash algorithm that signs the token itself > with the algorithm that integrity-protects STUN messages. If they must > be the same for some reason, please state it clearly. > > • 4.1: there are obvious benefits to using an asymmetric key here, and > in fact this can be done efficiently using elliptic curves (ECDSA). So I > think the "MUST establish a symmetric key" is misguided. > > • 4.1.1: the derivation of both keys seems to be the same, so are they > identical?! > > • 4.1.2: this interaction (a simple REST query to get a long-term key) > is by default insecure, so I'm surprised to see it here with no comments > about the need to encrypt it an authenticate the client. > > • 4.1.3: please provide a reference for AES_256_CBC_HMAC_SHA_512. > > • 6.1, last sentence: so an attacker who can disrupt communication to > the AS can force the client to switch to 1st party authentication, which > is easily susceptible to dictionary attacks? > > • 6.2: the timestamp value is strange, specifically the fractional part. > Why are fractions needed, do we think this improves security? > > • 6.2 example: when using AES-256-CBC something must be said about > padding and about the IV. > > • 6.2, last sentence: the length of the nonce surely depends on the > selected algorithm, and cannot be a constant 12. > > • 8: Is the MESAGE INTEGRITY attribute itself mandatory? The client > should reject messages if this attribute is not included. > > • 9: if the server is allowed to cache access tokens, there must be a > way for the client to refer to a token by name. Otherwise there may be > confusion when tokens are expired and replaced by new ones, especially > in the presence of dropped messages. > > • 10: is the server required to cache old transaction IDs to avoid > replay attacks? If this is the case, you need to mandate it explicitly. > > • App. A: the mac_key as included in the token should be binary IMO, and > not as shown here, encoded in base64. > > • I suggest to rename "long term password" to "long term key" (and > again, it should be binary). > > • Similarly, the nonce should be binary. > > Thanks, > Yaron From nobody Mon Feb 2 10:07:49 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580841A8836; Mon, 2 Feb 2015 10:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAKfyU4dFgyc; Mon, 2 Feb 2015 10:07:33 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB8E1A883A; Mon, 2 Feb 2015 10:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8188; q=dns/txt; s=iport; t=1422900439; x=1424110039; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=QtBbdREcyIGZXu2l/JRuJ7E5BdVGdQxyW62C5l2xFok=; b=Wr4VNt5/DaWuSZMSj22D6wswi2F3OQ1u1dJytE3aaQ533PEW1mCjBqnp zXygvhTND6wx6Hk8Z7AAy8ipcmcE3ZD6FWeEYJ9VngIPbxaw3sSJNk62f ZU/sWsXh5TdD1qAPyiVHG1rDMVeoUiZCcYf9XJV4WyZ+rE8lniNIiGvc8 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CPBQCYvM9U/40NJK1bgwZSWQTCP4IlhXECgRxDAQEBAQF9hAwBAQEDAScTPwUHBgEIEQQBAQsOBgkoERQJCQEEAQ0FCIgRAwkIDdBhDYU2AQEBAQEBAQEBAQEBAQEBAQEBAQEBF41OgXkxDRKCfoETBY0mgWODToQRgl02gk2IRYV9IoIBARyBUG8BgUN+AQEB X-IronPort-AV: E=Sophos;i="5.09,507,1418083200"; d="scan'208";a="119795734" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP; 02 Feb 2015 18:07:18 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t12I7I0i022162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Feb 2015 18:07:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 2 Feb 2015 12:07:18 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Yaron Sheffer , IETF Security Directorate , The IESG , "draft-ietf-tram-turn-third-party-authz.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-tram-turn-third-party-authz-07 Thread-Index: AdA/ExG1WBn6u6R0RKmUj5mvhiVERQ== Date: Mon, 2 Feb 2015 18:07:18 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35535978@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.32.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-tram-turn-third-party-authz-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 18:07:37 -0000 Hi Yaron, Thanks for the detailed review. Please see inline > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Sunday, February 01, 2015 11:26 PM > To: IETF Security Directorate; The IESG; draft-ietf-tram-turn-third-party= - > authz.all@tools.ietf.org > Subject: SecDir review of draft-ietf-tram-turn-third-party-authz-07 >=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 security are= a > directors. Document editors and WG chairs should treat these comments > just like any other last call comments. >=20 > This document defines a mechanism where a STUN client can present an > OAUTH token and get authorized to use a particular STUN server. >=20 > Summary >=20 > IMHO, the document is not yet ready to be published. >=20 > Details >=20 > * What is the motivation for this authorization? Is it intended to conser= ve > server resources? Yes, to ensure that only authorized clients can use the STUN server. For ex= ample allow the client to use the TURN server only when making a call using= the WebRTC server. >=20 > * What is HMAC-SHA-256-128? Is the output 128 or 256 bits long?=20 The output is truncated to 128 bit. > Please > include a reference. Added reference to RFC 4868. >=20 > * Maybe I'm confused, but it seems to me that the discussion immediately > following Fig. 2 mixes the hash algorithm that signs the token itself wit= h the > algorithm that integrity-protects STUN messages. If they must be the same > for some reason, please state it clearly. No, they do not need to be same. RFC 5389 mandates HMAC-SHA1 for integrity = protection of STUN message and in future the WG plans to remove this limita= tion, hence we added this paragraph after Fig.2. >=20 > * 4.1: there are obvious benefits to using an asymmetric key here, and in= fact > this can be done efficiently using elliptic curves (ECDSA). So I think th= e "MUST > establish a symmetric key" is misguided. Agreed.=20 NEW: Elliptic curve cryptography (ECC) or symmetric-key algorithm MUST be chosen= to ensure that the size of encrypted token is not large because usage of R= SA will result in large encrypted tokens which may not fit into a single ST= UN message. >=20 > * 4.1.1: the derivation of both keys seems to be the same, so are they > identical?! The derivation of the keys is required if the encryption and HMAC algorithm= require keys of different length. NEW: For example if the input symmetric key (K) is 32 octets length, encryption algorithm is AES_256_CBC and HMAC algorithm is HMAC-SHA1 [RFC2104] then the secondary keys AS-RS, AUTH are generated from the input key K as follows 1. HKDF-Extract(zero, K) -> PRK 2. HKDF-Expand(PRK, zero, 16) -> AUTH key=20 3. HKDF-Expand(PRK, zero, 32) -> AS-RS key >=20 > * 4.1.2: this interaction (a simple REST query to get a long-term key) is= by > default insecure, so I'm surprised to see it here with no comments about = the > need to encrypt it an authenticate the client. Good point, updated draft. NEW: The two servers could choose to use REST API over HTTPS to establish a symm= etric key. HTTPS MUST be used for mutual authentication and confidentiality= . >=20 > * 4.1.3: please provide a reference for AES_256_CBC_HMAC_SHA_512. Added reference. >=20 > * 6.1, last sentence: so an attacker who can disrupt communication to the= AS > can force the client to switch to 1st party authentication, which is easi= ly > susceptible to dictionary attacks ? The possible way to mitigate the attack is use (D)TLS for communication b/w= the client and server.=20 NEW text (added to Security considerations): An attacker may remove the THIRD-PARTY-AUTHORIZATION STUN attribute from the error message forcing the client to pick first party authentication, this attack may be mitigated by opting for Transport Layer Security (TLS) [RFC5246] or Datagram Transport Layer Security (DTLS) [RFC6347] as a transport protocol for Session Traversal Utilities for NAT (STUN), as defined in [RFC5389]and [RFC7350]. >=20 > * 6.2: the timestamp value is strange, specifically the fractional part. > Why are fractions needed, do we think this improves security? We used the description from http://tools.ietf.org/html/rfc3971#section-5.3= .1 =20 Do you see a problem ? >=20 > * 6.2 example: when using AES-256-CBC something must be said about > padding and about the IV. Yes, updated encrypted_block to include padding, padding_length; struct { opaque { uint16_t key_length; opaque mac_key[key_length]; uint64_t timestamp; uint32_t lifetime; uint8_t padding_length; uint8_t padding[padding_length]; } encrypted_block; opaque mac[mac_length]; uint8_t mac_length; } token; padding_length: The padding length MUST be such that the total size of the encrypted_block structure is a multiple of the cipher's block length. padding: Padding that is added to force the length of the plaintext to be an integral multiple of the block cipher's block length. And the below text to address the comment on IV o C =3D AES_256_CBC(AS-RS, encrypted_block) * Initialization vector can be set to zero because the encrypted_block in each access token will not be identical and hence will not result in generation of identical ciphertext. >=20 > * 6.2, last sentence: the length of the nonce surely depends on the selec= ted > algorithm, and cannot be a constant 12. Yes, removed the last sentence and added the following line: The length of nonce for AEAD algorithms is explained in [RFC5116]. >=20 > * 8: Is the MESAGE INTEGRITY attribute itself mandatory ?=20 Yes. > The client should > reject messages if this attribute is not included. Added following text for clarity: o The client looks for the MESSAGE-INTEGRITY attribute in the response. If MESSAGE-INTEGRITY is absent or the value computed for message integrity using mac_key does not match the contents of the MESSAGE-INTEGRITY attribute then the response MUST be discarded. >=20 > * 9: if the server is allowed to cache access tokens, there must be a way= for > the client to refer to a token by name. Otherwise there may be confusion > when tokens are expired and replaced by new ones, especially in the > presence of dropped messages. That line is only for server implementation optimization.=20 NEW: Since the access token is only valid for a specific period of time, the TUR= N server can cache it so that it can check if the access token in a new all= ocation request matches one of the cached tokens and avoids the need not de= crypt the access token. >=20 > * 10: is the server required to cache old transaction IDs to avoid replay > attacks? If this is the case, you need to mandate it explicitly. Fixed. NEW: An attacker trying to replay message with ACCESS-TOKEN attribute can be mit= igated by frequent changes of nonce value as discussed in section 10.2 of [RFC5389]. >=20 > * App. A: the mac_key as included in the token should be binary IMO, and > not as shown here, encoded in base64. Assuming mac_key is negotiated using DSKPP base64 encoding is shown, will a= dd a note that mac_key is base64 encoded and=20 must be converted to binary for HMAC computation. >=20 > * I suggest to rename "long term password" to "long term key"=20 Fixed. > (and again, it > should be binary). Added note that long_term_key is base64 encoded and must be converted to bi= nary for encrypting and decrypting of token. >=20 > * Similarly, the nonce should be binary. Updated. Best Regards, -Tiru >=20 > Thanks, > Yaron From nobody Mon Feb 2 10:30:49 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F971A8777; Mon, 2 Feb 2015 10:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7o_9LMVMV60S; Mon, 2 Feb 2015 10:30:43 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F4D1A1A20; Mon, 2 Feb 2015 10:30:43 -0800 (PST) Received: from [128.9.176.28] (c1-vpn2.isi.edu [128.9.176.28]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t12ITZqu006076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Feb 2015 10:29:36 -0800 (PST) Message-ID: <54CFC20E.9000701@isi.edu> Date: Mon, 02 Feb 2015 10:29:34 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Dan Harkins , iesg@ietf.org, secdir@ietf.org, draft-ietf-tsvwg-port-use.all@tools.ietf.org References: <950ad656ed2a0e36e24fd7dc0e2b60b1.squirrel@www.trepanning.net> In-Reply-To: <950ad656ed2a0e36e24fd7dc0e2b60b1.squirrel@www.trepanning.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-port-use X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 18:30:44 -0000 Hi, Dan, It should be easy to add DTLS where TLS is cited. IPsec is an interesting issue; I can add a few sentences to the security considerations area about that - e.g., that IPsec protects in a different way than TLS/DTLS, and that one key aspect of its configuration is port-specific parameters, which means it may be difficult to use separate IPsec policies on different services unless their port numbers are known and fixed in advance (even if using dynamic port numbers). That latter is probably 2-3 short sentences, and I think would be worthwhile. Joe On 1/30/2015 4:04 PM, Dan Harkins 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. > > This draft provides some advice and recommendations on protocol > port use to application and service designers. It has a nice, brief > history of port usage and a nice list of guiding principles to help > conserve port space. It will make a nice BCP. In my opinion it is Ready > For Publication. With that said, I do have a small comment. In section > 7.4 the draft says that TLS should be used to protect services that do > not provide their own security directly. It might be worth while adding > mention of DTLS and IPsec. And if the latter is not something that > should be recommended then justification for that stance should be > given. > > regards, > > Dan. > From nobody Mon Feb 2 12:01:42 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A601A8A48 for ; Mon, 2 Feb 2015 12:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uby2JMALac4D for ; Mon, 2 Feb 2015 12:01:35 -0800 (PST) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E851A8A43 for ; Mon, 2 Feb 2015 12:01:30 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id dc16so30772340qab.1 for ; Mon, 02 Feb 2015 12:01:29 -0800 (PST) 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=hiXHHhA11XJ3F5Q9MATSaImzwtA9WiNxSAQ3zbKhMo4=; b=fLV79HjspXh24IHcU31+WzjYaPTAeETLU87YmTaZnFzknqzypu4Zliyk61GJxI5tx8 tuzRN/7bpeiMvD84pfHQAJTuBLDeTVcezttxbKajuks/mirSCFAjmaawYHPWXZc7K0qD HlGYFppzXh6OmcHUNCf29vrvWiNbuIB3E3GBoEm90wj0FRVPSvlK24Ag2QiRefjDl4WD Gl7B6M/NFbcyINYiZKAgK4nd7Gccb3FVuINidb+FTY6eh/NGiucbieN7SRdtua9zM0Zk QWP3F7Itv3l62UriQZA7Mu6VMiuD2mtGBClrOFr/cpYZb9MEN0Ipg35d9fSY6kt/CzYj YHKQ== X-Gm-Message-State: ALoCoQnd8f2GpX04jksAYN/p3Ee8ue8FpDxWZVO6M3hPt40vOHf+WpyCWn9AQozdZ5/T3pU9Og5D MIME-Version: 1.0 X-Received: by 10.140.107.132 with SMTP id h4mr43785326qgf.71.1422907289684; Mon, 02 Feb 2015 12:01:29 -0800 (PST) Received: by 10.96.238.73 with HTTP; Mon, 2 Feb 2015 12:01:29 -0800 (PST) X-Originating-IP: [50.206.82.141] Date: Mon, 2 Feb 2015 12:01:29 -0800 Message-ID: From: Joseph Salowey To: secdir , draft-ietf-mpls-seamless-mcast.all@tools.ietf.org, The IESG Content-Type: multipart/alternative; boundary=001a113a79968ce556050e206b91 Archived-At: Subject: [secdir] secdir review of draft-ietf-mpls-seamless-mcast-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 20:01:38 -0000 --001a113a79968ce556050e206b91 Content-Type: text/plain; charset=UTF-8 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. I think the document is ready. This document describes procedures for building point-to-multipoint service LSPs. My background in this area is not very deep. I have read through the document and the references in the security considerations section. This guidance seems good, however the document describes a lot of procedures and its not obviously clear what part of the procedures are security impacting. Its not clear to me that this is a problem. Thanks, Joe --001a113a79968ce556050e206b91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this docume= nt as part of the security directorate's
ongoing effort to review all IETF docum= ents being processed by the
IESG.=C2=A0 These comments were written primarily for t= he benefit of the
security area directors.=C2=A0 Document editors and WG chairs shou= ld treat
= these comments just like any other last call comments.

I think the=C2=A0document i= s ready.=C2=A0

This document describes procedures for building point-to-multipoint serv= ice LSPs.=C2=A0 My background in this area is not very deep.=C2=A0 I have r= ead=C2=A0through the document and the references in the security considerat= ions section. =C2=A0 This guidance seems good, however the document describ= es a lot of procedures and its not obviously clear what part of the procedu= res are security impacting.=C2=A0 Its not clear to me that this is a proble= m. =C2=A0

Thanks,

Joe
--001a113a79968ce556050e206b91-- From nobody Mon Feb 2 12:29:44 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E001A8AD4 for ; Mon, 2 Feb 2015 12:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPoC7NJkxavk for ; Mon, 2 Feb 2015 12:29:42 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6381A03B3 for ; Mon, 2 Feb 2015 12:29:41 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 148A628B0053; Mon, 2 Feb 2015 15:29:41 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id AA2271F8035; Mon, 2 Feb 2015 15:29:40 -0500 (EST) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_6BFB66C8-015F-4533-B532-3EB0C821AC02"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 2 Feb 2015 15:29:40 -0500 Message-Id: <34030689-D361-42C6-8454-0FDC32A73731@tislabs.com> To: "secdir@ietf.org" , draft-ietf-httpbis-rfc7238bis@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Subject: [secdir] secdir review of draft-ietf-httpbis-rfc7238bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 20:29:43 -0000 --Apple-Mail=_6BFB66C8-015F-4533-B532-3EB0C821AC02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This is a review of The Hypertext Transfer Protocol Status Code 308 = (Permanent Redirect), draft-ietf-httpbis-rfc7238bis-02. I have reviewed this document as part of the security directorate=92s = 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 is procedural only - it promotes the 308 redirect HTTP = code from Experimental to Standards Track. The security considerations section refers to the section in RFC7231, = which seems to be thorough. I was curious about one question that is general to all redirects, not = this draft in particular. Suppose a server sent a redirect from a https = secured URI to a http unsecured URI. What happens? Of course, the = server is in a position to all sorts of evil stuff. But it seems that = it would be worth a warning from the web browser to the user Answering my own question: =46rom what I've found, I believe that = redirects are included in the same-origin (RFC6454) and cross-origin = CORS (see W3C doc) tests. A protocol change (https<->http) is enough to = classify a request/redirect as cross-origin. (RFC7231 does not mention = same-origin/cross-origin security concerns wrt the types of = attacks/damage it considers. Perhaps the same-origin policy was so = well-known as to be presumed.) Some sites say a cross-origin https->http redirect should fail. Some = w3c sites I've seen indicate some inconsistency in the various browser = CORS implementations, and a quick survey of colleagues indicates they = see varying responses. =20 And, of course, my quick survey could have led me astray as well. --Sandy Murphy P.S. Review another document, learn a little more. --Apple-Mail=_6BFB66C8-015F-4533-B532-3EB0C821AC02 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUz940AAoJEHplpQeet0IZWSUQAIcGEEyAeThdp6fTcx0CWrMu zk8T+KjsbHSPtL9CEoEinoUsqT14bGsUmNVnyjZc/osA0bktVDwzUIze+I0A7umN go6UJaHem3qzS2Le2Z6WX0XnfYYu+pZ+PaZzyKbEOLM+ZKYFG6afkpGoFmiYZmNB sIcM/IDirwKmn2JiLyZO1SS/k6yCne73AjoEa2Tl+IxjTM2U7IrLpdBZw3CracHl d8BayJ/HppiXomRRjGwOViDhYtbU6Eiu9nFaVyCNPSNh4fVg7GL6raAl8jyENTJF Vn1E4AtPXDR7gH7Pyxcyb4QNS1HMjdyLxUO7tJ+gFB5c8hcEM6MIVLeaE978MARP d/dv79hKcXObc6g2xCabgKhD2vDuIJn0ZrdW4nRK1RrtHAXCR0EUN/iWY1BLc7Jv lOzJBkF+JncRMDDfQkpBqUOmoOahSgk3L7yXIsKI6YcXYyt4IxTwd9h1aT3nFmdc MZXZY8sLobnuXGnblf4wWZukwTu8YqtVuzZyxhpulrbhfb4w4UMGF2+q12ckSI+N Z1MRlWtJmCjRqAm2gme2X02VXzpBtOTRdfij+IPrqP6j8m2luijB/FF0Mat6q2an qI/VI0mhbMB0m468eXSb1KJLiKoVZQzXEOoO+w/y/m5ho9WV1DxUo9oFclZvy8iX Qb9HtSkZ9IoNRmSuH1fM =nIKt -----END PGP SIGNATURE----- --Apple-Mail=_6BFB66C8-015F-4533-B532-3EB0C821AC02-- From nobody Mon Feb 2 12:42:03 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E961A8AE3; Mon, 2 Feb 2015 12:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCTlHpANj57N; Mon, 2 Feb 2015 12:42:00 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A171A8AE2; Mon, 2 Feb 2015 12:41:59 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t12Kfvcb008175; Mon, 2 Feb 2015 20:41:57 GMT Received: from 950129200 (089144232000.atnat0041.highway.a1.net [89.144.232.0]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t12KfrUd008153 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2015 20:41:54 GMT From: "Adrian Farrel" To: "'Joseph Salowey'" , "'secdir'" , , "'The IESG'" References: In-Reply-To: Date: Mon, 2 Feb 2015 20:41:43 -0000 Message-ID: <016e01d03f28$afecae30$0fc60a90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_016F_01D03F28.AFEE5BE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJGI96Gexjyp2rYtd80OhnS00YSQ5vyCYLg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21300.002 X-TM-AS-Result: No--15.891-10.0-31-10 X-imss-scan-details: No--15.891-10.0-31-10 X-TMASE-MatchedRID: nI1cAR4k0HanykMun0J1wvs9nOJYqD5IGbJMFqqIm9w4YKAM3oRt9mn7 AlTb8W2xmbgtFJbseiaV2J8ChOmkcwEPJSU5uWO//O70vD0Lt8DRahuPwaQ1WpJ5XtPVefA9qKE gwCKqpo6AYikR0dWTeZbNfgtQUD+kR1vveBQPCRdCvapcIkxJX66IBbSnfz+30pZKESwinxOekF Z5VzCMoF632KLJ/vqKoSAYJH6B6vYiHZrZAcDtw5cDhniv1q1zU+A7YkpDJ1goDMZ3xV44iHVw2 xxcZthfnb+0a0qIQCQpJvJLpbPfP2hKBwPmHsPFu72KpAktHS+2InV6AaP6lZUhT38IzfaR7KBB Z2QBUyxPifNxprH2cuulrrvUsCg/hxaO3bw3PjDjrayXo0o3MIfsPVs/8Vw6EfKzCAntKpAGk2p TPAu+9//55Kkc+9/6c91xMYNqHkXpRijJEQV2jEHrI6vFzzG7l2F9+KxZd8fnlNKhb+fAfpUgSL x++MHya2q9UDkwpo85efiEAHGFZPJRA2JqAZKz2x/FmlC/aowdgkzSIS9hz5gjZJ0l7MH/EpBnZ kLfl1ll5Y4ZwdJW2rof7TPpJvw88SfOLQ+4zH+eAiCmPx4NwGmRqNBHmBve1kTfEkyaZdxFGCd0 S0NCstbtHz/4FpgScCOrU/VulcsgMyhVlnNEgEQPakU1cvtClExlQIQeRG0= Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-mpls-seamless-mcast-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 20:42:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_016F_01D03F28.AFEE5BE0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Joe. Adrian =20 From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Joseph Salowey Sent: 02 February 2015 20:01 To: secdir; draft-ietf-mpls-seamless-mcast.all@tools.ietf.org; The IESG Subject: secdir review of draft-ietf-mpls-seamless-mcast-15 =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 I think the document is ready.=20 =20 This document describes procedures for building point-to-multipoint = service LSPs. My background in this area is not very deep. I have read = through the document and the references in the security considerations = section. This guidance seems good, however the document describes a = lot of procedures and its not obviously clear what part of the = procedures are security impacting. Its not clear to me that this is a = problem. =20 =20 Thanks, =20 Joe ------=_NextPart_000_016F_01D03F28.AFEE5BE0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks, = Joe.

Adrian

 

From: iesg = [mailto:iesg-bounces@ietf.org] On Behalf Of Joseph = Salowey
Sent: 02 February 2015 20:01
To: secdir; = draft-ietf-mpls-seamless-mcast.all@tools.ietf.org; The = IESG
Subject: secdir review of = draft-ietf-mpls-seamless-mcast-15

 

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.

 

I = think the document is ready. 

 

This document describes procedures for building = point-to-multipoint service LSPs.  My background in this area is = not very deep.  I have read through the document and the = references in the security considerations section.   This guidance = seems good, however the document describes a lot of procedures and its = not obviously clear what part of the procedures are security = impacting.  Its not clear to me that this is a problem. =  

 

Thanks,

 

Joe

------=_NextPart_000_016F_01D03F28.AFEE5BE0-- From nobody Mon Feb 2 15:49:32 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077CF1A8823; Mon, 2 Feb 2015 15:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncd9RnkV0f3M; Mon, 2 Feb 2015 15:49:23 -0800 (PST) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946221A89FE; Mon, 2 Feb 2015 15:48:22 -0800 (PST) Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1YIQj5-0004qp-E3; Mon, 02 Feb 2015 16:48:19 -0700 Received: from [72.250.219.84] (helo=sylvester.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1YIQj4-0001qW-Aq; Mon, 02 Feb 2015 16:48:19 -0700 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id t12NmCem002008; Mon, 2 Feb 2015 16:48:12 -0700 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id t12NmCNI002007; Mon, 2 Feb 2015 16:48:12 -0700 Date: Mon, 2 Feb 2015 16:48:12 -0700 Message-Id: <201502022348.t12NmCNI002007@sylvester.rhmr.com> From: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org, draft-ietf-6man-enhanced-dad@tools.ietf.org X-XM-AID: U2FsdGVkX18/vrTRocqi2ULT9RAM/Rbi X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ********;iesg@ietf.org, secdir@ietf.org, draft-ietf-6man-enhanced-dad@tools.ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 440 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 2.6 (0.6%), b_tie_ro: 1.94 (0.4%), parse: 0.55 (0.1%), extract_message_metadata: 5.0 (1.1%), get_uri_detail_list: 1.76 (0.4%), tests_pri_-1000: 3.1 (0.7%), tests_pri_-950: 1.31 (0.3%), tests_pri_-900: 1.03 (0.2%), tests_pri_-400: 25 (5.7%), check_bayes: 24 (5.4%), b_tokenize: 6 (1.5%), b_tok_get_all: 11 (2.5%), b_comp_prob: 2.6 (0.6%), b_tok_touch_all: 1.80 (0.4%), b_finish: 0.62 (0.1%), tests_pri_0: 393 (89.3%), tests_pri_500: 6 (1.3%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Archived-At: Subject: [secdir] Security review of draft-ietf-6man-enhanced-dad-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 23:49:26 -0000 Security review of Enhanced Duplicate Address Detection draft-ietf-6man-enhanced-dad-12 Do not be alarmed ... 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. Enhanced DAD (duplicate address detection) is intended to help network administrators with some debugging and measurement functions by allowing IPv6 routers to detect that the network has been configured for loopback testing. Without this new feature, routers would treat the recurring messages (the looped-back messages) as evidence of an address duplication. Currently, such an error should result in disabling the interface until manual commands are entered. The goal is to define a simple and reliable way for routers to detect that loopback is in effect. During the loopback testing, the detection of duplicate addresses will not result in disabling the interface. The proposed detection method, as mentioned in the Security Considerations, results in a new kind of attack, one in which duplicate addresses are allowed because an attacker can easily imitate or disable the loopback messages. The authors believe that SEND and SAVI protect against these attacks. If these are not already in place, an administrator must ask if the benefits of loopback are worth the increased risk of operating, at least temporarily, without DAD. If not, then is it worth the trouble of adding additional protections? The document intends to describe an algorithm and a state machine, but it does not have the terse language and diagrams that one would expect to accompany the prose descriptions. It does not explicitly describe what constitutes loopback detection. There is a grammo in the following crucial sentence: If there is a collision because two nodes using the same Target Address in their NS(DAD) and generated the same random nonce, then the algorithm will incorrectly detect a looped back NS(DAD) when a genuine address collision has occurred. I think that the sentence can be repaired by changing "using" to "used". With that, we implicitly get the definition of loopback detection: seeing two NS(DAD) messages with the same Target Address and the same Nonce. There is also a time window for the detection. The document refers to the normal (non-loopback) case of duplicate address detection as leading to the "DAD failed state". This term occurs almost nowhere else in the world. It may be the case that an interface in a failed state is not usually further qualified by the cause; maybe this draft should avoid the term. "Disabled because of DAD" perhaps? In section 5, I am confused by this statement: Any other network that follows the same trust model MAY use the automated actions proposed in this section. The problem is that as nearly as I can tell, there is only one such action in the section, the one in the immediately preceding sentence. It seems to me that the time interval for detection might be usefully replaced by a message count. This is because the probability of a nonce collision is the defining security metric, and that will depend on the size of the nonce space and the number of messages in the possible collision window. The minimum nonce size is 48 bits, a collision would be expected once in 16 million messages. I suppose that might happen on a very busy network with a small address space. Hilarie From nobody Mon Feb 2 16:18:05 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DE51A8845; Mon, 2 Feb 2015 16:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boTgFehBcnyi; Mon, 2 Feb 2015 16:18:00 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 264991A8856; Mon, 2 Feb 2015 16:17:53 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C03E010224008; Mon, 2 Feb 2015 16:17:52 -0800 (PST) Received: from 104.36.248.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 2 Feb 2015 16:17:52 -0800 (PST) Message-ID: In-Reply-To: <54CFC20E.9000701@isi.edu> References: <950ad656ed2a0e36e24fd7dc0e2b60b1.squirrel@www.trepanning.net> <54CFC20E.9000701@isi.edu> Date: Mon, 2 Feb 2015 16:17:52 -0800 (PST) From: "Dan Harkins" To: "Joe Touch" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: draft-ietf-tsvwg-port-use.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-port-use X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 00:18:02 -0000 Hi Joe, On Mon, February 2, 2015 10:29 am, Joe Touch wrote: > Hi, Dan, > > It should be easy to add DTLS where TLS is cited. IPsec is an > interesting issue; I can add a few sentences to the security > considerations area about that - e.g., that IPsec protects in a > different way than TLS/DTLS, and that one key aspect of its > configuration is port-specific parameters, which means it may be > difficult to use separate IPsec policies on different services unless > their port numbers are known and fixed in advance (even if using dynamic > port numbers). There's also the issue that even if it uses fixed ports the app has no assurance that IPsec will even be protecting it. From the app's perspective it's basically write-and-pray. > That latter is probably 2-3 short sentences, and I think would be > worthwhile. That would be great and would address my comment. regards, Dan. > Joe > > On 1/30/2015 4:04 PM, Dan Harkins 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. >> >> This draft provides some advice and recommendations on protocol >> port use to application and service designers. It has a nice, brief >> history of port usage and a nice list of guiding principles to help >> conserve port space. It will make a nice BCP. In my opinion it is Ready >> For Publication. With that said, I do have a small comment. In section >> 7.4 the draft says that TLS should be used to protect services that do >> not provide their own security directly. It might be worth while adding >> mention of DTLS and IPsec. And if the latter is not something that >> should be recommended then justification for that stance should be >> given. >> >> regards, >> >> Dan. >> > From nobody Mon Feb 2 16:55:59 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEB51A1ADD; Mon, 2 Feb 2015 16:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8djU-onTGbUf; Mon, 2 Feb 2015 16:55:56 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D88DF1A07BE; Mon, 2 Feb 2015 16:55:56 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id t130tQGX025170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Feb 2015 16:55:26 -0800 (PST) Message-ID: <54D01C7D.3070009@isi.edu> Date: Mon, 02 Feb 2015 16:55:25 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Dan Harkins References: <950ad656ed2a0e36e24fd7dc0e2b60b1.squirrel@www.trepanning.net> <54CFC20E.9000701@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: draft-ietf-tsvwg-port-use.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-port-use X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 00:55:58 -0000 On 2/2/2015 4:17 PM, Dan Harkins wrote: > > Hi Joe, > > On Mon, February 2, 2015 10:29 am, Joe Touch wrote: >> Hi, Dan, >> >> It should be easy to add DTLS where TLS is cited. IPsec is an >> interesting issue; I can add a few sentences to the security >> considerations area about that - e.g., that IPsec protects in a >> different way than TLS/DTLS, and that one key aspect of its >> configuration is port-specific parameters, which means it may be >> difficult to use separate IPsec policies on different services unless >> their port numbers are known and fixed in advance (even if using dynamic >> port numbers). > > There's also the issue that even if it uses fixed ports the app has > no assurance that IPsec will even be protecting it. From the app's > perspective it's basically write-and-pray. Yes, thanks for pointing that out. I'll add that too. > >> That latter is probably 2-3 short sentences, and I think would be >> worthwhile. > > That would be great and would address my comment. AOK - thanks again! Joe > > regards, > > Dan. > >> Joe >> >> On 1/30/2015 4:04 PM, Dan Harkins 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. >>> >>> This draft provides some advice and recommendations on protocol >>> port use to application and service designers. It has a nice, brief >>> history of port usage and a nice list of guiding principles to help >>> conserve port space. It will make a nice BCP. In my opinion it is Ready >>> For Publication. With that said, I do have a small comment. In section >>> 7.4 the draft says that TLS should be used to protect services that do >>> not provide their own security directly. It might be worth while adding >>> mention of DTLS and IPsec. And if the latter is not something that >>> should be recommended then justification for that stance should be >>> given. >>> >>> regards, >>> >>> Dan. >>> >> > From nobody Tue Feb 3 09:44:53 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21A81A6FE6; Tue, 3 Feb 2015 09:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.312 X-Spam-Level: X-Spam-Status: No, score=-10.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IClxeQTBGYk; Tue, 3 Feb 2015 09:44:29 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F3F1A1BFF; Tue, 3 Feb 2015 09:43:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5924; q=dns/txt; s=iport; t=1422985405; x=1424195005; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ieu/EZ/Lfus6b0cEFP3sUU54q6xzrCS0kzNgw2GluDg=; b=aIu7/XGfJipZOS8kSXW8TV7U4snpS2h2gMexl6+xfhGpAUzLb3cnpX1T 1OfW/zVwx4gPMkdcd292Ps+82ZykGTIbwMZMWsLiZCwqbIspeETzM7AvP o/vAnYVWt2yP0MWZe+OXdVAZ9F5iBzs3QpjFRN8IzGl0cR4QUOGAgTaH6 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BABQA/CNFU/4ENJK1RBgODBlJZBMUFhXECgR5DAQEBAQF9hAwBAQEDAXkFCwIBCBIGLjIXDgIEDgUbBIgGCA3XHAEBAQEBAQEBAQEBAQEBAQEBAQEBARePFgcDBwEdIxAHEYMFgRMFjwyDToVYgU2REiKBfYFxb4ECCRcifgEBAQ X-IronPort-AV: E=Sophos;i="5.09,514,1418083200"; d="scan'208";a="120111059" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP; 03 Feb 2015 17:43:24 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t13HhO7W019083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 17:43:24 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.248]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 11:43:24 -0600 From: "Brian Weis (bew)" To: Alan DeKok Thread-Topic: [secdir] Secdir review of draft-ietf-radext-dynamic-discovery-12 Thread-Index: AQHQP9jo/4E4W9eQfUWTlaJGLxs9hA== Date: Tue, 3 Feb 2015 17:43:23 +0000 Message-ID: <2B42564B-1BC8-437D-AACD-69785A90A795@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.211] Content-Type: text/plain; charset="Windows-1252" Content-ID: <009BCE590706FB448D94B05E2152CFD0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: The IESG , "draft-ietf-radext-dynamic-discovery.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-radext-dynamic-discovery-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 17:44:38 -0000 Hi Alan, The clarification below was very useful. Perhaps the authors will find it = valuable to include the references you mentioned, and clarify that there is= expected to be a limited number of trusted (preferably one) trusted to iss= ue certificates for the consortium use case. Thanks, Brian On Jan 4, 2015, at 8:48 PM, Alan DeKok wrote: > On Dec 24, 2014, at 4:05 PM, Brian Weis wrote: >=20 > I=92m not the document author, but I can help give some clarification. >=20 >> There=92s not much background given, and having an overview of the solut= ion architecture in the Introduction would be useful. I.e., a description a= nd picture showing the actors and the communication flows between them. >=20 > The current roaming behaviour is discussed in the NAI document, Section = 3. Unfortunately, it also assumes some familiarity with the field. >=20 > http://tools.ietf.org/html/draft-ietf-radext-nai-15#section-3 >=20 > Perhaps the simplest explanation is that RADIUS is client-server. Clien= ts request authentication on behalf of users, and servers authenticate the = users. The key thing is that historically, proxying has been static, and p= rovisioning of proxy configuration has been entirely outside of the protoco= l. i.e. proxies operate by consensus and habit, not by standard behaviour. >=20 > A long description of the Eduroam consortium is available as an individu= al draft: >=20 > http://tools.ietf.org/html/draft-wierenga-ietf-eduroam-04 >=20 > However, *commercial* proxies do not operate in the eduroam model. Comm= ercial proxies are largely =93star=94 configurations. An interconnect comp= any sits at the centre of a star. It may connect to one or more other inte= rconnect providers. Routes are largely static, and are usually updated by = hand, after legal contracts have been exchanged. >=20 > This document is standardizing provisioning of RADIUS proxying, via dyna= mic methods. >=20 >> I don=92t have complete confidence that I correctly understood which act= ors are involved in the RASIUS/TLS transaction -- in some sections it seems= that RADIUS clients are initiating requests and sometimes RADIUS servers a= nd I thought only clients contacted servers. An overview of the actors woul= d probably have clarified that. >=20 > Clients are the only ones initiating requests. In some cases, the syste= m running RADIUS can behave as a client or as a server, depending on it=92s= needs. That makes it more complicated. >=20 >> If I understand correctly how roaming consortiums currently work today, = a RADIUS client within a consortium needing to make a AAA call to a RADIUS = server in another realm does not contact the server directly. >=20 > s/does not/may not/ >=20 >> Instead, it routes the request through a hierarchy of RADIUS servers fol= lowing roots of trust. >=20 > That=92s how eduroam works. Commercial proxies are configured different= ly. >=20 > However, they both operate on a =93fire and forget=94 model. A RADIUS s= erver which wants to proxy a request somehow (magically, almost) determines= which upstream server to use. The =93magic=94 part of that process is wha= t the dynamic discovery document is trying to standardize. >=20 >> Section 2.1.1.3 discusses the use of TLS cipher suites, and makes the po= int that certificate based cipher suites need to be used because there won= =92t be any pre-distributed secret key material available. That=92s good ad= vice. I think the section should also give advice on choosing trust roots. = This is important because the identity of the server was gotten in an untru= sted manner (from unsecured DNS), and the certificate it presents contains = information used for authorization of a server (i.e., SubjectAltName). If = a RADIUS client were to accept a certificate signed by a wide range of trus= t roots (e.g, the set of roots used by browsers, where the trustability of = many CAs in the hierarchy is unknown) then the RADIUS client would be ill = advised to trust authorization information claims in the hierarchy. >=20 > Current RADIUS practice uses a limited set of CAs. Generally, only one.= This use-case is *very* different than that for browsers. This document = should make that clearer. Shipping a RADIUS server (or client) with a list= of pre-configured CAs is a *very bad* idea. RFC 6614 (RADIUS over TLS) sh= ould probably have had such statements. RFC 7360 (RADIUS over DTLS) has so= me related text which would be useful here: >=20 > https://tools.ietf.org/html/rfc7360 >=20 > Section 10.4: ... >=20 > Therefore, clients SHOULD NOT be pre-configured with a list of known > public CAs by the vendor or manufacturer. Instead, the clients > SHOULD start off with an empty CA list. The addition of a CA SHOULD > be done only when manually configured by an administrator. > This scenario is the opposite of web browsers, where they are pre- > configured with many known CAs. The goal there is security from > third-party observers, but also the ability to communicate with any > unknown site that presents a signed certificate. In contrast, the > goal of RADIUS/DTLS is both security from third-party observers and > the ability to communicate with only a small set of well-known > servers. >=20 >> On the other hand, if the trust roots were restricted to a set of highly= trusted trust roots maintained by the consortium, then the authorization i= nformation in the certificate would be trustable. This should be explained. >=20 > Generally there=92s only one root CA for a consortium. I=92m not sure w= hat the use-case would be for multiple root CAs. >=20 > Alan DeKok. >=20 --=20 Brian Weis Security, CSG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From nobody Tue Feb 3 20:50:24 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361561A1BF6 for ; Tue, 3 Feb 2015 20:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnz_mWBzY3Zd for ; Tue, 3 Feb 2015 20:50:16 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1628E1A1BEC for ; Tue, 3 Feb 2015 20:50:16 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id b13so48083101wgh.9 for ; Tue, 03 Feb 2015 20:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=oSgGm4DpaQeToTd7Ebybw5p6ktKkDL+bapdfm7SA38o=; b=05nubBfQQRTVUeVGMyRZEbQYZ1h39KJIGUppozgZPS52PdqwzZW2oLxDhXoTNyOsDN Xg76A1kR3RNlBASJdHMk3x9gusIDgnOu9JGKtOScipkrGa3O0l1Aa1+r9atqa1fYB40p NYEKJhJiu/pVDoNrUIrYL7mtSYTXJ9jk5/NbZMjAYosHG7kX+nRCIuXqTEE7Wl1J5nL3 gyDtYhcNu2xyUJoszLRwZTLgFVAp3DjSeCRz9GRMVyUb2J4BbbguT6/Wnm+5DqXNmBq2 P01Jzj0vNUxD5q1m08blZpd3G7pRay8sImHqaS6+/keHEVu6eEZ72QTHLPw+kgPaBjAN /1bQ== MIME-Version: 1.0 X-Received: by 10.180.23.36 with SMTP id j4mr250460wif.69.1423025414863; Tue, 03 Feb 2015 20:50:14 -0800 (PST) Received: by 10.180.189.139 with HTTP; Tue, 3 Feb 2015 20:50:14 -0800 (PST) Date: Tue, 3 Feb 2015 20:50:14 -0800 Message-ID: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= To: "secdir@ietf.org" , draft-farrresnickel-harassment@tools.ietf.org Content-Type: multipart/alternative; boundary=e89a8f83a0595bfec1050e3bec95 Archived-At: Subject: [secdir] Secdir review of draft-farrresnickel-harassment X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 04:50:17 -0000 --e89a8f83a0595bfec1050e3bec95 Content-Type: text/plain; charset=UTF-8 > 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 memo documents processes for the IETF to solve harassment situations. > As such, it has no protocol security implications. > -- Magnus --e89a8f83a0595bfec1050e3bec95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

This memo documen= ts processes for the IETF to solve harassment situations. As such, it has n= o protocol security implications.
=C2=A0
-- Magnus
--e89a8f83a0595bfec1050e3bec95-- From nobody Wed Feb 4 00:31:07 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBE81A6F3D; Wed, 4 Feb 2015 00:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SO0RZVmmZmRt; Wed, 4 Feb 2015 00:30:58 -0800 (PST) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A521D1A0163; Wed, 4 Feb 2015 00:30:56 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.204]) by smtp-cloud3.xs4all.net with ESMTP id o8Ws1p0024QBLo2018Ws1L; Wed, 04 Feb 2015 09:30:54 +0100 Received: from AMontpellier-654-1-194-252.w90-0.abo.wanadoo.fr ([90.0.97.252]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 04 Feb 2015 09:30:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 04 Feb 2015 09:30:52 +0100 From: peter van der Stok To: Steve.Hanna@infineon.com Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <7e9a24ab8a294586bc19f23673551c24@KLUSE610.infineon.com> <5e5cc9fe445de45d78bc05604a308da6@xs4all.nl> <75d052c652b043c88c3ecc3c469b6bcb@KLUSE610.infineon.com> <54AD33DA.5080006@gridmerge.com> Message-ID: X-Sender: stokcons@xs4all.nl (Tabl5Jkp7HN2c5eOKnXyQ6gOzTbMcQlF) User-Agent: XS4ALL Webmail Archived-At: Cc: robert.cragie@gridmerge.com, draft-ietf-roll-admin-local-policy.all@tools.ietf.org, iesg@ietf.org, consultancy@vanderstok.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-roll-admin-local-policy-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 08:31:01 -0000 Hi Steve, I have added a new section 4.3 and changed section 6. The text below. Does this text address your concerns? Greetings and thanks for your reaction, Peter 4.3. Encryption rules An incoming message protected at layer-2 MUST be subsequently re- protected at layer-2 at all outgoing interfaces. Incoming messages are integrity checked and optionally decrypted at the incoming interface at layer-2 using the keys and protection algorithm appropriate to the incoming interface's network and re-protected at the outgoing interface using the keys and protection algorithm appropriate to the outgoing interface's network. It may be necessary to assess the relative levels of protection on the respective interfaces and apply policy rules, for example to avoid downgrading security where one network has a lower level of security than another. An incoming MPL4 messages which is not protected at layer-2 MUST NOT be re-protected at layer-2 at all outgoing interfaces. 7. Security Considerations The security considerations of [I-D.ietf-roll-trickle-mcast] also apply to MPL4 routers. The sending of MPL4 messages by a malicious node can have unwanted consequences explained with the following example. It is not unusual for a wired (e.g. ethernet) link to be used between two floors or sections of an LLN, as radio propogation through re-inforced concrete is generally poor. The MPL4 zone can thus envelop mutiple routers, meshes and links. It is possible that a malicious node connects to a wired link, on which no MPL enabled nodes are foreseen. In this example configuration, the malicious node can send MPL4 messages to the MPL4 router interfaces. When nothing is done, the MPL4 routers will consequently distribute MPL4 messages from one mesh over the wired link to the next mesh, although the wired link was not expected to transport MPL4 messages. To understand the consequences of this unwanted behaviour, the following cases should be distinguished: o The source mesh uses layer-2 encryption. o The MPL4 router can be managed. The four possible combinations are discussed below: Layer-2 unsecured, Router unmanaged: In this case MPL4 messages are freely distributed over meshes and links which are interconnected by MPL4 routers within a zone. The MPL enabled (malicious) nodes can read all MPL4 messages and distribute MPL4 messages over a network limited by a zone. This situation can be acceptable for an isolated network, within a clearly defined space, where the connection of nodes can be tightly controlled. A completely wired LLN -- such as is seen in BACnet -- is an example of an unencrypted LLN which would be considered physically secure. Layer-2 secured, Router unmanaged: In this case MPL4 messages are freely distributed over meshes and links, which are interconnected by MPL4 routers within a zone. Following the rules of Section 4.3, the MPL4 enabled (malicious) nodes can not read the MPL4 messages and MPL4 messages sent by the malicious node are not accepted by other nodes. This situation is acceptable for a home network or managed network extending over precisely one zone, occupying a clearly defined physical space, where ease of installation is important. In such a network, the presence of the malicious node is not different from any other malicious node, which tries to send messages over layer-2 protected links. Because the network occupies exactly one zone, the MPL4 message distribution cannot be extended outside the network. Layer-2 unsecured, Router managed: In this case the distribution of MPL4 messages over MPL4 router interfaces can be limited to those interfaces, which a manager enabled for MPL and a set of multicast addresses. The malicious node cannot extend the distribution of MPL4 messages over unwanted interfaces. It is important that the handling of the interfaces by the manager is protected. However, MPL4 messages sent over the mesh can be interpreted by malicious nodes and malicious messages can be injected into the set of meshes and links which are connected by the MPL4 routers for which the manager enabled the interfaces. This situation can be practical for interconnected links and meshes, which are connected to a LAN over a limited period, for example during installation of the interconnected meshes and links. Layer-2 secured, Router managed: In this case the distribution of MPL4 messages over MPL4 router interfaces can be limited to those interfaces, which a manager enabled for MPL and a set of multicast addresses. Following the rules of Section 4.3, the malicious node cannot extend the distribution of MPL4 messages over unwanted interfaces and MPL4 messages sent by the malicious node are not accepted by other nodes. It is important that the handling of the interfaces by the manager is protected. The MPL enabled (malicious) nodes can not read the MPL4 messages and MPL4 messages sent by the malicious node are not accepted by other nodes. Dependent on the number of managed interfaces, the network can progressively pass from auto-configured to fully administratively controlled. Steve.Hanna@infineon.com schreef op 2015-01-14 23:08: > Rob, > > I have removed areas where we agree below and added new comments > marked with . > > Thanks, > > Steve > >>> After reading the document several times, I have concluded that > >>> section 3.2 contains the most important part of the document: an > >>> algorithm for automatically defining the boundaries of the > admin-local > >>> multicast scope using MPL. This section basically says that a > border > >>> router should periodically send an MPL message on all interfaces to > >>> the ALL_MPL_FORWARDERS multicast address with admin-local scope. It > >>> should also listen for such messages on all interfaces. If it > receives > >>> such a message, that interface should be marked as part of the > >>> admin-local scope. > >>> > >>> This algorithm seems problematic from a security standpoint. > Because > >>> any device on a network can send an MPL message to the > >>> ALL_MPL_FORWARDERS multicast address with admin-local scope, the > >>> boundaries of the admin-local multicast scope can be expanded by > >>> attackers fairly easily. > > I guess it depends what you mean by "fairly easily". An attacker > in > > this case would have interfaces on more than one network and would > have > > to be authenticated on all networks in question. The attack scenario > may > > be just to attach to one network and then forward into other > network(s) > > which would not originally be considered part of the admin-local scope > > > (which is I think what you are saying below) but it still has to > > authenticate to the network being attacked and obtain the relevant key > > > before its interface on that network can validly receive a MPL4 > > message. > > I don't see why the attacker would need to have interfaces on > > more than one network. See the ASCII art diagram below: > > H1 - R - H2 > > Border router R has two network interfaces. H1 and H2 are hosts > > connected to these interfaces. If both H1 and H2 send MPL4 messages > > and R has MPL4 enabled on those interfaces, R will put both networks > > into the same admin-local multicast scope. Am I wrong? > > > >>> Such manipulation may permit nodes that > >>> should be outside a particular administrative domain to join that > >>> domain and participate in receiving and sending multicast traffic > >>> within that domain. The implications of such an attack are not > clear > >>> to me because I am not familiar with the protocols and devices that > >>> use admin-local multicast scope. However, it seems likely that > >>> expanding the admin-local multicast scope will permit external > >>> attackers to more easily monitor multicast traffic that should be > >>> private and to inject multicast messages into a relatively trusted > >>> domain. > > Again, it has to have been authenticated to one or more networks > > and obtained the relevant key before it can do this. > >> > >> In the discussion with Joel, we came to the conclusion that we were > not > >> very clear with respect to the administrative zone specification. > >> We suggested to limit the mpl admin-local scope within one zone. > >> The text will be extended to include this extra limit on the > boundary of > >> admin-local-scope. > >> The extent of the scope does not specify anything about the contents > of > >> the MPL messages. > >> It is expected that MPL messages are encrypted depending on the > wanted > >> security level. > >> Monitoring by an attacker limits itself to counting messages, which > is > >> already possible on wireless links any way. > >> To inject messages, the attacker should know the keys necessary to > >> encrypt. > >> When messages are not encrypted they are already readable on the > >> wireless links, and the monitoring by extending the mpl-admin-local > >> scope does not increase the vulnerability to snooping the messages. > >> > >> > >> Please send me a copy of your new text limiting the admin-local > scope > >> to one zone. I don't see how this will help but maybe the new text > will > >> make it clear. > >> > >> You just stated that "It is expected that MPL messages are > encrypted". > >> However, this is never stated in > draft-ietf-roll-trickle-mcast-11.txt or in > >> draft-ietf-roll-admin-local-policy-02.txt. In fact, there's no > mention of > >> encryption in those documents at all. If the security of your design > >> depends on this encryption, you'd better talk about it somewhere! > >> > >> Now I'd like to investigate the security provided by this > encryption. > >> Are you expecting that application-layer encryption will be used? > >> I suppose not because that would require extensive description > >> And you provided none. Probably you're thinking about link-layer > >> encryption such as that provided by IEEE 802.11i. However, I don't > >> think that such encryption will prevent the attacks that I > described. > >> > >> A border router frequently spans networks that are part of multiple > >> administrative domains. Your current design (even with link > encryption) > >> means that any device connected to any of these networks can dictate > >> the boundaries of the admin-local scope. Is it really desirable to > trust > >> all those devices to that extent? I think not. > >> > > > > The concept of scope, network boundary and security boundary are all > > somewhat orthogonal. RFC7346 acknowledges this with additional text > and > > draft-ietf-roll-admin-local-policy explains how automatic > configuration > > for realm-local scope occurs in relation to a network identifier, > which > > then links network boundary and realm-local scope. However, there > isn't > > necessarily a one-to-one correspondence between security boundary and > > network boundary even though it often happens in practice, e.g. a WPA2 > > > key for an 802.11 WLAN or network key for ZigBee IP WPAN, for example. > > > Assuming this link-layer encryption, I don't think the attacks can > take > > place as an attacker would have to authenticate itself to the network > > being attacked first or else it would not be able to validly received > > the MPL4 message. > > It is true that a border router configured with multiple MPL-enabled > > interfaces does indeed by implication expand the admin-local scope, > > however it is not obliged to have all its interfaces MPL-enabled; this > > > is part of configuration as well, potentially controllable by some > > superordinate entity. > > Perhaps we need some extra text to explain this. > > > > > > Certainly, if extending the admin-local scope has no security > > implications, there's no security problem here. However, that > > is probably not a universal understanding. You should explain > > this issue in the Security Considerations section and describe > > the circumstances when it is a problem and when it is not. > > This will equip the reader to decide what to do. Just because > > a host has the keys needed to join one network does not > > mean that they should be permitted to change the admin-local > > scope boundaries between that network and all other networks > > joined via border routers. > > From nobody Wed Feb 4 02:40:20 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6F01A1B3E; Tue, 3 Feb 2015 11:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSIl-NXEVr-0; Tue, 3 Feb 2015 11:27:25 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F28A1A87A9; Tue, 3 Feb 2015 11:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4126; q=dns/txt; s=iport; t=1422991644; x=1424201244; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=OGkGmz0Fcg6b+VB5k15QygKVgy/kM+4jx1SdZ7InDyQ=; b=YV3R7oJGy6ykUu5AMiFoDL1D1izQJhF0Kmi6ET8sUqQVvgyxrdpvgvJJ BVMAhsYShsySmQBPRcjffn+EMj8QjgXDRpfZqUmvlTsQqVYfR9brYH8In AcyZz10zzu2QJ+FPWlUPX0ciHaFXh2CC20klTzy7/16B+TzPKBOl6wBo7 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A+BQC9INFU/5xdJa1aDoJ4gSsEyncCgR5DAQEBAQF9hAwBAQEEOksEAgEIDgMEAQELFAkHMhQJCAIEARIIiCXXAgEBAQEBAQEBAQEBAQEBAQEBAQEBGI9HOAaDEIETBY0pgWOKPYMDiwiDPSKBfYE0PW+BAiQefgEBAQ X-IronPort-AV: E=Sophos;i="5.09,514,1418083200"; d="scan'208";a="120148288" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP; 03 Feb 2015 19:27:23 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t13JRNtW007816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 19:27:23 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.166]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 13:27:23 -0600 From: "Hemant Singh (shemant)" To: Hilarie Orman , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-6man-enhanced-dad@tools.ietf.org" Thread-Topic: Security review of draft-ietf-6man-enhanced-dad-12 Thread-Index: AQHQP0LsE7zTJW6wuUm13YvZwTWf/pzfUA+g Date: Tue, 3 Feb 2015 19:27:22 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B891568ABA5@xmb-rcd-x06.cisco.com> References: <201502022348.t12NmCNI002007@sylvester.rhmr.com> In-Reply-To: <201502022348.t12NmCNI002007@sylvester.rhmr.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.71.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 04 Feb 2015 02:40:19 -0800 Subject: Re: [secdir] Security review of draft-ietf-6man-enhanced-dad-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 19:27:27 -0000 Hilarie, Thanks for the review. We are looking into your comments. Please stay tuned. Hemant -----Original Message----- From: Hilarie Orman [mailto:ho@alum.mit.edu]=20 Sent: Monday, February 02, 2015 6:48 PM To: iesg@ietf.org; secdir@ietf.org; draft-ietf-6man-enhanced-dad@tools.ietf= .org Subject: Security review of draft-ietf-6man-enhanced-dad-12 Security review of Enhanced Duplicate Address Detection draft-ietf-6man-enhanced-dad-12 Do not be alarmed ... 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. Enhanced DAD (duplicate address detection) is intended to help network admi= nistrators with some debugging and measurement functions by allowing IPv6 r= outers to detect that the network has been configured for loopback testing.= Without this new feature, routers would treat the recurring messages (the= looped-back messages) as evidence of an address duplication. Currently, s= uch an error should result in disabling the interface until manual commands= are entered. The goal is to define a simple and reliable way for routers to detect that = loopback is in effect. During the loopback testing, the detection of dupli= cate addresses will not result in disabling the interface. The proposed detection method, as mentioned in the Security Considerations,= results in a new kind of attack, one in which duplicate addresses are allo= wed because an attacker can easily imitate or disable the loopback messages= . The authors believe that SEND and SAVI protect against these attacks. I= f these are not already in place, an administrator must ask if the benefits= of loopback are worth the increased risk of operating, at least temporaril= y, without DAD. If not, then is it worth the trouble of adding additional = protections? The document intends to describe an algorithm and a state machine, but it d= oes not have the terse language and diagrams that one would expect to accom= pany the prose descriptions. It does not explicitly describe what constitu= tes loopback detection. There is a grammo in the following crucial sentence: If there is a collision because two nodes using the same Target Address in their NS(DAD) and generated the same random nonce, then the algorithm will incorrectly detect a looped back NS(DAD) when a genuine address collision has occurred.=20 I think that the sentence can be repaired by changing "using" to "used". W= ith that, we implicitly get the definition of loopback detection: seeing two NS(DAD) messages with the same Target Address and the= same Nonce. There is also a time window for the detection. The document refers to the normal (non-loopback) case of duplicate address = detection as leading to the "DAD failed state". This term occurs almost no= where else in the world. It may be the case that an interface in a failed = state is not usually further qualified by the cause; maybe this draft shoul= d avoid the term. "Disabled because of DAD" perhaps? In section 5, I am confused by this statement: Any other network that follows the same trust model MAY use the automated actions proposed in this section. The problem is that as nearly as I can tell, there is only one such action = in the section, the one in the immediately preceding sentence. It seems to me that the time interval for detection might be usefully repla= ced by a message count. This is because the probability of a nonce collisi= on is the defining security metric, and that will depend on the size of the= nonce space and the number of messages in the possible collision window. = The minimum nonce size is 48 bits, a collision would be expected once in 16= million messages. I suppose that might happen on a very busy network with= a small address space. Hilarie From nobody Wed Feb 4 16:21:50 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A941A00E5; Wed, 4 Feb 2015 16:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2q0D8vAX9rf; Wed, 4 Feb 2015 16:21:36 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0611A00CD; Wed, 4 Feb 2015 16:21:36 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id pv20so4584525lab.7; Wed, 04 Feb 2015 16:21:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=J+L9Rb/FB7nrjKYqbuJRuQxlEK/9Zz8YT/kWndLxaA8=; b=tmmCIim/5T+U/DL9eg2AmAM08yK3tItCz7HGM9SyVeuUBtYHhTTvDLZhZZEO1diUEB hSrsBF7pKVMBSuvby6je7YnamTGXk5fNoSJiYts3uZS8ljXRSg5E93zdYVe3iNDqwZTU 07G+BOMCBocsa5eHlhsBO9Ok1BhJS80R2jhoPqcuz/TJdagJnvqYELz8qCQUhMUDNZcL zH/MH2Lwau6atR5ZKm0V75DMi1HNGGXf4DBySlHoSM0QWxZjBOXalQExbRilqk1U1+hV +lUHPOxRjs+6ftC9kV5KBXQidWNFCho3E3v8gXLStZ7yCXZjCj7YOsyzuCs6gLYDLZfS 6RWA== MIME-Version: 1.0 X-Received: by 10.112.118.144 with SMTP id km16mr794424lbb.75.1423095694828; Wed, 04 Feb 2015 16:21:34 -0800 (PST) Received: by 10.112.167.134 with HTTP; Wed, 4 Feb 2015 16:21:34 -0800 (PST) In-Reply-To: <000001d03566$6ec169d0$4c443d70$@olddog.co.uk> References: <000001d03566$6ec169d0$4c443d70$@olddog.co.uk> Date: Wed, 4 Feb 2015 19:21:34 -0500 Message-ID: From: Kathleen Moriarty To: "adrian@olddog.co.uk" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "iesg@ietf.org" , draft-ietf-l2vpn-pbb-evpn.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-l2vpn-pbb-evpn-09 (resend) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 00:21:44 -0000 Thanks, Adrian for resending and Catherine for the helpful review. On Wed, Jan 21, 2015 at 5:38 AM, Adrian Farrel wrote: > Again, re-sending with fixed subject line for people who auto-file. > > > > > > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Catherine Meadows > Sent: 20 January 2015 21:49 > To: secdir@ietf.org; iesg@ietf.org; > draft-ietf-l2vpn-pbb-evpn.all@tools.ietf.org > Cc: Catherine Meadows > Subject: secdir review of draft-ietf-12vpn-pbb-evpn-09 (resend) > > > > I messed up the authors=E2=80=99 address when I sent this review last wee= k, so I=E2=80=99m > > trying again. > > > > Cathy > > > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This draft describes a method for integrating Ethernet Provider Backbone > Bridge (PBB) with Ethernet VPN (EVPN) to > improve the delivery of MAC addresses, in particular with respect to > scalability. > > I don=E2=80=99t see any security concerns with this draft, but I do have = some > comments on the Security Considerations section. > It is very short, and all it says that the security considerations in the > EVPN draft apply directly to this draft. I assume that > it is also the case that this draft introduces no new security > considerations. If so, you should say so, and you should > also say why. Also, I was wondering if the mechanisms introduced in this > draft, by introducing a greater degree of organization > in the delivery of MAC addresses, makes it easier to detect duplicated MA= Cs, > which were mentioned as a security risk in the > Security Considerations of the EVPN draft. If this is the case, it would= be > a good thing to mention here. Keying off of Adrian's question in his discuss, I think what Catherine is asking here (please correct me if I am wrong), is to know if the risk in the EVPN draft of duplicated MACs is mitigated with this draft since MACs are aggregated (better organized and duplicates removed). If so, should that be mentioned? The solution advantages section (10.1, 10.2, and 10.3 specifically) talks about the aggregation, but is there a security advantage too? 10.5 sounds as if you might get more granularity for forwarding policies as well. > > I=E2=80=99d consider the draft somewhere between ready with nits and read= y with > issues. I don=E2=80=99t see any real security issues > here, just a Security Considerations section that needs to be expanded a > little, but this seems to be a little more than what the > secdir guidelines would call a nit. If none of those apply and change anything from the referenced section, the simple statement that no additional security considerations are added could be helpful. Thank you, Kathleen > > > > Catherine Meadows > Naval Research Laboratory > Code 5543 > 4555 Overlook Ave., S.W. > Washington DC, 20375 > phone: 202-767-3490 > fax: 202-404-7942 > email: catherine.meadows@nrl.navy.mil > > --=20 Best regards, Kathleen From nobody Thu Feb 5 02:43:48 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F751A1B07 for ; Thu, 5 Feb 2015 02:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kz0ZIgRGUqOK for ; Thu, 5 Feb 2015 02:43:45 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BDF1A1B0B for ; Thu, 5 Feb 2015 02:43:44 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t15AhgfC003150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 5 Feb 2015 12:43:42 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t15AhgsZ029130; Thu, 5 Feb 2015 12:43:42 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21715.18782.289433.147612@fireball.kivinen.iki.fi> Date: Thu, 5 Feb 2015 12:43:42 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2015 10:43:46 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Donald Eastlake is next in the rotation. For telechat 2015-02-05 Reviewer LC end Draft Dorothy Gellert T 2014-12-22 draft-ietf-ippm-rate-problem-09 Tobias Gondrom T 2014-12-18 draft-ietf-mpls-ldp-ipv6-15 Jeffrey Hutzelman T 2015-01-22 draft-ietf-drinks-spp-protocol-over-soap-07 Sam Weiler T 2014-12-08 draft-ietf-l3vpn-acceptown-community-09 For telechat 2015-02-19 Shaun Cooley T 2015-02-13 draft-ietf-sidr-as-migration-03 Alexey Melnikov T 2015-01-14 draft-ietf-opsawg-coman-probstate-reqs-04 Takeshi Takahashi T 2015-02-17 draft-ietf-calext-rscale-03 Sean Turner T 2015-02-06 draft-ietf-mif-mpvd-arch-09 David Waltermire T 2015-02-10 draft-ietf-uta-tls-bcp-08 Paul Wouters T 2015-02-13 draft-ietf-idr-as-migration-03 For telechat 2015-03-05 Melinda Shore T 2015-02-24 draft-faltstrom-uri-10 Klaas Wierenga T 2015-02-18 draft-ietf-cdni-logging-15 Last calls and special requests: Derek Atkins 2015-02-17 draft-ietf-payload-rtp-opus-07 Dave Cridland 2015-02-18 draft-ietf-teas-lsp-attribute-ro-02 Alan DeKok 2015-02-18 draft-ietf-teas-rsvp-te-li-lb-03 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Jeffrey Hutzelman 2015-01-07 draft-ietf-dnssd-requirements-04 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Hannes Tschofenig 2015-02-09 draft-ietf-ippm-ipsec-08 Tina TSOU 2015-02-09 draft-ietf-kitten-gss-loop-04 Carl Wallace 2015-02-10 draft-ietf-netext-ani-location-07 Sam Weiler 2015-02-16 draft-ietf-6man-resilient-rs-04 Brian Weis 2015-02-18 draft-ietf-bess-orf-covering-prefixes-03 Paul Wouters 2014-12-04 draft-ietf-tcpm-accecn-reqs-07 Tom Yu 2015-02-12 draft-ietf-mpls-proxy-lsp-ping-03 Dacheng Zhang 2015-02-16 draft-ietf-nfsv4-lfs-registry-02 -- kivinen@iki.fi From nobody Thu Feb 5 10:21:18 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3C71A0AF1; Thu, 5 Feb 2015 10:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGOde0mcRc08; Thu, 5 Feb 2015 10:20:12 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D8A1A19F7; Thu, 5 Feb 2015 10:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5138; q=dns/txt; s=iport; t=1423160410; x=1424370010; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=m4uFlEDeJYKlWp+YEBSQdszkkYfu8LEmNbPHMHQe7Go=; b=YTHwVEc+lQGg2Teay9gDQhaUWmS0eBuZB2aP8B41jbxFyDPAjesV+ysS EQvB4esLgkK4BEogXXyIT60ke7bpMFVer7BOnVSI2XDRHZmbazomjjfZL 3Vm1Bf87HfW0Uux7hzqwLEhP2Kyl9x04N4Non0tHLfFayd22OWZhqgIqQ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAOGz01StJA2G/2dsb2JhbABaDoJ4gSsEyDsCgSdDAQEBAQF9hAwBAQEEOksGAQgOAwQBAQsUCTkUCQkBBAESCIgl1wsBAQEBAQEBAwEBAQEBAQEBGo9HPoMQgRMFjTWBY4pDgwOOUSKBfYE0PW+BAiQefgEBAQ X-IronPort-AV: E=Sophos;i="5.09,525,1418083200"; d="scan'208";a="393770916" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP; 05 Feb 2015 18:20:09 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t15IK9ST024176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Feb 2015 18:20:09 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.166]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Thu, 5 Feb 2015 12:20:08 -0600 From: "Hemant Singh (shemant)" To: Hilarie Orman , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-6man-enhanced-dad@tools.ietf.org" Thread-Topic: Security review of draft-ietf-6man-enhanced-dad-12 Thread-Index: AdBBcFoFMMircgorSuCR6l3hvDlnEw== Date: Thu, 5 Feb 2015 18:20:08 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B891568FC44@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.71.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Security review of draft-ietf-6man-enhanced-dad-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 18:20:25 -0000 X-List-Received-Date: Thu, 05 Feb 2015 18:20:25 -0000 Hilarie, Thanks for the review. Please see in line below. >-----Original Message----- >From: Hilarie Orman [mailto:ho@alum.mit.edu]=20 >Sent: Monday, February 02, 2015 6:48 PM >To: iesg@ietf.org; secdir@ietf.org; draft-ietf-6man-enhanced-dad@tools.iet= f.org >Subject: Security review of draft-ietf-6man-enhanced-dad-12 >Security review of Enhanced Duplicate Address Detection >draft-ietf-6man-enhanced-dad-12 >Do not be alarmed ... >I have reviewed this document as part of the security directorate's ongoin= g effort to review all IETF documents being processed by the IESG. These c= omments were written >primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments just like = any other last call comments. >Enhanced DAD (duplicate address detection) is intended to help network adm= inistrators with some debugging and measurement functions by allowing IPv6 = routers to detect >that the network has been configured for loopback testin= g. Without this new feature, routers would treat the recurring messages (t= he looped-back messages) as evidence of an >address duplication. Currently= , such an error should result in disabling the interface until manual comma= nds are entered. >The goal is to define a simple and reliable way for routers to detect that= loopback is in effect. During the loopback testing, the detection of dupl= icate addresses will not result in >disabling the interface. >The proposed detection method, as mentioned in the Security Considerations= , results in a new kind of attack, one in which duplicate addresses are all= owed because an attacker >can easily imitate or disable the loopback messag= es. The authors believe that SEND and SAVI protect against these attacks. = If these are not already in place, an administrator >must ask if the benef= its of loopback are worth the increased risk of operating, at least tempora= rily, without DAD. If not, then is it worth the trouble of adding addition= al >protections? Then the sending node, before initiating the deliberate Loopback circuit te= sting, can disable DAD on the interface. Any other protection is likely a = whole new RFC if SEND is not used.=20 >The document intends to describe an algorithm and a state machine, but it = does not have the terse language and diagrams that one would expect to acco= mpany the prose >descriptions. It does not explicitly describe what consti= tutes loopback detection. >There is a grammo in the following crucial sentence: >If there is a collision because two nodes using the same Target >Address in their NS(DAD) and generated the same random nonce, then >the algorithm will incorrectly detect a looped back NS(DAD) when a >genuine address collision has occurred.=20 >I think that the sentence can be repaired by changing "using" to "used". = With that, we implicitly get the definition of loopback >detection: seeing two NS(DAD) messages with the same Target Address and th= e same Nonce. There is also a time window for the detection. Will make the change. >The document refers to the normal (non-loopback) case of duplicate address= detection as leading to the "DAD failed state". =20 >This term occurs almost nowhere else in the world. =20 That is why "DAD-failed state" is defined in the Terminology section.=20 >It may be the case that an interface in a failed state is not usually furt= her qualified by the cause; maybe this draft should avoid the term. "Disab= led because of DAD" perhaps? It's not important what specific term is used and far as a term is defined.= =20 >In section 5, I am confused by this statement: >Any other network that follows the same trust model MAY use the >automated actions proposed in this section. >The problem is that as nearly as I can tell, there is only one such action= in the section, the one in the immediately preceding sentence. Ok, will replace all "actions" with "action". >it seems to me that the time interval for detection might be usefully repl= aced by a message count. This is because the probability of a nonce collis= ion is the defining security >metric, and that will depend on the size of t= he nonce space and the number of messages in the possible collision window.= The minimum nonce size is 48 bits, a collision would >be expected once in= 16 million messages. I suppose that might happen on a very busy network w= ith a small address space. We have used existing time intervals from RFC 4862 and RFC 4861. The time = interval is defined in RFC 4862 which says if a DAD probe is issued the sen= der waits for 2 seconds during which if no NA or the same DAD probe is rece= ived at the sender, the sender puts the Target Address to assigned state. = The Enhanced DAD algorithm uses time intervals defined in RFC 4861 which is= the RetransTimer waiting how long and stopping the probe. We acknowledge= the nonce collision and have addressed the issue in the 2nd paragraph of s= ection 4. =20 Regards, Hemant=20 From nobody Sun Feb 8 22:48:35 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF791A006D; Sun, 8 Feb 2015 22:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrZIVTUHEkQX; Sun, 8 Feb 2015 22:45:45 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB7831A0067; Sun, 8 Feb 2015 22:45:44 -0800 (PST) Received: from [192.168.10.149] ([193.83.169.152]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LwF9u-1XXqqg3LFW-0186YG; Mon, 09 Feb 2015 07:45:25 +0100 Message-ID: <54D85781.2080009@gmx.net> Date: Mon, 09 Feb 2015 07:45:21 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: secdir@ietf.org, "iesg@ietf.org >> The IESG" , draft-ietf-ippm-ipsec@tools.ietf.org OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="n4AuaxKIGd4uW5Ix6O2bsLMV3Ldnl5eUS" X-Provags-ID: V03:K0:kXxp17qCN3hNqDq0kkRWkny5DP9503qY1I+EFFXMkxyadEnCtjl Z/4xB144To4OSJ95QbOxNqDvlBoPzxBFlYMmg9IxYj0Xh3zlgGM9YpC6rdUMsw+RG41UjkK IT7xRnYNhxrV3rJtLWSEvdCqQoGE1CjkKpUT5Yu9izhE3ihE4HH3XTH40YObzm5yvhqn3Ge 7mk0g3E7cysjb5teKKlRg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [secdir] Security review of draft-ietf-ippm-ipsec-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 06:45:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --n4AuaxKIGd4uW5Ix6O2bsLMV3Ldnl5eUS Content-Type: text/plain; charset=utf-8 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 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: The specification proposes to derive keying material from an IKEv2 exchange to secure the One-way Active Measurement Protocol (OWAMP) [RFC4656] and the Two-Way Active Measurement Protocol (TWAMP) protocols. Introduction: In the introduction you point out that IKEv2 is very commonly deployed. You even say that "In mobile telecommunication networks, the deployment rate of IPsec exceeds 95% with respect to the LTE serving network." While the exact number is probably not that important (and very likely hard to verify) the statement does, however, raise some questions. You seem to expect that you can re-use already deployed IKEv2 for the special version of IKEv2 you are describing in this document and that's unfortunately very unlikely to be true. The solution described in the document requires a very tight integration between an IKEv2 implementation (not IPsec) and the O/TWAMP application and the text in the document gives me the impression that you are not entirely aware that this will actually need to happen. This may lead to unpleasant surprises when you implement it. First, you will have to trigger the IKEv2 exchange from the application. Second, you definitely do not want the IKEv2 exchange to create IPsec SAs since you only want the outcome of the exchange to produce the keying material as input to the O/TWAMP protocol via the already standardized pre-shared authentication exchange. Third, when the IKEv2 exchange is finished it needs to notify the application that the keying material is ready. The new key derivation function described in Section 5.1 is obviously not available in any IKEv2 implementation and, as you correctly stated, you don't want to make export the SK_d directly to the application but rather only the output of the derivation, namely prf( SK_d, "IPPM" ). IMHO no off-the-shelf IKEv2 implementation will let applications access the SK_d directly nor will it have an API to the IKEv2 SA either. It might also want to think about potential interactions from the IKEv2-> to O/TWAMP side, such as rekeying. I am not sure whether there are issues to take into account but have you thought about them? It might be wortwhile to talk to people who used IKEv2 in a way similar to what you are proposing (namely for not establishing IPsec SAs). While there may not be that many of such standardization development I remember that there was some work in the routing area. In Section 5.1 you describe a way to obtain for the O/TWAMP implementation to interact with the IKEv2 code as follows: " the IPSec layer can perform a lookup in the Security Association Database (SAD) using the IP address of the server and thus match the corresponding IKEv2 SA. At the server side, the IPSec layer can look up the corresponding IKEv2 SA by using the SPIs sent by the client, and therefore extract the shared secret " I believe that this approach will not work since your use of IKEv2 shouldn't actually require any interaction with IPsec at all. A small note on the use of shared secrets. It seems that you have the impression that the shared secrets used in the O/TWAMP protocol have to be manually configured. This may not necessarily be true if you want to use them in cellular networks, as you describe. I could imagine that a network management protocol could be used to provision the shared secrets to the appropriate nodes. While public key cryptography makes some aspects of the key distribution easier it does raise other questions, such as distribution of trust anchors and the question about authorization. Since you do not discuss authorization in the document I am not sure it is of concern with the use of O/TWAMP. I am not sure why you include the text in Section 5.4 where you describe O/TWAMP over an IPsec tunnel since in the introduction you argue that this is not an approach that you favour since it introduces delays into the measurements. I am also wondering whether this solution offers crypto agility. The text describes that you use AES-CBC (for encryption) and HMAC-SHA1 (for data origin authentication and integrity protection). IKEv2 could, of course, allow you to negotiate other algorithms and particularly the more modern AEAD ciphers. In a few parts of the document you say " The new Modes value indicating support for this specification is IKEv2Derived and is equal to 128 (i.e. bit set in position 7) [NOTE to IANA: remove before allocation and final publication]". I am not sure what you are asking IANA to do. I believe what you are trying to say is that you have proposed a specific value for this extension and you want IANA to confirm that allocation. If IANA cannot give you that value they should correct the text in the draft and put the appropriate value there. If that's the case then the correct way to write this is as follows: " The new Modes value indicating support for this specification is IKEv2Derived and is TBD." In the IANA consideration section you then note that all TBDs have to be replaced with the value allocated by IANA. I would also remove this paragraph in the Security Consideration section:= " As a more general note, the IPPM community may want to revisit the arguments listed in [RFC4656], Sec. 6.6. Other widely-used Internet security mechanisms, such as TLS and DTLS, may also be considered for future use over and above of what is already specified in [RFC4656] [RFC5357]. " While it is true that DTLS/TLS could also used (and are probably a better choice) it feels like the wrong statement in this document. It makes the reader feel like that even the authors are not convinced that this is the right solution approach. Ciao Hannes --n4AuaxKIGd4uW5Ix6O2bsLMV3Ldnl5eUS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU2FeBAAoJEGhJURNOOiAtxEkIAKQU+fYrFYTcCOL5Ptr2hq1T a60+ce/xAVKb07fv+nTzgFT5bUkYbhcuI7St4qYzYTlqtEOywKwDmk9kNR/m0+sN 88Tni4dujLn/JQLgjfNFhPc0acvtMc4y/dOHm74p8GcKlveILwWSsvDbiLbGhayh zVZjt9lx+mkjYkcgnN0ZgGb/j0wtsWJbSVOsissD4bUN7DBVeFfGBr9T1VTv9/W3 Z75jt0h9YMad/jgs1V8NFgp1KqjoOVh+2y5RWSbycyzdlTd4FuFvyZPAA0BIJUVA KYz/bdl8tHMI+SyGAG9JIH6HtmuOGvbXWj5Ugz8v/R97KFdPvqaoOlEbJaHbbKA= =2xct -----END PGP SIGNATURE----- --n4AuaxKIGd4uW5Ix6O2bsLMV3Ldnl5eUS-- From nobody Mon Feb 9 17:55:43 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04D21A8ACC; Mon, 9 Feb 2015 17:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zPnh0WdSvvE; Mon, 9 Feb 2015 17:55:26 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0101.outbound.protection.outlook.com [207.46.100.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4361A01F0; Mon, 9 Feb 2015 17:55:26 -0800 (PST) Received: from DM2PR09MB0224.namprd09.prod.outlook.com (25.160.92.146) by DM2PR09MB0222.namprd09.prod.outlook.com (25.160.92.144) with Microsoft SMTP Server (TLS) id 15.1.81.19; Tue, 10 Feb 2015 01:55:25 +0000 Received: from DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) by DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) with mapi id 15.01.0081.018; Tue, 10 Feb 2015 01:55:25 +0000 From: "Waltermire, David A." To: "iesg@ietf.org" , "'secdir@ietf.org'" , "draft-ietf-uta-tls-bcp.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-uta-tls-bcp-08 Thread-Index: AdBE0QRTgwoPUN/4SsGTOM7zzTmiBA== Date: Tue, 10 Feb 2015 01:55:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.227.107] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0222; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0222; x-forefront-prvs: 048396AFA0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2900100001)(229853001)(107886001)(19300405004)(76576001)(16236675004)(122556002)(46102003)(92566002)(40100003)(74316001)(66066001)(15975445007)(54356999)(33656002)(50986999)(102836002)(19580395003)(19625215002)(561944003)(99286002)(2656002)(86362001)(230783001)(87936001)(77156002)(2501002)(62966003)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0222; H:DM2PR09MB0224.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_DM2PR09MB02247B391BD2A86482C949E0F0240DM2PR09MB0224namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2015 01:55:24.8126 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0222 Archived-At: Subject: [secdir] secdir review of draft-ietf-uta-tls-bcp-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 01:55:30 -0000 --_000_DM2PR09MB02247B391BD2A86482C949E0F0240DM2PR09MB0224namp_ Content-Type: text/plain; charset="us-ascii" 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 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: This proposed BCP outlines a number of security issues related to = use of various revisions of TLS and DTLS. It details a number of attacks ag= ainst various versions of TLS, cipher suites, and modes of operation; and p= rovides recommendations to avoid these attacks in a way that is applicable = to the majority of use cases for these protocols. This document is generally well-written and clear in its content. I find th= is document to be ready with nits. My only nit is a minor ambiguity in the text in section 4.2.1. Two of the "= SHOULD" statements seem to be in conflict (#2 and #3) by my read: #1 Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the first proposal to any server, unless they have prior knowledge that the server cannot respond to a TLS 1.2 client_hello message #2 Servers SHOULD prefer this cipher suite whenever it is proposed, even if it is not the first proposal. #3 Clients are of course free to offer stronger cipher suites, e.g., using AES-256; when they do, the server SHOULD prefer the stronger cipher suite unless there are compelling reasons (e.g., seriously degraded performance) to choose otherwise. The way I read it, if statement #2 is honored, then statement #3 would not = be honored, even if the stronger cipher suite is ordered before the TLS_ECD= HE_RSA_WITH_AES_128_GCM_SHA256. I don't think this is the intent! It would be better to qualify statement #2 with regards to weaker cipher su= ites to avoid weaker proposals, while allowing stronger proposals. Sincerely, Dave Waltermire --_000_DM2PR09MB02247B391BD2A86482C949E0F0240DM2PR09MB0224namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the secu= rity directorate's ongoing effort to review all IETF documents being proces= sed by the IESG.  These comments were written primarily for the benefi= t of the security area directors.  Document editors and WG chairs should treat these comments just like any other last= call comments.

 

Summary: This proposed BCP outlines a number of secu= rity issues related to use of various revisions of TLS and DTLS. It details= a number of attacks against various versions of TLS, cipher suites, and mo= des of operation; and provides recommendations to avoid these attacks in a way that is applicable to the majority of use = cases for these protocols.

 

This document is generally well-written and clear in= its content. I find this document to be ready with nits.

 

My only nit is a minor ambiguity in the text in sect= ion 4.2.1. Two of the “SHOULD” statements seem to be in conflic= t (#2 and #3) by my read:

 

#1 Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the=

   first proposal to any server, unless they have prior know=
ledge that
   the server cannot respond to a TLS 1.2 client_hello messa=
ge

 

#2 Servers SHOULD prefer this cipher suite whenever it is = proposed, even

   if it is not the first proposal.

 

#3 Clients are of course free to offer stronger cipher sui= tes, e.g.,

   using AES-256; when they do, the server SHOUL= D prefer the stronger

   cipher suite unless there are compelling reas= ons (e.g., seriously

   degraded performance) to choose otherwise.

 

The way I read it, if statement #2 is honored, then = statement #3 would not be honored, even if the stronger cipher suite is ord= ered before the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. I don’t think = this is the intent!

 

It would be better to qualify statement #2 with rega= rds to weaker cipher suites to avoid weaker proposals, while allowing stron= ger proposals.

 

Sincerely,

Dave Waltermire

--_000_DM2PR09MB02247B391BD2A86482C949E0F0240DM2PR09MB0224namp_-- From nobody Tue Feb 10 06:48:51 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FD51A026A for ; Tue, 10 Feb 2015 06:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yurgEOAokVYR for ; Tue, 10 Feb 2015 06:19:48 -0800 (PST) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DB551A011D for ; Tue, 10 Feb 2015 06:19:48 -0800 (PST) Received: by iecrd18 with SMTP id rd18so12807286iec.8 for ; Tue, 10 Feb 2015 06:19:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HAy4t9poM0e1qFAXJHPMDWyrXc6J7hWycHY6lcsx8BI=; b=Y5iBDroSOWXfRsJX65qmA4+gz1yhuHH7QH2HyzOD3xa/+AVogbPT6W/WpAScO+jmOV AUMkfi0vH3WqhtjjR9OlqClRainAzMpVOu8MagzPp5jKNNn561J7uY9Jvp0dIovpEs7o 1yikn22QE5R2K87vFHxcFGObmUKnixebCfWMaWatKP+okmRixlCpzqXk0OVdwdAGXhCx Z+upecZf1WDK1FT8InASPxRPP4CrbrB6YKdOctw+mgDREjrZcFPq0qRWOKoeB/9hmXDL wS63kZdNmWh9dLBLXWU8z6smzGHTjmA4FgdCZjgvA2th+ndXnv2rf8AHD0Ebhyfo4V0c gYGg== X-Gm-Message-State: ALoCoQksvra5cdG1AwSe1L510bbSQZs9ZZU7hTOQ4dd1znxZKEl0EwiV35SU6V0uNFHDEhoyB/fS X-Received: by 10.50.124.133 with SMTP id mi5mr23686719igb.13.1423577987738; Tue, 10 Feb 2015 06:19:47 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id c70sm8655757ioc.3.2015.02.10.06.19.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Feb 2015 06:19:46 -0800 (PST) Message-ID: <54DA1382.4060905@andyet.net> Date: Tue, 10 Feb 2015 07:19:46 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Waltermire, David A." , "iesg@ietf.org" , "'secdir@ietf.org'" , "draft-ietf-uta-tls-bcp.all@tools.ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Tue, 10 Feb 2015 06:48:48 -0800 Subject: Re: [secdir] secdir review of draft-ietf-uta-tls-bcp-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 14:19:50 -0000 Hi Dave, thanks for the review. On 2/9/15 6:55 PM, Waltermire, David A. 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: This proposed BCP outlines a number of security issues related > to use of various revisions of TLS and DTLS. It details a number of > attacks against various versions of TLS, cipher suites, and modes of > operation; and provides recommendations to avoid these attacks in a way > that is applicable to the majority of use cases for these protocols. > > This document is generally well-written and clear in its content. I find > this document to be ready with nits. > > My only nit is a minor ambiguity in the text in section 4.2.1. Two of > the “SHOULD” statements seem to be in conflict (#2 and #3) by my read: > > #1 Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the > > first proposal to any server, unless they have prior knowledge that > > the server cannot respond to a TLS 1.2 client_hello message > > #2 Servers SHOULD prefer this cipher suite whenever it is proposed, even > > if it is not the first proposal. > > #3 Clients are of course free to offer stronger cipher suites, e.g., > > using AES-256; when they do, the server SHOULD prefer the stronger > > cipher suite unless there are compelling reasons (e.g., seriously > > degraded performance) to choose otherwise. > > The way I read it, if statement #2 is honored, then statement #3 would > not be honored, even if the stronger cipher suite is ordered before the > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. I don’t think this is the intent! > > It would be better to qualify statement #2 with regards to weaker cipher > suites to avoid weaker proposals, while allowing stronger proposals. That's a good catch. #2 needs say "Servers SHOULD prefer this cipher suite over weaker cipher suites..." We'll fix that in a revised I-D that we plan to submit tomorrow morning (after IETF LC ends). Peter From nobody Thu Feb 12 03:10:45 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699F51A8798 for ; Thu, 12 Feb 2015 03:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2xHoR-cQaJ5 for ; Thu, 12 Feb 2015 03:10:17 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31BE31A870D for ; Thu, 12 Feb 2015 03:10:17 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t1CBABVc027495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 12 Feb 2015 13:10:11 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t1CBA9Si015156; Thu, 12 Feb 2015 13:10:09 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21724.35345.280038.845940@fireball.kivinen.iki.fi> Date: Thu, 12 Feb 2015 13:10:09 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 2 min X-Total-Time: 1 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2015 11:10:20 -0000 [I am going to be on vacation next week, so most likely there will not be assignments done next Thursday]. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Tobias Gondrom is next in the rotation. For telechat 2015-02-19 Reviewer LC end Draft Shaun Cooley T 2015-02-13 draft-ietf-sidr-as-migration-03 Daniel Kahn Gillmor T 2015-02-19 draft-ietf-httpauth-basicauth-update-05 Jeffrey Hutzelman T 2015-01-22 draft-ietf-drinks-spp-protocol-over-soap-07 Alexey Melnikov T 2015-01-14 draft-ietf-opsawg-coman-probstate-reqs-04 Takeshi Takahashi T 2015-02-17 draft-ietf-calext-rscale-04 Tina TSOU T 2015-02-09 draft-ietf-kitten-gss-loop-04 Sean Turner T 2015-02-06 draft-ietf-mif-mpvd-arch-10 Paul Wouters T 2014-12-04 draft-ietf-tcpm-accecn-reqs-07 Paul Wouters T 2015-02-13 draft-ietf-idr-as-migration-03 Tom Yu T 2015-02-12 draft-ietf-mpls-proxy-lsp-ping-03 For telechat 2015-03-05 Melinda Shore T 2015-02-24 draft-faltstrom-uri-10 Carl Wallace T 2015-02-10 draft-ietf-netext-ani-location-08 Klaas Wierenga T 2015-02-18 draft-ietf-cdni-logging-15 Last calls and special requests: Derek Atkins 2015-02-17 draft-ietf-payload-rtp-opus-08 Dave Cridland 2015-02-18 draft-ietf-teas-lsp-attribute-ro-02 Alan DeKok 2015-02-18 draft-ietf-teas-rsvp-te-li-lb-03 Donald Eastlake 2015-02-20 draft-ietf-6tisch-tsch-05 Shawn Emery 2015-02-19 draft-ietf-ccamp-rwa-wson-encode-27 Dorothy Gellert 2015-02-23 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-01 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Jeffrey Hutzelman 2015-01-07 draft-ietf-dnssd-requirements-04 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Sam Weiler 2015-02-16 draft-ietf-6man-resilient-rs-04 Brian Weis 2015-02-18 draft-ietf-bess-orf-covering-prefixes-03 Dacheng Zhang 2015-02-16 draft-ietf-nfsv4-lfs-registry-02 -- kivinen@iki.fi From nobody Thu Feb 12 07:04:32 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969C41A1BFE; Thu, 12 Feb 2015 04:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ky6692AsJDDL; Thu, 12 Feb 2015 04:29:56 -0800 (PST) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF471A6EE1; Thu, 12 Feb 2015 04:29:43 -0800 (PST) Received: by mx2.eict.de (Postfix, from userid 481) id 3E48A1FF5E; Thu, 12 Feb 2015 13:29:42 +0100 (CET) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 255DB1FF5A; Thu, 12 Feb 2015 13:29:41 +0100 (CET) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id B1FBA3780A2; Thu, 12 Feb 2015 13:29:40 +0100 (CET) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Thu, 12 Feb 2015 13:29:40 +0100 From: Kostas Pentikousis To: Hannes Tschofenig , "secdir@ietf.org" , "iesg@ietf.org >> The IESG" , "draft-ietf-ippm-ipsec@tools.ietf.org" Date: Thu, 12 Feb 2015 13:29:39 +0100 Thread-Topic: [secdir] Security review of draft-ietf-ippm-ipsec-08 Thread-Index: AdBENBtbbWdDn4hIQZC8Xj0YCzLTqQCfLi8w Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEB5AB748D98@SBS2008.eict.local> References: <54D85781.2080009@gmx.net> In-Reply-To: <54D85781.2080009@gmx.net> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 12 Feb 2015 07:04:28 -0800 Subject: Re: [secdir] Security review of draft-ietf-ippm-ipsec-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 12:30:00 -0000 SGkgSGFubmVzLA0KDQo8c25pcD4NCg0KfCBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5 IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYQ0KfCBkaXJlY3RvcnMuICBEb2N1 bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1 c3QNCnwgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpNYW55IHRoYW5rcyBm b3IgdGhlIHRob3JvdWdoIHJldmlldy4gTXVjaCBhcHByZWNpYXRlZC4NCg0KPHNuaXA+DQoNCg0K fCBJbiB0aGUgaW50cm9kdWN0aW9uIHlvdSBwb2ludCBvdXQgdGhhdCBJS0V2MiBpcyB2ZXJ5IGNv bW1vbmx5IGRlcGxveWVkLg0KfCBZb3UgZXZlbiBzYXkgdGhhdCAiSW4gbW9iaWxlIHRlbGVjb21t dW5pY2F0aW9uIG5ldHdvcmtzLCB0aGUgZGVwbG95bWVudCByYXRlDQp8IG9mIElQc2VjIGV4Y2Vl ZHMgOTUlIHdpdGggcmVzcGVjdCB0byB0aGUgTFRFIHNlcnZpbmcgbmV0d29yay4iDQp8IA0KfCBX aGlsZSB0aGUgZXhhY3QgbnVtYmVyIGlzIHByb2JhYmx5IG5vdCB0aGF0IGltcG9ydGFudCAoYW5k IHZlcnkgbGlrZWx5IGhhcmQgdG8NCg0KVGhpcyB0ZXh0IG9yaWdpbmF0ZXMgZnJvbSB0aGUgbW90 aXZhdGlvbiB0aGF0IGdvdCB0aGlzIGRyYWZ0IGdvaW5nLiBJbiBwYXJ0aWN1bGFyLCB0aGUgbmVh cmx5IDEwLXllYXIgb2xkIFJGQyA0NjU2IGFyZ3VlcyBpbiBzZWMuIDYuNiAoaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzQ2NTYjc2VjdGlvbi02LjYpLCBhbW9uZyBvdGhlciB0aGluZ3Ms IHRoYXQgDQoNCiAgICAgIlRoZSBkZXBsb3ltZW50IHBhdGhzIG9mIElQc2VjIGFuZCBPV0FNUCBj b3VsZCBiZSBzZXBhcmF0ZSBpZiBPV0FNUA0KICAgICAgZG9lcyBub3QgZGVwZW5kIG9uIElQc2Vj LiAgQWZ0ZXIgbmluZSB5ZWFycyBvZiBJUHNlYywgb25seSAwLjA1JQ0KICAgICAgb2YgdHJhZmZp YyBvbiBhbiBhZHZhbmNlZCBiYWNrYm9uZSBuZXR3b3JrLCBzdWNoIGFzIEFiaWxlbmUsIHVzZXMN CiAgICAgIElQc2VjIChmb3IgY29tcGFyaXNvbiBwdXJwb3NlcyB3aXRoIGVuY3J5cHRpb24gYWJv dmUgbGF5ZXIgNCwgU1NIDQogICAgICB1c2UgaXMgYXQgMi00JSBhbmQgSFRUUFMgdXNlIGlzIGF0 IDAuMi0wLjYlKS4gIEl0IGlzIGRlc2lyYWJsZSB0bw0KICAgICAgYmUgYWJsZSB0byBkZXBsb3kg T1dBTVAgb24gYXMgbGFyZ2UgYSBudW1iZXIgb2YgZGlmZmVyZW50DQogICAgICBwbGF0Zm9ybXMg YXMgcG9zc2libGUuIg0KDQpJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8gYXJndWUgYWJvdXQgdGhl IG51bWJlcnMgZm9yIElQc2VjLCBIVFRQUyBhbmQgc28gb24gdG9kYXkgKGVzcC4gYXMgd2UgbG9v ayB0b3dhcmRzIDIwMjApLCBidXQgSSB3b3VsZCBtYWtlIHRoZSBjYXNlIHRoYXQgaXQncyBsaWtl bHkgdGhhdCBJUHNlYyBpcyBtb3JlIHdpZGVseSBkZXBsb3llZCB0b2RheSB0aGFuIE9XQU1QIGlz LiBQZXJoYXBzIEknbSB3cm9uZywgcGxlYXNlIGNvcnJlY3QgbWUuIEhlbmNlLCBkdXJpbmcgdGhl IGVhcmx5IHBoYXNlIG9mIGRldmVsb3BtZW50IG9mIHRoaXMgZHJhZnQgd2UgaW5jbHVkZWQgdGhp cyB0ZXh0IHRvIGlsbHVzdHJhdGUgZW1pbmVudCB1c2UgY2FzZXMgZm9yIHRoaXMgZHJhZnQgKHN1 Y2ggYXMgdGhlIExURSBjYXNlKS4gSWYgeW91IHRoaW5rIHRoYXQgIjk1JSIgc2hvdWxkIGJlIHJl cGxhY2VkIHdpdGggInRoZSB2YXN0IG1ham9yaXR5IG9mIiBvciBzb21ldGhpbmcgb2YgdGhhdCBu YXR1cmUsIHBsZWFzZSBsZXQgdXMga25vdy4gSWYgeW91IGhhdmUgY29tcGxldGVseSBkaWZmZXJl bnQgbnVtYmVycyBmcm9tIG9wZXJhdG9ycywgcmVzZWFyY2ggc3R1ZGllcyBvciB2ZW5kb3JzIGZv ciB0aGlzIHR5cGUgb2YgZGVwbG95bWVudCAob3Igb3RoZXIgc2V0dGluZ3MgZm9yIHRoYXQgbWF0 dGVyKSwgSSdsbCBiZSBoYXBweSB0byBoZWFyIHRoZW0uIA0KDQoNCnwgdmVyaWZ5KSB0aGUgc3Rh dGVtZW50IGRvZXMsIGhvd2V2ZXIsIHJhaXNlIHNvbWUgcXVlc3Rpb25zLiBZb3Ugc2VlbSB0byBl eHBlY3QNCnwgdGhhdCB5b3UgY2FuIHJlLXVzZSBhbHJlYWR5IGRlcGxveWVkIElLRXYyIGZvciB0 aGUgc3BlY2lhbCB2ZXJzaW9uIG9mIElLRXYyDQp8IHlvdSBhcmUgZGVzY3JpYmluZyBpbiB0aGlz IGRvY3VtZW50IGFuZCB0aGF0J3MgdW5mb3J0dW5hdGVseSB2ZXJ5IHVubGlrZWx5IHRvDQp8IGJl IHRydWUuDQoNCkkgZG9uJ3QgYWdyZWUgdGhpcyBpcyB0aGUgY2FzZSB3aGVuIEkgcmVhZCB0aGUg dGV4dC4NCg0KIA0KfCBUaGUgc29sdXRpb24gZGVzY3JpYmVkIGluIHRoZSBkb2N1bWVudCByZXF1 aXJlcyBhIHZlcnkgdGlnaHQgaW50ZWdyYXRpb24NCnwgYmV0d2VlbiBhbiBJS0V2MiBpbXBsZW1l bnRhdGlvbiAobm90IElQc2VjKSBhbmQgdGhlIE8vVFdBTVAgYXBwbGljYXRpb24gYW5kDQp8IHRo ZSB0ZXh0IGluIHRoZSBkb2N1bWVudCBnaXZlcyBtZSB0aGUgaW1wcmVzc2lvbiB0aGF0IHlvdSBh cmUgbm90IGVudGlyZWx5DQp8IGF3YXJlIHRoYXQgdGhpcyB3aWxsIGFjdHVhbGx5IG5lZWQgdG8g aGFwcGVuLiBUaGlzIG1heSBsZWFkIHRvIHVucGxlYXNhbnQNCnwgc3VycHJpc2VzIHdoZW4geW91 IGltcGxlbWVudCBpdC4NCg0KSSBkb24ndCBhZ3JlZSB3aXRoIHRoZSB0ZXJtICJ2ZXJ5IHRpZ2h0 IGludGVncmF0aW9uIi4gSW4gZmFjdCwgd2UgaGFkIHRoZSBBUEkgZGlzY3Vzc2lvbiBzZXZlcmFs IHRpbWVzIHdpdGggZm9sa3MgaW4gaXBzZWNtZSBvdmVyIHRoZSBsYXN0IDIgeWVhcnMgYW5kIGEg Yml0LiBJIGhlYXJkIHNvbWUgb2YgdGhlIGJhY2tncm91bmQsIGFuZCBJIGFncmVlIHRoYXQgcGVy aGFwcyBhbiBJUHNlYyB2ZW5kb3Igd2l0aCAqbm8gaW50ZXJlc3QgaW4gVFdBTVAqIG1heSBoYXZl IHRvIHRoaW5rIG1vcmUgaWYgdGhleSB3YW50IHRvIGludmVzdCB0aGUgZWZmb3J0IHRvIHN1cHBv cnQgdGhpcyBzcGVjLiBCdXQgZm9yIHZlbmRvcnMgd2l0aCBib3RoIGltcGxlbWVudGF0aW9ucyBp biBob3VzZSwgSSB3b3VsZCBsZWF2ZSBpdCB0byB0aGVpciByZXNwZWN0aXZlIGltcGxlbWVudGF0 aW9uIHRlYW1zLiBUaGlzIHNwZWMgd291bGQgZmFjaWxpdGF0ZSBpbnRlcm9wZXJhYmlsaXR5IGlu IHRoaXMgbGF0dGVyIGNhc2UuDQoNCkFzIGFuIGFzaWRlLCBhbmQgZ2l2ZW4gdGhhdCB0aGlzIGlz IGFuIElQUE0gZHJhZnQsIEkgd291bGQgbGlrZSB0byBwb2ludCBvdXQgdGhhdCBUV0FNUCBwZXIg c2UgKFJGQyA1MzU3LCBzZWMuIDEuMjogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUz NTcjc2VjdGlvbi0xLjIpIGRvZXMgbGVhdmUgY2VydGFpbiBpbnRlcmFjdGlvbnMgInVuc3BlY2lm aWVkIiwgd2hpY2ggIm1heSBiZSBwcm9wcmlldGFyeSBwcm90b2NvbHMiLg0KDQp8IEZpcnN0LCB5 b3Ugd2lsbCBoYXZlIHRvIHRyaWdnZXIgdGhlIElLRXYyIGV4Y2hhbmdlIGZyb20gdGhlIGFwcGxp Y2F0aW9uLg0KfCBTZWNvbmQsIHlvdSBkZWZpbml0ZWx5IGRvIG5vdCB3YW50IHRoZSBJS0V2MiBl eGNoYW5nZSB0byBjcmVhdGUgSVBzZWMgU0FzDQoNCjxzbmlwPg0KDQp8ICJJUFBNIiApLiBJTUhP IG5vIG9mZi10aGUtc2hlbGYgSUtFdjIgaW1wbGVtZW50YXRpb24gd2lsbCBsZXQgYXBwbGljYXRp b25zDQp8IGFjY2VzcyB0aGUgU0tfZCBkaXJlY3RseSBub3Igd2lsbCBpdCBoYXZlIGFuIEFQSSB0 byB0aGUgSUtFdjIgU0EgZWl0aGVyLg0KDQpBZ3JlZWQsIHdydCAib2ZmLXRoZS1zaGVsZiIgKGlu IGdlbmVyYWwpLCBhZnRlciBhbGwgdGhpcyBpcyBub3QgYW4gUkZDIHlldC4gQnV0IHBsZWFzZSBz ZWUgYWJvdmUuDQoNCg0KfCBJdCBtaWdodCBhbHNvIHdhbnQgdG8gdGhpbmsgYWJvdXQgcG90ZW50 aWFsIGludGVyYWN0aW9ucyBmcm9tIHRoZQ0KfCBJS0V2Mi0+IHRvIE8vVFdBTVAgc2lkZSwgc3Vj aCBhcyByZWtleWluZy4gSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHRoZXJlDQp8IGFyZSBpc3N1ZXMg dG8gdGFrZSBpbnRvIGFjY291bnQgYnV0IGhhdmUgeW91IHRob3VnaHQgYWJvdXQgdGhlbT8NCg0K VGhpcyBpcyBhZGRyZXNzZWQgaW4gdGhlIGxhc3QgcGFyYWdyYXBoIG9mIHNlYy4gNS4xIChodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHBtLWlwc2VjLTA5I3NlY3Rpb24t NS4xKS4gSWYgeW91IHdvdWxkIGxpa2Ugb3RoZXIgdGV4dCB0byBiZSBhZGRlZCBvciB0aGlzIHRv IGJlIGVkaXRlZCwgcGxlYXNlIGtpbmRseSBzZW5kIGEgcHJvcG9zYWwuDQoNCjxzbmlwPg0KDQoN CnwgSW4gU2VjdGlvbiA1LjEgeW91IGRlc2NyaWJlIGEgd2F5IHRvIG9idGFpbiBmb3IgdGhlIE8v VFdBTVAgaW1wbGVtZW50YXRpb24gdG8NCnwgaW50ZXJhY3Qgd2l0aCB0aGUgSUtFdjIgY29kZSBh cyBmb2xsb3dzOg0KfCANCnwgIg0KfCAgICB0aGUgSVBTZWMgbGF5ZXIgY2FuIHBlcmZvcm0gYSBs b29rdXANCnwgICAgaW4gdGhlIFNlY3VyaXR5IEFzc29jaWF0aW9uIERhdGFiYXNlIChTQUQpIHVz aW5nIHRoZSBJUCBhZGRyZXNzIG9mDQp8ICAgIHRoZSBzZXJ2ZXIgYW5kIHRodXMgbWF0Y2ggdGhl IGNvcnJlc3BvbmRpbmcgSUtFdjIgU0EuICBBdCB0aGUgc2VydmVyDQp8ICAgIHNpZGUsIHRoZSBJ UFNlYyBsYXllciBjYW4gbG9vayB1cCB0aGUgY29ycmVzcG9uZGluZyBJS0V2MiBTQSBieSB1c2lu Zw0KfCAgICB0aGUgU1BJcyBzZW50IGJ5IHRoZSBjbGllbnQsIGFuZCB0aGVyZWZvcmUgZXh0cmFj dCB0aGUgc2hhcmVkIHNlY3JldCAiDQp8IA0KfCBJIGJlbGlldmUgdGhhdCB0aGlzIGFwcHJvYWNo IHdpbGwgbm90IHdvcmsgc2luY2UgeW91ciB1c2Ugb2YgSUtFdjIgc2hvdWxkbid0DQp8IGFjdHVh bGx5IHJlcXVpcmUgYW55IGludGVyYWN0aW9uIHdpdGggSVBzZWMgYXQgYWxsLg0KDQpXZSB1c2Ug SVBzZWMgdG8gcmVmZXIgdG8gSUtFK0VTUC9BSCBpbiB0aGlzIGRyYWZ0LiBJZiB5b3Ugd291bGQg bGlrZSB0byBwcm9wb3NlIGFsdGVybmF0aXZlLCBiZXR0ZXIgcmVmaW5lZCB0ZXh0LCBwbGVhc2Ug bGV0IHVzIGtub3cuDQoNCjxzbmlwPg0KDQoNCnwgSSBjb3VsZCBpbWFnaW5lIHRoYXQgYSBuZXR3 b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2wgY291bGQgYmUgdXNlZCB0byBwcm92aXNpb24NCnwgdGhl IHNoYXJlZCBzZWNyZXRzIHRvIHRoZSBhcHByb3ByaWF0ZSBub2Rlcy4gV2hpbGUgcHVibGljIGtl eSBjcnlwdG9ncmFwaHkNCnwgbWFrZXMgc29tZSBhc3BlY3RzIG9mIHRoZSBrZXkgZGlzdHJpYnV0 aW9uIGVhc2llciBpdCBkb2VzIHJhaXNlIG90aGVyDQp8IHF1ZXN0aW9ucywgc3VjaCBhcyBkaXN0 cmlidXRpb24gb2YgdHJ1c3QgYW5jaG9ycyBhbmQgdGhlIHF1ZXN0aW9uIGFib3V0DQp8IGF1dGhv cml6YXRpb24uIFNpbmNlIHlvdSBkbyBub3QgZGlzY3VzcyBhdXRob3JpemF0aW9uIGluIHRoZSBk b2N1bWVudCBJIGFtIG5vdA0KfCBzdXJlIGl0IGlzIG9mIGNvbmNlcm4gd2l0aCB0aGUgdXNlIG9m IE8vVFdBTVAuDQoNCkluZGVlZCwgYSBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2wgX2NvdWxk XyBiZSB1c2VkLCBidXQgdGhpcyBpcyBub3Qgc3RhbmRhcmRpemVkIGFuZCwgaW1vLCBvcnRob2dv bmFsIHRvIHRoZSBwcm9ibGVtIGF0IGhhbmQuIFBlcmhhcHMgd2Ugc2hvdWxkIHN0YXJ0IGEgc2Vw YXJhdGUgZHJhZnQgZm9yIE9BTS1iYXNlZCBzaGFyZWQgc2VjcmV0IGRpc3RyaWJ1dGlvbiBmb3Ig VFdBTVAuDQoNCg0KfCBJIGFtIG5vdCBzdXJlIHdoeSB5b3UgaW5jbHVkZSB0aGUgdGV4dCBpbiBT ZWN0aW9uIDUuNCB3aGVyZSB5b3UgZGVzY3JpYmUNCnwgTy9UV0FNUCBvdmVyIGFuIElQc2VjIHR1 bm5lbCBzaW5jZSBpbiB0aGUgaW50cm9kdWN0aW9uIHlvdSBhcmd1ZSB0aGF0IHRoaXMgaXMNCnwg bm90IGFuIGFwcHJvYWNoIHRoYXQgeW91IGZhdm91ciBzaW5jZSBpdCBpbnRyb2R1Y2VzIGRlbGF5 cyBpbnRvIHRoZQ0KfCBtZWFzdXJlbWVudHMuDQoNClRoaXMgd2FzIGludHJvZHVjZWQgYXMgcGFy dCBvZiB0aGUgY29uc2Vuc3VzIHByb2Nlc3MgaW4gdGhlIFdHLiBJZiB5b3VyIGNvbW1lbnQgaXMg ZWRpdG9yaWFsIGluIG5hdHVyZSwgdGhlbiBbZWRpdG9yIGhhdCBvbl0gSSB3b3VsZCBsZXQgaXQg Z28gW2VkaXRvciBoYXQgb2ZmXS4gSWYgaXQncyBzdWJzdGFudGlhbCwgYmxvY2tpbmcsIHRoZW4g SSB3b3VsZCBiZSBoYXBweSB0byByZW1vdmUgc2VjLiA1LjQuIE1pbmQgeW91LCBzZXZlcmFsIHBh cnRzIG9mIHRoZSBkcmFmdCBoYXZlIGJlZW4gcmVwZWF0ZWRseSB0dW5lZCB0byByZWFjaCBjb25z ZW5zdXMgb3ZlciB0aGUgbGFzdCAyIHllYXJzLg0KDQoNCnwgSSBhbSBhbHNvIHdvbmRlcmluZyB3 aGV0aGVyIHRoaXMgc29sdXRpb24gb2ZmZXJzIGNyeXB0byBhZ2lsaXR5LiBUaGUgdGV4dA0KfCBk ZXNjcmliZXMgdGhhdCB5b3UgdXNlIEFFUy1DQkMgKGZvciBlbmNyeXB0aW9uKSBhbmQgSE1BQy1T SEExIChmb3IgZGF0YSBvcmlnaW4NCnwgYXV0aGVudGljYXRpb24gYW5kIGludGVncml0eSBwcm90 ZWN0aW9uKS4gSUtFdjIgY291bGQsIG9mIGNvdXJzZSwgYWxsb3cgeW91IHRvDQp8IG5lZ290aWF0 ZSBvdGhlciBhbGdvcml0aG1zIGFuZCBwYXJ0aWN1bGFybHkgdGhlIG1vcmUgbW9kZXJuIEFFQUQg Y2lwaGVycy4NCg0KQUVTLUNCQyBhbmQgSE1BQy1TSEExIGFyZSBhbGdvcml0aG1zIGRlZmluZWQg aW4gdGhlIE8vVFdBTVAgUkZDcy4gUGVyaGFwcyB0aGVyZSBpcyBzcGFjZSBmb3IgYW5vdGhlciBk cmFmdCBpbiB0aGlzIGRpcmVjdGlvbiBhcyB3ZWxsLCBpLmUuIHRvIGFsbG93IGZvciBtb3JlIGNy eXB0byBhZ2lsaXR5IGluIFRXQU1QIGJleW9uZCBoYXMgYmVlbiBzdGFuZGFyZGl6ZWQgc28gZmFy Lg0KDQoNCnwgSW4gYSBmZXcgcGFydHMgb2YgdGhlIGRvY3VtZW50IHlvdSBzYXkgIg0KfCAgICBU aGUgbmV3IE1vZGVzIHZhbHVlIGluZGljYXRpbmcgc3VwcG9ydCBmb3IgdGhpcw0KfCAgICBzcGVj aWZpY2F0aW9uIGlzIElLRXYyRGVyaXZlZCBhbmQgaXMgZXF1YWwgdG8gMTI4IChpLmUuIGJpdCBz ZXQgaW4NCnwgICAgcG9zaXRpb24gNykgW05PVEUgdG8gSUFOQTogcmVtb3ZlIGJlZm9yZSBhbGxv Y2F0aW9uIGFuZCBmaW5hbA0KfCBwdWJsaWNhdGlvbl0iLg0KfCANCnwgSSBhbSBub3Qgc3VyZSB3 aGF0IHlvdSBhcmUgYXNraW5nIElBTkEgdG8gZG8uIEkgYmVsaWV2ZSB3aGF0IHlvdSBhcmUgdHJ5 aW5nIHRvDQp8IHNheSBpcyB0aGF0IHlvdSBoYXZlIHByb3Bvc2VkIGEgc3BlY2lmaWMgdmFsdWUg Zm9yIHRoaXMgZXh0ZW5zaW9uIGFuZCB5b3Ugd2FudA0KfCBJQU5BIHRvIGNvbmZpcm0gdGhhdCBh bGxvY2F0aW9uLg0KDQo8c25pcD4NCg0KRG9uZSBpbiAtMDkNCg0KDQp8IEkgd291bGQgYWxzbyBy ZW1vdmUgdGhpcyBwYXJhZ3JhcGggaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb24gc2VjdGlv bjoNCnwgDQp8IA0KfCAiDQp8ICAgIEFzIGEgbW9yZSBnZW5lcmFsIG5vdGUsIHRoZSBJUFBNIGNv bW11bml0eSBtYXkgd2FudCB0byByZXZpc2l0IHRoZQ0KfCAgICBhcmd1bWVudHMgbGlzdGVkIGlu IFtSRkM0NjU2XSwgU2VjLiA2LjYuICBPdGhlciB3aWRlbHktdXNlZCBJbnRlcm5ldA0KfCAgICBz ZWN1cml0eSBtZWNoYW5pc21zLCBzdWNoIGFzIFRMUyBhbmQgRFRMUywgbWF5IGFsc28gYmUgY29u c2lkZXJlZCBmb3INCnwgICAgZnV0dXJlIHVzZSBvdmVyIGFuZCBhYm92ZSBvZiB3aGF0IGlzIGFs cmVhZHkgc3BlY2lmaWVkIGluIFtSRkM0NjU2XQ0KfCAgICBbUkZDNTM1N10uDQp8ICINCnwgDQp8 IFdoaWxlIGl0IGlzIHRydWUgdGhhdCBEVExTL1RMUyBjb3VsZCBhbHNvIHVzZWQgKGFuZCBhcmUg cHJvYmFibHkgYSBiZXR0ZXINCnwgY2hvaWNlKSBpdCBmZWVscyBsaWtlIHRoZSB3cm9uZyBzdGF0 ZW1lbnQgaW4gdGhpcyBkb2N1bWVudC4gSXQgbWFrZXMgdGhlDQp8IHJlYWRlciBmZWVsIGxpa2Ug dGhhdCBldmVuIHRoZSBhdXRob3JzIGFyZSBub3QgY29udmluY2VkIHRoYXQgdGhpcyBpcyB0aGUN CnwgcmlnaHQgc29sdXRpb24gYXBwcm9hY2guDQoNCldlIGhhdmUgcmVtb3ZlZCB0aGlzIHBhcmFn cmFwaCBpbiAtMDksIGFzIHBlciB5b3VyIHJlcXVlc3Q6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwxPWRyYWZ0LWlldGYtaXBwbS1pcHNlYy0wOCZ1cmwyPWRyYWZ0LWlldGYtaXBwbS1p cHNlYy0wOS4gSG93ZXZlciwgdGhpcyBicmluZ3MgdXMgYmFjayB0byBtb3RpdmF0aW9uIGRpc2N1 c3Npb24gYXQgdGhlIGJlZ2lubmluZyBvZiB0aGlzIGVtYWlsLg0KDQpPbmNlIGFnYWluLCBtYW55 IHRoYW5rcy4NCg0KQmVzdCByZWdhcmRzLA0KDQpLb3N0YXMNCg== From nobody Fri Feb 13 08:06:29 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBDC1A0358; Fri, 13 Feb 2015 08:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRlT7R41fPbS; Fri, 13 Feb 2015 08:06:20 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB8C1A875C; Fri, 13 Feb 2015 08:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4352; q=dns/txt; s=iport; t=1423843545; x=1425053145; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=IJb7xLdMVPS+HZqMs5ZDpBxMsn+BjMVupcbACGvvNx0=; b=hJNMHQBKqJBl8pvCC0Ukg2FBGLW1YBPgKfFxi8ObzKxMMYUxto6ygzUa fLsIGEQ15GvyiIUYg4X6KpqBXp6GHvmm/tJ839sRJZqW+pxxPFoO4/gww 0FkrO62ow95QLNmlmbZKWW6Kw4rOnszF8rx5t8l0hcXwF6ju5sxr6Y95w U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosFAKgf3lStJV2P/2dsb2JhbABSCYMGgTCCfr0FiDZ4QwEBAQEBAXyEEyMRPhkBBhwCJgIEMBUSBAGIP6EdnGyXFAEBAQEBAQEDAQEBAQEBHIEhiWuEEoNKLoEUBY80hWmDTIEYgweCSYwdIoIBHYFQgjN/AQEB X-IronPort-AV: E=Sophos;i="5.09,571,1418083200"; d="scan'208";a="395885787" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP; 13 Feb 2015 16:05:45 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t1DG5iFD018087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Feb 2015 16:05:44 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.223]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Fri, 13 Feb 2015 10:05:44 -0600 From: "Klaas Wierenga (kwiereng)" To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-cdni-logging.all@tools.ietf.org" Thread-Topic: review of draft-ietf-cdni-logging.15 Thread-Index: AQHQR6bsatwFQJOdLkuG1v9BlCIAFQ== Date: Fri, 13 Feb 2015 16:05:44 +0000 Message-ID: <493249E6-FD3B-46F3-AA3E-79ED26B594E1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.219.126] Content-Type: text/plain; charset="utf-8" Content-ID: <32FC4DC09A73B24685101E42C8A60C4C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [secdir] review of draft-ietf-cdni-logging.15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 16:06:25 -0000 SGksDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3Vy aXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3Vt ZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJlIHdy aXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgIHNlY3VyaXR5IGFyZWEgZGly ZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVz ZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0KVGhp cyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIGxvZ2dpbmcgZm9ybWF0IGFuZCB0aGUgZXhjaGFuZ2Ug cHJvdG9jb2wgZm9yIGxvZ2dpbmcgaW5mb3JtYXRpb24gYmV0d2VlbiB1cHN0cmVhbSBhbmQgZG93 bnN0cmVhbSBDRE5zIHRoYXQgYXJlIGludGVyY29ubmVjdGVkIHVzaW5nIHRoZSBDRE4gaW50ZXJj b25uZWN0aW9uIGZyYW1ld29yay4NCg0KVGhlIGRvY3VtZW50IGlzIHdlbGwgd3JpdHRlbiBhbmQg ZWFzeSB0byByZWFkLiBJIGhhdmUgZmV3IGlzc3VlcyB3aXRoIHRoZSBtYWluIHRleHQsIGJ1dCBk byBoYXZlIHNvbWUgY29uY2VybnMgYWJvdXQgdGhlIHNlY3VyaXR5IGFuZCBwcml2YWN5IGNvbnNp ZGVyYXRpb25zLiBJIHRoZXJlZm9yZSBjb25zaWRlciB0aGUgZG9jdW1lbnQg4oCccmVhZHkgd2l0 aCBpc3N1ZXPigJ0NCg0KRGV0YWlsZWQgY29tbWVudHM6DQoNCiogSW50cm9kdWN0aW9uIGFuZCBG aWd1cmUgMTogV2hhdCBpcyBub3QgY2xlYXIgdG8gbWUgZnJvbSB0aGUgdGV4dCBpcyB3aGV0aGVy IHRoZXJlIGlzIGFueSBmdW5jdGlvbmFsIGRpZmZlcmVuY2UgYmV0d2VlbiBhbiB1Q0ROIGFuZCBh biBkQ0ROLG9yIHRoYXQgdGhleSBqdXN0IGhhcHBlbiB0byBiZSBpbiBhIGhpZXJhcmNoaWNhbCBy ZWxhdGlvbiB0byBlYWNoIG90aGVyLiAgSSBjb3VsZCBhbHNvIGZpbmQgbm8gcmVmZXJlbmNlIHRv IHRoYXQgaW4gUkZDNzMzNi4gVGhlIGZhY3QgdGhhdCBpbiBGaWd1cmUgMSBkQ0ROLTIgaXMgbm90 IGFsc28gbGFiZWxlZCBhcyB1Q0ROLTIgbGVkIG1lIHRvIGJlbGlldmUgdGhhdCB0aGVyZSBpcyBh IGZ1bmN0aW9uYWwgZGlmZmVyZW5jZS4gSG93ZXZlciBmcm9tIHRoZSB0ZXh0IGl0IGFwcGVhcnMg dGhhdCBhbnkgdHdvIERDTnMgY2FuIGJlIGluIGFuIHUtZCByZWxhdGlvbiB0byBlYWNoIG90aGVy LiBQbGVhc2UgY2xhcmlmeS4NCg0KKiBQYXJhZ3JhcGggMy4yICBDRE5JIExvZ2dpbmcgRmlsZSBT dHJ1Y3R1cmUNCg0KWW91IHN0YXRlIHRoYXQgeW91IGNob3NlIGEgZm9ybWF0IGFzIGNsb3NlIGFz IHBvc3NpYmxlIHRvIHRoZSBXM0MgRUxGIEZvcm1hdC4gSeKAmWQgbGlrZSB0byBzZWUgYSBzaG9y dCBleHBsYW5hdGlvbiB3aHkgeW91IGNhbiBub3QgdXNlIHRoYXQgZm9ybWF0LCBhbmQgd2hldGhl ciBpdCB3b3VsZCBiZSBhbiBvcHRpb24gdG8gZXh0ZW5kIHRoYXQgZm9ybWF0IHJhdGhlciB0aGFu IGRlZmluaW5nIGEgbmV3IGZvcm1hdCB0aGF0IGlzIHNsaWdodGx5IGRpZmZlcmVudCBidXQgaXMg ZXNzZW50aWFsbHkgYSBmb3JtIGFuZCBjb3VsZCBvdmVyIHRpbWUgYmUgc2lnbmlmaWNhbnRseSBk aWZmZXJlbnQuDQoNCiogcGFyYWdyYXBoIDMuMyBEaXJlY3RpdmVzDQoNCkZvciB0aGUgSW50ZWdy aXR5LUhhc2ggeW91IHdyaXRlOiAiaGFzaCBmdW5jdGlvbiBvZiBhbGwgbG9nZ2luZyByZWNvcmRz IGFuZCBkaXJlY3RpdmVzIHVwIHRvIHRoZSBoYXNoLWRpcmVjdGl2ZSBpdHNlbGbigJ0uIEkgaGF2 ZSBub3Qgc2VlbiB0aGF0IHRoZSBkaXJlY3RpdmVzIGFyZSBpbiBhIHNwZWNpYWwgb3JkZXIgd2l0 aCB0aGUgSW50ZWdyaXR5LWhhc3QgYXMgbGFzdCBvbmUsIHNvIGl0IGFwcGVhcnMgdGhhdCB3aGVu IHRoZSBpbnRlZ3JpdHktaGFzaCBkaXJlY3RpdmUgaXMgdGhlIHZlcnkgZmlyc3Qgb25lIHRoZXJl IHdpbGwgYmUgbm8gc2Vuc2libGUgaGFzaC4gVW5sZXNzIHRoZXJlIGlzIGFjdHVhbCBvcmRlciBp biB0aGUgZGlyZWN0aXZlcyAod3JpdGUgdGhhdCBkb3duKSBJIHN1Z2dlc3Qg4oCcaGFzIGFsbCBs b2dnaW5nIGluZm9ybWF0aW9uIGFuZCBkaXJlY3RpdmVzIHdpdGggdGhlIGV4Y2VwdGlvbiBvZiB0 aGUgSW50ZWdyaXR5LUhhc2ggZGlyZWN0aXZlIGl0c2VsZuKAnQ0KDQoqIFBhcmFncmFwaCA3LjEg QXV0aGVudGljYXRpb24sIENvbmZpZGVudGlhbGl0eSwgSW50ZWdyaXR5IFByb3RlY3Rpb24NCg0K WW91IGxlYXZlIG91dCB0aGUgM2QgQSwgQXV0aG9yaXphdGlvbiwgYnV0IHRoZW4geW91IHRhbGsg YWJvdXQgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIHRvIGRlY2lkZSB3aGV0aGVyIGFuIGVudGl0eSBp cyBhdXRob3Jpc2VkIHRvIHJlY2VpdmUgdGhlIGxvZ3MsIHNvIEkgdGhpbmsgeW91IHNob3VsZCBp bnNlcnQgaXQgdGhhdCBvbmUgdG9vLg0KDQpZb3Ugc3RhdGUgdGhhdCB0aGUgdXNlIG9mIFRMUyBm b3IgdHJhbnNwb3J0IGFsbG93cyBmb3IgbXV0dWFsIGF1dGhlbnRpY2F0aW9uLCBjb25maWRlbnRp YWxpdHkgYW5kIGludGVncml0eSwgdGhhdCBpbiBpdHNlbGYgaXMgbm90IHRydWUuIFlvdSBuZWVk IFRMUyArIG11dHVhbCBhdXRoZW50aWNhdGlvbiB0byBnZXQgY29uZmlkZW50aWFsaXR5IGFuZCBp bnRlZ3JpdHkuIA0KDQpJbiB0aGUgdGV4dCDigJxJbiBhbiBlbnZpcm9ubWVudCB3aGVyZSBhbnkg c3VjaCBwcm90ZWN0aW9uIGlzIHJlcXVpcmVk4oCmLuKAnSBUTFMgaXMgYSAiU0hPVUxEIHVubGVz c+KApi4u4oCdLCBXaHkgbm90IOKAnE1VU1QgdW5sZXNz4oCmLuKAnQ0KDQoqIHBhcmFncmFwaCA3 LjIgRG9TDQoNCkkgZG9u4oCZdCB1bmRlcnN0YW5kIGhvdyB0aGUgdXNlIG9mIFRMUyBwcm90ZWN0 cyBhZ2FpbnMgRG9TLCBvbiB0aGUgY29udHJhcnkgSSB3b3VsZCBzYXksIHRyeWluZyB0byBlc3Rh Ymxpc2ggYSBUTFMgc2Vzc2lvbiBpcyBjb3N0bHksIHNvIGFuIGV2aWwgZW50aXR5IGNvdWxkIGVh c2lseSBtb3VudCBhIERvUyBieSB0cnlpbmcgdG8gY29ubmVjdCBhbmQgZXhjaGFuZ2UgY3J5cHRv IG1hdGVyaWFsLg0KDQoNCktsYWFzDQoNCg0KLS0NCktsYWFzIFdpZXJlbmdhDQpJZGVudGl0eSBB cmNoaXRlY3QNCkNpc2NvIENsb3VkIFNlcnZpY2VzDQoNCg0KDQoNCg0KDQo= From nobody Fri Feb 13 09:56:04 2015 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 AFB211A1B85; Fri, 13 Feb 2015 00:11:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1423815106; bh=dTeFlnABtpA5GCAvgXqY69IcQ5rsFN0v3n6b1QWmjcE=; 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=MazLEHFA0GSyNFoZ/zF8kCE8eQ5oTbZK2r6UIG5wuML9+c9CB2VyRXIicB+hI/y8a P7gbXkhe/Jbe7LqXnDqn4iUadMvkfW4vvpvFidmPqmonk2V1ivWF3lBS24hNtWaMyK ibOlFLvbTZsjIZyN3KsekurxaLMXdxe70uDUKABk= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BD81A1B8F for ; Fri, 13 Feb 2015 00:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ULkPPy3Qegq for ; Fri, 13 Feb 2015 00:11:19 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FD5C1A1B89 for ; Fri, 13 Feb 2015 00:11:09 -0800 (PST) Received: from 34.233.120.153.tokyo.global.crust-r.net ([153.120.233.34] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YMBL8-0007ve-1M; Fri, 13 Feb 2015 03:11:06 -0500 To: new-work@ietf.org Date: Fri, 13 Feb 2015 17:11:04 +0900 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 13 Feb 2015 09:56:01 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Web Real-Time Communications Working Group (until 2015-03-15) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 08:11:46 -0000 CgpIZWxsbywKClRvZGF5IFczQyBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmVzIHJl Y2VpdmVkIGEgUHJvcG9zYWwKdG8gcmV2aXNlIHRoZSBVYmlxdWl0b3VzIFdlYiBBcHBsaWNhdGlv bnMgQWN0aXZpdHkgWzBdIChzZWUgdGhlIFczQyBQcm9jZXNzCkRvY3VtZW50IGRlc2NyaXB0aW9u IG9mIEFjdGl2aXR5IFByb3Bvc2FscyBbMV0pLiBUaGlzIHByb3Bvc2FsCmluY2x1ZGVzIGEgZHJh ZnQgY2hhcnRlciBmb3IgdGhlIFdlYiBSZWFsLVRpbWUgQ29tbXVuaWNhdGlvbnMgV29ya2luZyAg Ckdyb3VwOgogICBodHRwOi8vd3d3LnczLm9yZy8yMDE1LzAyL3dlYnJ0Yy1jaGFydGVyLmh0bWwK CkFzIHBhcnQgb2YgZW5zdXJpbmcgdGhhdCB0aGUgY29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bv c2VkIHdvcmsKYXQgVzNDLCB0aGlzIGRyYWZ0IGNoYXJ0ZXIgaXMgcHVibGljIGR1cmluZyB0aGUg QWR2aXNvcnkKQ29tbWl0dGVlIHJldmlldyBwZXJpb2QuCgpXM0MgaW52aXRlcyBwdWJsaWMgY29t bWVudHMgdGhyb3VnaCAyMDE1LTAzLTE1IG9uIHRoZQpwcm9wb3NlZCBjaGFydGVyLiBQbGVhc2Ug c2VuZCBjb21tZW50cyB0bwpwdWJsaWMtbmV3LXdvcmtAdzMub3JnLCB3aGljaCBoYXMgYSBwdWJs aWMgYXJjaGl2ZToKICAgaHR0cDovL2xpc3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvcHVibGlj LW5ldy13b3JrLwoKT3RoZXIgdGhhbiBjb21tZW50cyBzZW50IGluIGZvcm1hbCByZXNwb25zZXMg YnkgVzNDIEFkdmlzb3J5CkNvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMsIFczQyBjYW5ub3QgZ3Vh cmFudGVlIGEgcmVzcG9uc2UgdG8KY29tbWVudHMuIElmIHlvdSB3b3JrIGZvciBhIFczQyBNZW1i ZXIgWzJdLCBwbGVhc2UgY29vcmRpbmF0ZQp5b3VyIGNvbW1lbnRzIHdpdGggeW91ciBBZHZpc29y eSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUuIEZvcgpleGFtcGxlLCB5b3UgbWF5IHdpc2ggdG8g bWFrZSBwdWJsaWMgY29tbWVudHMgdmlhIHRoaXMgbGlzdCBhbmQKaGF2ZSB5b3VyIEFkdmlzb3J5 IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZSByZWZlciB0byBpdCBmcm9tIGhpcwpvciBoZXIgZm9y bWFsIHJldmlldyBjb21tZW50cy4KCklmIHlvdSBzaG91bGQgaGF2ZSBhbnkgcXVlc3Rpb25zIG9y IG5lZWQgZnVydGhlciBpbmZvcm1hdGlvbiwgcGxlYXNlCmNvbnRhY3QgRG9taW5pcXVlIEhhemHD q2wtTWFzc2lldXgsIFN0YWZmIENvbnRhY3RzIDxkb21AdzMub3JnPi4KClRoYW5rIHlvdSwKCkNv cmFsaWUgTWVyY2llciwgQWN0aW5nIEhlYWQgb2YgVzNDIE1hcmtldGluZyAmIENvbW11bmljYXRp b25zCgpbMF0gaHR0cDovL3d3dy53My5vcmcvMjAwNy91d2EvQWN0aXZpdHkuaHRtbApbMV0gaHR0 cDovL3d3dy53My5vcmcvMjAxNC9Qcm9jZXNzLTIwMTQwODAxLyNBY3Rpdml0eUNyZWF0aW9uClsy XSBodHRwOi8vd3d3LnczLm9yZy9Db25zb3J0aXVtL01lbWJlci9MaXN0CgotLSAKICBDb3JhbGll IE1lcmNpZXIgIC0gIFczQyBDb21tdW5pY2F0aW9ucyBUZWFtICAtICBodHRwOi8vd3d3LnczLm9y ZwptYWlsdG86Y29yYWxpZUB3My5vcmcgKzMzNiA0MzIyIDAwMDEgaHR0cDovL3d3dy53My5vcmcv UGVvcGxlL0NNZXJjaWVyLwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KbmV3LXdvcmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Sat Feb 14 00:37:40 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8961A1B38; Sat, 14 Feb 2015 00:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.497 X-Spam-Level: ** X-Spam-Status: No, score=2.497 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-kpC0HGGEHy; Sat, 14 Feb 2015 00:37:37 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF361A1B07; Sat, 14 Feb 2015 00:37:36 -0800 (PST) Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id t1E8bXmg017860; Sat, 14 Feb 2015 17:37:33 +0900 (JST) Received: from TakeVaioVJP13 (ssh.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id t1E8bXgn017857; Sat, 14 Feb 2015 17:37:33 +0900 (JST) From: "Takeshi Takahashi" To: Date: Sat, 14 Feb 2015 17:37:41 +0900 Message-ID: <05dd01d04831$7f1feb20$7d5fc160$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdBIMOOiaLelG4CVQLmmb8T68PWZdA== Content-Language: ja X-Virus-Scanned: clamav-milter 0.98.5 at zenith1 X-Virus-Status: Clean Archived-At: Cc: secdir@ietf.org, calext-chairs@tools.ietf.org, 'The IESG' Subject: [secdir] Secdir review of draft-ietf-calext-rscale-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 08:37:38 -0000 Hello, I have reviewed current version of 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. [overview] This draft provides an extension to iCalender to support use of non-Gregorian recurrence rules. It first elaborates the difficulties to cope with the non-Gregorian calendar using the existing "CALSCALE" property in iCalendar. The "RRULE" property is thus extended to include an "RSCALE" element. The draft also explains how to handle the dates expressed by non-Gregorian calendar. [security consideration check] The security consideration section says that this draft does not introduce any additional security concerns beyond those described in RFC 5545, 5546, and 4791. I agree, since this draft simply added an "RSCALE" element; I do not think it may cause any extra security concerns. [status] I think this draft is ready for further process. Thank you. Take From nobody Sun Feb 15 05:13:59 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031371A1B66; Sun, 15 Feb 2015 05:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_skRbpR66PW; Sun, 15 Feb 2015 05:13:34 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7FB91A1B64; Sun, 15 Feb 2015 05:13:33 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSQ69219; Sun, 15 Feb 2015 13:13:31 +0000 (GMT) Received: from SZXEML432-HUB.china.huawei.com (10.82.67.209) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 15 Feb 2015 13:13:30 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.208]) by szxeml432-hub.china.huawei.com ([10.82.67.209]) with mapi id 14.03.0158.001; Sun, 15 Feb 2015 21:13:23 +0800 From: Tina TSOU To: "secdir@ietf.org" Thread-Topic: Secdir review of draft-ietf-kitten-gss-loop-04 Thread-Index: AQHQSSEsFCDMb7qIck6QKsq/WsPnVQ== Date: Sun, 15 Feb 2015 13:13:23 +0000 Message-ID: References: <05dd01d04831$7f1feb20$7d5fc160$@nict.go.jp> In-Reply-To: <05dd01d04831$7f1feb20$7d5fc160$@nict.go.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_DBEACD8F3B2F4C56AC8347EB6F55E8F9huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-ietf-kitten-gss-loop.all@tools.ietf.org" , "kitten-chairs@tools.ietf.org" , The IESG Subject: [secdir] Secdir review of draft-ietf-kitten-gss-loop-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 13:13:46 -0000 --_000_DBEACD8F3B2F4C56AC8347EB6F55E8F9huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I have reviewed current version of this document as part of the security directorate'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. * Section 3.2, page 5: The initiator calls GSS_Init_sec_context(), using the input_context_handle for the current proto-security-context and its fixed set of input parameters, and the input_token received from the acceptor (if not the first iteration of the loop). Your use of proto-security-context would make it seem like this is a parameter specified in RFC2473 but it is not. So I'd recommend to remove the hyphens. (BTW, at times you refer to "proto-security-context" while at others to just "security context"... why?) * Section 3.2, Page 5: (if not the first iteration of the loop) Please rephrase as "(if this is not...)" * Section 3.2, page 5: However, there are some known implementations of certain mechanisms which do produce empty context negotiation tokens. For maximum interoperability, applications should be prepa It would be great if you could provide examples of such implementations. * Section 3.4, page 6 It is likely appropriate for the acceptor to report this error condition to the acceptor via the application's communication channel. It should say: It is likely appropriate for the acceptor to report this error condition to the initiator via the application's communication channel. * Section 3.5, page 7: The GSS acceptor calls GSS_Accept_sec_context(), using the input_context_handle for the current proto-security-context and the input_token received from the initiator Again, remove the hyphens * Section 4.1, page 10 Additional information can be available in GSS-API Naming Extensions, [RFC6680]. s/can be/is/ * Section 5.1: You should clarify what's the convention for the return codes of send_token() and receive_token(). Otherwise it's not clear whether, when you use these functions, you're checking the return codes correctly. Thank you, Tina --_000_DBEACD8F3B2F4C56AC8347EB6F55E8F9huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear all,

I have reviewed current version of this document as part of the= security
directorate'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<= br> directors.
Document editors and WG chairs should treat these comments just like any other last call comments.

* Section 3.= 2, page 5:
  The initiator calls GSS_Init_s= ec_context(), using the
  input_context_handle for the c= urrent proto-security-context and its
  fixed set of input parameters,= and the input_token received from the
  acceptor (if not the first ite= ration of the loop).

Your use of proto-security-context would make it seem like this is a
parameter specified in RFC2473 but it is not. So I'd recommend to remove the hyphens. (BTW, at times you refer to "proto-security-context"= while
at others to just "security context"... why?)


* Section 3.2, Page 5:
(if not the first iteration of the loop)

Please rephrase as "(if this is not...)"


* Section 3.2, page 5:
However, there are some known
     implementati= ons of certain mechanisms which do produce empty
     context nego= tiation tokens.  For maximum interoperability,
     applications= should be prepa

It would be great if you could provide examples of such implementations.

* Section 3.4, page 6
It is likely appropriate
  for the acceptor to report thi= s error condition to the acceptor via
  the application's communicatio= n channel.


It should say:
  It is likely appropriate
  for the acceptor to report this error condition to the initiato= r via
  the application's communication channel.


* Section 3.5, page 7:
  The GSS acceptor calls GSS_Acc= ept_sec_context(), using the
  input_context_handle for the c= urrent proto-security-context and the
  input_token received from the = initiator

Again, remove the hyphens


* Section 4.1, page 10
Additional information can be
  available in GSS-API Naming Ex= tensions, [RFC6680].

s/can be/is/


* Section 5.1: You should clarify what's the convention for the return
codes of send_token() and receive_token(). Otherwise it's not clear
whether, when you use these functions, you're checking the return codes
correctly.


Thank you,
Tina
--_000_DBEACD8F3B2F4C56AC8347EB6F55E8F9huaweicom_-- From nobody Mon Feb 16 07:15:34 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84E11A1EF3; Mon, 16 Feb 2015 07:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPi3CNiej0Hq; Mon, 16 Feb 2015 07:15:24 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82211A1BD1; Mon, 16 Feb 2015 07:15:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4698; q=dns/txt; s=iport; t=1424099712; x=1425309312; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=snF/w3sjoTVx+1p6ver/ftqlyTcSAijv2XzbFkelXGw=; b=FbbfxNEf9lS8EaFsdFCK3Sj6sQ2KSuUE966TMO0nuykhnyDYZNo902Tz Y8Qt9bke9Cb61X9vP6KILOLE0L3DwRj9QTBmVT17uTJ6rS3fWg2TVcfzo A5DBFcD3kC0ESb/wxLxkdxiH8nBQDtoxsrvD3fp/LNQQhdm/JO967o+yz E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIGAMwI4lStJV2a/2dsb2JhbABTCYMGgSAMBIJ/vRCIGwIceEMBAQEBAQF8hAwBAQEDASMRPgcFCwIBBgIYAgImAgICMBUQAgQOBYglCJlXnGyWaAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYlrhBIoMweCaC6BFAEEjziFaoNNgRiDDYJLjB0iggEdgVBvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.09,588,1418083200"; d="scan'208";a="396592392" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 16 Feb 2015 15:15:12 +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 t1GFFB8G016002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Feb 2015 15:15:12 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Mon, 16 Feb 2015 09:15:11 -0600 From: "Francois Le Faucheur (flefauch)" To: "Klaas Wierenga (kwiereng)" Thread-Topic: review of draft-ietf-cdni-logging.15 Thread-Index: AQHQR6bsatwFQJOdLkuG1v9BlCIAFZzzy/wA Date: Mon, 16 Feb 2015 15:15:11 +0000 Message-ID: References: <493249E6-FD3B-46F3-AA3E-79ED26B594E1@cisco.com> In-Reply-To: <493249E6-FD3B-46F3-AA3E-79ED26B594E1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.200] Content-Type: text/plain; charset="utf-8" Content-ID: <6155DA3BDD6BD441BE3D35B0A07F172E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-cdni-logging.all@tools.ietf.org" , "Francois Le Faucheur \(flefauch\)" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] review of draft-ietf-cdni-logging.15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 15:15:27 -0000 SGksDQoNClRoYW5rIHlvdSBLbGFhcy4gV2XigJlsbCBsb29rIGludG8gdGhpcyBzaG9ydGx5Lg0K DQpGcmFuY29pcw0KDQo+IE9uIDEzIEZlYiAyMDE1LCBhdCAxNzowNSwgS2xhYXMgV2llcmVuZ2Eg KGt3aWVyZW5nKSA8a3dpZXJlbmdAY2lzY28uY29tPiB3cm90ZToNCj4gDQo+IEhpLA0KPiANCj4g SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGly ZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJl aW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBw cmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSAgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMu ICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1l bnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPiANCj4gVGhpcyBk b2N1bWVudCBzcGVjaWZpZXMgdGhlIGxvZ2dpbmcgZm9ybWF0IGFuZCB0aGUgZXhjaGFuZ2UgcHJv dG9jb2wgZm9yIGxvZ2dpbmcgaW5mb3JtYXRpb24gYmV0d2VlbiB1cHN0cmVhbSBhbmQgZG93bnN0 cmVhbSBDRE5zIHRoYXQgYXJlIGludGVyY29ubmVjdGVkIHVzaW5nIHRoZSBDRE4gaW50ZXJjb25u ZWN0aW9uIGZyYW1ld29yay4NCj4gDQo+IFRoZSBkb2N1bWVudCBpcyB3ZWxsIHdyaXR0ZW4gYW5k IGVhc3kgdG8gcmVhZC4gSSBoYXZlIGZldyBpc3N1ZXMgd2l0aCB0aGUgbWFpbiB0ZXh0LCBidXQg ZG8gaGF2ZSBzb21lIGNvbmNlcm5zIGFib3V0IHRoZSBzZWN1cml0eSBhbmQgcHJpdmFjeSBjb25z aWRlcmF0aW9ucy4gSSB0aGVyZWZvcmUgY29uc2lkZXIgdGhlIGRvY3VtZW50IOKAnHJlYWR5IHdp dGggaXNzdWVz4oCdDQo+IA0KPiBEZXRhaWxlZCBjb21tZW50czoNCj4gDQo+ICogSW50cm9kdWN0 aW9uIGFuZCBGaWd1cmUgMTogV2hhdCBpcyBub3QgY2xlYXIgdG8gbWUgZnJvbSB0aGUgdGV4dCBp cyB3aGV0aGVyIHRoZXJlIGlzIGFueSBmdW5jdGlvbmFsIGRpZmZlcmVuY2UgYmV0d2VlbiBhbiB1 Q0ROIGFuZCBhbiBkQ0ROLG9yIHRoYXQgdGhleSBqdXN0IGhhcHBlbiB0byBiZSBpbiBhIGhpZXJh cmNoaWNhbCByZWxhdGlvbiB0byBlYWNoIG90aGVyLiAgSSBjb3VsZCBhbHNvIGZpbmQgbm8gcmVm ZXJlbmNlIHRvIHRoYXQgaW4gUkZDNzMzNi4gVGhlIGZhY3QgdGhhdCBpbiBGaWd1cmUgMSBkQ0RO LTIgaXMgbm90IGFsc28gbGFiZWxlZCBhcyB1Q0ROLTIgbGVkIG1lIHRvIGJlbGlldmUgdGhhdCB0 aGVyZSBpcyBhIGZ1bmN0aW9uYWwgZGlmZmVyZW5jZS4gSG93ZXZlciBmcm9tIHRoZSB0ZXh0IGl0 IGFwcGVhcnMgdGhhdCBhbnkgdHdvIERDTnMgY2FuIGJlIGluIGFuIHUtZCByZWxhdGlvbiB0byBl YWNoIG90aGVyLiBQbGVhc2UgY2xhcmlmeS4NCj4gDQo+ICogUGFyYWdyYXBoIDMuMiAgQ0ROSSBM b2dnaW5nIEZpbGUgU3RydWN0dXJlDQo+IA0KPiBZb3Ugc3RhdGUgdGhhdCB5b3UgY2hvc2UgYSBm b3JtYXQgYXMgY2xvc2UgYXMgcG9zc2libGUgdG8gdGhlIFczQyBFTEYgRm9ybWF0LiBJ4oCZZCBs aWtlIHRvIHNlZSBhIHNob3J0IGV4cGxhbmF0aW9uIHdoeSB5b3UgY2FuIG5vdCB1c2UgdGhhdCBm b3JtYXQsIGFuZCB3aGV0aGVyIGl0IHdvdWxkIGJlIGFuIG9wdGlvbiB0byBleHRlbmQgdGhhdCBm b3JtYXQgcmF0aGVyIHRoYW4gZGVmaW5pbmcgYSBuZXcgZm9ybWF0IHRoYXQgaXMgc2xpZ2h0bHkg ZGlmZmVyZW50IGJ1dCBpcyBlc3NlbnRpYWxseSBhIGZvcm0gYW5kIGNvdWxkIG92ZXIgdGltZSBi ZSBzaWduaWZpY2FudGx5IGRpZmZlcmVudC4NCj4gDQo+ICogcGFyYWdyYXBoIDMuMyBEaXJlY3Rp dmVzDQo+IA0KPiBGb3IgdGhlIEludGVncml0eS1IYXNoIHlvdSB3cml0ZTogImhhc2ggZnVuY3Rp b24gb2YgYWxsIGxvZ2dpbmcgcmVjb3JkcyBhbmQgZGlyZWN0aXZlcyB1cCB0byB0aGUgaGFzaC1k aXJlY3RpdmUgaXRzZWxm4oCdLiBJIGhhdmUgbm90IHNlZW4gdGhhdCB0aGUgZGlyZWN0aXZlcyBh cmUgaW4gYSBzcGVjaWFsIG9yZGVyIHdpdGggdGhlIEludGVncml0eS1oYXN0IGFzIGxhc3Qgb25l LCBzbyBpdCBhcHBlYXJzIHRoYXQgd2hlbiB0aGUgaW50ZWdyaXR5LWhhc2ggZGlyZWN0aXZlIGlz IHRoZSB2ZXJ5IGZpcnN0IG9uZSB0aGVyZSB3aWxsIGJlIG5vIHNlbnNpYmxlIGhhc2guIFVubGVz cyB0aGVyZSBpcyBhY3R1YWwgb3JkZXIgaW4gdGhlIGRpcmVjdGl2ZXMgKHdyaXRlIHRoYXQgZG93 bikgSSBzdWdnZXN0IOKAnGhhcyBhbGwgbG9nZ2luZyBpbmZvcm1hdGlvbiBhbmQgZGlyZWN0aXZl cyB3aXRoIHRoZSBleGNlcHRpb24gb2YgdGhlIEludGVncml0eS1IYXNoIGRpcmVjdGl2ZSBpdHNl bGbigJ0NCj4gDQo+ICogUGFyYWdyYXBoIDcuMSBBdXRoZW50aWNhdGlvbiwgQ29uZmlkZW50aWFs aXR5LCBJbnRlZ3JpdHkgUHJvdGVjdGlvbg0KPiANCj4gWW91IGxlYXZlIG91dCB0aGUgM2QgQSwg QXV0aG9yaXphdGlvbiwgYnV0IHRoZW4geW91IHRhbGsgYWJvdXQgbXV0dWFsIGF1dGhlbnRpY2F0 aW9uIHRvIGRlY2lkZSB3aGV0aGVyIGFuIGVudGl0eSBpcyBhdXRob3Jpc2VkIHRvIHJlY2VpdmUg dGhlIGxvZ3MsIHNvIEkgdGhpbmsgeW91IHNob3VsZCBpbnNlcnQgaXQgdGhhdCBvbmUgdG9vLg0K PiANCj4gWW91IHN0YXRlIHRoYXQgdGhlIHVzZSBvZiBUTFMgZm9yIHRyYW5zcG9ydCBhbGxvd3Mg Zm9yIG11dHVhbCBhdXRoZW50aWNhdGlvbiwgY29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHks IHRoYXQgaW4gaXRzZWxmIGlzIG5vdCB0cnVlLiBZb3UgbmVlZCBUTFMgKyBtdXR1YWwgYXV0aGVu dGljYXRpb24gdG8gZ2V0IGNvbmZpZGVudGlhbGl0eSBhbmQgaW50ZWdyaXR5LiANCj4gDQo+IElu IHRoZSB0ZXh0IOKAnEluIGFuIGVudmlyb25tZW50IHdoZXJlIGFueSBzdWNoIHByb3RlY3Rpb24g aXMgcmVxdWlyZWTigKYu4oCdIFRMUyBpcyBhICJTSE9VTEQgdW5sZXNz4oCmLi7igJ0sIFdoeSBu b3Qg4oCcTVVTVCB1bmxlc3PigKYu4oCdDQo+IA0KPiAqIHBhcmFncmFwaCA3LjIgRG9TDQo+IA0K PiBJIGRvbuKAmXQgdW5kZXJzdGFuZCBob3cgdGhlIHVzZSBvZiBUTFMgcHJvdGVjdHMgYWdhaW5z IERvUywgb24gdGhlIGNvbnRyYXJ5IEkgd291bGQgc2F5LCB0cnlpbmcgdG8gZXN0YWJsaXNoIGEg VExTIHNlc3Npb24gaXMgY29zdGx5LCBzbyBhbiBldmlsIGVudGl0eSBjb3VsZCBlYXNpbHkgbW91 bnQgYSBEb1MgYnkgdHJ5aW5nIHRvIGNvbm5lY3QgYW5kIGV4Y2hhbmdlIGNyeXB0byBtYXRlcmlh bC4NCj4gDQo+IA0KPiBLbGFhcw0KPiANCj4gDQo+IC0tDQo+IEtsYWFzIFdpZXJlbmdhDQo+IElk ZW50aXR5IEFyY2hpdGVjdA0KPiBDaXNjbyBDbG91ZCBTZXJ2aWNlcw0KPiANCj4gDQo+IA0KPiAN Cj4gDQo+IA0KDQo= From nobody Mon Feb 16 14:16:32 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02781A6F22; Mon, 16 Feb 2015 14:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmuFhQ3G6ZiL; Mon, 16 Feb 2015 14:16:28 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B07F1A6ED9; Mon, 16 Feb 2015 14:16:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1358; q=dns/txt; s=iport; t=1424124988; x=1425334588; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=jPdg5GhXh8Il9rsLMTgFoYvdNGwk+dGNAtHLaF6nslg=; b=c8YDPMcQoT5xBM+kZ1O1El1Qp3lGJSxZRpQPpsJmD5bpO8ykNWSPoGwB Tw82Ye6F85AHl/RwjsSuSeDEoeyOlKu56XUHXFOFsOj1lYZ7mU+zKNF7Y VsWrbjR9sYPyVZ8VoPjKivUGiKgl84J5UprPHJ3Q6QOn/tp+gTnjdYEh4 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AHBQAXa+JU/5NdJa1bgwaBMMgtgRpDAQEBAQEBfIQTOj8SAT5CJwQBDYgyzjMBAQEBAQEBAQEBAQEBAQEBAQEBGY8iV4MdgRQFjziJN5MNIoNugXJBfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,590,1418083200"; d="scan'208";a="396592467" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP; 16 Feb 2015 22:16:28 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t1GMGRai030043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Feb 2015 22:16:28 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.126]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Mon, 16 Feb 2015 16:16:27 -0600 From: "Brian Weis (bew)" To: "secdir@ietf.org" , The IESG Thread-Topic: Secdir review of draft-ietf-bess-orf-covering-prefixes-03 Thread-Index: AQHQSjY0yliOlRO3G0WC3nxhYyYkig== Date: Mon, 16 Feb 2015 22:16:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.160.193] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-bess-orf-covering-prefixes.all@tools.ietf.org" Subject: [secdir] Secdir review of draft-ietf-bess-orf-covering-prefixes-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 22:16:30 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a new type of Outbound Route Filter (ORF), which is a directive sent to a BGP speaker requesting it to drop packets matching the filter. This can be used to avoid propogating traffic that will be filtered after delivery. The new ORF type is a Covering Prefixes ORF (CP-ORF), which has additional flexibility in specififying which addresses are to be filtered. The CP-ORF is stated as being useful within Virutal Hub-and-Spoke VPNs and EVPNs, both of which include a set of cooperating BGP speakers implementing a private network. Given that there is a general trust between the BGP speakers, the security considerations of the CP-ORF are few. The Security Considerations section describes how a BGP speaker can limit resource usage, and there is a pointer to the Security Considerations section of RFC 4271, which describes more generally how a BGP speaker can reject ORFs due to an=20 unwillingness to use additional resources. I consider this document Ready To Publish. Brian From nobody Tue Feb 17 10:24:40 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C331A8AF0; Tue, 17 Feb 2015 10:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE9OVI3zPL4S; Tue, 17 Feb 2015 10:24:32 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D81B1A1B84; Tue, 17 Feb 2015 10:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13860; q=dns/txt; s=iport; t=1424197471; x=1425407071; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=DLqvOzaYj2LD/aAP043/ukAiaecxM8U35/pjC8xVFXc=; b=PdAPpVCqy/BKjJC46iKr//YI15zSVVFAJqxPW2mC7IBtIAWcatSAH5VS XFUvY11ciOZdKVBArZkBBDGDdLYthG2yvEio8/tCLda8mFDEbgAc9OM/S 8pSyA67Lq5zj2REBZRH/PLFn0tpkvSbXrZ0LiTJe4wOxcqVviw2Cl5/Qz U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DLBABZhuNU/xbLJq1bgkOBFYNdv1SFbQKBWQEBAQEBAXyEDQEBBCNCExELIQQSCwICCQMCAQIBRQYBDAgBAYgrDblYl3cBAQEBAQEBAwEBAQEBAQEBFgSLD4R1gmiBQgWYb4EYhTeFd4MJgz4ig289gnQBAQE X-IronPort-AV: E=Sophos;i="5.09,595,1418083200"; d="scan'208,217";a="352542337" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 17 Feb 2015 18:24:28 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t1HIOSP8031211; Tue, 17 Feb 2015 18:24:28 GMT Message-ID: <54E3875C.5040108@cisco.com> Date: Tue, 17 Feb 2015 19:24:28 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Radia Perlman , "secdir@ietf.org" , The IESG , draft-ietf-lmap-framework.all@tools.ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050201070205090906050701" Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-lmap-framework-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 18:24:35 -0000 This is a multi-part message in MIME format. --------------050201070205090906050701 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Thanks Radia for your review. The authors have posted the v10. I believe it addresses your feedback. https://www.ietf.org/rfcdiff?url1=draft-ietf-lmap-framework-08&difftype=--html&submit=Go!&url2=draft-ietf-lmap-framework-10 I would appreciate if you could double-check. Regards, Benoit > I have reviewed this document as part of the security directorate's > ongoing > effort to review all IETF documents being processed by the IESG. Document > editors and WG chairs should treat these comments just like any other last > call comments. > > Summary: It's fine, though I couldn't resist making a few suggestions. > > LMAP is apparently a strained acronym for "Large-scale Measurement of > Access > network Performance", a collection of protocols designed for measuring the > capacity and responsiveness of connectivity provided by broadband ISPs, > though there may have been some feature creep as the protocols are > sufficiently general to be used for other things. This document is a > framework document defining terms and providing an overview of the > intended > deployment model (and intended to be INFORMATIONAL). There are companion > I-Ds specifying individual protocols in more detail. As such, most of the > security considerations would be discussed in those documents, though this > overview document provides an overview of the types of security > considerations to be discussed in those documents. > > The major components of LMAP are a Measurement Agent (MA) usually residing > on customer premises that runs periodic performance tests and reports > results, a Controller usually residing off-customer-premises that > configures > some large collection of Measurement Agents, and a Collector usually > residing off-customer-premises that receives and records reports from the > Measurement Agents. Those reports may contain statistical data concerning > normal operation of the MA's platform as well as the results of specific > tests. It is the Controller to MA and MA to Collector protocols that will > require rigorous security analysis and which are specified in different > documents within LMAP. The protocols whose performance is measured may > also > require a rigorous security analysis, but they are defined outside of > LMAP. > > The security considerations section lists the sorts of issues that > will need > to be dealt with in the other documents. It does not go into how those > issues are addressed; presumably the companion documents do. There is > a much > longer privacy considerations section that enumerates an intimidating > set of > potential privacy abuses that need to be mitigated. > > An important security consideration that I didn't see was dealing with the > case of a corrupted MA that reports falsified information to the > collector. > This might occur in the case where a customer wants it to appear that the > ISP is not meeting its commitments when in fact the ISP is. Whether > this can > be effectively mitigated depends on the platform on which the MA is > deployed, but where the MA is deployed on a customer-controlled > platform it > must be recognized that the data collected is to some degree inherently > untrustworthy. This means, for example, that in such configurations > the data > should not be used as the basis for a customer to get refunds of > subscription fees. > > I saw two questionable aspects of the design (at this level of > abstraction). > > The first has to do with who initiates the Controller to MA > connection. This > spec seems to imply that the connection can be initiated from either > end... > the Controller can initiate a connection to the MA when it wants to update > the MA's configuration and the MA and initiate a connection to the > controller to report errors and log debugging information. This is > problematic for several reasons. Most importantly, in many scenarios > the MA > might move around and therefore be difficult for the Controller to > find; or > it might be behind a NAT or other firewall and might not be capable of > accepting incoming connections (at least not without a lot of additional > effort). If all such connections were initiated by the MA, including a > polling interval configured by the controller, such configuration > issues go > away. > > Alternately, if the Controller initiated all connections, it becomes much > easier to protect the Controller from DoS attacks, since it is generally > much easier to attack a server than a client. But having connections being > initiated from both directions gives the worst of both worlds. > > The second has to do with the MA sending error and log reports to the > Controller. While it makes sense for the MA to report errors that occur in > processing Controller Instructions in the responses to those commands, > errors and logged events that occur asynchronously would seem (to me > anyway) > as more naturally being sent to the Collector, since its job is to harvest > massive amounts of information from lots of MAs. It is likely to be more > highly replicated and load balanced than the Controller, and thus more > capable of handling bursty loads. But this has little to do with security, > and I throw it out only for your consideration. > > Radia --------------050201070205090906050701 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Thanks Radia for your review.
The authors have posted the v10. I believe it addresses your feedback.
https://www.ietf.org/rfcdiff?url1=draft-ietf-lmap-framework-08&difftype=--html&submit=Go!&url2=draft-ietf-lmap-framework-10
I would appreciate if you could double-check.

Regards, Benoit
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.ย  Document
editors and WG chairs should treat these comments just like any other last
call comments.

Summary: It's fine, though I couldn't resist making a few suggestions.

LMAP is apparently a strained acronym for "Large-scale Measurement of Access
network Performance", a collection of protocols designed for measuring the
capacity and responsiveness of connectivity provided by broadband ISPs,
though there may have been some feature creep as the protocols are
sufficiently general to be used for other things. This document is a
framework document defining terms and providing an overview of the intended
deployment model (and intended to be INFORMATIONAL). There are companion
I-Ds specifying individual protocols in more detail. As such, most of the
security considerations would be discussed in those documents, though this
overview document provides an overview of the types of security
considerations to be discussed in those documents.

The major components of LMAP are a Measurement Agent (MA) usually residing
on customer premises that runs periodic performance tests and reports
results, a Controller usually residing off-customer-premises that configures
some large collection of Measurement Agents, and a Collector usually
residing off-customer-premises that receives and records reports from the
Measurement Agents. Those reports may contain statistical data concerning
normal operation of the MA's platform as well as the results of specific
tests. It is the Controller to MA and MA to Collector protocols that will
require rigorous security analysis and which are specified in different
documents within LMAP. The protocols whose performance is measured may also
require a rigorous security analysis, but they are defined outside of LMAP.

The security considerations section lists the sorts of issues that will need
to be dealt with in the other documents. It does not go into how those
issues are addressed; presumably the companion documents do. There is a much
longer privacy considerations section that enumerates an intimidating set of
potential privacy abuses that need to be mitigated.

An important security consideration that I didn't see was dealing with the
case of a corrupted MA that reports falsified information to the collector.
This might occur in the case where a customer wants it to appear that the
ISP is not meeting its commitments when in fact the ISP is. Whether this can
be effectively mitigated depends on the platform on which the MA is
deployed, but where the MA is deployed on a customer-controlled platform it
must be recognized that the data collected is to some degree inherently
untrustworthy. This means, for example, that in such configurations the data
should not be used as the basis for a customer to get refunds of
subscription fees.

I saw two questionable aspects of the design (at this level of abstraction).

The first has to do with who initiates the Controller to MA connection. This
spec seems to imply that the connection can be initiated from either end...
the Controller can initiate a connection to the MA when it wants to update
the MA's configuration and the MA and initiate a connection to the
controller to report errors and log debugging information. This is
problematic for several reasons. Most importantly, in many scenarios the MA
might move around and therefore be difficult for the Controller to find; or
it might be behind a NAT or other firewall and might not be capable of
accepting incoming connections (at least not without a lot of additional
effort). If all such connections were initiated by the MA, including a
polling interval configured by the controller, such configuration issues go
away.

Alternately, if the Controller initiated all connections, it becomes much
easier to protect the Controller from DoS attacks, since it is generally
much easier to attack a server than a client. But having connections being
initiated from both directions gives the worst of both worlds.

The second has to do with the MA sending error and log reports to the
Controller. While it makes sense for the MA to report errors that occur in
processing Controller Instructions in the responses to those commands,
errors and logged events that occur asynchronously would seem (to me anyway)
as more naturally being sent to the Collector, since its job is to harvest
massive amounts of information from lots of MAs. It is likely to be more
highly replicated and load balanced than the Controller, and thus more
capable of handling bursty loads. But this has little to do with security,
and I throw it out only for your consideration.

Radia

--------------050201070205090906050701-- From nobody Tue Feb 17 10:44:38 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255011A8A51; Tue, 17 Feb 2015 07:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhoOvMd9XBLT; Tue, 17 Feb 2015 07:34:36 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 429A91A8A49; Tue, 17 Feb 2015 07:34:35 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t1HFYYXe026454; Tue, 17 Feb 2015 08:34:34 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 17 Feb 2015 08:34:33 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Tue, 17 Feb 2015 08:34:32 -0700 From: Daryl Malas To: "Francois Le Faucheur (flefauch)" , "Klaas Wierenga (kwiereng)" Thread-Topic: review of draft-ietf-cdni-logging.15 Thread-Index: AQHQR6bsatwFQJOdLkuG1v9BlCIAFZzzy/wAgAG5RQA= Date: Tue, 17 Feb 2015 15:34:31 +0000 Message-ID: References: <493249E6-FD3B-46F3-AA3E-79ED26B594E1@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.4.7.141117 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 17 Feb 2015 10:44:37 -0800 Cc: "draft-ietf-cdni-logging.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] review of draft-ietf-cdni-logging.15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 15:34:42 -0000 Question for clarity in-line. On 2/16/15, 4:15 PM, "Francois Le Faucheur (flefauch)" wrote: >Hi, > >Thank you Klaas. We=B9ll look into this shortly. > >Francois > >> On 13 Feb 2015, at 17:05, Klaas Wierenga (kwiereng) >> wrote: >>=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 specifies the logging format and the exchange protocol >>for logging information between upstream and downstream CDNs that are >>interconnected using the CDN interconnection framework. >>=20 >> The document is well written and easy to read. I have few issues with >>the main text, but do have some concerns about the security and privacy >>considerations. I therefore consider the document =B3ready with issues=B2 >>=20 >> Detailed comments: >>=20 >> * Introduction and Figure 1: What is not clear to me from the text is >>whether there is any functional difference between an uCDN and an >>dCDN,or that they just happen to be in a hierarchical relation to each >>other. I could also find no reference to that in RFC7336. The fact that >>in Figure 1 dCDN-2 is not also labeled as uCDN-2 led me to believe that >>there is a functional difference. However from the text it appears that >>any two DCNs can be in an u-d relation to each other. Please clarify. In Figure 1 of RFC 7336, you will notice the interfaces are indicated as bi-directional. I believe the spirit of this is to provide a hierarchal perspective. In any case, can you please clarify your =B3security=B2 relat= ed concerns relative to this scenario? So far, you have only indicated a question of whether a downstream CDN can also be an upstream CDN. What is your related security question if the function changes relative to exchanges via the logging interfaces? If this is a terminology question, I think it should have been addressed with regards to 7336. To be clear, I=B9m just asking for more clarity for the authors to properly address this question. >>=20 >> * Paragraph 3.2 CDNI Logging File Structure >>=20 >> You state that you chose a format as close as possible to the W3C ELF >>Format. I=B9d like to see a short explanation why you can not use that >>format, and whether it would be an option to extend that format rather >>than defining a new format that is slightly different but is essentially >>a form and could over time be significantly different. >>=20 >> * paragraph 3.3 Directives >>=20 >> For the Integrity-Hash you write: "hash function of all logging records >>and directives up to the hash-directive itself=B2. I have not seen that >>the directives are in a special order with the Integrity-hast as last >>one, so it appears that when the integrity-hash directive is the very >>first one there will be no sensible hash. Unless there is actual order >>in the directives (write that down) I suggest =B3has all logging >>information and directives with the exception of the Integrity-Hash >>directive itself=B2 >>=20 >> * Paragraph 7.1 Authentication, Confidentiality, Integrity Protection >>=20 >> You leave out the 3d A, Authorization, but then you talk about mutual >>authentication to decide whether an entity is authorised to receive the >>logs, so I think you should insert it that one too. >>=20 >> You state that the use of TLS for transport allows for mutual >>authentication, confidentiality and integrity, that in itself is not >>true. You need TLS + mutual authentication to get confidentiality and >>integrity.=20 >>=20 >> In the text =B3In an environment where any such protection is required= =8A.=B2 >>TLS is a "SHOULD unless=8A..=B2, Why not =B3MUST unless=8A.=B2 >>=20 >> * paragraph 7.2 DoS >>=20 >> I don=B9t understand how the use of TLS protects agains DoS, on the >>contrary I would say, trying to establish a TLS session is costly, so an >>evil entity could easily mount a DoS by trying to connect and exchange >>crypto material. >>=20 >>=20 >> Klaas >>=20 >>=20 >> -- >> Klaas Wierenga >> Identity Architect >> Cisco Cloud Services >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 > From nobody Tue Feb 17 11:54:36 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F0D1A1B49; Tue, 17 Feb 2015 11:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_capRv6gOHW; Tue, 17 Feb 2015 11:54:32 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774891A1ABE; Tue, 17 Feb 2015 11:54:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 4204BE2036; Tue, 17 Feb 2015 14:54:31 -0500 (EST) 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 03249-08; Tue, 17 Feb 2015 14:54:29 -0500 (EST) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id EDDB1E2035; Tue, 17 Feb 2015 14:54:28 -0500 (EST) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t1HJsRu1012059; Tue, 17 Feb 2015 14:54:27 -0500 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Tue, 17 Feb 2015 14:54:26 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: koenvos74@gmail.com, jspittka@gmail.com, jmvalin@jmvalin.ca, payload-chairs@tools.ietf.org Subject: [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 19:54:34 -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 with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Ready to publish with a question: I question why the use of SRTP is a MAY and not a SHOULD (as detailed in the Security Considerations section). Considering PERPASS I believe this should be a SHOULD; someone should have a very good reason why they are NOT using SRTP. Details: This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus encoded speech and audio data necessary to integrate the codec in the most compatible way. Further, it describes media type registrations for the RTP payload format. I have no other comments on this document. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Feb 17 15:10:17 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F601A8862; Tue, 17 Feb 2015 15:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4mFPxcCDFJq; Tue, 17 Feb 2015 15:10:14 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0FEF1A1AB5; Tue, 17 Feb 2015 15:10:13 -0800 (PST) X-AuditID: 1209190d-f792d6d000001fc7-bc-54e3ca540127 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 4F.7F.08135.45AC3E45; Tue, 17 Feb 2015 18:10:12 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t1HNABGj007862; Tue, 17 Feb 2015 18:10:12 -0500 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1HNA9Pf017191; Tue, 17 Feb 2015 18:10:10 -0500 From: Tom Yu To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org Date: Tue, 17 Feb 2015 18:10:08 -0500 Message-ID: Lines: 38 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUixCmqrBty6nGIwb4P6hYr+qcxWsz4M5HZ 4sPChywOzB5Llvxk8vhy+TNbAFMUl01Kak5mWWqRvl0CV0bXQd6CmfwV575eYG1gXMPTxcjJ ISFgIvFqyz4mCFtM4sK99WxdjFwcQgKLmSRudnYzQjgbGSWmzHvIDOG8YZRY0LaFEaSFTUBa 4vjlXWDtIgJxEu82L2MHsYUFrCVWP/7BBmKzCKhK/LjbyQJi8wroSuw/e4cZxOYR4JRYuK6L HSIuKHFy5hOwGmYBLYkb/14yTWDknYUkNQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJd I73czBK91JTSTYzgkJLk3cH47qDSIUYBDkYlHl6LCY9ChFgTy4orcw8xSnIwKYnyBh55HCLE l5SfUpmRWJwRX1Sak1p8iFGCg1lJhFfpBFCONyWxsiq1KB8mJc3BoiTOu+kHX4iQQHpiSWp2 ampBahFMVoaDQ0mCd95JoEbBotT01Iq0zJwShDQTByfIcB6g4YdBaniLCxJzizPTIfKnGBWl xHmngSQEQBIZpXlwvbCYf8UoDvSKMK80SBUPMF3Adb8CGswENHj+n0cgg0sSEVJSDYzMC/UO TmzbcMRpOst8vT+curoLKrImcD8MDvmxoiv0yFfLjmCRjE7/hxqWej7KEvNKDL5/vPqizcdk wzylEB+2z5ZT1jzqCvbxUMqS4tsn4aj6ZPWXf7z9ttvM/vgYSp7/Y/pC8OHjZ2s8HAryBDyC 3v9S/CI1+cg66w/ztqUeYHF0zkt3ZFBiKc5INNRiLipOBAB2I9ks1AIAAA== Archived-At: Subject: [secdir] secdir review of draft-ietf-mpls-proxy-lsp-ping-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 23:10:16 -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: ready with nits The Security Considerations section seems mostly adequate, assuming that it is an acceptable risk to use address-based filtering. I am a little concerned about the wording of the destination address checks on the proxy ping requests. Shouldn't the Proxy LSR know what its own addresses are, and explicitly check for them? Does "Martian" filtering refer to all undesired destination addresses, or just reserved ones? There seems to be no citation for the term "Martian address" as used in sections 3.2 and 6 of this document; RFC 3704 comes close. If that definition is appropriate here, perhaps this document should cite RFC 3704? I think I have also heard "Martian" used more expansively to refer to other address blocks that should not be routed, despite not being formally reserved (e.g., unallocated by the responsible registry). Perhaps that definition is more appropriate. Editorial: The use of destination addresses in range 127/8 seems odd to me, but I eventually found that RFC 4379 allows the use of such loopback range addresses for the LSP echo requests. Is this correct? It might be good to briefly explain that unusual usage. Also, I am not too familiar with the special IPv6 address ranges, but it seems that ::FFFF:7F00:0/104 is a IPv4-mapped loopback range, and therefore is equivalent to the 127/8 IPv4 range mentioned earlier. I don't know whether you need to call this out specifically. Also, RFC 4379 uses the notation ::FFFF:127/104. I'm not sure which of those notations is preferred for IPv4-mapped addresses. From nobody Tue Feb 17 20:01:35 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE8B1A916F; Tue, 17 Feb 2015 20:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ME1auxUTuAh; Tue, 17 Feb 2015 20:01:20 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57C671A8AF6; Tue, 17 Feb 2015 20:01:19 -0800 (PST) X-AuditID: 1209190f-f79546d000007593-d3-54e40e8d97ae Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 56.E9.30099.E8E04E45; Tue, 17 Feb 2015 23:01:18 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t1I41GSP009798; Tue, 17 Feb 2015 23:01:17 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1I41DSS011259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Feb 2015 23:01:15 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1I41DY3017027; Tue, 17 Feb 2015 23:01:13 -0500 (EST) Date: Tue, 17 Feb 2015 23:01:13 -0500 (EST) From: Benjamin Kaduk To: Tina TSOU In-Reply-To: Message-ID: References: <05dd01d04831$7f1feb20$7d5fc160$@nict.go.jp> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT0e3jexJisPQJi8XH+9tYLGb8mchs cejCcUaLDwsfslgc/b2W1YHVo+XIW1aPJUt+Mnl8ufyZLYA5issmJTUnsyy1SN8ugSvj/PM7 7AXrJSumz/vA3MDYKNLFyMkhIWAisXPCJTYIW0ziwr31QDYXh5DAYiaJA6fbmCCcjYwSf24d h3IOMUlcfPWdFcJpYJTYO20KE0g/i4C2xIMVH1hBbDYBFYmZbzaCzRUR0JHY1bYLbC6zwGdG iUszZzGDJIQFrCX2zJ7JAmJzCthJbNz2gB3E5hVwkFh08wuYLSSQJfHq8RmwBaJAg1bvn8IC USMocXLmEzCbWUBLYvn0bSwTGAVnIUnNQpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdE LzezRC81pXQTIyisOSX5dzB+O6h0iFGAg1GJh7eD6UmIEGtiWXFl7iFGSQ4mJVHepO+PQ4T4 kvJTKjMSizPii0pzUosPMUpwMCuJ8CqdAMrxpiRWVqUW5cOkpDlYlMR5N/3gCxESSE8sSc1O TS1ILYLJynBwKEnwFvMC7REsSk1PrUjLzClBSDNxcIIM5wEa/oUHqIa3uCAxtzgzHSJ/ilFR SpxXD6RZACSRUZoH1wtLO68YxYFeEebdB1LFA0xZcN2vgAYzAQ2e/+cRyOCSRISUVANj2VpJ 36vBZv9OTqxdsGfhogYOybXtTUavV63MbD68+cM6jqtvd76957y/p+Wh0K69t8uKpJc6/1/D Ja6SO3vu2p//qiPFV916x84ordm8XyHhaNDV6M4TuwUv7uj4nKqQcUfsCWuXQKIVg1gabxjP rQ+f1t3VC2bmmyu0ftvb+pVcczaeu5yprMRSnJFoqMVcVJwIAGqPff8WAwAA Archived-At: Cc: "draft-ietf-kitten-gss-loop.all@tools.ietf.org" , "kitten-chairs@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-kitten-gss-loop-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 04:01:26 -0000 On Sun, 15 Feb 2015, Tina TSOU wrote: > Dear all, > > I have reviewed current version of 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. Thank you for the review. > * Section 3.2, page 5: > The initiator calls GSS_Init_sec_context(), using the > input_context_handle for the current proto-security-context and its > fixed set of input parameters, and the input_token received from the > acceptor (if not the first iteration of the loop). > > Your use of proto-security-context would make it seem like this is a > parameter specified in RFC2473 but it is not. So I'd recommend to remove > the hyphens. (BTW, at times you refer to "proto-security-context" while > at others to just "security context"... why?) The use of "proto-" was to indicate that this was a security context which is not fully established; that is, one for which the establishment process is still under way. Since this is confusing, I think I would rather change it to "security context being established" instead of just removing the hyphens. > * Section 3.2, Page 5: > > (if not the first iteration of the loop) > > Please rephrase as "(if this is not...)" Okay. > * Section 3.2, page 5: > However, there are some known > implementations of certain mechanisms which do produce empty > context negotiation tokens. For maximum interoperability, > applications should be prepa > > It would be great if you could provide examples of such implementations. I believe the NTLMSSP mechanism is the main example. I am not sure what the best reference to use for it is, though. > * Section 3.4, page 6 > It is likely appropriate > for the acceptor to report this error condition to the acceptor via > the application's communication channel. > > > It should say: > It is likely appropriate > for the acceptor to report this error condition to the initiator via > the application's communication channel. Thank you for spotting this (Gen-ART did as well). > * Section 3.5, page 7: > The GSS acceptor calls GSS_Accept_sec_context(), using the > input_context_handle for the current proto-security-context and the > input_token received from the initiator > > Again, remove the hyphens As above. > * Section 4.1, page 10 > Additional information can be > available in GSS-API Naming Extensions, [RFC6680]. > > s/can be/is/ I believe that "can be" is appropriate, since the naming extensions from RFC 6680 are not universally deployed. > * Section 5.1: You should clarify what's the convention for the return > codes of send_token() and receive_token(). Otherwise it's not clear > whether, when you use these functions, you're checking the return codes > correctly. I think that the intent is clear from the return code checking where they are used, but will add a comment above the implementations, "Returns 0 on success, non-zero on failure." Thank you, Ben From nobody Wed Feb 18 00:15:29 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2144F1A911A; Wed, 18 Feb 2015 00:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErMDMgNvCmVd; Wed, 18 Feb 2015 00:15:25 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 20B721A9115; Wed, 18 Feb 2015 00:15:25 -0800 (PST) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 0E1C2F984; Wed, 18 Feb 2015 03:15:20 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id BB7A92000A; Wed, 18 Feb 2015 03:15:27 -0500 (EST) From: Daniel Kahn Gillmor To: draft-ietf-httpauth-basicauth-update.all@tools.ietf.org User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 18 Feb 2015 03:15:24 -0500 Message-ID: <874mqjd49v.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-httpauth-basicauth-update-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 08:15:28 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable This is a secdir review of draft-ietf-httpauth-basicauth-update-06 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. Overview =3D=3D=3D=3D=3D=3D=3D=3D This draft updates the HTTP Basic Authentication scheme with a charset parameter, whose only allowed value is "UTF-8". I believe the draft is almost ready, but there are some issues, described below. Security and Privacy Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Should recommend strong password-hashing on the server side =2D---------------------------------------------------------- The Security Considerations section acknowledges that passwords can be stolen from servers, but does not encourage server operators to hash stored passwords with a reasonable or strong algorithm. This document may not be the place to provide normative guidance on how to store passwords to mitigate the exposure of a password table, but perhaps a brief mention and an informative reference would be useful? Many systems (e.g. modern nginx and apache) use 1000 iterations of salted MD5, but still support cleartext passwords, crypt(), and unsalted SHA-1, which are all terrible. https://httpd.apache.org/docs/2.4/misc/password_encryptions.html http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html#auth_basic_u= ser_file an informative reference might point to the Password Hashing Competition, which documents sensible rationales for why you should use strong password hashing, and how to know it when you see it: https://password-hashing.net by comparison the digest draft has a lot more about how passwords should be stored (even though Digest auth can offer only weaker protections for the password store compared to Basic auth): https://tools.ietf.org/html/draft-ietf-httpauth-digest-13#section-5.2 Should recommend constant-time server-side comparisons =2D----------------------------------------------------- Servers that implement basic auth should not leak information about the stored password via timing of rejections. For example, a server that stored cleartext passwords (which is a bad idea anyway) should mechanically compare the entire string instead of bytewise comparisons. The attack here is an attacker who guesses credentials a byte at a time, by making 256 initial guesses and seeing which of them gets back a rejection faster than the other (and iterates down the list). This might be less of an issue for reasonable (non-cleartext) password storage, but if we're not requiring strong password hashing, we should at least require constant time comparisons. Should recommend padding the Authorization: response =2D--------------------------------------------------- When used behind HTTPS as recommended, TLS hides the username and password presented. However, it does not hide the length of the username and password if the other parameters of the HTTPS request are known. An active attacker who wants to learn the length of the victim's username and password together for a particular basic auth realm could force the user's browser to make HTTPS requests to a few different URLs within the realm and see how large the packets are. This could be mitigated by including whitespace padding in the client's Authorization: header itself up to some multiple of a blocksize (perhaps 256B) to obscure the length. UTF-8 security considerations by reference: is this OK? =2D----------------------------------------- The Security Considerations section includes the UTF-8 security considerations section by reference, but doesn't call out any specific issues for implementers to be aware of. the NFC canonicalization draft also has Security Considersations section, which is not included by reference: https://tools.ietf.org/html/rfc5198#section-6 Interaction with proxies? =2D------------------------ There is only a passing mention of Proxy-Authenticate: and Proxy-Authorization: headers, so one assumes that both mechanisms should support this new auth-param. It's not clear to me whether there are any additional security or privacy implications when this is addressed to proxies compared to origin servers. Section 2.2 ("reusing credentials") talks about the URI path (presumably for "WWW-Authenticate", but then mixes "Proxy-Authenticate" into the middle of that commentary. It looks to me like "Proxy-Authenticate" is not intended to be scoped by the URI path (there is no mention of "in that space" in the sentence about Proxy-Authenticate in Section 2.2), but this is kind of ambiguous. Clarification would be good. Path matching? =2D------------- Nothing in the security considerations section talks about the threat that motivates path matching for determination of which realm to use. It might be useful to spell this out explicitly: * A user agent that sends the Authorization: header to URLs outside the authentication scope as described in Section 2.2 may leak the user's credentials User Agent visibility and logout? =2D-------------------------------- Most RFCs don't talk at all about the human interface of the mentioned tools. But this draft refers briefly to interaction between the user and the User Agent (see step 1 on https://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-06#page-6). However, it provides no other guidance. There are several additional guidelines that make basic authentication more acceptable from a privacy and security point of view for a typical web browser User Agent: * user agents should indicate to the user when they are re-using the user's authentication credentials as described in section 2.2 (indicating the realm, authentication scope, and user-id?) * user agents should not display the user's password anywhere by default * user agents should make it straightforward for users to clear their credentials for any . https://tools.ietf.org/html/rfc7235#section-6.3 includes some of these guidelines; perhaps this is another include-by-reference? Other Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Deployment chicken-and-egg =2D------------------------- The server has no way of knowing that the client is trying to obey the charset header. For the servers mentioned in that do user-agent sniffing, it's not clear how those servers could ever know to stop relying on the user-agent, since the clients have no way of signalling their intent to use UTF-8 for the Authorization header. If the servers don't know when to start accepting UTF-8 from these clients, then the clients also have no way of knowing when they should switch over themselves. This strikes me as a recipe for stalled adoption, since "user agents in the latter group" (from section B.3) will never use UTF-8, even if they know about it. If we want to avoid the adoption stall, we might need more forceful language to discourage user agents from trying to guess whether they are in "the latter group" User IDs with Colons =2D------------------- The draft says "a user-id containing a colon character is invalid" -- why not say that "the user-id MUST NOT contain a colon character", as it already does for control characters? Nits =3D=3D=3D=3D * in B.3, "Authentication on these sites will stop to work" should be "Authentication on these sites will stop working" Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJU5EodXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcU60P/2ICGeo3y44Tg3jNzBzTtgBu FPfuPuv2F6RJF5o5MgVebYKD/q8wRkc1WFIW7dNXnim4I3GftssHhAPpTt9PvggE G4Lr3YET9sUzMSXkzcZgtHbOBrgwM1mwn5ywry/1vK20jGfsUBLCVYKU8/zU47/9 3jsTwCdf0hQzLeDS4EhTgTg7vLPRRZuJ7KZTrqV/OCy42wB9+FMqkllnX0V+xHiQ 9vJcIO20dUD9J5JCJoy4Q31IYcnAPMjLTWNY1BzT0CIr/agRYR+8DSkq7/QgdjjW MMqSpBwk18sRZZJ+LiugNt72qTN+CNFKPdodXoLc3JeHWwp1OZ+xOFM9JEQmOktx fyIl81Ll0o7VlyG0YYCMV58v3eyycReDxyG/kWMFeKu5GsFQchPnmy6OL6j9aEHc VyGBW/ttw6SfRZP7rkCqo40kAsf+k4o+JzJIxG9vmxJSPZoWQS6a1WfU3bEE538f 1iM1in6tPqagMz4V3zzXjfbuofqQUWNDEXbRCgUv+d4H15kS+B4hXghJycwUafPe qV4AVKUGdhf+G9KdwIG0J4m8mdgsKlTuaJeoj4ijW5hFqjUCDWhYDR58AhzBzBwW mOoZCSAt6bIiRWYRJp8UUmbGkD08QGDZMsWjlSKFD77Vng3sBvBYs1z+71bfjFdz 1fDsf5Hv+6fAnufeD09Y =Og3Q -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 18 06:17:08 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F9A1A87ED for ; Wed, 18 Feb 2015 06:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysDmjs0NpbnT for ; Wed, 18 Feb 2015 06:17:05 -0800 (PST) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.93.179.25]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71FEB1A87BF for ; Wed, 18 Feb 2015 06:17:05 -0800 (PST) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id DA609D1D1AA32; Wed, 18 Feb 2015 08:17:04 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway14.websitewelcome.com (Postfix) with ESMTP id A8BB0D1D1A9C7 for ; Wed, 18 Feb 2015 08:17:04 -0600 (CST) Received: from [96.231.221.128] (port=53853 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YO5R1-0005MB-SP; Wed, 18 Feb 2015 08:17:03 -0600 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Feb 2015 09:17:01 -0500 Message-Id: <79A24849-274F-4E45-BDED-1EE103D484B8@ieca.com> To: draft-ietf-mif-mpvd-arch.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) 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-IP: 96.231.221.128 X-Exim-ID: 1YO5R1-0005MB-SP X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [96.231.221.128]:53853 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: The IESG , secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-mif-mpvd-arch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 14:17:06 -0000 Fear not as this is just the secdir review! I have reviewed this document as part of the security directorate=92s = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written with the intent of improving security = requirements and considerations in IETF drafts. Comments not addressed = in last call may be included in AD reviews during the IESG review. = Document editors and WG chairs should treat these comments just like any = other last call comments. Summary: Ready with nits. Nits: 0. s1.1: This section can be removed because there=92s no 2119-language = in the draft, but that can be done by the RFC editor later. 1. s3.5: Somebody once suggested adding an IKEv2 payload for = configuration data and got their head handed to them. I guess it=92s = fine to leave the paragraph in the draft because this is just a possible = solution, but I=92d not count on it as a viable option. 2. s4.2: Makes me think of Fernado=92s VPN leaks RFC: = http://datatracker.ietf.org/doc/rfc7359/. 3. s5.2.1: Makes me hope that the if there=92s two connections and one = is a VPN that lookups meant for that connection is only done over that = connection and not leaked out. I think this is covered later in the = section though. spt From nobody Wed Feb 18 10:00:45 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78441A8ACA; Wed, 18 Feb 2015 10:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDU0P51Kuz1F; Wed, 18 Feb 2015 10:00:42 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6220B1A8AC9; Wed, 18 Feb 2015 10:00:42 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 19C8DDA0229; Wed, 18 Feb 2015 18:00:42 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id D89D353E083; Wed, 18 Feb 2015 10:00:41 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 18 Feb 2015 10:00:41 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <79A24849-274F-4E45-BDED-1EE103D484B8@ieca.com> Date: Wed, 18 Feb 2015 13:00:26 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <008B9168-0AF1-4AE5-A316-4EEBD97C63FD@nominum.com> References: <79A24849-274F-4E45-BDED-1EE103D484B8@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: secdir@ietf.org, The IESG , draft-ietf-mif-mpvd-arch.all@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-mif-mpvd-arch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 18:00:43 -0000 On Feb 18, 2015, at 9:17 AM, Sean Turner wrote: > 3. s5.2.1: Makes me hope that the if there=92s two connections and one = is a VPN that lookups meant for that connection is only done over that = connection and not leaked out. I think this is covered later in the = section though. I think you may have used the wrong preposition here, and consequently = I'm having trouble parsing this. Can you restate? From nobody Wed Feb 18 14:19:07 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5371A1B5A; Wed, 18 Feb 2015 14:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKaMTIMBJhJk; Wed, 18 Feb 2015 14:19:01 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 552D91A1B47; Wed, 18 Feb 2015 14:19:01 -0800 (PST) Received: from [192.168.2.175] ([93.217.116.45]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MTSmp-1Xx51s40Ih-00SS56; Wed, 18 Feb 2015 23:18:48 +0100 Message-ID: <54E50FC3.9080708@gmx.de> Date: Wed, 18 Feb 2015 23:18:43 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org References: <874mqjd49v.fsf@alice.fifthhorseman.net> In-Reply-To: <874mqjd49v.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:P4Um3TMahQ08+sqXfbHSGNHKDCJb9mkvR8sfWMjat5uSt8fYj2d I3pQIRzf9knYc2MvCU/hS2PaHADInHKIpgBlpE+k7v9n6A7Ki/K7AyCfjwkPPXwluoDO4VE 9yJIkQQA/c5pKRyugQnxu3e0+CesVzl1cWQ+09IzlzyanpfWuG/2oASGDYr+SkXtUpaT1SF Qfm10b0SIDoVhOKyb5B4A== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-httpauth-basicauth-update-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 22:19:06 -0000 Hi Daniel, thanks for the review. Feedback in-line. On 2015-02-18 09:15, Daniel Kahn Gillmor wrote: > ... > Should recommend strong password-hashing on the server side > ----------------------------------------------------------- > > The Security Considerations section acknowledges that passwords can be > stolen from servers, but does not encourage server operators to hash > stored passwords with a reasonable or strong algorithm. This document > may not be the place to provide normative guidance on how to store > passwords to mitigate the exposure of a password table, but perhaps a > brief mention and an informative reference would be useful? Many > systems (e.g. modern nginx and apache) use 1000 iterations of salted > MD5, but still support cleartext passwords, crypt(), and unsalted SHA-1, > which are all terrible. > > https://httpd.apache.org/docs/2.4/misc/password_encryptions.html > http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html#auth_basic_user_file > > an informative reference might point to the Password Hashing > Competition, which documents sensible rationales for why you should use > strong password hashing, and how to know it when you see it: > > https://password-hashing.net > > by comparison the digest draft has a lot more about how passwords should > be stored (even though Digest auth can offer only weaker protections for > the password store compared to Basic auth): > > https://tools.ietf.org/html/draft-ietf-httpauth-digest-13#section-5.2 > ... I would really like to avoid talking about threads that are generic to password-based authentication. Optimally, the security area would have a document that discusses exactly these kind of things so that other specs can reference that. Does something like this exist? Or do you want to propose concrete text? > Should recommend constant-time server-side comparisons > ------------------------------------------------------ > > Servers that implement basic auth should not leak information about > the stored password via timing of rejections. For example, a server > that stored cleartext passwords (which is a bad idea anyway) should > mechanically compare the entire string instead of bytewise comparisons. > The attack here is an attacker who guesses credentials a byte at a time, > by making 256 initial guesses and seeing which of them gets back a > rejection faster than the other (and iterates down the list). > > This might be less of an issue for reasonable (non-cleartext) password > storage, but if we're not requiring strong password hashing, we should > at least require constant time comparisons. Do you seriously believe that the time for a string comparison is relevant compared to the overhead of two network hops plus encapsulation into HTTP messages? > Should recommend padding the Authorization: response > ---------------------------------------------------- > > When used behind HTTPS as recommended, TLS hides the username and > password presented. However, it does not hide the length of the > username and password if the other parameters of the HTTPS request are > known. > > An active attacker who wants to learn the length of the victim's > username and password together for a particular basic auth realm could > force the user's browser to make HTTPS requests to a few different URLs > within the realm and see how large the packets are. > > This could be mitigated by including whitespace padding in the client's > Authorization: header itself up to some multiple of a blocksize (perhaps > 256B) to obscure the length. Actually, padding can happen anywhere in the message; it doesn't need to be in this header field. It's an interesting idea; have you checked whether existing User Agents do this? > UTF-8 security considerations by reference: is this OK? > ------------------------------------------ > > The Security Considerations section includes the UTF-8 security > considerations section by reference, but doesn't call out any specific > issues for implementers to be aware of. the NFC canonicalization draft Intentionally. > also has Security Considersations section, which is not included by > reference: > > https://tools.ietf.org/html/rfc5198#section-6 I'll add that. > Interaction with proxies? > ------------------------- > > There is only a passing mention of Proxy-Authenticate: and > Proxy-Authorization: headers, so one assumes that both mechanisms should > support this new auth-param. It's not clear to me whether there are any > additional security or privacy implications when this is addressed to > proxies compared to origin servers. I'm not aware of any. > Section 2.2 ("reusing credentials") talks about the URI path (presumably > for "WWW-Authenticate", but then mixes "Proxy-Authenticate" into the > middle of that commentary. It looks to me like "Proxy-Authenticate" is > not intended to be scoped by the URI path (there is no mention of "in > that space" in the sentence about Proxy-Authenticate in Section 2.2), > but this is kind of ambiguous. Clarification would be good. To be frank, I don't know. My best guess is that it works exactly the same, so I'll add "in that space" there as well. > Path matching? > -------------- > > Nothing in the security considerations section talks about the threat > that motivates path matching for determination of which realm to use. > It might be useful to spell this out explicitly: > > * A user agent that sends the Authorization: header to URLs outside the > authentication scope as described in Section 2.2 may leak the user's > credentials That applies to all schemes that use protection spaces and is mentioned in already. > User Agent visibility and logout? > --------------------------------- > > Most RFCs don't talk at all about the human interface of the mentioned > tools. > > But this draft refers briefly to interaction between the user and the > User Agent (see step 1 on > https://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-06#page-6). > However, it provides no other guidance. There are several additional > guidelines that make basic authentication more acceptable from a privacy > and security point of view for a typical web browser User Agent: > > * user agents should indicate to the user when they are re-using the > user's authentication credentials as described in section 2.2 > (indicating the realm, authentication scope, and user-id?) They don't right now. Do you believe that requiring it will have any effect on existing UAs? > * user agents should not display the user's password anywhere by > default That sounds pretty obvious. > * user agents should make it straightforward for users to clear their > credentials for any . Define "straightforward". > https://tools.ietf.org/html/rfc7235#section-6.3 includes some of these > guidelines; perhaps this is another include-by-reference? All security considerations of RFC 7235 apply by definition, as this spec is using the framework defined by RFC 7235. I don't believe that we need to state this. > Other Considerations > ==================== > > Deployment chicken-and-egg > -------------------------- > > The server has no way of knowing that the client is trying to obey the > charset header. For the servers mentioned in that do user-agent Actually, it could apply heuristics. I header detection of UTF-8 is quire reliable. > sniffing, it's not clear how those servers could ever know to stop > relying on the user-agent, since the clients have no way of signalling > their intent to use UTF-8 for the Authorization header. If the servers > don't know when to start accepting UTF-8 from these clients, then the > clients also have no way of knowing when they should switch over > themselves. This strikes me as a recipe for stalled adoption, since > "user agents in the latter group" (from section B.3) will never use > UTF-8, even if they know about it. I don't see why the server can't just start accepting UTF-8 right away. > If we want to avoid the adoption stall, we might need more forceful > language to discourage user agents from trying to guess whether they are > in "the latter group" Do you believe that will affect what existing sites do today? > User IDs with Colons > -------------------- > > The draft says "a user-id containing a colon character is invalid" -- > why not say that "the user-id MUST NOT contain a colon character", as it > already does for control characters? I don't think it really matters how we say it (both have exactly the same normative power), but I agree it would be better for consistency. > Nits > ==== > > * in B.3, "Authentication on these sites will stop to work" should be > "Authentication on these sites will stop working" Ok. Best regards, Julian From nobody Wed Feb 18 14:45:56 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA4E1A1B60; Wed, 18 Feb 2015 14:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxZGqQU5EYhq; Wed, 18 Feb 2015 14:45:53 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8081A1B83; Wed, 18 Feb 2015 14:45:53 -0800 (PST) Received: from [192.168.2.175] ([93.217.116.45]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M7CRe-1XbS2N357e-00x7Cc; Wed, 18 Feb 2015 23:45:49 +0100 Message-ID: <54E5161A.5050606@gmx.de> Date: Wed, 18 Feb 2015 23:45:46 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> In-Reply-To: <54E50FC3.9080708@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:94YCzVSQOzpgcGdlCkI92Z91E8zK8C+JNULuPlPFTl38zja28RW c9k43gk0ZCmuAIQQEL83eVHg6ALW7EiLzJN/Vsr9gFDFSzTBD5rqhyGrD/D1YjViYcs2CEM UKimPV3bAJorjb6BL//Lzi7TLrYhNDe7dn9k+Gm0JrvzWOoGJY0p2SuPXTCDYVpnnSsU0R0 q0Q3NkJqhkfTbrc0gL6KQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-httpauth-basicauth-update-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 22:45:55 -0000 On 2015-02-18 23:18, Julian Reschke wrote: > ... >> Interaction with proxies? >> ------------------------- >> >> There is only a passing mention of Proxy-Authenticate: and >> Proxy-Authorization: headers, so one assumes that both mechanisms should >> support this new auth-param. It's not clear to me whether there are any >> additional security or privacy implications when this is addressed to >> proxies compared to origin servers. > > I'm not aware of any. > >> Section 2.2 ("reusing credentials") talks about the URI path (presumably >> for "WWW-Authenticate", but then mixes "Proxy-Authenticate" into the >> middle of that commentary. It looks to me like "Proxy-Authenticate" is >> not intended to be scoped by the URI path (there is no mention of "in >> that space" in the sentence about Proxy-Authenticate in Section 2.2), >> but this is kind of ambiguous. Clarification would be good. > > To be frank, I don't know. My best guess is that it works exactly the > same, so I'll add "in that space" there as well. > ... I'll take that back. The current draft is in sync with what RFC 2617 said. I'd rather not change that without understanding the implications. >> User IDs with Colons >> -------------------- >> >> The draft says "a user-id containing a colon character is invalid" -- >> why not say that "the user-id MUST NOT contain a colon character", as it >> already does for control characters? > > I don't think it really matters how we say it (both have exactly the > same normative power), but I agree it would be better for consistency. I changed my mind when I replied to Pete Resnick's mail: I really don't see the point of declaring something a "MUST NOT" when most UAs actually do it. >> Nits >> ==== >> >> * in B.3, "Authentication on these sites will stop to work" should be >> "Authentication on these sites will stop working" > > Ok. So far, I have and . Best regards, Julian From nobody Wed Feb 18 21:30:18 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25931A8798; Wed, 18 Feb 2015 21:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUdX83XYRU9E; Wed, 18 Feb 2015 21:30:10 -0800 (PST) Received: from hwsga02-in.huaweimarine.com (hwsga02-in.huaweimarine.com [119.145.15.224]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E59271A8789; Wed, 18 Feb 2015 21:30:09 -0800 (PST) Received: from 172.24.1.80 (EHLO szxpml401-hub.exmail.huawei.com) ([172.24.1.80]) by szxrg12-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHN99486; Thu, 19 Feb 2015 13:26:39 +0800 (CST) Received: from SZXPML507-MBX.exmail.huawei.com ([169.254.2.73]) by szxpml401-hub.exmail.huawei.com ([10.82.67.140]) with mapi id 14.03.0158.001; Thu, 19 Feb 2015 13:26:34 +0800 From: Roni Even To: Jean-Marc Valin , Derek Atkins , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: sec-dir review of draft-ietf-payload-rtp-opus-08 Thread-Index: AQHQSuuZ9ux5tJ4kjEmfw6kdoshUWZz0wyWAgAKvGiI= Date: Thu, 19 Feb 2015 05:26:33 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> References: , <54E3A32F.2010008@jmvalin.ca> In-Reply-To: <54E3A32F.2010008@jmvalin.ca> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "koenvos74@gmail.com" , "jspittka@gmail.com" , "payload-chairs@tools.ietf.org" Subject: Re: [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 05:30:14 -0000 Hi, The reason for the may is discussed in RFC7201 and RFC 7202, it can be a SH= OULD and these RFCs exaplain when it is not required to use SRTP. Maybe add a reference to these RFCs in the security section when saying tal= king about good reasons for not using SRTP Roni Even ________________________________________ From: Jean-Marc Valin [jvalin@mozilla.com] on behalf of Jean-Marc Valin [jm= valin@mozilla.com] Sent: Tuesday, February 17, 2015 10:23 PM To: Derek Atkins; iesg@ietf.org; secdir@ietf.org Cc: payload-chairs@tools.ietf.org; koenvos74@gmail.com; jspittka@gmail.com Subject: Re: sec-dir review of draft-ietf-payload-rtp-opus-08 Hi Derek, There was no particular reason for the MAY, the text was merely copied from other RTP payload RFC. I totally agree with making it a SHOULD. Thanks, Jean-Marc On 17/02/15 02:54 PM, Derek Atkins wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written with the intent of improving > security requirements and considerations in IETF drafts. Comments > not addressed in last call may be included in AD reviews during the > IESG review. Document editors and WG chairs should treat these > comments just like any other last call comments. > > Summary: > > Ready to publish with a question: I question why the use of SRTP is a > MAY and not a SHOULD (as detailed in the Security Considerations > section). Considering PERPASS I believe this should be a SHOULD; > someone should have a very good reason why they are NOT using SRTP. > > Details: > > This document defines the Real-time Transport Protocol (RTP) payload > format for packetization of Opus encoded speech and audio data > necessary to integrate the codec in the most compatible way. > Further, it describes media type registrations for the RTP payload > format. > > I have no other comments on this document. > > -derek > From nobody Thu Feb 19 04:23:12 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238FA1A8A16; Thu, 19 Feb 2015 04:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bttoyhZh74ug; Thu, 19 Feb 2015 04:23:09 -0800 (PST) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6A81A889C; Thu, 19 Feb 2015 04:23:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1424348586; d=isode.com; s=selector; i=@isode.com; bh=62DeHkU7g6SZS8R8+HE5W+nu7mNbLUzAwxBelJGA2MY=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=duO7d4DFO+ZMKTqckCGBLfQL9KUTuckEYKzdUpihvvtR0+1rOoSJwNy6DlDi8S7UfYRsC9 HLOGi/L7biEy7Oalneat+FW/tq1lk95mCUvoGgm2kLK4CtuvGAYvMUkGtwR+sIFLizoK5w +ebcWCNiv4/aoNIATUbBS9wrPqPCdPQ=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 19 Feb 2015 12:23:06 +0000 Message-ID: <54E5D598.9070807@isode.com> Date: Thu, 19 Feb 2015 12:22:48 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-opsawg-coman-probstate-reqs.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] SecDir review of draft-ietf-opsawg-coman-probstate-reqs-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 12:23: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 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: not sure, see below I am agreeing with RAI ADs that it is not exactly clear what is the value in publishing this document. I am also very curious to see some design that can satisfy all of these requirements (which are frequently contradictive). Having said that, I liked the introduction (problem statement) part of the document. Security considerations seem to be covered, but as per above, I have hard time figuring out if a system that satisfy them is actually feasible. In particular I am interested in knowing how devices can satisfy the following requirements: Support suitable security bootstrapping mechanisms Self-configuration capability Self-management - Self-healing Recovery in presence of hostile agents on a network of constraint devices. From nobody Thu Feb 19 06:53:35 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345CA1A1AC6; Thu, 19 Feb 2015 06:53:34 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dck1Tdd5YTbL; Thu, 19 Feb 2015 06:53:32 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5461A001C; Thu, 19 Feb 2015 06:53:27 -0800 (PST) Received: by lbvp9 with SMTP id p9so265146lbv.3; Thu, 19 Feb 2015 06:53:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/m9o1pS0NhhEgqKeVjDOU5tMYQ2ypYrv01vvTaGuIKM=; b=01zl2kaYJzk8xv79PqtuRGTjWQh0OX4OJJFweF4/apM43SrrcN30mGXs8MuaiClv98 LGxyLqT22yR1ynf+YS0VmUHxJwaFWWX0sPVtgEn0Jjsa9GK2Z9CXAaOB4Af/3oqQynkb 1+h9HA+rfxS8EGRa9EydEna+eHnuYIgvTZshBEnMGS91grFarGu/lYbHYC6wc6qMpp8s dUmyTreZEx5GCF/4IiCmCY0ykLu/mZuCPRgva5eqL0vNUQPjnd0RdCAHB5Fekg8qzDs7 AH5yf5d7yLkLeGCYYlzRAL7iKGqtCnjJFWYjtjAllPZua8Tya29BNmR5KhorNbvlPA8T zJHg== MIME-Version: 1.0 X-Received: by 10.152.183.165 with SMTP id en5mr4534608lac.0.1424357606306; Thu, 19 Feb 2015 06:53:26 -0800 (PST) Received: by 10.112.167.101 with HTTP; Thu, 19 Feb 2015 06:53:26 -0800 (PST) In-Reply-To: <008B9168-0AF1-4AE5-A316-4EEBD97C63FD@nominum.com> References: <79A24849-274F-4E45-BDED-1EE103D484B8@ieca.com> <008B9168-0AF1-4AE5-A316-4EEBD97C63FD@nominum.com> Date: Thu, 19 Feb 2015 09:53:26 -0500 Message-ID: From: Kathleen Moriarty To: Ted Lemon Content-Type: multipart/alternative; boundary=001a1134573c283945050f721976 Archived-At: Cc: draft-ietf-mif-mpvd-arch.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-mif-mpvd-arch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 14:53:34 -0000 --001a1134573c283945050f721976 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sean & Ted, Sean, thank you for your review of the draft! On Wed, Feb 18, 2015 at 1:00 PM, Ted Lemon wrote: > On Feb 18, 2015, at 9:17 AM, Sean Turner wrote: > > 3. s5.2.1: Makes me hope that the if there=E2=80=99s two connections an= d one is > a VPN that lookups meant for that connection is only done over that > connection and not leaked out. I think this is covered later in the > section though. > > I think you may have used the wrong preposition here, and consequently I'= m > having trouble parsing this. Can you restate? > I'm reading the text in 4.2 as addressing the concern in 5.2.1 that Sean raises. Yes, I agree on the comparison to the VPN leak RFC, but having this statement prevents the need for a similar on on this topic. The routing to IP addresses reachable within this PvD will be set up via the VPN connection, and the routing of packets to addresses outside the scope of this PvD will remain unaffected. But in 5.1, you may need a clause at the end of this sentence to make sure the same PvD is used to prevent such issues (it is implied, but may be better stated explicitly). From: As an example, a node administrator could inject a DNS server which is not ISP-specific into PvDs for use on any of the networks that the node could attach to. Such creation / augmentation of PvD(s) could be static or dynamic. To: As an example, a node administrator could inject a DNS server which is not ISP-specific into PvDs for use on any of the networks that the node could attach to via the same PvD. Such creation / augmentation of PvD(s) could be static or dynamic. For Sean's comment on 5.2.1, I think the above modified text in combination with this text in 5.2.1 (plus what's in 4.2) is sufficient to address the concern. In either case, by default a node uses information obtained via a name service lookup to establish connections only within the same PvD as the lookup results were obtained. For clarification, when it is written that the name service lookup results were obtained "from a PvD", it should be understood to mean that the name service query was issued against a name service which is configured for use in a particular PvD. In that sense, the results are "from" that particular PvD. --=20 Best regards, Kathleen --001a1134573c283945050f721976 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sean & Ted,

Sean, thank you for you= r review of the draft!

On Wed, Feb 18, 2015 at 1:00 PM, Ted Lemon <<= a href=3D"mailto:Ted.Lemon@nominum.com" target=3D"_blank">Ted.Lemon@nominum= .com> wrote:
On Feb 18, = 2015, at 9:17 AM, Sean Turner <turne= rs@ieca.com> wrote:
> 3. s5.2.1: Makes me hope that the if there=E2=80=99s two connections a= nd one is a VPN that lookups meant for that connection is only done over th= at connection and not leaked out.=C2=A0 I think this is covered later in th= e section though.

I think you may have used the wrong preposition here, and consequent= ly I'm having trouble parsing this.=C2=A0 =C2=A0Can you restate?

I'm reading the text in 4.2 as addressing= the concern in 5.2.1 that Sean raises.=C2=A0 Yes, I agree on the compariso= n to the VPN leak RFC, but having this statement prevents the need for a si= milar on on this topic.=C2=A0
From:=

   As=
 an example, a node administrator could inject a DNS server which
   is not ISP-specific into PvDs for use on any of the networks that the
   node could attach to.  Such creation / augmentation of PvD(s) could
   be static or dynamic.
To:=C2=A0
   As an example, a node administrator could inject a DNS=
 server which
   is not ISP-specific into PvDs for use on any of the networks that the
   node could attach to via the same PvD.  Such creation / augmentation of =
PvD(s) could
   be static or dynamic. 

For Sean's comment on 5.2.1, I think the above modified text in comb=
ination with this text in 5.2.1 (plus what's in 4.2) is sufficient to a=
ddress the concern.
   In either case, by default a node uses information obtained via a
   name service lookup to establish connections only within the same PvD
   as the lookup results were obtained.


   For clarificatio=
n, when it is written that the name service lookup
   results were obtained "from a PvD", it should be understood to=
 mean
   that the name service query was issued against a name service which
   is configured for use in a particular PvD.  In that sense, the
   results are "from" that particular PvD.

--

B= est regards,
Kathleen
--001a1134573c283945050f721976-- From nobody Thu Feb 19 09:08:07 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3D81A8820; Thu, 19 Feb 2015 09:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6ljRbIlRSKt; Thu, 19 Feb 2015 09:08:01 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE8661A8931; Thu, 19 Feb 2015 09:07:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id DF12BE2036; Thu, 19 Feb 2015 12:07:55 -0500 (EST) 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 18102-08; Thu, 19 Feb 2015 12:07:54 -0500 (EST) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 024CEE2035; Thu, 19 Feb 2015 12:07:54 -0500 (EST) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t1JH7qEg014364; Thu, 19 Feb 2015 12:07:52 -0500 From: Derek Atkins To: Roni Even References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> Date: Thu, 19 Feb 2015 12:07:51 -0500 In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> (Roni Even's message of "Thu, 19 Feb 2015 05:26:33 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Jean-Marc Valin , "secdir@ietf.org" , "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" Subject: Re: [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 17:08:03 -0000 Roni, I'm not an RTP guy. To me "SRTP" is a general class of "Secure RTP" protocols. So let's work on that as my starting point: implementations SHOULD protect their RTP stream. Based on that, how about a re-wording here? Instead of just saying "MAY use SRTP", how about something like "SHOULD use one of the possible RTP Security methods (See RFC7201, RFC7202)"? (Obviously this can be worded better). -derek Roni Even writes: > Hi, > The reason for the may is discussed in RFC7201 and RFC 7202, it can be > a SHOULD and these RFCs exaplain when it is not required to use SRTP. > Maybe add a reference to these RFCs in the security section when > saying talking about good reasons for not using SRTP > > Roni Even > > ________________________________________ > From: Jean-Marc Valin [jvalin@mozilla.com] on behalf of Jean-Marc > Valin [jmvalin@mozilla.com] > Sent: Tuesday, February 17, 2015 10:23 PM > To: Derek Atkins; iesg@ietf.org; secdir@ietf.org > Cc: payload-chairs@tools.ietf.org; koenvos74@gmail.com; jspittka@gmail.com > Subject: Re: sec-dir review of draft-ietf-payload-rtp-opus-08 > > Hi Derek, > > There was no particular reason for the MAY, the text was merely copied > from other RTP payload RFC. I totally agree with making it a SHOULD. > > Thanks, > > Jean-Marc > > On 17/02/15 02:54 PM, Derek Atkins wrote: >> Hi, >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written with the intent of improving >> security requirements and considerations in IETF drafts. Comments >> not addressed in last call may be included in AD reviews during the >> IESG review. Document editors and WG chairs should treat these >> comments just like any other last call comments. >> >> Summary: >> >> Ready to publish with a question: I question why the use of SRTP is a >> MAY and not a SHOULD (as detailed in the Security Considerations >> section). Considering PERPASS I believe this should be a SHOULD; >> someone should have a very good reason why they are NOT using SRTP. >> >> Details: >> >> This document defines the Real-time Transport Protocol (RTP) payload >> format for packetization of Opus encoded speech and audio data >> necessary to integrate the codec in the most compatible way. >> Further, it describes media type registrations for the RTP payload >> format. >> >> I have no other comments on this document. >> >> -derek >> > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Feb 19 10:23:08 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEEB1A0158; Thu, 19 Feb 2015 10:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XOdUUgPuGh9; Thu, 19 Feb 2015 10:23:04 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4750D1A797C; Thu, 19 Feb 2015 10:22:44 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id CB5A8F984; Thu, 19 Feb 2015 13:22:38 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 6DE24202F4; Thu, 19 Feb 2015 13:22:35 -0500 (EST) From: Daniel Kahn Gillmor To: Julian Reschke , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org In-Reply-To: <54E50FC3.9080708@gmx.de> References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 19 Feb 2015 13:22:35 -0500 Message-ID: <871tllbw2c.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-httpauth-basicauth-update-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 18:23:08 -0000 Hi Julian-- Thanks for the prompt response! My own are inline below. On Wed 2015-02-18 17:18:43 -0500, Julian Reschke wrote: > On 2015-02-18 09:15, Daniel Kahn Gillmor wrote: >> ... >> Should recommend strong password-hashing on the server side >> ----------------------------------------------------------- >> >> The Security Considerations section acknowledges that passwords can be >> stolen from servers, but does not encourage server operators to hash >> stored passwords with a reasonable or strong algorithm. This document >> may not be the place to provide normative guidance on how to store >> passwords to mitigate the exposure of a password table, but perhaps a >> brief mention and an informative reference would be useful? Many >> systems (e.g. modern nginx and apache) use 1000 iterations of salted >> MD5, but still support cleartext passwords, crypt(), and unsalted SHA-1, >> which are all terrible. >> >> https://httpd.apache.org/docs/2.4/misc/password_encryptions.html >> http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html#auth_basic_user_file >> >> an informative reference might point to the Password Hashing >> Competition, which documents sensible rationales for why you should use >> strong password hashing, and how to know it when you see it: >> >> https://password-hashing.net >> >> by comparison the digest draft has a lot more about how passwords should >> be stored (even though Digest auth can offer only weaker protections for >> the password store compared to Basic auth): >> >> https://tools.ietf.org/html/draft-ietf-httpauth-digest-13#section-5.2 >> ... > > I would really like to avoid talking about threads that are generic to > password-based authentication. Optimally, the security area would have a > document that discusses exactly these kind of things so that other specs > can reference that. Does something like this exist? These threats aren't generic to password-based authentication. they're specific to the *type* of password-based authentication used by HTTP basic auth. For example HTTP Digest and PAKE schemes are both password-based, but have different properties, different requirements for the password store, and different threats. I don't know if there is an IETF document that describes password-hashing best-practices or formats. Maybe someone else knows? > Or do you want to propose concrete text? I don't have the bandwidth to craft something fancy right now, but here's a first stab that you're welcome to carve up as you see fit, if no IETF references are forthcoming: Servers and proxies requiring Basic Authentication must store user passwords in some form in order to verify the request's Authorization: header. These passwords should be stored in such a way that a leak of the password table doesn't make them trivially recoverable. This is especially when users are allowed to set their own passwords, since users are known to choose weak passwords and to reuse them across authentication realms. While a full discussion of good password hashing techniques for HTTP Basic Authentication is beyond the scope of this document, server operators should make an effort to minimize risks to their users in the event of a password table leak. For example, servers should not store user passwords in plaintext or as unsalted digests. For more discussion about modern password hashing techniques, see [PHC]. [PHC] https://password-hashing.net Password Hashing Competition (i've used "should not" instead of RFC 2119 "SHOULD NOT" above because this is not a recommendation about the on-the-wire protocol. If anyone thinks it should be elevated to an RFC 2119 "SHOULD NOT" i'd be happy to see that happen, because this is seriously low-hanging fruit, and i'm sure there are still operators out there disregarding it. >> Should recommend constant-time server-side comparisons >> ------------------------------------------------------ >> >> Servers that implement basic auth should not leak information about >> the stored password via timing of rejections. For example, a server >> that stored cleartext passwords (which is a bad idea anyway) should >> mechanically compare the entire string instead of bytewise comparisons. >> The attack here is an attacker who guesses credentials a byte at a time, >> by making 256 initial guesses and seeing which of them gets back a >> rejection faster than the other (and iterates down the list). >> >> This might be less of an issue for reasonable (non-cleartext) password >> storage, but if we're not requiring strong password hashing, we should >> at least require constant time comparisons. > > Do you seriously believe that the time for a string comparison is > relevant compared to the overhead of two network hops plus encapsulation > into HTTP messages? If the transport framework (network hops plus encapsulation into HTTP messages) has no jitter, then the ratio of timing between string comparison and the transport framework overhead is irrelevant; an attacker just cares about difference, not magnitude. Even with some small jitter, statistical analyses over many connections could yield information. Do i expect the transport framework to be jitter-free in the real world? Usually, no. But do you want the security of the scheme to depend on the transport framework having jitter? If this is a security consideration, would you rather say "deploy this only over jittery transports" or "don't leak timing information when you compare passwords"? The latter seems simpler and clearer to me. >> Should recommend padding the Authorization: response >> ---------------------------------------------------- >> >> When used behind HTTPS as recommended, TLS hides the username and >> password presented. However, it does not hide the length of the >> username and password if the other parameters of the HTTPS request are >> known. >> >> An active attacker who wants to learn the length of the victim's >> username and password together for a particular basic auth realm could >> force the user's browser to make HTTPS requests to a few different URLs >> within the realm and see how large the packets are. >> >> This could be mitigated by including whitespace padding in the client's >> Authorization: header itself up to some multiple of a blocksize (perhaps >> 256B) to obscure the length. > > Actually, padding can happen anywhere in the message; it doesn't need to > be in this header field. That's true, but padding the entire HTTP request to a standard blocksize has different security properties than just padding this field to a standard blocksize, because parts of the HTTP request could be under control of the attacker. For example, if Alice can make Bob's user agent fetch arbitrary URLs from https://example.com/, then she can pass steadily increasing URLs to Bob's user agent (e.g. https://example.com/a https://example.com/aa https://example.com/aaa) and see at what point the size jumps a quantum. Restricting the padding to the field that is not under attacker control in any part should prevent this attack. > It's an interesting idea; have you checked whether existing User Agents > do this? I don't know whether any existing User Agents do this, sorry. >> UTF-8 security considerations by reference: is this OK? >> ------------------------------------------ >> >> The Security Considerations section includes the UTF-8 security >> considerations section by reference, but doesn't call out any specific >> issues for implementers to be aware of. the NFC canonicalization draft > > Intentionally. > >> also has Security Considersations section, which is not included by >> reference: >> >> https://tools.ietf.org/html/rfc5198#section-6 > > I'll add that. cool, thanks! >> Interaction with proxies? >> ------------------------- >> >> There is only a passing mention of Proxy-Authenticate: and >> Proxy-Authorization: headers, so one assumes that both mechanisms should >> support this new auth-param. It's not clear to me whether there are any >> additional security or privacy implications when this is addressed to >> proxies compared to origin servers. > > I'm not aware of any. > >> Section 2.2 ("reusing credentials") talks about the URI path (presumably >> for "WWW-Authenticate", but then mixes "Proxy-Authenticate" into the >> middle of that commentary. It looks to me like "Proxy-Authenticate" is >> not intended to be scoped by the URI path (there is no mention of "in >> that space" in the sentence about Proxy-Authenticate in Section 2.2), >> but this is kind of ambiguous. Clarification would be good. > > To be frank, I don't know. My best guess is that it works exactly the > same, so I'll add "in that space" there as well. This ambiguity worries me a bit; should we take this opportunity to clear it up to match what happens in practice? It seems like we should have some people with operational experience on this who could provide clarification here, but i'm not one of them. >> Path matching? >> -------------- >> >> Nothing in the security considerations section talks about the threat >> that motivates path matching for determination of which realm to use. >> It might be useful to spell this out explicitly: >> >> * A user agent that sends the Authorization: header to URLs outside the >> authentication scope as described in Section 2.2 may leak the user's >> credentials > > That applies to all schemes that use protection spaces and is mentioned > in > already. > >> User Agent visibility and logout? >> --------------------------------- >> >> Most RFCs don't talk at all about the human interface of the mentioned >> tools. >> >> But this draft refers briefly to interaction between the user and the >> User Agent (see step 1 on >> https://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-06#page-6). >> However, it provides no other guidance. There are several additional >> guidelines that make basic authentication more acceptable from a privacy >> and security point of view for a typical web browser User Agent: >> >> * user agents should indicate to the user when they are re-using the >> user's authentication credentials as described in section 2.2 >> (indicating the realm, authentication scope, and user-id?) > > They don't right now. Do you believe that requiring it will have any > effect on existing UAs? i don't know, but i'd certainly like to see that happen. If it doesn't happen, perhaps we need to mention in Security Considerations that User Agents which do not indicate to the user when they are reusing the user's credentials risk leaking those credentials without the user knowing that it's happening? >> * user agents should not display the user's password anywhere by >> default > > That sounds pretty obvious. I agree! Maybe we don't need to say obvious things? >> * user agents should make it straightforward for users to clear their >> credentials for any . > > Define "straightforward". That probably depends on the type of user agent, no? as a suggestion, this seems like it could be something that we encourage without specifying concrete mechanism. >> https://tools.ietf.org/html/rfc7235#section-6.3 includes some of these >> guidelines; perhaps this is another include-by-reference? > > All security considerations of RFC 7235 apply by definition, as this > spec is using the framework defined by RFC 7235. I don't believe that we > need to state this. It wasn't immediately obvious to me that all security considerations of RFC 7235 apply by definition, but now that you say it it makes sense. Do you think that an implementor of HTTP basic auth with less experience reading RFCs is going to understand that? >> Other Considerations >> ==================== >> >> Deployment chicken-and-egg >> -------------------------- >> >> The server has no way of knowing that the client is trying to obey the >> charset header. For the servers mentioned in that do user-agent > > Actually, it could apply heuristics. I header detection of UTF-8 is > quire reliable. What heuristics should it apply? If there is a standard set of heuristics we expect servers to use, we should put them in this document. >> sniffing, it's not clear how those servers could ever know to stop >> relying on the user-agent, since the clients have no way of signalling >> their intent to use UTF-8 for the Authorization header. If the servers >> don't know when to start accepting UTF-8 from these clients, then the >> clients also have no way of knowing when they should switch over >> themselves. This strikes me as a recipe for stalled adoption, since >> "user agents in the latter group" (from section B.3) will never use >> UTF-8, even if they know about it. > > I don't see why the server can't just start accepting UTF-8 right away. Because "User agents in the latter group will have to continue to do what they do today", so the servers will need to interpret the response in the same way. If you mean to say that 'User agents in the latter group will have to continue to do what they do today unless the server has sent charset="UTF-8"' then please say so explicitly. And sorry, one more question arises for me on re-read. i'm not sure i understand what this means: Server implementers SHOULD guard against the possibility of this sort of counterfeiting by gateways or CGI scripts. In particular it is very dangerous for a server to simply turn over a connection to a gateway. That gateway can then use the persistent connection mechanism to engage in multiple transactions with the client while impersonating the original server in a way that is not detectable by the client. How should the server guard against this attack? what sort does it mean to "turn over a connection to a gateway"? does "gateway" mean "transparent HTTP proxy" or does it refer to something else? Sorry if this is elementary stuff, but the term "gateway" only appears in this paragraph. --dkg From nobody Thu Feb 19 11:08:44 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6261A0077; Thu, 19 Feb 2015 11:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi9tndY6LaJC; Thu, 19 Feb 2015 11:08:31 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196071A0040; Thu, 19 Feb 2015 11:08:31 -0800 (PST) Received: from [192.168.2.175] ([93.217.98.69]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MVIva-1Y36810kqk-00Yjq9; Thu, 19 Feb 2015 20:07:59 +0100 Message-ID: <54E6348A.3080606@gmx.de> Date: Thu, 19 Feb 2015 20:07:54 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , Julian Reschke , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> In-Reply-To: <871tllbw2c.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:htzPt/ofMbErKisew9cLGWsP58qdN15F1cCj3xdratn4hg/1Rz9 bwDtHEAFw9uDfrN4kJpv5UmHAMXmxqrN6Om1PsvzMw8rZkM2o3KUU2Mu/5WuCLmxkXC3qsZ 1AdfTliBipWjQ+Ibr46MABUVnv8t7Be2/5Q9DBxsbrXnNiYj2AqufnxlsFX1lX/km9u6p/s 1++KBc8IHNBsKYSEFZf4w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "http-auth@ietf.org" , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-httpauth-basicauth-update-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 19:08:36 -0000 On 2015-02-19 19:22, Daniel Kahn Gillmor wrote: > Hi Julian-- > > Thanks for the prompt response! My own are inline below. > > On Wed 2015-02-18 17:18:43 -0500, Julian Reschke wrote: >> On 2015-02-18 09:15, Daniel Kahn Gillmor wrote: >>> ... >>> Should recommend strong password-hashing on the server side >>> ----------------------------------------------------------- >>> >>> The Security Considerations section acknowledges that passwords can be >>> stolen from servers, but does not encourage server operators to hash >>> stored passwords with a reasonable or strong algorithm. This document >>> may not be the place to provide normative guidance on how to store >>> passwords to mitigate the exposure of a password table, but perhaps a >>> brief mention and an informative reference would be useful? Many >>> systems (e.g. modern nginx and apache) use 1000 iterations of salted >>> MD5, but still support cleartext passwords, crypt(), and unsalted SHA-1, >>> which are all terrible. >>> >>> https://httpd.apache.org/docs/2.4/misc/password_encryptions.html >>> http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html#auth_basic_user_file >>> >>> an informative reference might point to the Password Hashing >>> Competition, which documents sensible rationales for why you should use >>> strong password hashing, and how to know it when you see it: >>> >>> https://password-hashing.net >>> >>> by comparison the digest draft has a lot more about how passwords should >>> be stored (even though Digest auth can offer only weaker protections for >>> the password store compared to Basic auth): >>> >>> https://tools.ietf.org/html/draft-ietf-httpauth-digest-13#section-5.2 >>> ... >> >> I would really like to avoid talking about threads that are generic to >> password-based authentication. Optimally, the security area would have a >> document that discusses exactly these kind of things so that other specs >> can reference that. Does something like this exist? > > These threats aren't generic to password-based authentication. they're > specific to the *type* of password-based authentication used by HTTP > basic auth. For example HTTP Digest and PAKE schemes are both > password-based, but have different properties, different requirements > for the password store, and different threats. > > I don't know if there is an IETF document that describes > password-hashing best-practices or formats. Maybe someone else knows? > >> Or do you want to propose concrete text? > > I don't have the bandwidth to craft something fancy right now, but > here's a first stab that you're welcome to carve up as you see fit, if > no IETF references are forthcoming: > > Servers and proxies requiring Basic Authentication must store user > passwords in some form in order to verify the request's > Authorization: header. These passwords should be stored in such a > way that a leak of the password table doesn't make them trivially > recoverable. This is especially when users are allowed to set their > own passwords, since users are known to choose weak passwords and to > reuse them across authentication realms. While a full discussion of > good password hashing techniques for HTTP Basic Authentication is > beyond the scope of this document, server operators should make an > effort to minimize risks to their users in the event of a password > table leak. For example, servers should not store user passwords in > plaintext or as unsalted digests. For more discussion about modern > password hashing techniques, see [PHC]. > > [PHC] https://password-hashing.net Password Hashing Competition > > (i've used "should not" instead of RFC 2119 "SHOULD NOT" above because > this is not a recommendation about the on-the-wire protocol. If anyone > thinks it should be elevated to an RFC 2119 "SHOULD NOT" i'd be happy to > see that happen, because this is seriously low-hanging fruit, and i'm > sure there are still operators out there disregarding it. I like the text, and I'm ok with including it or a variation of it. I'm not 100% convinced that the RFC Editor will be ok with the citation. >>> Should recommend constant-time server-side comparisons >>> ------------------------------------------------------ >>> >>> Servers that implement basic auth should not leak information about >>> the stored password via timing of rejections. For example, a server >>> that stored cleartext passwords (which is a bad idea anyway) should >>> mechanically compare the entire string instead of bytewise comparisons. >>> The attack here is an attacker who guesses credentials a byte at a time, >>> by making 256 initial guesses and seeing which of them gets back a >>> rejection faster than the other (and iterates down the list). >>> >>> This might be less of an issue for reasonable (non-cleartext) password >>> storage, but if we're not requiring strong password hashing, we should >>> at least require constant time comparisons. >> >> Do you seriously believe that the time for a string comparison is >> relevant compared to the overhead of two network hops plus encapsulation >> into HTTP messages? > > If the transport framework (network hops plus encapsulation into HTTP > messages) has no jitter, then the ratio of timing between string > comparison and the transport framework overhead is irrelevant; an > attacker just cares about difference, not magnitude. Even with some > small jitter, statistical analyses over many connections could yield > information. > > Do i expect the transport framework to be jitter-free in the real world? > Usually, no. But do you want the security of the scheme to depend on > the transport framework having jitter? > > If this is a security consideration, would you rather say "deploy this > only over jittery transports" or "don't leak timing information when you > compare passwords"? The latter seems simpler and clearer to me. The network exchange will be take milliseconds. The string comparison microseconds. /me not convinced there's a problem here. >>> Should recommend padding the Authorization: response >>> ---------------------------------------------------- >>> >>> When used behind HTTPS as recommended, TLS hides the username and >>> password presented. However, it does not hide the length of the >>> username and password if the other parameters of the HTTPS request are >>> known. >>> >>> An active attacker who wants to learn the length of the victim's >>> username and password together for a particular basic auth realm could >>> force the user's browser to make HTTPS requests to a few different URLs >>> within the realm and see how large the packets are. >>> >>> This could be mitigated by including whitespace padding in the client's >>> Authorization: header itself up to some multiple of a blocksize (perhaps >>> 256B) to obscure the length. >> >> Actually, padding can happen anywhere in the message; it doesn't need to >> be in this header field. > > That's true, but padding the entire HTTP request to a standard blocksize > has different security properties than just padding this field to a > standard blocksize, because parts of the HTTP request could be under > control of the attacker. > > For example, if Alice can make Bob's user agent fetch arbitrary URLs > from https://example.com/, then she can pass steadily increasing URLs to > Bob's user agent (e.g. https://example.com/a https://example.com/aa > https://example.com/aaa) and see at what point the size jumps a quantum. > Restricting the padding to the field that is not under attacker control > in any part should prevent this attack. How would the attacker be able to modify fields in the request? I think it would be great to have a document that describes these threats and how to mitigate them; in particular comparing HTTP/1.1 and 2, but I seriously doubt this document would be the right place to do this. (It seems to be as relevant for cookies, no?) >> It's an interesting idea; have you checked whether existing User Agents >> do this? > > I don't know whether any existing User Agents do this, sorry. > >>> UTF-8 security considerations by reference: is this OK? >>> ------------------------------------------ >>> >>> The Security Considerations section includes the UTF-8 security >>> considerations section by reference, but doesn't call out any specific >>> issues for implementers to be aware of. the NFC canonicalization draft >> >> Intentionally. >> >>> also has Security Considersations section, which is not included by >>> reference: >>> >>> https://tools.ietf.org/html/rfc5198#section-6 >> >> I'll add that. > > cool, thanks! > > >>> Interaction with proxies? >>> ------------------------- >>> >>> There is only a passing mention of Proxy-Authenticate: and >>> Proxy-Authorization: headers, so one assumes that both mechanisms should >>> support this new auth-param. It's not clear to me whether there are any >>> additional security or privacy implications when this is addressed to >>> proxies compared to origin servers. >> >> I'm not aware of any. >> >>> Section 2.2 ("reusing credentials") talks about the URI path (presumably >>> for "WWW-Authenticate", but then mixes "Proxy-Authenticate" into the >>> middle of that commentary. It looks to me like "Proxy-Authenticate" is >>> not intended to be scoped by the URI path (there is no mention of "in >>> that space" in the sentence about Proxy-Authenticate in Section 2.2), >>> but this is kind of ambiguous. Clarification would be good. >> >> To be frank, I don't know. My best guess is that it works exactly the >> same, so I'll add "in that space" there as well. > > This ambiguity worries me a bit; should we take this opportunity to > clear it up to match what happens in practice? It seems like we should > have some people with operational experience on this who could provide > clarification here, but i'm not one of them. Nor am I. I do agree that proxy authentication needs better documentation, but that's a problem of RFC 7235, not this spec. >>> Path matching? >>> -------------- >>> >>> Nothing in the security considerations section talks about the threat >>> that motivates path matching for determination of which realm to use. >>> It might be useful to spell this out explicitly: >>> >>> * A user agent that sends the Authorization: header to URLs outside the >>> authentication scope as described in Section 2.2 may leak the user's >>> credentials >> >> That applies to all schemes that use protection spaces and is mentioned >> in >> already. >> >>> User Agent visibility and logout? >>> --------------------------------- >>> >>> Most RFCs don't talk at all about the human interface of the mentioned >>> tools. >>> >>> But this draft refers briefly to interaction between the user and the >>> User Agent (see step 1 on >>> https://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-06#page-6). >>> However, it provides no other guidance. There are several additional >>> guidelines that make basic authentication more acceptable from a privacy >>> and security point of view for a typical web browser User Agent: >>> >>> * user agents should indicate to the user when they are re-using the >>> user's authentication credentials as described in section 2.2 >>> (indicating the realm, authentication scope, and user-id?) >> >> They don't right now. Do you believe that requiring it will have any >> effect on existing UAs? > > i don't know, but i'd certainly like to see that happen. If it doesn't > happen, perhaps we need to mention in Security Considerations that User > Agents which do not indicate to the user when they are reusing the > user's credentials risk leaking those credentials without the user > knowing that it's happening? We could say that (text welcome), but I seriously doubt it will affect what software does. The current trend is to remove as much UI as possible (or even all on mobile), so asking for this indicator is really wishful thinking. >>> * user agents should not display the user's password anywhere by >>> default >> >> That sounds pretty obvious. > > I agree! Maybe we don't need to say obvious things? > >>> * user agents should make it straightforward for users to clear their >>> credentials for any . >> >> Define "straightforward". > > That probably depends on the type of user agent, no? as a suggestion, > this seems like it could be something that we encourage without > specifying concrete mechanism. Again, we're talking about code that has been written almost 20 years ago. New advice on nice-to-haves will not have any effect on these implementations. >>> https://tools.ietf.org/html/rfc7235#section-6.3 includes some of these >>> guidelines; perhaps this is another include-by-reference? >> >> All security considerations of RFC 7235 apply by definition, as this >> spec is using the framework defined by RFC 7235. I don't believe that we >> need to state this. > > It wasn't immediately obvious to me that all security considerations of > RFC 7235 apply by definition, but now that you say it it makes sense. > > Do you think that an implementor of HTTP basic auth with less experience > reading RFCs is going to understand that? An implementor of this spec will need to read and understand RFC 7235. So, yes. >>> Other Considerations >>> ==================== >>> >>> Deployment chicken-and-egg >>> -------------------------- >>> >>> The server has no way of knowing that the client is trying to obey the >>> charset header. For the servers mentioned in that do user-agent >> >> Actually, it could apply heuristics. I header detection of UTF-8 is >> quire reliable. > > What heuristics should it apply? If there is a standard set of > heuristics we expect servers to use, we should put them in this > document. I don't *expect* servers to use heuristics. That being said, the heuristics are quite simple: try to decode the octets with a strict UTF-8 decoder, and if that doesn't fail the input was likely encoded in UTF-8. >>> sniffing, it's not clear how those servers could ever know to stop >>> relying on the user-agent, since the clients have no way of signalling >>> their intent to use UTF-8 for the Authorization header. If the servers >>> don't know when to start accepting UTF-8 from these clients, then the >>> clients also have no way of knowing when they should switch over >>> themselves. This strikes me as a recipe for stalled adoption, since >>> "user agents in the latter group" (from section B.3) will never use >>> UTF-8, even if they know about it. >> >> I don't see why the server can't just start accepting UTF-8 right away. > > > Because "User agents in the latter group will have to continue to do > what they do today", so the servers will need to interpret the response > in the same way. If you mean to say that 'User agents in the latter > group will have to continue to do what they do today unless the server > has sent charset="UTF-8"' then please say so explicitly. No, that's not what I meant. By "accepting UTF-8" I mean "trying to decode as UTF-8" in addition to what the server is already doing; basically a trial-and-error approach. > And sorry, one more question arises for me on re-read. i'm not sure i > understand what this means: > > Server implementers SHOULD guard against the possibility of this sort > of counterfeiting by gateways or CGI scripts. In particular it is > very dangerous for a server to simply turn over a connection to a > gateway. That gateway can then use the persistent connection > mechanism to engage in multiple transactions with the client while > impersonating the original server in a way that is not detectable by > the client. > > How should the server guard against this attack? what sort does it mean > to "turn over a connection to a gateway"? does "gateway" mean > "transparent HTTP proxy" or does it refer to something else? Sorry if > this is elementary stuff, but the term "gateway" only appears in this > paragraph. That text is present in RFC 2617; I don't understand it completely either. Maybe just drop the second half of the paragraph and only mention the thread itself? Best regards, Julian From nobody Thu Feb 19 12:15:52 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315EB1A006F; Thu, 19 Feb 2015 12:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnGKuHHgZZ1z; Thu, 19 Feb 2015 12:15:46 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id DCD7A1A00AE; Thu, 19 Feb 2015 12:15:45 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id C3630F984; Thu, 19 Feb 2015 15:15:41 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id CCD091FFDD; Thu, 19 Feb 2015 15:15:38 -0500 (EST) From: Daniel Kahn Gillmor To: Julian Reschke , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org In-Reply-To: <54E6348A.3080606@gmx.de> References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 19 Feb 2015 15:15:38 -0500 Message-ID: <87mw49ac9h.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "http-auth@ietf.org" , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-httpauth-basicauth-update-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 20:15:48 -0000 On Thu 2015-02-19 14:07:54 -0500, Julian Reschke wrote: > The network exchange will be take milliseconds. The string comparison > microseconds. /me not convinced there's a problem here. as long as the attacker can measure microseconds, and the network exchange has small or regular-enough jitter to be accounted for with statistical techniques, the size difference between these parts doesn't matter to a timing attack. http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf says: The resolution an attacker can time a remote host depends on how many measurements they can collect. Our simulated attacker using statistical hypothesis testing was able to reliably distinguish a processing time differences as low as 200ns and 30ยตs with 1,000 measurements on the LAN and WAN respectively with. (See Section 6.) Note that salted, hashed passwords where the attacker doesn't know the salt are resistant to using a timing oracle like this to do byte-by-byte guessing. I still think it's simpler to just recommend that the tests should be constant time. >> That's true, but padding the entire HTTP request to a standard blocksize >> has different security properties than just padding this field to a >> standard blocksize, because parts of the HTTP request could be under >> control of the attacker. >> >> For example, if Alice can make Bob's user agent fetch arbitrary URLs >> from https://example.com/, then she can pass steadily increasing URLs to >> Bob's user agent (e.g. https://example.com/a https://example.com/aa >> https://example.com/aaa) and see at what point the size jumps a quantum. >> Restricting the padding to the field that is not under attacker control >> in any part should prevent this attack. > > How would the attacker be able to modify fields in the request? By changing the length of the requested URL (which is part of the request), as described above. For example, if you visit my website, i can add new elements trying to fetch whatever URLs i want you to fetch. If i can watch your traffic, i can compare the sizes of those requests. > I think it would be great to have a document that describes these > threats and how to mitigate them; in particular comparing HTTP/1.1 and > 2, but I seriously doubt this document would be the right place to do this. > > (It seems to be as relevant for cookies, no?) It does seem relevant for cookies, but this draft isn't about cookies :) If there's no document to point to, we should still acknowledge the concern here, no? > That being said, the heuristics are quite simple: try to decode the > octets with a strict UTF-8 decoder, and if that doesn't fail the input > was likely encoded in UTF-8. Some binary strings are valid in both character encodings, though, right? For example, "c3 a1 62 63" in UTF-8 is "รกbc", but in ISO-8859-1, it is "รƒยกbc" So if my password is non-ASCII in the first place, it could very well match the UTF-8 encoding even though i've intended another one. So maybe the heuristic should be: even if the UTF-8 decode succeeds, the server could try its fallback decoding mechanism if the UTF-8 version of the password doesn't match. (fwiw, my understanding is that facebook checks common accidental variations on the entered password during their (non-basic-auth) login process. so if my password is b4nanAs, but i type B4NANaS or b5nanAs, facebook might let me in anyway) Is this advisable? What are the risks of testing two variants of the password against the password table? I haven't thought this through fully, but it seems like it would be a relevant consideration. In the absence of a signal from the client about their choice of encoding, documenting these heuristics and recommending them seems like a useful way to facilitate adoption and uniformity among servers implementing this spec. >> And sorry, one more question arises for me on re-read. i'm not sure i >> understand what this means: >> >> Server implementers SHOULD guard against the possibility of this sort >> of counterfeiting by gateways or CGI scripts. In particular it is >> very dangerous for a server to simply turn over a connection to a >> gateway. That gateway can then use the persistent connection >> mechanism to engage in multiple transactions with the client while >> impersonating the original server in a way that is not detectable by >> the client. >> >> How should the server guard against this attack? what sort does it mean >> to "turn over a connection to a gateway"? does "gateway" mean >> "transparent HTTP proxy" or does it refer to something else? Sorry if >> this is elementary stuff, but the term "gateway" only appears in this >> paragraph. > > That text is present in RFC 2617; I don't understand it completely either. > > Maybe just drop the second half of the paragraph and only mention the > thread itself? If we drop the second half, i'd still like to know what kind of steps a server should take to guard against the possibility of counterfeiting. If we don't have any recommendations or external references, an unactionable SHOULD seems troublesome. Regards, --dkg From nobody Thu Feb 19 12:34:39 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994041A0151; Thu, 19 Feb 2015 12:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVYETkzL--cE; Thu, 19 Feb 2015 12:34:31 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250B71A0108; Thu, 19 Feb 2015 12:34:31 -0800 (PST) Received: from [192.168.2.175] ([93.217.98.69]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MQR3s-1XzCuB179g-00Toe6; Thu, 19 Feb 2015 21:34:07 +0100 Message-ID: <54E648B9.6030606@gmx.de> Date: Thu, 19 Feb 2015 21:34:01 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> In-Reply-To: <87mw49ac9h.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:Kvv788L0dmvePF7IlxW5V6BljzNXa8+LYm07fsXe4+ie1uYV5F9 bxmEqVXFqDUWmeShZ42H+7Gw1jm9+tWoaoUO9s8gGdjH/z80BWdAbyPo4AuSpBDkiloNcbE Hon7ZPDx1ZibBEvk01zH3kbXxlUVsVMV2yCBS6/tj7GHhisWx/y/afC3mQ6xV20p+gJ0jO2 zyM8MjiJ1S8b0Q+5nWU6g== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "http-auth@ietf.org" , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-httpauth-basicauth-update-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 20:34:33 -0000 On 2015-02-19 21:15, Daniel Kahn Gillmor wrote: > On Thu 2015-02-19 14:07:54 -0500, Julian Reschke wrote: >> The network exchange will be take milliseconds. The string comparison >> microseconds. /me not convinced there's a problem here. > > as long as the attacker can measure microseconds, and the network > exchange has small or regular-enough jitter to be accounted for with > statistical techniques, the size difference between these parts doesn't > matter to a timing attack. > > http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf > > says: > > The resolution an attacker can time a remote host depends on how many > measurements they can collect. Our simulated attacker using > statistical hypothesis testing was able to reliably distinguish a > processing time differences as low as 200ns and 30ยตs with 1,000 > measurements on the LAN and WAN respectively with. (See Section 6.) > > Note that salted, hashed passwords where the attacker doesn't know the > salt are resistant to using a timing oracle like this to do byte-by-byte > guessing. I still think it's simpler to just recommend that the tests > should be constant time. I'm sorry, I'm not convinced. What do others think? >>> That's true, but padding the entire HTTP request to a standard blocksize >>> has different security properties than just padding this field to a >>> standard blocksize, because parts of the HTTP request could be under >>> control of the attacker. >>> >>> For example, if Alice can make Bob's user agent fetch arbitrary URLs >>> from https://example.com/, then she can pass steadily increasing URLs to >>> Bob's user agent (e.g. https://example.com/a https://example.com/aa >>> https://example.com/aaa) and see at what point the size jumps a quantum. >>> Restricting the padding to the field that is not under attacker control >>> in any part should prevent this attack. >> >> How would the attacker be able to modify fields in the request? > > By changing the length of the requested URL (which is part of the > request), as described above. For example, if you visit my website, i > can add new elements trying to fetch whatever URLs i > want you to fetch. If i can watch your traffic, i can compare the sizes > of those requests. But the actual request is still under control of the browser. >> I think it would be great to have a document that describes these >> threats and how to mitigate them; in particular comparing HTTP/1.1 and >> 2, but I seriously doubt this document would be the right place to do this. >> >> (It seems to be as relevant for cookies, no?) > > It does seem relevant for cookies, but this draft isn't about cookies :) > If there's no document to point to, we should still acknowledge the > concern here, no? Well, I'm actually not concerned yet. If this was a problem in practice then we should have evidence, for instance, by finding padding code in user agents. I'm not saying there is none, but I do believe that if you are serious about this you ought to research yourself what the current state of implementations is. >> That being said, the heuristics are quite simple: try to decode the >> octets with a strict UTF-8 decoder, and if that doesn't fail the input >> was likely encoded in UTF-8. > > Some binary strings are valid in both character encodings, though, > right? For example, "c3 a1 62 63" in UTF-8 is "รกbc", but in ISO-8859-1, > it is "รƒยกbc" So if my password is non-ASCII in the first place, it could > very well match the UTF-8 encoding even though i've intended another > one. Any octet sequence is valid in ISO-8859-1, true. If the server doesn't know whether a certain sequence is UTF-8 or ISO-8859-1, it simply could try both. > So maybe the heuristic should be: even if the UTF-8 decode succeeds, the > server could try its fallback decoding mechanism if the UTF-8 version of > the password doesn't match. (fwiw, my understanding is that facebook > checks common accidental variations on the entered password during their > (non-basic-auth) login process. so if my password is b4nanAs, but i > type B4NANaS or b5nanAs, facebook might let me in anyway) > > Is this advisable? What are the risks of testing two variants of the > password against the password table? I haven't thought this through > fully, but it seems like it would be a relevant consideration. It might. > In the absence of a signal from the client about their choice of ...which we can't have unless we switch to a new auth scheme... > encoding, documenting these heuristics and recommending them seems like > a useful way to facilitate adoption and uniformity among servers > implementing this spec. I'll think about what advice we can give here. >>> And sorry, one more question arises for me on re-read. i'm not sure i >>> understand what this means: >>> >>> Server implementers SHOULD guard against the possibility of this sort >>> of counterfeiting by gateways or CGI scripts. In particular it is >>> very dangerous for a server to simply turn over a connection to a >>> gateway. That gateway can then use the persistent connection >>> mechanism to engage in multiple transactions with the client while >>> impersonating the original server in a way that is not detectable by >>> the client. >>> >>> How should the server guard against this attack? what sort does it mean >>> to "turn over a connection to a gateway"? does "gateway" mean >>> "transparent HTTP proxy" or does it refer to something else? Sorry if >>> this is elementary stuff, but the term "gateway" only appears in this >>> paragraph. >> >> That text is present in RFC 2617; I don't understand it completely either. >> >> Maybe just drop the second half of the paragraph and only mention the >> thread itself? > > If we drop the second half, i'd still like to know what kind of steps a > server should take to guard against the possibility of counterfeiting. > If we don't have any recommendations or external references, an > unactionable SHOULD seems troublesome. I'd just say "Basic Authentication is also vulnerable to spoofing by counterfeit servers. If a user can be led to believe that he is connecting to a host containing information protected by Basic authentication when, in fact, he is connecting to a hostile server or gateway, then the attacker can request a password, store it for later use, and feign an error. This type of attack is not possible with other authentication schemes, such as Digest Authentication." and leave it at that. Best regards, Julian From nobody Thu Feb 19 13:49:56 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF321A0270; Thu, 19 Feb 2015 13:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xw1SZRWcVes; Thu, 19 Feb 2015 13:49:48 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8AB1A01FA; Thu, 19 Feb 2015 13:49:47 -0800 (PST) Received: from netb ([89.204.130.64]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lx5hl-1XVv7C0Rtx-016kCT; Thu, 19 Feb 2015 22:49:27 +0100 From: Bjoern Hoehrmann To: Julian Reschke Date: Thu, 19 Feb 2015 22:49:23 +0100 Message-ID: References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> <54E648B9.6030606@gmx.de> In-Reply-To: <54E648B9.6030606@gmx.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:CD8YhhO+C0BPniJG+IhXnrBF4/jObob23IS3UD8gZ25OYmJKcnT ip6QFn9F/rRZvUXkp/gOWfl5Yz14uiVgVHqoXwZ398vaNSjJ0vkekMsKSRnO/m77PzDqrlX /BiqcKYO/7UaKwvbVl4y5keShMmNY04Fba2SDxTZdWNJELMjt1tgyMtzdKG9/hFtRsHQZlk lx+Y3z9aP/s7sMWBP4OPA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "http-auth@ietf.org" , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 21:49:50 -0000 * Julian Reschke wrote: >On 2015-02-19 21:15, Daniel Kahn Gillmor wrote: >> On Thu 2015-02-19 14:07:54 -0500, Julian Reschke wrote: >>> The network exchange will be take milliseconds. The string comparison >>> microseconds. /me not convinced there's a problem here. >> >> as long as the attacker can measure microseconds, and the network >> exchange has small or regular-enough jitter to be accounted for with >> statistical techniques, the size difference between these parts doesn't >> matter to a timing attack. >> >> http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf >> >> says: >> >> The resolution an attacker can time a remote host depends on how many >> measurements they can collect. Our simulated attacker using >> statistical hypothesis testing was able to reliably distinguish a >> processing time differences as low as 200ns and 30ตs with 1,000 >> measurements on the LAN and WAN respectively with. (See Section 6.) >> >> Note that salted, hashed passwords where the attacker doesn't know the >> salt are resistant to using a timing oracle like this to do byte-by-byte >> guessing. I still think it's simpler to just recommend that the tests >> should be constant time. > >I'm sorry, I'm not convinced. What do others think? I would prefer to point to an existing document for considerations such as this one, and I do not think it is entirely obvious for implementers of the scheme that comparison should take time independent of the length of the credentials, so including something brief about this makes sense to me. -- Bj๖rn H๖hrmann ท mailto:bjoern@hoehrmann.de ท http://bjoern.hoehrmann.de D-10243 Berlin ท PGP Pub. KeyID: 0xA4357E78 ท http://www.bjoernsworld.de Available for hire in Berlin (early 2015) ท http://www.websitedev.de/ From nobody Thu Feb 19 14:35:55 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424421A19F6; Thu, 19 Feb 2015 14:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77NUDb--0pPk; Thu, 19 Feb 2015 14:35:40 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C1C1A19EF; Thu, 19 Feb 2015 14:35:39 -0800 (PST) Received: by labhz20 with SMTP id hz20so2730101lab.0; Thu, 19 Feb 2015 14:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SjiFlI5FRJHXqrVp2B//4u/Um62s5AKQTEmwVWtFkU0=; b=snkj+tw1LpiX9/kV7+PSTEVtExGHRuDEUQRAwgXvOty4HQdEElIQASA1j0HjwtT8mQ 3PYKYJ9PHJIjoGKNpJOJpepCJiGeBp5Cil4BE22NEqmOyzVkWvZy5kIKfCAF9lgKfNoT MMbGtqJcaCvBO6nryYgGWwJOYloqYsfS9etEThnr+WVFqBvOydcQbHAOw+004W8zo5nT LIf3wMZRUv8QkuW10R48WhUn6R5B6QS60Mt3+QnDXJgr26ij1db8ie8HfFbaFLnJ+Mua WXSiLjMzlENT6FYF1981y08DCI4wbpHlwQtghsxt41Zcm6j9laSdYVGdQmA6L0/qGj8V o5Qw== MIME-Version: 1.0 X-Received: by 10.152.8.229 with SMTP id u5mr6080432laa.4.1424385338299; Thu, 19 Feb 2015 14:35:38 -0800 (PST) Received: by 10.112.167.101 with HTTP; Thu, 19 Feb 2015 14:35:38 -0800 (PST) In-Reply-To: <54E648B9.6030606@gmx.de> References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> <54E648B9.6030606@gmx.de> Date: Thu, 19 Feb 2015 17:35:38 -0500 Message-ID: From: Kathleen Moriarty To: Julian Reschke Content-Type: multipart/alternative; boundary=089e0158ab601cdabc050f788eab Archived-At: Cc: "http-auth@ietf.org" , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 22:35:44 -0000 --089e0158ab601cdabc050f788eab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Daniel, Thanks for much for the detailed review and discussion! It may be helpful to document some of these concerns in another draft and see what we can do to improve going forward. Would you be up for that? Julian, Thanks for the discussion. I think we are close to addressing the concerns raised and that we can let some slip for this draft since it was meant to be an update to address internationalization concerns. It does already say this isn't a secure choice and this review adds more reasons for that concern. The rest is inline. On Thu, Feb 19, 2015 at 3:34 PM, Julian Reschke wrote: > On 2015-02-19 21:15, Daniel Kahn Gillmor wrote: > >> On Thu 2015-02-19 14:07:54 -0500, Julian Reschke wrote: >> >>> The network exchange will be take milliseconds. The string comparison >>> microseconds. /me not convinced there's a problem here. >>> >> >> as long as the attacker can measure microseconds, and the network >> exchange has small or regular-enough jitter to be accounted for with >> statistical techniques, the size difference between these parts doesn't >> matter to a timing attack. >> >> http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf >> >> says: >> >> The resolution an attacker can time a remote host depends on how man= y >> measurements they can collect. Our simulated attacker using >> statistical hypothesis testing was able to reliably distinguish a >> processing time differences as low as 200ns and 30=C2=B5s with 1,000 >> measurements on the LAN and WAN respectively with. (See Section 6.) >> >> Note that salted, hashed passwords where the attacker doesn't know the >> salt are resistant to using a timing oracle like this to do byte-by-byte >> guessing. I still think it's simpler to just recommend that the tests >> should be constant time. >> > > I'm sorry, I'm not convinced. What do others think? I think it's okay to leave out mention of side channel attacks like this timing attack. It might be useful in a follow up draft or if this were earlier in the process. > > > That's true, but padding the entire HTTP request to a standard blocksize >>>> has different security properties than just padding this field to a >>>> standard blocksize, because parts of the HTTP request could be under >>>> control of the attacker. >>>> >>>> For example, if Alice can make Bob's user agent fetch arbitrary URLs >>>> from https://example.com/, then she can pass steadily increasing URLs >>>> to >>>> Bob's user agent (e.g. https://example.com/a https://example.com/aa >>>> https://example.com/aaa) and see at what point the size jumps a >>>> quantum. >>>> Restricting the padding to the field that is not under attacker contro= l >>>> in any part should prevent this attack. >>>> >>> >>> How would the attacker be able to modify fields in the request? >>> >> >> By changing the length of the requested URL (which is part of the >> request), as described above. For example, if you visit my website, i >> can add new elements trying to fetch whatever URLs i >> want you to fetch. If i can watch your traffic, i can compare the sizes >> of those requests. >> > > But the actual request is still under control of the browser. > > I think it would be great to have a document that describes these >>> threats and how to mitigate them; in particular comparing HTTP/1.1 and >>> 2, but I seriously doubt this document would be the right place to do >>> this. >>> >>> (It seems to be as relevant for cookies, no?) >>> >> >> It does seem relevant for cookies, but this draft isn't about cookies :) >> If there's no document to point to, we should still acknowledge the >> concern here, no? >> > > Well, I'm actually not concerned yet. If this was a problem in practice > then we should have evidence, for instance, by finding padding code in us= er > agents. I'm not saying there is none, but I do believe that if you are > serious about this you ought to research yourself what the current state = of > implementations is. I think it's okay to leave this out for now as well, may be material for another draft. Basic is used in lots of places still, so understanding all the bad things about it may help inspire people to switch to something else (says optimistic SecAD). > > > That being said, the heuristics are quite simple: try to decode the >>> octets with a strict UTF-8 decoder, and if that doesn't fail the input >>> was likely encoded in UTF-8. >>> >> >> Some binary strings are valid in both character encodings, though, >> right? For example, "c3 a1 62 63" in UTF-8 is "=C3=A1bc", but in ISO-88= 59-1, >> it is "=C3=83=C2=A1bc" So if my password is non-ASCII in the first place= , it could >> very well match the UTF-8 encoding even though i've intended another >> one. >> > > Any octet sequence is valid in ISO-8859-1, true. > > If the server doesn't know whether a certain sequence is UTF-8 or > ISO-8859-1, it simply could try both. > > So maybe the heuristic should be: even if the UTF-8 decode succeeds, the >> server could try its fallback decoding mechanism if the UTF-8 version of >> the password doesn't match. (fwiw, my understanding is that facebook >> checks common accidental variations on the entered password during their >> (non-basic-auth) login process. so if my password is b4nanAs, but i >> type B4NANaS or b5nanAs, facebook might let me in anyway) >> >> Is this advisable? What are the risks of testing two variants of the >> password against the password table? I haven't thought this through >> fully, but it seems like it would be a relevant consideration. >> > > It might. > > In the absence of a signal from the client about their choice of >> > > ...which we can't have unless we switch to a new auth scheme... Another draft might be good... > > > encoding, documenting these heuristics and recommending them seems like >> a useful way to facilitate adoption and uniformity among servers >> implementing this spec. >> > > I'll think about what advice we can give here. > > And sorry, one more question arises for me on re-read. i'm not sure i >>>> understand what this means: >>>> >>>> Server implementers SHOULD guard against the possibility of this >>>> sort >>>> of counterfeiting by gateways or CGI scripts. In particular it i= s >>>> very dangerous for a server to simply turn over a connection to a >>>> gateway. That gateway can then use the persistent connection >>>> mechanism to engage in multiple transactions with the client whil= e >>>> impersonating the original server in a way that is not detectable >>>> by >>>> the client. >>>> >>>> How should the server guard against this attack? what sort does it me= an >>>> to "turn over a connection to a gateway"? does "gateway" mean >>>> "transparent HTTP proxy" or does it refer to something else? Sorry if >>>> this is elementary stuff, but the term "gateway" only appears in this >>>> paragraph. >>>> >>> >>> That text is present in RFC 2617; I don't understand it completely >>> either. >>> >>> Maybe just drop the second half of the paragraph and only mention the >>> thread itself? >>> >> >> If we drop the second half, i'd still like to know what kind of steps a >> server should take to guard against the possibility of counterfeiting. >> If we don't have any recommendations or external references, an >> unactionable SHOULD seems troublesome. >> > > I'd just say > > "Basic Authentication is also vulnerable to spoofing by counterfeit > servers. If a user can be led to believe that he is connecting to a host > containing information protected by Basic authentication when, in fact, h= e > is connecting to a hostile server or gateway, then the attacker can reque= st > a password, store it for later use, and feign an error. This type of atta= ck > is not possible with other authentication schemes, such as Digest > Authentication." > > and leave it at that. The text proposal looks reasonable. I'll go back through the original review to make sure nothing was missed. Thanks again!! Kathleen > > > Best regards, Julian > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --=20 Best regards, Kathleen --089e0158ab601cdabc050f788eab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Daniel,

Thanks for much for the detaile= d review and discussion!=C2=A0 It may be helpful to document some of these = concerns in another draft and see what we can do to improve going forward.= =C2=A0 Would you be up for that? =C2=A0

Julian,

Thanks for the discussion.=C2=A0 I think we are clos= e to addressing the concerns raised and that we can let some slip for this = draft since it was meant to be an update to address internationalization co= ncerns.=C2=A0 It does already say this isn't a secure choice and this r= eview adds more reasons for that concern.

The rest= is inline. =C2=A0

On Thu, Feb 19, 2015 at 3:34 PM, Julian Reschke &l= t;julian.reschke= @gmx.de> wrote:
On 2015-02-19 21:15, Daniel Kahn Gillmor wrote:
On Thu 2015-02-19 14:07:54 -0500, Julian Reschke wrote:
The network exchange will be take milliseconds. The string comparison
microseconds. /me not convinced there's a problem here.

as long as the attacker can measure microseconds, and the network
exchange has small or regular-enough jitter to be accounted for with
statistical techniques, the size difference between these parts doesn't=
matter to a timing attack.

=C2=A0 =C2=A0http://www.cs.rice.edu/~dwallach/pub/cros= by-timing2009.pdf

says:

=C2=A0 =C2=A0 The resolution an attacker can time a remote host depends on = how many
=C2=A0 =C2=A0 measurements they can collect. Our simulated attacker using =C2=A0 =C2=A0 statistical hypothesis testing was able to reliably distingui= sh a
=C2=A0 =C2=A0 processing time differences as low as 200ns and 30=C2=B5s wit= h 1,000
=C2=A0 =C2=A0 measurements on the LAN and WAN respectively with. (See Secti= on 6.)

Note that salted, hashed passwords where the attacker doesn't know the<= br> salt are resistant to using a timing oracle like this to do byte-by-byte guessing.=C2=A0 I still think it's simpler to just recommend that the t= ests
should be constant time.

 I'm sorry, I'm not convinced. What do others think?

I think it's okay to leave out mention of side channel= attacks like this timing attack.=C2=A0 It might be useful in a follow up d= raft or if this were earlier in the process.=C2=A0


That's true, but padding the entire HTTP request to a standard blocksiz= e
has different security properties than just padding this field to a
standard blocksize, because parts of the HTTP request could be under
control of the attacker.

For example, if Alice can make Bob's user agent fetch arbitrary URLs from https://example.com= /, then she can pass steadily increasing URLs to
Bob's user agent (e.g. https://example.com/a https://example.com/aa
https://example.com/a= aa) and see at what point the size jumps a quantum.
Restricting the padding to the field that is not under attacker control
in any part should prevent this attack.

How would the attacker be able to modify fields in the request?

By changing the length of the requested URL (which is part of the
request), as described above.=C2=A0 For example, if you visit my website, i=
can add new <img src=3D"..."> elements trying to fetch what= ever URLs i
want you to fetch.=C2=A0 If i can watch your traffic, i can compare the siz= es
of those requests.

 But the actual request is still under control of the browser.

I think it would be great to have a document that describes these
threats and how to mitigate them; in particular comparing HTTP/1.1 and
2, but I seriously doubt this document would be the right place to do this.=

(It seems to be as relevant for cookies, no?)

It does seem relevant for cookies, but this draft isn't about cookies := )
If there's no document to point to, we should still acknowledge the
concern here, no?

 Well, I'm actually not concerned yet. If this was a problem in practice= then we should have evidence, for instance, by finding padding code in use= r agents. I'm not saying there is none, but I do believe that if you ar= e serious about this you ought to research yourself what the current state = of implementations is.

I think it's oka= y to leave this out for now as well, may be material for another draft.=C2= =A0 Basic is used in lots of places still, so understanding all the bad thi= ngs about it may help inspire people to switch to something else (says opti= mistic SecAD).
=C2=A0


That being said, the heuristics are quite simple: try to decode the
octets with a strict UTF-8 decoder, and if that doesn't fail the input<= br> was likely encoded in UTF-8.

Some binary strings are valid in both character encodings, though,
right?=C2=A0 For example, "c3 a1 62 63" in UTF-8 is "=C3=A1b= c", but in ISO-8859-1,
it is "=C3=83=C2=A1bc" So if my password is non-ASCII in the firs= t place, it could
very well match the UTF-8 encoding even though i've intended another one.

 Any octet sequence is valid in ISO-8859-1, true.

If the server doesn't know whether a certain sequence is UTF-8 or ISO-8= 859-1, it simply could try both.

So maybe the heuristic should be: even if the UTF-8 decode succeeds, the server could try its fallback decoding mechanism if the UTF-8 version of the password doesn't match.=C2=A0 (fwiw, my understanding is that faceb= ook
checks common accidental variations on the entered password during their (non-basic-auth) login process.=C2=A0 so if my password is b4nanAs, but i type B4NANaS or b5nanAs, facebook might let me in anyway)

Is this advisable?=C2=A0 What are the risks of testing two variants of the<= br> password against the password table?=C2=A0 I haven't thought this throu= gh
fully, but it seems like it would be a relevant consideration.

 It might.

In the absence of a signal from the client about their choice of

 ...which we can't have unless we switch to a new auth scheme...

Another draft might be good...=C2=A0


encoding, documenting these heuristics and recommending them seems like
a useful way to facilitate adoption and uniformity among servers
implementing this spec.

 I'll think about what advice we can give here.

And sorry, one more question arises for me on re-read. i'm not sure i understand what this means:

=C2=A0 =C2=A0 =C2=A0Server implementers SHOULD guard against the possibilit= y of this sort
=C2=A0 =C2=A0 =C2=A0of counterfeiting by gateways or CGI scripts.=C2=A0 In = particular it is
=C2=A0 =C2=A0 =C2=A0very dangerous for a server to simply turn over a conne= ction to a
=C2=A0 =C2=A0 =C2=A0gateway.=C2=A0 That gateway can then use the persistent= connection
=C2=A0 =C2=A0 =C2=A0mechanism to engage in multiple transactions with the c= lient while
=C2=A0 =C2=A0 =C2=A0impersonating the original server in a way that is not = detectable by
=C2=A0 =C2=A0 =C2=A0the client.

How should the server guard against this attack?=C2=A0 what sort does it me= an
to "turn over a connection to a gateway"?=C2=A0 does "gatewa= y" mean
"transparent HTTP proxy" or does it refer to something else?=C2= =A0 Sorry if
this is elementary stuff, but the term "gateway" only appears in = this
paragraph.

That text is present in RFC 2617; I don't understand it completely eith= er.

Maybe just drop the second half of the paragraph and only mention the
thread itself?

If we drop the second half, i'd still like to know what kind of steps a=
server should take to guard against the possibility of counterfeiting.
If we don't have any recommendations or external references, an
unactionable SHOULD seems troublesome.

 I'd just say

"Basic Authentication is also vulnerable to spoofing by counterfeit se= rvers. If a user can be led to believe that he is connecting to a host cont= aining information protected by Basic authentication when, in fact, he is c= onnecting to a hostile server or gateway, then the attacker can request a p= assword, store it for later use, and feign an error. This type of attack is= not possible with other authentication schemes, such as Digest Authenticat= ion."

and leave it at that.

The text proposal loo= ks reasonable. I'll go back through the original review to make sure no= thing was missed.

Thanks again!!

Kathleen
=


Best regards, Julian

_______________________________________________
http-auth mailing list
http-auth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/http-auth



--
=

Best regards,
Kathleen
--089e0158ab601cdabc050f788eab-- From nobody Thu Feb 19 14:55:05 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CA31A00B8; Thu, 19 Feb 2015 14:55:03 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJOOwunlN0TH; Thu, 19 Feb 2015 14:54:56 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C339E1A00B1; Thu, 19 Feb 2015 14:54:55 -0800 (PST) Received: by lbjb6 with SMTP id b6so3000746lbj.2; Thu, 19 Feb 2015 14:54:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iczfq9dYapAD2i74vXLIDPtS19CiI2xeJ4O4qzUzgZs=; b=tzzxaEyFzQ3b2CjFcRdikvOTt98gQnEL/2VnZ4H7FZpU7u1j0p2DnxD3a0Fwe+u/qQ pnaOWSKWBkwEr1uDjs+6RCVsu4SVQVhnbblW9KDt7DtfixUupt0SQ0lI+HEWsrM0E/gl GFMam00OrMU8T8aHhO4FmNO3j6QBJDz/nohCY8tI0hnb5J3YfAyIuw3WfR8f/z9n++gL N0wcwf7hOhibzsKGFoB2oDvjMefiB2mQAqz5F0BVRzUCKQaDvAEleQ1bJxB4Y2ECMble WvqtbqBc1LGJJvjMCSn0ph/bvZvQ0JKC77t6Lx6OTJhp6i8/IWslIAabXfPTlPwCg0dQ OViw== MIME-Version: 1.0 X-Received: by 10.152.8.229 with SMTP id u5mr6133221laa.4.1424386493873; Thu, 19 Feb 2015 14:54:53 -0800 (PST) Received: by 10.112.167.101 with HTTP; Thu, 19 Feb 2015 14:54:53 -0800 (PST) In-Reply-To: <54E6348A.3080606@gmx.de> References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> Date: Thu, 19 Feb 2015 17:54:53 -0500 Message-ID: From: Kathleen Moriarty To: Julian Reschke Content-Type: multipart/alternative; boundary=089e0158ab60fd85ab050f78d2d4 Archived-At: Cc: "http-auth@ietf.org" , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 22:55:03 -0000 --089e0158ab60fd85ab050f78d2d4 Content-Type: text/plain; charset=UTF-8 > > This part of the thread resulted in a few more changes, I'm ok with them as noted below and just want to track this and add an RFC editor note on the reference concern. Thanks! On Thu, Feb 19, 2015 at 2:07 PM, Julian Reschke wrote: > On 2015-02-19 19:22, Daniel Kahn Gillmor wrote: > >> Hi Julian-- >> >> Thanks for the prompt response! My own are inline below. >> >> On Wed 2015-02-18 17:18:43 -0500, Julian Reschke wrote: >> >>> On 2015-02-18 09:15, Daniel Kahn Gillmor wrote: >>> >>>> ... >>>> Should recommend strong password-hashing on the server side >>>> ----------------------------------------------------------- >>>> >>>> The Security Considerations section acknowledges that passwords can be >>>> stolen from servers, but does not encourage server operators to hash >>>> stored passwords with a reasonable or strong algorithm. This document >>>> may not be the place to provide normative guidance on how to store >>>> passwords to mitigate the exposure of a password table, but perhaps a >>>> brief mention and an informative reference would be useful? Many >>>> systems (e.g. modern nginx and apache) use 1000 iterations of salted >>>> MD5, but still support cleartext passwords, crypt(), and unsalted SHA-1, >>>> which are all terrible. >>>> >>>> https://httpd.apache.org/docs/2.4/misc/password_encryptions.html >>>> http://nginx.org/en/docs/http/ngx_http_auth_basic_module. >>>> html#auth_basic_user_file >>>> >>>> an informative reference might point to the Password Hashing >>>> Competition, which documents sensible rationales for why you should use >>>> strong password hashing, and how to know it when you see it: >>>> >>>> https://password-hashing.net >>>> >>>> by comparison the digest draft has a lot more about how passwords should >>>> be stored (even though Digest auth can offer only weaker protections for >>>> the password store compared to Basic auth): >>>> >>>> https://tools.ietf.org/html/draft-ietf-httpauth-digest-13# >>>> section-5.2 >>>> ... >>>> >>> >>> I would really like to avoid talking about threads that are generic to >>> password-based authentication. Optimally, the security area would have a >>> document that discusses exactly these kind of things so that other specs >>> can reference that. Does something like this exist? >>> >> >> These threats aren't generic to password-based authentication. they're >> specific to the *type* of password-based authentication used by HTTP >> basic auth. For example HTTP Digest and PAKE schemes are both >> password-based, but have different properties, different requirements >> for the password store, and different threats. >> >> I don't know if there is an IETF document that describes >> password-hashing best-practices or formats. Maybe someone else knows? >> >> Or do you want to propose concrete text? >>> >> >> I don't have the bandwidth to craft something fancy right now, but >> here's a first stab that you're welcome to carve up as you see fit, if >> no IETF references are forthcoming: >> >> Servers and proxies requiring Basic Authentication must store user >> passwords in some form in order to verify the request's >> Authorization: header. These passwords should be stored in such a >> way that a leak of the password table doesn't make them trivially >> recoverable. This is especially when users are allowed to set their >> own passwords, since users are known to choose weak passwords and to >> reuse them across authentication realms. While a full discussion of >> good password hashing techniques for HTTP Basic Authentication is >> beyond the scope of this document, server operators should make an >> effort to minimize risks to their users in the event of a password >> table leak. For example, servers should not store user passwords in >> plaintext or as unsalted digests. For more discussion about modern >> password hashing techniques, see [PHC]. >> >> [PHC] https://password-hashing.net Password Hashing Competition >> >> (i've used "should not" instead of RFC 2119 "SHOULD NOT" above because >> this is not a recommendation about the on-the-wire protocol. If anyone >> thinks it should be elevated to an RFC 2119 "SHOULD NOT" i'd be happy to >> see that happen, because this is seriously low-hanging fruit, and i'm >> sure there are still operators out there disregarding it. >> > > I like the text, and I'm ok with including it or a variation of it. I'm > not 100% convinced that the RFC Editor will be ok with the citation. OK, this looks good as well, thanks. We'll figure out the reference as we go. I can make an RFC editor note on it so we don't forget to figure it out. > > > Should recommend constant-time server-side comparisons >>>> ------------------------------------------------------ >>>> >>>> Servers that implement basic auth should not leak information about >>>> the stored password via timing of rejections. For example, a server >>>> that stored cleartext passwords (which is a bad idea anyway) should >>>> mechanically compare the entire string instead of bytewise comparisons. >>>> The attack here is an attacker who guesses credentials a byte at a time, >>>> by making 256 initial guesses and seeing which of them gets back a >>>> rejection faster than the other (and iterates down the list). >>>> >>>> This might be less of an issue for reasonable (non-cleartext) password >>>> storage, but if we're not requiring strong password hashing, we should >>>> at least require constant time comparisons. >>>> >>> >>> Do you seriously believe that the time for a string comparison is >>> relevant compared to the overhead of two network hops plus encapsulation >>> into HTTP messages? >>> >> >> If the transport framework (network hops plus encapsulation into HTTP >> messages) has no jitter, then the ratio of timing between string >> comparison and the transport framework overhead is irrelevant; an >> attacker just cares about difference, not magnitude. Even with some >> small jitter, statistical analyses over many connections could yield >> information. >> >> Do i expect the transport framework to be jitter-free in the real world? >> Usually, no. But do you want the security of the scheme to depend on >> the transport framework having jitter? >> >> If this is a security consideration, would you rather say "deploy this >> only over jittery transports" or "don't leak timing information when you >> compare passwords"? The latter seems simpler and clearer to me. >> > > The network exchange will be take milliseconds. The string comparison > microseconds. /me not convinced there's a problem here. > > > > Should recommend padding the Authorization: response >>>> ---------------------------------------------------- >>>> >>>> When used behind HTTPS as recommended, TLS hides the username and >>>> password presented. However, it does not hide the length of the >>>> username and password if the other parameters of the HTTPS request are >>>> known. >>>> >>>> An active attacker who wants to learn the length of the victim's >>>> username and password together for a particular basic auth realm could >>>> force the user's browser to make HTTPS requests to a few different URLs >>>> within the realm and see how large the packets are. >>>> >>>> This could be mitigated by including whitespace padding in the client's >>>> Authorization: header itself up to some multiple of a blocksize (perhaps >>>> 256B) to obscure the length. >>>> >>> >>> Actually, padding can happen anywhere in the message; it doesn't need to >>> be in this header field. >>> >> >> That's true, but padding the entire HTTP request to a standard blocksize >> has different security properties than just padding this field to a >> standard blocksize, because parts of the HTTP request could be under >> control of the attacker. >> >> For example, if Alice can make Bob's user agent fetch arbitrary URLs >> from https://example.com/, then she can pass steadily increasing URLs to >> Bob's user agent (e.g. https://example.com/a https://example.com/aa >> https://example.com/aaa) and see at what point the size jumps a quantum. >> Restricting the padding to the field that is not under attacker control >> in any part should prevent this attack. >> > > How would the attacker be able to modify fields in the request? > > I think it would be great to have a document that describes these threats > and how to mitigate them; in particular comparing HTTP/1.1 and 2, but I > seriously doubt this document would be the right place to do this. > > (It seems to be as relevant for cookies, no?) > > > > It's an interesting idea; have you checked whether existing User Agents >>> do this? >>> >> >> I don't know whether any existing User Agents do this, sorry. >> >> UTF-8 security considerations by reference: is this OK? >>>> ------------------------------------------ >>>> >>>> The Security Considerations section includes the UTF-8 security >>>> considerations section by reference, but doesn't call out any specific >>>> issues for implementers to be aware of. the NFC canonicalization draft >>>> >>> >>> Intentionally. >>> >>> also has Security Considersations section, which is not included by >>>> reference: >>>> >>>> https://tools.ietf.org/html/rfc5198#section-6 >>>> >>> >>> I'll add that. >>> >> >> cool, thanks! >> > Good, thanks for this addition as well. > >> >> Interaction with proxies? >>>> ------------------------- >>>> >>>> There is only a passing mention of Proxy-Authenticate: and >>>> Proxy-Authorization: headers, so one assumes that both mechanisms should >>>> support this new auth-param. It's not clear to me whether there are any >>>> additional security or privacy implications when this is addressed to >>>> proxies compared to origin servers. >>>> >>> >>> I'm not aware of any. >>> >>> Section 2.2 ("reusing credentials") talks about the URI path (presumably >>>> for "WWW-Authenticate", but then mixes "Proxy-Authenticate" into the >>>> middle of that commentary. It looks to me like "Proxy-Authenticate" is >>>> not intended to be scoped by the URI path (there is no mention of "in >>>> that space" in the sentence about Proxy-Authenticate in Section 2.2), >>>> but this is kind of ambiguous. Clarification would be good. >>>> >>> >>> To be frank, I don't know. My best guess is that it works exactly the >>> same, so I'll add "in that space" there as well. >>> >> >> This ambiguity worries me a bit; should we take this opportunity to >> clear it up to match what happens in practice? It seems like we should >> have some people with operational experience on this who could provide >> clarification here, but i'm not one of them. >> > > Nor am I. > > I do agree that proxy authentication needs better documentation, but > that's a problem of RFC 7235, not this spec. > > > Path matching? >>>> -------------- >>>> >>>> Nothing in the security considerations section talks about the threat >>>> that motivates path matching for determination of which realm to use. >>>> It might be useful to spell this out explicitly: >>>> >>>> * A user agent that sends the Authorization: header to URLs outside >>>> the >>>> authentication scope as described in Section 2.2 may leak the >>>> user's >>>> credentials >>>> >>> >>> That applies to all schemes that use protection spaces and is mentioned >>> in >>> already. >>> >>> User Agent visibility and logout? >>>> --------------------------------- >>>> >>>> Most RFCs don't talk at all about the human interface of the mentioned >>>> tools. >>>> >>>> But this draft refers briefly to interaction between the user and the >>>> User Agent (see step 1 on >>>> https://tools.ietf.org/html/draft-ietf-httpauth-basicauth- >>>> update-06#page-6). >>>> However, it provides no other guidance. There are several additional >>>> guidelines that make basic authentication more acceptable from a privacy >>>> and security point of view for a typical web browser User Agent: >>>> >>>> * user agents should indicate to the user when they are re-using the >>>> user's authentication credentials as described in section 2.2 >>>> (indicating the realm, authentication scope, and user-id?) >>>> >>> >>> They don't right now. Do you believe that requiring it will have any >>> effect on existing UAs? >>> >> >> i don't know, but i'd certainly like to see that happen. If it doesn't >> happen, perhaps we need to mention in Security Considerations that User >> Agents which do not indicate to the user when they are reusing the >> user's credentials risk leaking those credentials without the user >> knowing that it's happening? >> > > We could say that (text welcome), but I seriously doubt it will affect > what software does. The current trend is to remove as much UI as possible > (or even all on mobile), so asking for this indicator is really wishful > thinking. > > * user agents should not display the user's password anywhere by >>>> default >>>> >>> >>> That sounds pretty obvious. >>> >> >> I agree! Maybe we don't need to say obvious things? >> >> * user agents should make it straightforward for users to clear their >>>> credentials for any . >>>> >>> >>> Define "straightforward". >>> >> >> That probably depends on the type of user agent, no? as a suggestion, >> this seems like it could be something that we encourage without >> specifying concrete mechanism. >> > > Again, we're talking about code that has been written almost 20 years ago. > New advice on nice-to-haves will not have any effect on these > implementations. > > https://tools.ietf.org/html/rfc7235#section-6.3 includes some of these >>>> guidelines; perhaps this is another include-by-reference? >>>> >>> >>> All security considerations of RFC 7235 apply by definition, as this >>> spec is using the framework defined by RFC 7235. I don't believe that we >>> need to state this. >>> >> >> It wasn't immediately obvious to me that all security considerations of >> RFC 7235 apply by definition, but now that you say it it makes sense. >> >> Do you think that an implementor of HTTP basic auth with less experience >> reading RFCs is going to understand that? >> > > An implementor of this spec will need to read and understand RFC 7235. So, > yes. > > Other Considerations >>>> ==================== >>>> >>>> Deployment chicken-and-egg >>>> -------------------------- >>>> >>>> The server has no way of knowing that the client is trying to obey the >>>> charset header. For the servers mentioned in that do user-agent >>>> >>> >>> Actually, it could apply heuristics. I header detection of UTF-8 is >>> quire reliable. >>> >> >> What heuristics should it apply? If there is a standard set of >> heuristics we expect servers to use, we should put them in this >> document. >> > > I don't *expect* servers to use heuristics. > > That being said, the heuristics are quite simple: try to decode the octets > with a strict UTF-8 decoder, and if that doesn't fail the input was likely > encoded in UTF-8. > > sniffing, it's not clear how those servers could ever know to stop >>>> relying on the user-agent, since the clients have no way of signalling >>>> their intent to use UTF-8 for the Authorization header. If the servers >>>> don't know when to start accepting UTF-8 from these clients, then the >>>> clients also have no way of knowing when they should switch over >>>> themselves. This strikes me as a recipe for stalled adoption, since >>>> "user agents in the latter group" (from section B.3) will never use >>>> UTF-8, even if they know about it. >>>> >>> >>> I don't see why the server can't just start accepting UTF-8 right away. >>> >> >> >> Because "User agents in the latter group will have to continue to do >> what they do today", so the servers will need to interpret the response >> in the same way. If you mean to say that 'User agents in the latter >> group will have to continue to do what they do today unless the server >> has sent charset="UTF-8"' then please say so explicitly. >> > > No, that's not what I meant. > > By "accepting UTF-8" I mean "trying to decode as UTF-8" in addition to > what the server is already doing; basically a trial-and-error approach. > > And sorry, one more question arises for me on re-read. i'm not sure i >> understand what this means: >> >> Server implementers SHOULD guard against the possibility of this sort >> of counterfeiting by gateways or CGI scripts. In particular it is >> very dangerous for a server to simply turn over a connection to a >> gateway. That gateway can then use the persistent connection >> mechanism to engage in multiple transactions with the client while >> impersonating the original server in a way that is not detectable by >> the client. >> >> How should the server guard against this attack? what sort does it mean >> to "turn over a connection to a gateway"? does "gateway" mean >> "transparent HTTP proxy" or does it refer to something else? Sorry if >> this is elementary stuff, but the term "gateway" only appears in this >> paragraph. >> > > That text is present in RFC 2617; I don't understand it completely either. > > Maybe just drop the second half of the paragraph and only mention the > thread itself? > > Best regards, Julian > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > -- Best regards, Kathleen --089e0158ab60fd85ab050f78d2d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This part of the thread resulted in a few= more changes, I'm ok with them as noted below and just want to track t= his and add an RFC editor note on the reference concern.

Thanks!

On Th= u, Feb 19, 2015 at 2:07 PM, Julian Reschke <julian.reschke@gmx.de&= gt; wrote:
<= div class=3D"h5">On 2015-02-19 19:22, Daniel Kahn Gillmor wrote:
Hi Julian--

Thanks for the prompt response!=C2=A0 My own are inline below.

On Wed 2015-02-18 17:18:43 -0500, Julian Reschke wrote:
On 2015-02-18 09:15, Daniel Kahn Gillmor wrote:
...
Should recommend strong password-hashing on the server side
-----------------------------------------------------------

The Security Considerations section acknowledges that passwords can be
stolen from servers, but does not encourage server operators to hash
stored passwords with a reasonable or strong algorithm.=C2=A0 This document=
may not be the place to provide normative guidance on how to store
passwords to mitigate the exposure of a password table, but perhaps a
brief mention and an informative reference would be useful?=C2=A0 Many
systems (e.g. modern nginx and apache) use 1000 iterations of salted
MD5, but still support cleartext passwords, crypt(), and unsalted SHA-1, which are all terrible.

=C2=A0 =C2=A0https://httpd.apache.org/docs/2.4/m= isc/password_encryptions.html
=C2=A0 =C2=A0http://nginx.org/en/docs= /http/ngx_http_auth_basic_module.html#auth_basic_user_file

an informative reference might point to the Password Hashing
Competition, which documents sensible rationales for why you should use
strong password hashing, and how to know it when you see it:

=C2=A0 =C2=A0 ht= tps://password-hashing.net

by comparison the digest draft has a lot more about how passwords should be stored (even though Digest auth can offer only weaker protections for the password store compared to Basic auth):

=C2=A0 =C2=A0https://tools.ietf.org/html/dr= aft-ietf-httpauth-digest-13#section-5.2
...

I would really like to avoid talking about threads that are generic to
password-based authentication. Optimally, the security area would have a document that discusses exactly these kind of things so that other specs can reference that. Does something like this exist?

These threats aren't generic to password-based authentication.=C2=A0 th= ey're
specific to the *type* of password-based authentication used by HTTP
basic auth.=C2=A0 For example HTTP Digest and PAKE schemes are both
password-based, but have different properties, different requirements
for the password store, and different threats.

I don't know if there is an IETF document that describes
password-hashing best-practices or formats.=C2=A0 Maybe someone else knows?=

Or do you want to propose concrete text?

I don't have the bandwidth to craft something fancy right now, but
here's a first stab that you're welcome to carve up as you see fit,= if
no IETF references are forthcoming:

=C2=A0 =C2=A0 Servers and proxies requiring Basic Authentication must store= user
=C2=A0 =C2=A0 passwords in some form in order to verify the request's =C2=A0 =C2=A0 Authorization: header.=C2=A0 These passwords should be stored= in such a
=C2=A0 =C2=A0 way that a leak of the password table doesn't make them t= rivially
=C2=A0 =C2=A0 recoverable.=C2=A0 This is especially when users are allowed = to set their
=C2=A0 =C2=A0 own passwords, since users are known to choose weak passwords= and to
=C2=A0 =C2=A0 reuse them across authentication realms.=C2=A0 While a full d= iscussion of
=C2=A0 =C2=A0 good password hashing techniques for HTTP Basic Authenticatio= n is
=C2=A0 =C2=A0 beyond the scope of this document, server operators should ma= ke an
=C2=A0 =C2=A0 effort to minimize risks to their users in the event of a pas= sword
=C2=A0 =C2=A0 table leak.=C2=A0 For example, servers should not store user = passwords in
=C2=A0 =C2=A0 plaintext or as unsalted digests.=C2=A0 For more discussion a= bout modern
=C2=A0 =C2=A0 password hashing techniques, see [PHC].

=C2=A0 [PHC] htt= ps://password-hashing.net Password Hashing Competition

(i've used "should not" instead of RFC 2119 "SHOULD NOT&= quot; above because
this is not a recommendation about the on-the-wire protocol.=C2=A0 If anyon= e
thinks it should be elevated to an RFC 2119 "SHOULD NOT" i'd = be happy to
see that happen, because this is seriously low-hanging fruit, and i'm sure there are still operators out there disregarding it.

I like the text, and I'm ok with including it or a variation of it. I&#= 39;m not 100% convinced that the RFC Editor will be ok with the citation.

OK, this looks good as well, thanks.=C2=A0 W= e'll figure out the reference as we go.=C2=A0 I can make an RFC editor = note on it so we don't forget to figure it out.


Should recommend constant-time server-side comparisons
------------------------------------------------------

Servers that implement basic auth should not leak information about
the stored password via timing of rejections.=C2=A0 For example, a server that stored cleartext passwords (which is a bad idea anyway) should
mechanically compare the entire string instead of bytewise comparisons.
The attack here is an attacker who guesses credentials a byte at a time, by making 256 initial guesses and seeing which of them gets back a
rejection faster than the other (and iterates down the list).

This might be less of an issue for reasonable (non-cleartext) password
storage, but if we're not requiring strong password hashing, we should<= br> at least require constant time comparisons.

Do you seriously believe that the time for a string comparison is
relevant compared to the overhead of two network hops plus encapsulation into HTTP messages?

If the transport framework (network hops plus encapsulation into HTTP
messages) has no jitter, then the ratio of timing between string
comparison and the transport framework overhead is irrelevant; an
attacker just cares about difference, not magnitude.=C2=A0 Even with some small jitter, statistical analyses over many connections could yield
information.

Do i expect the transport framework to be jitter-free in the real world? Usually, no.=C2=A0 But do you want the security of the scheme to depend on<= br> the transport framework having jitter?

If this is a security consideration, would you rather say "deploy this=
only over jittery transports" or "don't leak timing informati= on when you
compare passwords"?=C2=A0 The latter seems simpler and clearer to me.<= br>

The network exchange will be take milliseconds. The string comparison micro= seconds. /me not convinced there's a problem here.



Should recommend padding the Authorization: response
----------------------------------------------------

When used behind HTTPS as recommended, TLS hides the username and
password presented.=C2=A0 However, it does not hide the length of the
username and password if the other parameters of the HTTPS request are
known.

An active attacker who wants to learn the length of the victim's
username and password together for a particular basic auth realm could
force the user's browser to make HTTPS requests to a few different URLs=
within the realm and see how large the packets are.

This could be mitigated by including whitespace padding in the client's=
Authorization: header itself up to some multiple of a blocksize (perhaps 256B) to obscure the length.

Actually, padding can happen anywhere in the message; it doesn't need t= o
be in this header field.

That's true, but padding the entire HTTP request to a standard blocksiz= e
has different security properties than just padding this field to a
standard blocksize, because parts of the HTTP request could be under
control of the attacker.

For example, if Alice can make Bob's user agent fetch arbitrary URLs from https://example.com= /, then she can pass steadily increasing URLs to
Bob's user agent (e.g. https://example.com/a https://example.com/aa
https://example.com/a= aa) and see at what point the size jumps a quantum.
Restricting the padding to the field that is not under attacker control
in any part should prevent this attack.

How would the attacker be able to modify fields in the request?

I think it would be great to have a document that describes these threats a= nd how to mitigate them; in particular comparing HTTP/1.1 and 2, but I seri= ously doubt this document would be the right place to do this.

(It seems to be as relevant for cookies, no?)



It's an interesting idea; have you checked whether existing User Agents=
do this?

I don't know whether any existing User Agents do this, sorry.

UTF-8 security considerations by reference: is this OK?
------------------------------------------

The Security Considerations section includes the UTF-8 security
considerations section by reference, but doesn't call out any specific<= br> issues for implementers to be aware of.=C2=A0 the NFC canonicalization draf= t

Intentionally.

also has Security Considersations section, which is not included by
reference:

=C2=A0 =C2=A0 https://tools.ietf.org/html/rfc5198#section-6

I'll add that.

cool, thanks!

= Good, thanks for this addition as well.=C2=A0


Interaction with proxies?
-------------------------

There is only a passing mention of Proxy-Authenticate: and
Proxy-Authorization: headers, so one assumes that both mechanisms should support this new auth-param.=C2=A0 It's not clear to me whether there a= re any
additional security or privacy implications when this is addressed to
proxies compared to origin servers.

I'm not aware of any.

Section 2.2 ("reusing credentials") talks about the URI path (pre= sumably
for "WWW-Authenticate", but then mixes "Proxy-Authenticate&q= uot; into the
middle of that commentary.=C2=A0 It looks to me like "Proxy-Authentica= te" is
not intended to be scoped by the URI path (there is no mention of "in<= br> that space" in the sentence about Proxy-Authenticate in Section 2.2),<= br> but this is kind of ambiguous.=C2=A0 Clarification would be good.

To be frank, I don't know. My best guess is that it works exactly the same, so I'll add "in that space" there as well.

This ambiguity worries me a bit; should we take this opportunity to
clear it up to match what happens in practice?=C2=A0 It seems like we shoul= d
have some people with operational experience on this who could provide
clarification here, but i'm not one of them.

Nor am I.

I do agree that proxy authentication needs better documentation, but that&#= 39;s a problem of RFC 7235, not this spec.


Path matching?
--------------

Nothing in the security considerations section talks about the threat
that motivates path matching for determination of which realm to use.
It might be useful to spell this out explicitly:

=C2=A0 =C2=A0* A user agent that sends the Authorization: header to URLs ou= tside the
=C2=A0 =C2=A0 =C2=A0authentication scope as described in Section 2.2 may le= ak the user's
=C2=A0 =C2=A0 =C2=A0credentials

That applies to all schemes that use protection spaces and is mentioned
in <http://greenbytes.de/tech/webdav/rfc7235.h= tml#protection.spaces>
already.

User Agent visibility and logout?
---------------------------------

Most RFCs don't talk at all about the human interface of the mentioned<= br> tools.

But this draft refers briefly to interaction between the user and the
User Agent (see step 1 on
https://tools.ietf.org/html/draft-ietf= -httpauth-basicauth-update-06#page-6).
However, it provides no other guidance.=C2=A0 There are several additional<= br> guidelines that make basic authentication more acceptable from a privacy and security point of view for a typical web browser User Agent:

=C2=A0 =C2=A0* user agents should indicate to the user when they are re-usi= ng the
=C2=A0 =C2=A0 =C2=A0user's authentication credentials as described in s= ection 2.2
=C2=A0 =C2=A0 =C2=A0(indicating the realm, authentication scope, and user-i= d?)

They don't right now. Do you believe that requiring it will have any effect on existing UAs?

i don't know, but i'd certainly like to see that happen.=C2=A0 If i= t doesn't
happen, perhaps we need to mention in Security Considerations that User
Agents which do not indicate to the user when they are reusing the
user's credentials risk leaking those credentials without the user
knowing that it's happening?

We could say that (text welcome), but I seriously doubt it will affect what= software does. The current trend is to remove as much UI as possible (or e= ven all on mobile), so asking for this indicator is really wishful thinking= .

=C2=A0 =C2=A0* user agents should not display the user's password anywh= ere by
=C2=A0 =C2=A0 =C2=A0default

That sounds pretty obvious.

I agree!=C2=A0 Maybe we don't need to say obvious things?

=C2=A0 =C2=A0* user agents should make it straightforward for users to clea= r their
=C2=A0 =C2=A0 =C2=A0credentials for any <realm,authentication scope,user= -id>.

Define "straightforward".

That probably depends on the type of user agent, no?=C2=A0 as a suggestion,=
this seems like it could be something that we encourage without
specifying concrete mechanism.

 Again, we're talking about code that has been written almost 20 years a= go. New advice on nice-to-haves will not have any effect on these implement= ations.

https://tools.ietf.org/html/rfc7235#section-6.3 includes some= of these
guidelines; perhaps this is another include-by-reference?

All security considerations of RFC 7235 apply by definition, as this
spec is using the framework defined by RFC 7235. I don't believe that w= e
need to state this.

It wasn't immediately obvious to me that all security considerations of=
RFC 7235 apply by definition, but now that you say it it makes sense.

Do you think that an implementor of HTTP basic auth with less experience reading RFCs is going to understand that?

 An implementor of this spec will need to read and understand RFC 7235. So, = yes.

Other Considerations
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Deployment chicken-and-egg
--------------------------

The server has no way of knowing that the client is trying to obey the
charset header.=C2=A0 For the servers mentioned in that do user-agent

Actually, it could apply heuristics. I header detection of UTF-8 is
quire reliable.

What heuristics should it apply?=C2=A0 If there is a standard set of
heuristics we expect servers to use, we should put them in this
document.

 I don't *expect* servers to use heuristics.

That being said, the heuristics are quite simple: try to decode the octets = with a strict UTF-8 decoder, and if that doesn't fail the input was lik= ely encoded in UTF-8.

sniffing, it's not clear how those servers could ever know to stop
relying on the user-agent, since the clients have no way of signalling
their intent to use UTF-8 for the Authorization header.=C2=A0 If the server= s
don't know when to start accepting UTF-8 from these clients, then the clients also have no way of knowing when they should switch over
themselves.=C2=A0 This strikes me as a recipe for stalled adoption, since "user agents in the latter group" (from section B.3) will never u= se
UTF-8, even if they know about it.

I don't see why the server can't just start accepting UTF-8 right a= way.


Because "User agents in the latter group will have to continue to do what they do today", so the servers will need to interpret the respons= e
in the same way.=C2=A0 If you mean to say that 'User agents in the latt= er
group will have to continue to do what they do today unless the server
has sent charset=3D"UTF-8"' then please say so explicitly.

No, that's not what I meant.

By "accepting UTF-8" I mean "trying to decode as UTF-8"= in addition to what the server is already doing; basically a trial-and-err= or approach.

And sorry, one more question arises for me on re-read. i'm not sure i understand what this means:

=C2=A0 =C2=A0 Server implementers SHOULD guard against the possibility of t= his sort
=C2=A0 =C2=A0 of counterfeiting by gateways or CGI scripts.=C2=A0 In partic= ular it is
=C2=A0 =C2=A0 very dangerous for a server to simply turn over a connection = to a
=C2=A0 =C2=A0 gateway.=C2=A0 That gateway can then use the persistent conne= ction
=C2=A0 =C2=A0 mechanism to engage in multiple transactions with the client = while
=C2=A0 =C2=A0 impersonating the original server in a way that is not detect= able by
=C2=A0 =C2=A0 the client.

How should the server guard against this attack?=C2=A0 what sort does it me= an
to "turn over a connection to a gateway"?=C2=A0 does "gatewa= y" mean
"transparent HTTP proxy" or does it refer to something else?=C2= =A0 Sorry if
this is elementary stuff, but the term "gateway" only appears in = this
paragraph.

 That text is present in RFC 2617; I don't understand it completely eith= er.

Maybe just drop the second half of the paragraph and only mention the threa= d itself?

Best regards, Julian

_______________________________________________
http-auth mailing list
http-auth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/http-auth



--

Best regards,
Kath= leen
--089e0158ab60fd85ab050f78d2d4-- From nobody Thu Feb 19 15:28:30 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43FF1A0398; Thu, 19 Feb 2015 15:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xv9KREIBfMgs; Thu, 19 Feb 2015 15:06:44 -0800 (PST) Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 117C21A0371; Thu, 19 Feb 2015 15:06:44 -0800 (PST) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 0CB953B805C; Thu, 19 Feb 2015 15:06:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=puE9hLU3cluv6aZuUUYHf4gRF4Q=; b=qifJHA2UKDqYdqdSoY/Vw2gyCzdB PpbC4SnqebFQgyeOAb8Xg/ZZMzbObzHwe8WtNoTqMPqtF4u4J19CnTwfnSzyb0cr WLJAo/euxZieNOS+T3jTgX682hndMU0y1wBDMFng534XWsV7c12rFgs8cp8/KsSf SZfrYJCepBHKWzM= Received: from [192.168.1.12] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id CD40D3B8059; Thu, 19 Feb 2015 15:06:42 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: "Roy T. Fielding" In-Reply-To: <54E648B9.6030606@gmx.de> Date: Thu, 19 Feb 2015 15:06:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9A93C4F9-C14E-410E-81B7-E36E05270FD2@gbiv.com> References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> <54E648B9.6030606@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1283) Archived-At: X-Mailman-Approved-At: Thu, 19 Feb 2015 15:28:29 -0800 Cc: "http-auth@ietf.org" , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 23:06:46 -0000 On Feb 19, 2015, at 12:34 PM, Julian Reschke wrote: > On 2015-02-19 21:15, Daniel Kahn Gillmor wrote: >> On Thu 2015-02-19 14:07:54 -0500, Julian Reschke wrote: >>> The network exchange will be take milliseconds. The string = comparison >>> microseconds. /me not convinced there's a problem here. >>=20 >> as long as the attacker can measure microseconds, and the network >> exchange has small or regular-enough jitter to be accounted for with >> statistical techniques, the size difference between these parts = doesn't >> matter to a timing attack. >>=20 >> http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf >>=20 >> says: >>=20 >> The resolution an attacker can time a remote host depends on how = many >> measurements they can collect. Our simulated attacker using >> statistical hypothesis testing was able to reliably distinguish a >> processing time differences as low as 200ns and 30=B5s with 1,000 >> measurements on the LAN and WAN respectively with. (See Section = 6.) >>=20 >> Note that salted, hashed passwords where the attacker doesn't know = the >> salt are resistant to using a timing oracle like this to do = byte-by-byte >> guessing. I still think it's simpler to just recommend that the = tests >> should be constant time. >=20 > I'm sorry, I'm not convinced. What do others think? It is possible to run a timing attack on a remote server that uses any form of authentication scheme. However, the likelihood of detecting within the attack a difference of matching N characters vs N+1 = characters is incredibly small (usually less than 1 nanosecond) unless the matching algorithm itself is unusually complicated. In any case, we can't just recommend that the tests should be constant = time. Very few people understand what that means, even in a security = discussion. I don't think we use any matching schemes within Apache that do partial comparison during mid-algorithm -- IIRC, we recreate the hash based on = the complete input and then use a string function to compare the result to = the stored password. Of course, others could extend Apache to do more. A more reasonable thing to say is that any authentication system that allows a client to perform more than three failed authentication = attempts on a single connection, or more than ten on a single account over = multiple connections, is likely to be vulnerable to password guessing attacks. Timing attacks then become completely irrelevant. [...] >>>> And sorry, one more question arises for me on re-read. i'm not sure = i >>>> understand what this means: >>>>=20 >>>> Server implementers SHOULD guard against the possibility of = this sort >>>> of counterfeiting by gateways or CGI scripts. In particular it = is >>>> very dangerous for a server to simply turn over a connection to = a >>>> gateway. That gateway can then use the persistent connection >>>> mechanism to engage in multiple transactions with the client = while >>>> impersonating the original server in a way that is not = detectable by >>>> the client. >>>>=20 >>>> How should the server guard against this attack? what sort does it = mean >>>> to "turn over a connection to a gateway"? does "gateway" mean >>>> "transparent HTTP proxy" or does it refer to something else? Sorry = if >>>> this is elementary stuff, but the term "gateway" only appears in = this >>>> paragraph. >>>=20 >>> That text is present in RFC 2617; I don't understand it completely = either. This is about web server internals. Back in the early days, when HTTP = was limited to one request per connection, there was a thing called NPH = scripts that would allow a script to directly respond to the client instead of = their response being framed by the server; a trivial implementation could hand off the file descriptor to the script and exit. However, that kind of implementation became a potential security hole when persistent = connections were introduced, since the script could redirect the client to a protected space within the same origin (controlled by someone else) and receive the redirected request within the script input, bypassing = the web server's normal request-target hierarchy and collecting the = credentials. The solution is to never delegate message framing. >>>=20 >>> Maybe just drop the second half of the paragraph and only mention = the >>> thread itself? >>=20 >> If we drop the second half, i'd still like to know what kind of steps = a >> server should take to guard against the possibility of = counterfeiting. >> If we don't have any recommendations or external references, an >> unactionable SHOULD seems troublesome. >=20 > I'd just say >=20 > "Basic Authentication is also vulnerable to spoofing by counterfeit = servers. If a user can be led to believe that he is connecting to a host = containing information protected by Basic authentication when, in fact, = he is connecting to a hostile server or gateway, then the attacker can = request a password, store it for later use, and feign an error. This = type of attack is not possible with other authentication schemes, such = as Digest Authentication." Er, it is possible with Digest, but less productive (the credentials are only usable for as long as the nonce works). ....Roy From nobody Thu Feb 19 15:39:44 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0991E1A1A48; Thu, 19 Feb 2015 15:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ac8m2M3CzNgo; Thu, 19 Feb 2015 15:39:38 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB631A1A45; Thu, 19 Feb 2015 15:39:38 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 1D3B8F984; Thu, 19 Feb 2015 18:39:33 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 04616202F4; Thu, 19 Feb 2015 18:39:31 -0500 (EST) From: Daniel Kahn Gillmor To: "Roy T. Fielding" , Julian Reschke In-Reply-To: <9A93C4F9-C14E-410E-81B7-E36E05270FD2@gbiv.com> References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> <54E648B9.6030606@gmx.de> <9A93C4F9-C14E-410E-81B7-E36E05270FD2@gbiv.com> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 19 Feb 2015 18:39:30 -0500 Message-ID: <877fvda2tp.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "http-auth@ietf.org" , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 23:39:41 -0000 On Thu 2015-02-19 18:06:42 -0500, Roy T. Fielding wrote: > I don't think we use any matching schemes within Apache that do partial > comparison during mid-algorithm -- IIRC, we recreate the hash based on the > complete input and then use a string function to compare the result to the > stored password. Of course, others could extend Apache to do more. fwiw, apache on windows and netware apparently does support plaintext password files: https://httpd.apache.org/docs/2.4/misc/password_encryptions.html it seems likely that this is just strcmp() or the equivalent though i haven't looked. I'm not calling out Apache on this, fwiw -- i think Apache httpd is usually doing the right thing here, and has clearly indicated that this is insecure. > A more reasonable thing to say is that any authentication system that > allows a client to perform more than three failed authentication attempts > on a single connection, or more than ten on a single account over multiple > connections, is likely to be vulnerable to password guessing attacks. > Timing attacks then become completely irrelevant. This is an interesting suggestion, and should be useful against more than just timing attacks. How should that filter be applied? It seems like it could create some sort of denial of service attack vector if it's not done judiciously (e.g. Alice tries to lock out Bob by faking bad logins from Bob). >>>>> And sorry, one more question arises for me on re-read. i'm not sure i >>>>> understand what this means: >>>>> >>>>> Server implementers SHOULD guard against the possibility of this sort >>>>> of counterfeiting by gateways or CGI scripts. In particular it is >>>>> very dangerous for a server to simply turn over a connection to a >>>>> gateway. That gateway can then use the persistent connection >>>>> mechanism to engage in multiple transactions with the client while >>>>> impersonating the original server in a way that is not detectable by >>>>> the client. >>>>> >>>>> How should the server guard against this attack? what sort does it mean >>>>> to "turn over a connection to a gateway"? does "gateway" mean >>>>> "transparent HTTP proxy" or does it refer to something else? Sorry if >>>>> this is elementary stuff, but the term "gateway" only appears in this >>>>> paragraph. >>>> >>>> That text is present in RFC 2617; I don't understand it completely either. > > This is about web server internals. Back in the early days, when HTTP was > limited to one request per connection, there was a thing called NPH scripts > that would allow a script to directly respond to the client instead of their > response being framed by the server; a trivial implementation could hand > off the file descriptor to the script and exit. However, that kind of > implementation became a potential security hole when persistent connections > were introduced, since the script could redirect the client to a > protected space within the same origin (controlled by someone else) > and receive the redirected request within the script input, bypassing the > web server's normal request-target hierarchy and collecting the credentials. > The solution is to never delegate message framing. Thanks for this explanation, it makes much more sense to me with the context, and the key takeaway (about delegation of message framing) seems like it's likely to be still relevant. Can we incorporate some of this in the draft somehow? --dkg From nobody Thu Feb 19 16:10:26 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0648A1A1A7E; Thu, 19 Feb 2015 16:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0AwuybIhRF4; Thu, 19 Feb 2015 16:10:23 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 61B6B1A1A78; Thu, 19 Feb 2015 16:10:23 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 2512F77805B; Thu, 19 Feb 2015 16:10:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=gpkLeCxJC0LT7S9WBv1RU1YjrNE=; b=npG4o/oH1y1bw82ICnlEFRqYUwTV dceqvT09RY5CXiYgRJf1OoGJlCAYXSExkaSaH3mfTL6nfbYQLdlDtzOY6iwoxCNw gUslse4WZIru4WgUkX23urvRK2Wak1fOyMVcThs6+IRkbkx9wJgXEqOHW8vQSrRr VQkKEIW/kWbWozI= Received: from [192.168.1.12] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id E6FBA778057; Thu, 19 Feb 2015 16:10:22 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <877fvda2tp.fsf@alice.fifthhorseman.net> Date: Thu, 19 Feb 2015 16:10:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> <54E648B9.6030606@gmx.de> <9A93C4F9-C14E-410E-81B7-E36E05270FD2@gbiv.com> <877fvda2tp.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.1283) Archived-At: Cc: Julian Reschke , "http-auth@ietf.org" , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 00:10:25 -0000 On Feb 19, 2015, at 3:39 PM, Daniel Kahn Gillmor wrote: > On Thu 2015-02-19 18:06:42 -0500, Roy T. Fielding wrote: >=20 >> I don't think we use any matching schemes within Apache that do = partial >> comparison during mid-algorithm -- IIRC, we recreate the hash based = on the >> complete input and then use a string function to compare the result = to the >> stored password. Of course, others could extend Apache to do more. >=20 > fwiw, apache on windows and netware apparently does support plaintext > password files: >=20 > https://httpd.apache.org/docs/2.4/misc/password_encryptions.html >=20 > it seems likely that this is just strcmp() or the equivalent though i > haven't looked. >=20 > I'm not calling out Apache on this, fwiw -- i think Apache httpd is > usually doing the right thing here, and has clearly indicated that = this > is insecure. Right, these files are typically for storing simple barriers -- like the shared codes you might give out to a family for a picture album. Good enough to block spiders, but not intended to be secure, and = generally admin-defined rather than user-chosen. Apache also supports a variety = of hash algorithms for backwards compatibility with previously stored = accounts. >> A more reasonable thing to say is that any authentication system that >> allows a client to perform more than three failed authentication = attempts >> on a single connection, or more than ten on a single account over = multiple >> connections, is likely to be vulnerable to password guessing attacks. >> Timing attacks then become completely irrelevant. >=20 > This is an interesting suggestion, and should be useful against more > than just timing attacks. How should that filter be applied? It = seems > like it could create some sort of denial of service attack vector if > it's not done judiciously (e.g. Alice tries to lock out Bob by faking > bad logins from Bob). Yes, what I've seen is typically implemented as a temporary lock-out on the order of minutes -- long enough to prevent iterative attack techniques, but short enough that a user wouldn't mind. It is also sometimes combined with an alert to the user. How to implement it correctly depends on the overall web server architecture, such as whether the block is only per-server or covers an entire domain. I don't think we need to describe specifically how to implement it. >>>>>> And sorry, one more question arises for me on re-read. i'm not = sure i >>>>>> understand what this means: >>>>>>=20 >>>>>> Server implementers SHOULD guard against the possibility of = this sort >>>>>> of counterfeiting by gateways or CGI scripts. In particular = it is >>>>>> very dangerous for a server to simply turn over a connection = to a >>>>>> gateway. That gateway can then use the persistent connection >>>>>> mechanism to engage in multiple transactions with the client = while >>>>>> impersonating the original server in a way that is not = detectable by >>>>>> the client. >>>>>>=20 >>>>>> How should the server guard against this attack? what sort does = it mean >>>>>> to "turn over a connection to a gateway"? does "gateway" mean >>>>>> "transparent HTTP proxy" or does it refer to something else? = Sorry if >>>>>> this is elementary stuff, but the term "gateway" only appears in = this >>>>>> paragraph. >>>>>=20 >>>>> That text is present in RFC 2617; I don't understand it completely = either. >>=20 >> This is about web server internals. Back in the early days, when = HTTP was >> limited to one request per connection, there was a thing called NPH = scripts >> that would allow a script to directly respond to the client instead = of their >> response being framed by the server; a trivial implementation could = hand >> off the file descriptor to the script and exit. However, that kind = of >> implementation became a potential security hole when persistent = connections >> were introduced, since the script could redirect the client to a >> protected space within the same origin (controlled by someone else) >> and receive the redirected request within the script input, bypassing = the >> web server's normal request-target hierarchy and collecting the = credentials. >> The solution is to never delegate message framing. >=20 > Thanks for this explanation, it makes much more sense to me with the > context, and the key takeaway (about delegation of message framing) > seems like it's likely to be still relevant. Can we incorporate some = of > this in the draft somehow? Fine with me, ....Roy From nobody Fri Feb 20 05:32:56 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE731A8ACA; Fri, 20 Feb 2015 05:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.916 X-Spam-Level: * X-Spam-Status: No, score=1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=2.795, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMx8DASgCR1L; Fri, 20 Feb 2015 05:32:52 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A49551A8A16; Fri, 20 Feb 2015 05:32:51 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M3RVA-1XYD6i2Nxg-00r3ZF; Fri, 20 Feb 2015 14:32:36 +0100 Message-ID: <54E7376C.5070303@gmx.de> Date: Fri, 20 Feb 2015 14:32:28 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> In-Reply-To: <871tllbw2c.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:FxBtHdFQoQRz5einn3CQUP/I1Xg+hR4Lg47uZ0NiGcZ1jAGmfgL /21WNPOT1VeeZycDk5+PBCBFN5Gxsz864Clp93MV8/UKjnb4xGRxnxVmLX4/JmEvF3GBw1Y MvMOtJKG4uJkAY5hFI0520q7VZy/382T4WEVAta/L6/SRVra7FmaOrLSVS4VLMgwmb8tcPx mxBolQWHnXHXUQNxpxcEA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "http-auth@ietf.org" , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-httpauth-basicauth-update-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 13:32:53 -0000 On 2015-02-19 19:22, Daniel Kahn Gillmor wrote:> ... > I don't have the bandwidth to craft something fancy right now, but > here's a first stab that you're welcome to carve up as you see fit, if > no IETF references are forthcoming: > > Servers and proxies requiring Basic Authentication must store user > passwords in some form in order to verify the request's > Authorization: header. These passwords should be stored in such a > way that a leak of the password table doesn't make them trivially > recoverable. This is especially when users are allowed to set their > own passwords, since users are known to choose weak passwords and to > reuse them across authentication realms. While a full discussion of > good password hashing techniques for HTTP Basic Authentication is > beyond the scope of this document, server operators should make an > effort to minimize risks to their users in the event of a password > table leak. For example, servers should not store user passwords in > plaintext or as unsalted digests. For more discussion about modern > password hashing techniques, see [PHC]. > > [PHC] https://password-hashing.net Password Hashing Competition > > (i've used "should not" instead of RFC 2119 "SHOULD NOT" above because > this is not a recommendation about the on-the-wire protocol. If anyone > thinks it should be elevated to an RFC 2119 "SHOULD NOT" i'd be happy to > see that happen, because this is seriously low-hanging fruit, and i'm > sure there are still operators out there disregarding it. > ... I have added very similar text with ): >> Servers and proxies implementing Basic Authentication need to store >> user passwords in some form in order to authenticate a request. >> These passwords ought to be be stored in such a way that a leak of >> the password data doesn't make them trivially recoverable. This is >> especially important when users are allowed to set their own >> passwords, since users are known to choose weak passwords and to >> reuse them across authentication realms. While a full discussion of >> good password hashing techniques is beyond the scope of this >> document, server operators ought to make an effort to minimize risks >> to their users in the event of a password data leak. For example, >> servers ought to avoid storing user passwords in plaintext or as >> unsalted digests. For more discussion about modern password hashing >> techniques, see the "Password Hashing Competition" >> (). Thanks for the proposal! Best regards, Julian From nobody Fri Feb 20 05:53:28 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFE31A7D81; Fri, 20 Feb 2015 05:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQEbTaRqC0T2; Fri, 20 Feb 2015 05:53:21 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104391A710C; Fri, 20 Feb 2015 05:53:21 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lv8hi-1XOpmz22SY-010OSP; Fri, 20 Feb 2015 14:53:00 +0100 Message-ID: <54E73C32.6070108@gmx.de> Date: Fri, 20 Feb 2015 14:52:50 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "http-auth@ietf.org" References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> <54E648B9.6030606@gmx.de> <9A93C4F9-C14E-410E-81B7-E36E05270FD2@gbiv.com> In-Reply-To: <9A93C4F9-C14E-410E-81B7-E36E05270FD2@gbiv.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:moybVFRhPayWO/el3nE88vk+uXPw5ZD0U6//Ghp9yFtblo7CkF5 YoOKtUBgvuSfQj0mpwFyPZkZQiYJ246fD4KYvTuf1SMaWAG+ocEkYpeS2hk6wI28nn58n0j HOL8FI3MGy0XplzO9fVGG2nmdQju5JVP+FviwcJ46Y2x9D2CSHzjrqOqPhd7/1/820CzQWl tKo+AS1SwRnAofJz6m6Iw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "secdir@ietf.org" , "Roy T. Fielding" , "http-auth@ietf.org" , iesg@ietf.org, draft-ietf-httpauth-basicauth-update.all@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-httpauth-basicauth-update-06 - security considerations on counterfeiting attacks X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 13:53:23 -0000 On 2015-02-20 00:06, Roy T. Fielding wrote: > ... >>>>> And sorry, one more question arises for me on re-read. i'm not sure i >>>>> understand what this means: >>>>> >>>>> Server implementers SHOULD guard against the possibility of this sort >>>>> of counterfeiting by gateways or CGI scripts. In particular it is >>>>> very dangerous for a server to simply turn over a connection to a >>>>> gateway. That gateway can then use the persistent connection >>>>> mechanism to engage in multiple transactions with the client while >>>>> impersonating the original server in a way that is not detectable by >>>>> the client. >>>>> >>>>> How should the server guard against this attack? what sort does it mean >>>>> to "turn over a connection to a gateway"? does "gateway" mean >>>>> "transparent HTTP proxy" or does it refer to something else? Sorry if >>>>> this is elementary stuff, but the term "gateway" only appears in this >>>>> paragraph. >>>> >>>> That text is present in RFC 2617; I don't understand it completely either. > > This is about web server internals. Back in the early days, when HTTP was > limited to one request per connection, there was a thing called NPH scripts > that would allow a script to directly respond to the client instead of their > response being framed by the server; a trivial implementation could hand > off the file descriptor to the script and exit. However, that kind of > implementation became a potential security hole when persistent connections > were introduced, since the script could redirect the client to a > protected space within the same origin (controlled by someone else) > and receive the redirected request within the script input, bypassing the > web server's normal request-target hierarchy and collecting the credentials. > The solution is to never delegate message framing. > ... Thanks for the explanation, Roy. I have changed that paragraph to: > Basic authentication is also vulnerable to spoofing by counterfeit > servers. If a user can be led to believe that she is connecting to a > host containing information protected by Basic authentication when, > in fact, she is connecting to a hostile server or gateway, then the > attacker can request a password, store it for later use, and feign an > error. Server implementers ought to guard against this sort of > counterfeiting; in particular, software components which can take > over control over the message framing on an existing connection (for > instance, "NPH" ("non parsing of headers") scripts) need to be used > carefully or not at all. () Best regards, Julian From nobody Fri Feb 20 06:01:06 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453B61A879A; Fri, 20 Feb 2015 06:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1w2gi39ABW2C; Fri, 20 Feb 2015 06:01:01 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946801A87E3; Fri, 20 Feb 2015 06:01:01 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M6Ana-1XeEvY1Z1O-00y9uj; Fri, 20 Feb 2015 15:00:34 +0100 Message-ID: <54E73DF9.5050501@gmx.de> Date: Fri, 20 Feb 2015 15:00:25 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , http-auth@ietf.org References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> <54E648B9.6030606@gmx.de> <9A93C4F9-C14E-410E-81B7-E36E05270FD2@gbiv.com> <877fvda2tp.fsf@alice.fifthhorseman.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:f+CNl1Yjj3irXYTUBnIu6nnFWHJB75gFXI3dHJWb4o0Mt4I49eN WgCs/MUYGnDmKdgFygIVGwg0BEr05F2lHR4jtiqzO4mg8ZQrXfbSXbxmjIvHr4msjQb3hLN 2IIRECaVKI/l47nxdn/j4tBrbcp0St9oQjjQr1Yx3yb5POOvWuZBEQ7DYBcbv5ZLNE2xA9k heloIDyY48KYFzu5Nd18g== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: secdir@ietf.org, Julian Reschke , "Roy T. Fielding" , "http-auth@ietf.org" , iesg@ietf.org, draft-ietf-httpauth-basicauth-update.all@tools.ietf.org Subject: [secdir] [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 -- security considerations on timing/guessing attacks X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 14:01:03 -0000 On 2015-02-20 01:10, Roy T. Fielding wrote: > ... >>> A more reasonable thing to say is that any authentication system that >>> allows a client to perform more than three failed authentication attempts >>> on a single connection, or more than ten on a single account over multiple >>> connections, is likely to be vulnerable to password guessing attacks. >>> Timing attacks then become completely irrelevant. >> >> This is an interesting suggestion, and should be useful against more >> than just timing attacks. How should that filter be applied? It seems >> like it could create some sort of denial of service attack vector if >> it's not done judiciously (e.g. Alice tries to lock out Bob by faking >> bad logins from Bob). > > Yes, what I've seen is typically implemented as a temporary lock-out > on the order of minutes -- long enough to prevent iterative attack > techniques, but short enough that a user wouldn't mind. It is also > sometimes combined with an alert to the user. How to implement it > correctly depends on the overall web server architecture, such as > whether the block is only per-server or covers an entire domain. > > I don't think we need to describe specifically how to implement it. > ... As this advice applies is not specific to Basic: how about putting this on our TODO list for RFC 7235bis? Best regards, Julian From nobody Fri Feb 20 07:50:10 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052751A8781; Fri, 20 Feb 2015 07:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLRrBy2pR4vE; Fri, 20 Feb 2015 07:50:02 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62941A8547; Fri, 20 Feb 2015 07:50:01 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M7HGA-1Xapi23egY-00x41H; Fri, 20 Feb 2015 16:49:37 +0100 Message-ID: <54E75788.2020809@gmx.de> Date: Fri, 20 Feb 2015 16:49:28 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> In-Reply-To: <87mw49ac9h.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:nybL+O+WEV2E2oNVzXd3cY33aepJfgT07Yvq4oqwF7jfr+B6Y3M cgvgO7JvmjavSGkYaPWC3LlBVbdpz3DwtN9weSTpNnPjmGZPI7SQeo0ErZwqKAteO5/SEPL qGsfOzcF0Qy1RNc3pvsU/6vVy5HPPXgdRQkFUWQLTT0CvsCMTxEbnPG0jQ+uaBKKQXNY/p3 fTtXyHhQJi+zaT+mVuC3g== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "http-auth@ietf.org" , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-httpauth-basicauth-update-06 -- transition strategy for charset parameter X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 15:50:04 -0000 On 2015-02-19 21:15, Daniel Kahn Gillmor wrote: > ... >> That being said, the heuristics are quite simple: try to decode the >> octets with a strict UTF-8 decoder, and if that doesn't fail the input >> was likely encoded in UTF-8. > > Some binary strings are valid in both character encodings, though, > right? For example, "c3 a1 62 63" in UTF-8 is "รกbc", but in ISO-8859-1, > it is "รƒยกbc" So if my password is non-ASCII in the first place, it could > very well match the UTF-8 encoding even though i've intended another > one. > > So maybe the heuristic should be: even if the UTF-8 decode succeeds, the > server could try its fallback decoding mechanism if the UTF-8 version of > the password doesn't match. (fwiw, my understanding is that facebook > checks common accidental variations on the entered password during their > (non-basic-auth) login process. so if my password is b4nanAs, but i > type B4NANaS or b5nanAs, facebook might let me in anyway) > > Is this advisable? What are the risks of testing two variants of the > password against the password table? I haven't thought this through > fully, but it seems like it would be a relevant consideration. > > In the absence of a signal from the client about their choice of > encoding, documenting these heuristics and recommending them seems like > a useful way to facilitate adoption and uniformity among servers > implementing this spec. > ... I looked at this some more, and it seems that the general question applies to the third paragraph in B.2 (): Finally, origin servers that need to support non-US-ASCII characters and can use the UTF-8 character encoding scheme can opt in as described above. In the worst case, they'll continue to see either broken credentials or no credentials at all (depending on how legacy clients handle characters they cannot encode). I propose to expand the problem description, and to mention that servers that need to support a mix of clients can attempt a "try both" strategy: Finally, origin servers that need to support non-US-ASCII characters and can use the UTF-8 character encoding scheme can opt in by specifying the charset parameter in the authentication challenge. Clients that do understand the charset parameter will then start to use UTF-8, while other clients will continue to send credentials in their default encoding, broken credentials, or no credentials at all. Until all clients are upgraded to support UTF-8, servers are likely to see both UTF-8 and "legacy" encodings in requests. When processing as UTF-8 fails (due to a failure to decode as UTF-8 or a mismatch of user-id/password), a server might try a fallback to the previously supported legacy encoding in order to accomodate these legacy clients. Note that implicit retries need to be done carefully; for instance, some subsystems might detect repeated login failures and treat them as potential credentials guessing attack. (). WDYT? Best regards, Julian PS: slightly related: this section talks about origin servers instead of servers (-> proxy authentication); I'll fix that as well. From nobody Fri Feb 20 10:50:17 2015 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 2704F1A8746; Fri, 20 Feb 2015 10:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1424457644; bh=lW1ltYFKbgW1Staw/O4e8Obkr3QgpwUYhjR7O8s1opo=; 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=DIyM5mTcZWrOGDXYCgIbgoxjxnhXtM8QqhPYLBImdjaLiAsS0BKRLsZmjreBM0pSA 7DQ96zY0sedSDJo+G52f6LBgjE6av8RWy0on2E1Gejz7L4ARdYpISWe+8KVgNNNgzd AhIDtUKJljQnXKJWzTtVpF+KxpZGzZmwbLOh1jwY= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED7E1A8746; Fri, 20 Feb 2015 10:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8v_wLZKk4tS; Fri, 20 Feb 2015 10:40:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5514B1A00E5; Fri, 20 Feb 2015 10:40:41 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150220184041.25156.74580.idtracker@ietfa.amsl.com> Date: Fri, 20 Feb 2015 10:40:41 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 20 Feb 2015 10:50:15 -0800 Subject: [secdir] [new-work] WG Review: Token Binding (tokbind) 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, 20 Feb 2015 18:40:44 -0000 A new IETF working group has been proposed in the Security 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 2015-03-02. Token Binding (tokbind) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Stephen Farrell Mailing list Address: unbearable@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/unbearable Archive: http://www.ietf.org/mail-archive/web/unbearable/ Charter: Web services generate various security tokens (e.g. HTTP cookies, OAuth tokens, etc.) for web applications to access protected resources. Currently these are bearer tokens, i.e. any party in possession of such token gains access to the protected resource. Attackers export bearer tokens from client machines or from compromised network connections, present these bearer tokens to Web services, and impersonate authenticated users. Token Binding enables defense against such attacks by cryptographically binding security tokens to a secret held by the client. The tasks of this working group are as follows: 1. Specify the Token Binding protocol v1.0. 2. Specify the use of the Token Binding protocol in combination with HTTPS. It is a goal of this working group to enable defense against attacks that involve unauthorized replay of security tokens. Other issues associated with the use of security tokens are out of scope. Another goal of this working group is to design the Token Binding protocol such that it would be also useable with application protocols other than HTTPS. Specifying alternative application protocols is not a primary goal. The main design objectives for the Token Binding protocol, in no particular order: 1. Allow applications and services to prevent unauthorized replay of security tokens. 2. Allow strong key protection, e.g. using hardware-bound keys. 3. Support both first-party (server generates a token for later use with this server) and federation (server generates a token for use with another server) scenarios. 4. Preserve user privacy. 5. Make the Token Binding protocol useable in combination with a variety of application protocols. 6. Allow the negotiation of the Token Binding protocol without additional round-trips. 7. Allow the use of multiple cryptographic algorithms, so that a variety of secure hardware modules with different cryptographic capabilities could be used with Token Binding. 8. Propose Token Binding specification that can be implemented in Web browsers (but is not limited to them). E.g. Web browsers require that the same bound security token must be presentable over multiple TLS sessions and connections. The working group will use the following documents as a starting point for its work: - draft-popov-token-binding-00; - draft-balfanz-https-token-binding-00. This WG will collaborate with other IETF WGs, in particular with the TLS, HTTPbis and Oauth WGs and with the W3C webappsec WG. Milestones: Jan 2016 - HTTPS Token Binding to IESG. Jan 2016 - WG document for the Token Binding Protocol v1.0. Jan 2016 - WG document for HTTPS Token Binding. Jan 2016 - Token Binding Protocol v1.0 to IESG. _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Feb 20 10:50:18 2015 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 E8CB21A889C; Fri, 20 Feb 2015 10:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1424458092; bh=vhSJ/ZpXwqT8yX3YlMyRQYVwVZIENmq0I8CkwhjY0jM=; 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=NHRxltv2HpIFBpktK3X+xs7RN2rfz+osJX1rAt1f943Lvs4cCvsSEWfmOKHv7wD5a DkGN+bcJprfX/7cv3XmH7/gEXyDggBZX0wEJ6ajVZRK5Zn6VShHs6BvCKYk2Ub7ZxT JDA+v5ULL8USErIxZyFZKFxHrZN4yLI5QFNHmrqU= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845481A88AC; Fri, 20 Feb 2015 10:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.906 X-Spam-Level: X-Spam-Status: No, score=-0.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FS_REPLICA=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5JxvOc34j-8; Fri, 20 Feb 2015 10:48:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D271A6FD5; Fri, 20 Feb 2015 10:48:07 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150220184807.29521.19544.idtracker@ietfa.amsl.com> Date: Fri, 20 Feb 2015 10:48:07 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 20 Feb 2015 10:50:15 -0800 Subject: [secdir] [new-work] WG Review: Bit Indexed Explicit Replication (bier) 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, 20 Feb 2015 18:48:12 -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 2015-03-02. Bit Indexed Explicit Replication (bier) ------------------------------------------------ Current Status: Proposed WG Chairs: Greg Shepherd Tony Przygienda Assigned Area Director: Alia Atlas Mailing list Address: bier@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bier Archive: http://www.ietf.org/mail-archive/web/bier/current/maillist.html Charter: In conventional IP multicast forwarding, the packets of a given multicast "flow" are forwarded along a tree that has been constructed for the specific purpose of carrying that flow. This requires transit nodes to maintain state on a per-flow basis, and requires the transit nodes to participate in multicast-specific tree building protocols. The flow to which a packet belongs is determined by its IP source and destination address fields. BIER (Bit Index Explicit Replication) is an alternative method of multicast forwarding. It does not require any multicast-specific trees, and hence does not require any multicast-specific tree building protocols. Within a given "BIER domain", an ingress node encapsulates a multicast data packet in a "BIER header". The BIER header identifies the packet's egress nodes in that domain. Each possible egress node is represented by a a single bit within a bitstring; to send a packet to a particular set of egress nodes, the ingress node sets the bits for each of those egress nodes, and clears the other bits in the bistring. Each packet can then be forwarded along the unicast shortest path tree from the ingress node to the egress nodes. Thus there are no per-flow forwarding entries. Due to the particular sensitivity of adding new significant functionality into the data-plane at high link speeds, the BIER work will progress as Experimental. As described in item (9) below, the work may become Standards Track once there is sufficient experience with the benefits and downsides of the technology. BIER is initially chartered to do experimental work on this new multicast forwarding mechanism as follows: 1) BIER architecture: The WG will publish an architecture, based upon draft-wijnands-bier-architecture-04. It will include the normative algorithm for how BIER packet forwarding is done. It will specify the information that is required by a BIER header to support BIER forwarding. 2) BIER encapsulation: The working group should assume that the technology will need to be embedded in the data plane and operate at the highest packet line speeds. The WG will publish a document defining an MPLS-based encapsulation based upon draft-wijnands-mpls-bier-encapsulation-02. Due to the critical need to have a high-quality and stable RFC for a new data-plane encapsulation, the MPLS-based encapsulation draft shall wait after WGLC and not progress to IETF Last Call until there are two independent interoperable implementations. As a secondary focus, the WG may also work on one non-MPLS data-plane encapsulation. This draft also shall wait after WGLC and not progress to IETF Last Call until there are two independent interoperable implementations. This draft must focus on and include the following details: a) What is the applicability of the encapsulation and for which use-cases is this encapsulation required? b) Does this proposed encapsulation imply any changes to the MPLS-based encapsulation? c) What design choices have been made for the encapsulation type and the included fields. d) The proposed encapsulation with considerations given to at least OAM, Class of Service, security, fragmentation, TTL. 3) Transition Mechanisms: The WG will describe how BIER can be partially deployed and still provide useful functionality. A minimum of the necessary mechanisms to support incremental deployment and/or managing different BIER mask-length compatibility may be defined. Each such mechanism must include an applicability statement to differentiate its necessity from other proposed mechanisms. 4) Applicability Statements: The WG will work on a document describing how BIER can be applied to multicast L3VPN and to EVPN. This draft will describe what mechanism is used to communicate the group membership between the ingress router and the egress routers, what scalability considerations may arise, and any deployment considerations. 5) Use Case: The WG may produce one use-case document that clearly articulates the potential benefits of BIER for different use-cases. This would be based upon draft-kumar-bier-use-cases-01. 6) OAM: The WG will describe how OAM will work in a BIER domain and what simplifications BIER offers for managing the multicast traffic. A strong preference will be given to extensions to existing protocols. 7) Management models: The WG may work on YANG models and, if needed, MIB modules to support common manageability. 8) IGP extensions. When a BIER domain falls within a "link state IGP"" network, the information needed to set up the BIER forwarding tables (e.g., the mapping between a given bit position and a given egress router) may be carried in the link state advertisements of the IGP. The link state advertisments may also carry other information related to forwarding (e.g., the IGP may support multiple topologies, in which case it may be necessary to advertise which topologies are to be used for BIER forwarding). Any necessary extensions to the IGP will be specified by the WG, in cooperation with the ISIS and OSPF WGs. 9) Deployment Experience: Once there is deployment experience, the WG will produce a document describing the benefits, problems, and trade-offs for using BIER instead of traditional multicast forwarding mechanisms. Ideally, this should also contain an analysis of the impact and benefit of the new BIER data-plane to the overall Internet architecture. This document is intended to be used to evaluate whether to recharter BIER to produce Standards Track RFCs. The BIER working group will coordinate with several different working groups and must include the relevant other working groups during working group last call on the relevant drafts. BIER will coordinate with MPLS on the MPLS-based encapsulation and associated MPLS-based OAM mechanisms. BIER will coordinate with ISIS and OSPF on extensions to flood BIER-related information. BIER will coordinate with BESS and IDR on the applicability of existing BGP-based mechanisms for providing multicast group membership information. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Sun Feb 22 23:01:59 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818451A014E for ; Sun, 22 Feb 2015 23:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQ9EvMjq6EaC for ; Sun, 22 Feb 2015 23:01:57 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD481A004B for ; Sun, 22 Feb 2015 23:01:56 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t1N71sBa011179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Feb 2015 07:01:55 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1N71s8l017132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2015 07:01:54 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t1N71rrn011737; Mon, 23 Feb 2015 07:01:54 GMT Received: from [10.159.86.55] (/10.159.86.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 22 Feb 2015 23:01:48 -0800 Message-ID: <54EAD095.2000200@oracle.com> Date: Mon, 23 Feb 2015 00:02:45 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20150125 Thunderbird/17.0.11 MIME-Version: 1.0 To: secdir@ietf.org, draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org References: <54AA17B0.40500@oracle.com> In-Reply-To: <54AA17B0.40500@oracle.com> X-Forwarded-Message-Id: <54AA17B0.40500@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: Subject: [secdir] Review of draft-ietf-ccamp-rwa-wson-encode-27 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 07:01:58 -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. The draft specifies an encoding scheme for information on a Wavelength Switched Optical Network (WSON). Specifically, information that is used for Routing and Wavelength Assignment (RWA). The security considerations section does exist and discloses that the draft does not impose any security considerations in itself, but does admit that documents that reference this draft would have considerations for privacy, spoofing, and tampering of any associated data. I agree with this assertion. General comments: None. Editorial comments: Usually the Abstract is the first section in the draft. The abbreviations should have the expanded word with the corresponding capital letter. GMPLS is not initially expanded in the Abstract section. s/RB identifier./RB identifiers./ Shawn. -- From nobody Mon Feb 23 15:37:34 2015 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 C21601A1A92; Mon, 23 Feb 2015 15:35:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1424734518; bh=TtBVVkGfuvck4VKxXhVXnLd+IXOuAv2QICM8gmLVVrI=; h=Mime-Version:From:Date:Message-Id:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=ylJdhOM8Mh0uzgsdjBgMlRkBlEVa15PwcPKLqxXxOkyuQ7z5m+JaM95gOdl7qJ/AI Fu29uZeqP10TmaMWixuL1hf/X5IYpC5yNyS5Sm3/tQDxlH6dHk9ip2uHM3EqwZ3mNS uvAvYdfvtVMsLEQ0k76+apBBpeOQiNbMJuiB4Uc4= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F80A1A0235 for ; Mon, 23 Feb 2015 15:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjy4S3xVt_C6 for ; Mon, 23 Feb 2015 15:35:15 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9542E1A1A92 for ; Mon, 23 Feb 2015 15:35:15 -0800 (PST) Received: from [205.178.22.30] (helo=[192.168.1.4]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YQ2Ww-0004F7-1T; Mon, 23 Feb 2015 18:35:14 -0500 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ian Jacobs Date: Mon, 23 Feb 2015 17:35:13 -0600 X-Mao-Original-Outgoing-Id: 446427312.787572-85d166c2ac24caf11f3713e4fd97c6d6 Message-Id: <531D487A-C9C8-4551-8460-A30044D3B11C@w3.org> To: new-work@ietf.org X-Mailer: Apple Mail (2.2070.6) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Mon, 23 Feb 2015 15:37:33 -0800 Subject: [secdir] [new-work] Proposed W3C Web Accessibility Initiative (WAI) Charters (until 2015-03-23) 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, 23 Feb 2015 23:35:19 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Web Accessibility Initiative [0] (see the W3C Process Document description of Activity Proposals [1]). The proposal includes the following draft charters: Accessible Platform Architectures Working Group (APA WG) (Formerly the Protocols and Formats Working Group) http://www.w3.org/2012/10/draft-pfwg-charter Web Content Accessibility Guidelines Working Group (WCAG WG) http://www.w3.org/2013/04/draft-wcag-charter Authoring Tool Accessibility Guidelines Working Group (ATAG WG) http://www.w3.org/WAI/AU/2013/draft_auwg_charter.html User Agent Accessibility Guidelines Working Group (UAWG) http://www.w3.org/WAI/UA/2013/draft_uawg_charter Evaluation and Repair Tools Working Group (ERT WG) http://www.w3.org/WAI/ER/charter5.html Education and Outreach Working Group (EOWG) http://www.w3.org/WAI/EO/2013/charter6 Research and Development Working Group (RDWG) http://www.w3.org/WAI/RD/charter4.html WAI Interest Group (WAI IG) http://www.w3.org/WAI/IG/charter5.html WAI Coordination Group (WAI CG) http://www.w3.org/WAI/CG/charter5.html As part of ensuring that the community is aware of proposed work at W3C, these draft charters are public during the Advisory Committee review period. W3C invites public comments through 2015-03-23. 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 Judy Brewer . Thank you, Ian Jacobs [0] http://www.w3.org/WAI/ [1] http://www.w3.org/2014/Process-20140801/#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs http://www.w3.org/People/Jacobs Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Wed Feb 25 14:46:35 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585731A9124 for ; Wed, 25 Feb 2015 14:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOlyzJrGRT13 for ; Wed, 25 Feb 2015 14:46:32 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73EB61A908B for ; Wed, 25 Feb 2015 14:46:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F087FBE9F for ; Wed, 25 Feb 2015 22:46:30 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ii9CRiyV9tp for ; Wed, 25 Feb 2015 22:46:29 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.41.57.139]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D37D9BE75 for ; Wed, 25 Feb 2015 22:46:29 +0000 (GMT) Message-ID: <54EE50C5.2030802@cs.tcd.ie> Date: Wed, 25 Feb 2015 22:46:29 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "secdir@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] secdir lunch in Dallas X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 22:46:33 -0000 Hiya, The room assignment for the secdir lunch in Dallas is Pavilion. We're meeting at the usual Tuesday lunch slot and also as usual please grab yourself some lunch beforehand. Cheers, S. From nobody Thu Feb 26 01:30:40 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7ED1A1BE3 for ; Thu, 26 Feb 2015 01:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRMzgDkrYGit for ; Thu, 26 Feb 2015 01:30:35 -0800 (PST) Received: from BLU004-OMC2S4.hotmail.com (blu004-omc2s4.hotmail.com [65.55.111.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44181A0367 for ; Thu, 26 Feb 2015 01:30:34 -0800 (PST) Received: from BLU436-SMTP137 ([65.55.111.73]) by BLU004-OMC2S4.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 26 Feb 2015 01:30:34 -0800 X-TMN: [smRw7VDuzUE7ngB+7PBG08jDBiDaiOzk] X-Originating-Email: [zhang_dacheng@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_B6F8753C-E7D7-4463-BB1F-EEB22E6D8EDB" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dacheng In-Reply-To: <54EAD095.2000200@oracle.com> Date: Thu, 26 Feb 2015 17:30:22 +0800 References: <54AA17B0.40500@oracle.com> <54EAD095.2000200@oracle.com> To: secdir@ietf.org X-Mailer: Apple Mail (2.1878.6) X-OriginalArrivalTime: 26 Feb 2015 09:30:32.0509 (UTC) FILETIME=[DE05D6D0:01D051A6] Archived-At: Cc: draft-ietf-nfsv4-lfs-registry.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-nfsv4-lfs-registry-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 09:30:39 -0000 --Apple-Mail=_B6F8753C-E7D7-4463-BB1F-EEB22E6D8EDB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="GB2312" I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. This document specifies a registry of label format specifications. I didn=A1=AFt see any security issues in this document and consider it = Ready To Publish. Cheers Dacheng --Apple-Mail=_B6F8753C-E7D7-4463-BB1F-EEB22E6D8EDB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="GB2312" I have reviewed this document as = part of the security directorate's ongoing effort to review all IETF = documents being processed by the IESG.  These comments were written = primarily for the benefit of the  security area directors. =  Document editors and WG chairs should treat these comments just = like any other last call comments.

This document specifies a = registry of label format specifications.

I didn=A1=AFt see = any security issues in this document and consider = it Ready To Publish.

Cheers

Dacheng

= --Apple-Mail=_B6F8753C-E7D7-4463-BB1F-EEB22E6D8EDB--