From kent@bbn.com Tue Nov 1 05:50:59 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34EBD11E8820 for ; Tue, 1 Nov 2011 05:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.357 X-Spam-Level: X-Spam-Status: No, score=-106.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTN0W8dKZc3g for ; Tue, 1 Nov 2011 05:50:58 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4861F11E8855 for ; Tue, 1 Nov 2011 05:50:58 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:34908 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RLDnq-0003Zh-PN; Tue, 01 Nov 2011 08:50:55 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 1 Nov 2011 08:46:08 -0400 To: secdir@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: simon@josefsson.org, lear@cisco.com, hmauldin@cisco.com Subject: [secdir] review of draft-ietf-kitten-sasl-openid-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 12:50:59 -0000 I reviewed this document (draft-ietf-kitten-sasl-openid-06) 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. Overall comment: the document contains a number of typos, and odd English constructions. These problems detract from its readability, and need to be addressed. This document describes how to map OpenID to GSS-API and SASL. OpenID is a protocol used to enable single sign-on (SSO) in a three party (client, server, id provider) scheme. SASL is an IETF standard used to "modularize" authentication (and other security mechanisms) so that new mechanisms can easily be added, as needed. GSS-API is an IETF framework intended to enable use of various authentication mechanisms via a uniform interface. Thus there is overlap between SASL and GSS-API. This document defines a "pure" SASL mechanism but it also offers a GSS-API G2 interface as well. The document says that it attempts to reuse as much of the OpenID mechanism as possible, and notes that it targets browser environments. The proposal preserves the OpenID provider interface, but requires "enhancements" (a euphemism for changes) to both the client and relying party (e.g., server). The document says that use of TLS is a MUST, for protection of OpenID transactions. Consistent with this requirement, the document says that "the client MUST successfully validate the server certificate" but then includes an ambiguous phrase "or similar integrity protected and authenticated channels." The two cites provided here are to the current PKIX base standard (RFC 5280) and to the recent standard on how to use ID info extracted from a certificate in the TLS context (RFC 6125). Thus the cites provide no hints about what the latter phrase really means. Although the introduction says "This specification is appropriate for use when a browser is available." Section 2 is titled "Applicability for non-HTTP Use Cases" a surprising start to the non-intro portion of the document! In examining the processing steps described in Section 2, I was confused by step 4, on page 6. The text says: 4. The Relying Party and the OP optionally establish an association -- a shared secret established using Diffie-Hellman Key Exchange. The OP uses an association to sign subsequent messages and the Relying Party to verify those messages; this removes the need for subsequent direct requests to verify the signature after each authentication request/response. A Diffie-Hellman exchange yields a shared secret value that typically is used to encrypt traffic, using a symmetric algorithm. But, the text says that the association created using Diffie-Hellman is used to "sign subsequent messages." I don't see how this occurs. Perhaps the authors meant to say that traffic sent via this connection will be integrity protected (not signed), but there is no mention here of the integrity mechanism that would be employed with the shared secret from the Diffie-Hellman exchange. Also, this step is cited as optional. If the option is not elected, what are the security implications for the remaining steps (5-11) of the protocol? This text needs to be modified to address these problems and questions. The diagram that describes these protocol steps (and which has no label) is a good way to augment the text description of the 11 steps. However, the diagram includes tags "gt" and "lt" that do not appear in legends anywhere in this document. Section 2.1 is very brief, and a bit confusing. It discusses the potential need for a relying party to place a nonce or ID into URIs. The text gives only generic examples of how to do this, suggesting that there is no need to define a standard representation. If this is true, the text should be expanded a bit to make clear why this is true. At the end of Section 2.2, (page 9) the document says "A transaction id, MUST be included by the RP by appending it to the return_to URL." This text in 2.2 and the text in 2.1 seem to contradict one another. Section 2.2 uses the acronym "IPC" which appears nowhere else, and is not defined. The phrasing in the second paragraph is very odd in several places. I suggest enlisting the help of a native English speaker to improve the text here. At the end of 2.2 (page 9) the wording is confusing, i.e., "OpenID is also meant to be used in serial within the web." Also, there is no specification for the transaction id that is a MUST at the end of 2.2. An explanation is needed here, i.e., why is a transaction id required, but there is no need for a spec for this id. In 3.1, the document says "The GS2 header carries the optional authorization identity." It is not clear if this implies that the header MUST carry the auth identity, even though it is optional in the more general case, or if carriage of this identity is a MAY. Subsequent text does not clarify this ambiguity, e.g., "The "gs2-authzid" carries the optional authorization identity." In 3.2, the document clarifies that the format of the transaction ID is not mandated. However, the admonition "but SHOULD be large enough to be resistant to being guessed or attacked." is not very helpful. Guidance ought to be included here. The opening paragraph for section 4 is too long and needs to be reworded. In Section 5, the term "OpenID Consumer" is used for the first time. It is not defined anywhere in the document. Is "OpenID Consumer" the relying party? Since the example here does not entail an association between the OP and the OpenID Consumer is it a suitably representative example? The Secruity Considerations Section (#6) addresses security topics only in the context of OpenID when used with SASL and GSS-API. I think this is appropriate, and a reference to an OpenID-specific security considerations is OK. But, the cite provided is not to an IETF document, and thus I do not consider it adequate. Section 6.1 is very fluffy in its discussion of what is needed to ensure that the mapping between an OpenID and an authorization ID is appropriate/secure. Also, the term "server" is as used here, which may be ambiguous. I assume the relying party is the server in question, right? The security issue highlighted in 6.2 is worthy of the discussion, but, again, the advice is a bit fluffy. Saying that an implementation should "carefully analyze URLs received" is not especially helpful. The RECOMMENDATION to restrict the URL to http or https is the only concrete guidance. I find the discussion in Section 7 to not be very useful. It provides a vague suggestion about the utility of a SASL client signaling the beginning of a sensitive transaction, to trigger "increased scrutiny." Since this document describes how to use SASL (and GSS-API) with OpenID in a fashion that preserves the current OpenID interface, a vague suggestion about how that interface might be improved seems out of place. From kivinen@iki.fi Tue Nov 1 06:12:02 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E1C11E8118; Tue, 1 Nov 2011 06:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y21g-x7dxGb; Tue, 1 Nov 2011 06:12:01 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8A521F8FAE; Tue, 1 Nov 2011 06:11:59 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id pA1DBjfH003672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Nov 2011 15:11:45 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id pA1DBisQ022202; Tue, 1 Nov 2011 15:11:44 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20143.61456.621918.500638@fireball.kivinen.iki.fi> Date: Tue, 1 Nov 2011 15:11:44 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: draft-ietf-avtext-client-to-mixer-audio-level.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-avtext-client-to-mixer-audio-level-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 13:12:02 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a extension to the RTP to indicate the audio level of stream without the need to decode and measure the stream received. This is needed so conference call mixer does not need to decode all streams to be able to detect which of them contains audio and which should be forwarded to participants. The security considerations section seems to include good analysis on what security properties this extension could have (including denial-of service attack, and passive listeners infering information about the conversation). I see no issues with this document. -- kivinen@iki.fi From simon@josefsson.org Tue Nov 1 07:20:53 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFDE21F9089 for ; Tue, 1 Nov 2011 07:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bahAptsxXo7G for ; Tue, 1 Nov 2011 07:20:53 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfa.amsl.com (Postfix) with ESMTP id 6D82821F908E for ; Tue, 1 Nov 2011 07:20:51 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id pA1EJjGD022428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 1 Nov 2011 15:19:47 +0100 From: Simon Josefsson To: Stephen Kent References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:111101:kent@bbn.com::Z20sJ1xeGKDFFwlB:4cgG X-Hashcash: 1:22:111101:shawn.emery@oracle.com::/VNv+hqICRYMr8ni:3y68 X-Hashcash: 1:22:111101:hmauldin@cisco.com::lxg92h5rIVKvil1K:AmbB X-Hashcash: 1:22:111101:secdir@ietf.org::cyG16F1OjZVm7ey8:FFat X-Hashcash: 1:22:111101:hannes.tschofenig@gmx.net::dHzTW7Jad4cpgeTs:7a0Y X-Hashcash: 1:22:111101:lear@cisco.com::ouPH3yqvhGRN1woW:Dgig X-Hashcash: 1:22:111101:tlyu@mit.edu::+TD/cIK5s6y99M+1:EppD X-Hashcash: 1:22:111101:alexey.melnikov@isode.com::Kimc2I02XID+p/XV:B0bN X-Hashcash: 1:22:111101:stephen.farrell@cs.tcd.ie::66FKT9auMKTwE7km:VTAl Date: Tue, 01 Nov 2011 15:19:45 +0100 In-Reply-To: (Stephen Kent's message of "Tue\, 1 Nov 2011 08\:46\:08 -0400") Message-ID: <871utr53i6.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.2 at yxa-v X-Virus-Status: Clean Cc: lear@cisco.com, secdir@ietf.org, hmauldin@cisco.com Subject: Re: [secdir] review of draft-ietf-kitten-sasl-openid-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 14:20:53 -0000 Stephen, Thanks for your review. I'm addressing some issues, leaving the rest for Eliot and others. Stephen Kent writes: > In examining the processing steps described in Section 2, I was > confused by step 4, on page 6. The text says: > > 4. The Relying Party and the OP optionally establish an association > -- a shared secret established using Diffie-Hellman Key Exchange. The > OP uses an association to sign subsequent messages and the Relying > Party to verify those messages; this removes the need for subsequent > direct requests to verify the signature after each authentication > request/response. > > A Diffie-Hellman exchange yields a shared secret value that typically > is used to encrypt traffic, using a symmetric algorithm. But, the text > says that the association created using Diffie-Hellman is used to > "sign subsequent messages." I don't see how this occurs. Perhaps the > authors meant to say that traffic sent via this connection will be > integrity protected (not signed), but there is no mention here of the > integrity mechanism that would be employed with the shared secret from > the Diffie-Hellman exchange. Also, this step is cited as optional. If > the option is not elected, what are the security implications for the > remaining steps (5-11) of the protocol? This text needs to be modified > to address these problems and questions. Isn't all that specified by the OpenID protocol? > In 3.1, the document says "The GS2 header carries the optional > authorization identity." It is not clear if this implies that the > header MUST carry the auth identity, even though it is optional in the > more general case, or if carriage of this identity is a > MAY. Subsequent text does not clarify this ambiguity, e.g., "The > "gs2-authzid" carries the optional authorization identity." The situation is a bit more complicated than a simple MUST/MAY, but I believe everything is clear from the base SASL specification: https://tools.ietf.org/html/rfc4422#section-3.4.1 Authorization identities are always optional, but mechanisms are required to be able to transfer them if they are used by the application. If you review the base SASL specification about authorization identity, do you still believe this document needs to say more than it does here? > In Section 5, the term "OpenID Consumer" is used for the first > time. It is not defined anywhere in the document. Is "OpenID Consumer" > the relying party? Yes. "Consumer" is OpenID 1.x terminology, this should be fixed. /Simon From kent@bbn.com Tue Nov 1 08:43:58 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A25811E80A2 for ; Tue, 1 Nov 2011 08:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.4 X-Spam-Level: X-Spam-Status: No, score=-106.4 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3yX5UYLLOcW for ; Tue, 1 Nov 2011 08:43:57 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A337F11E8094 for ; Tue, 1 Nov 2011 08:43:57 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:46605 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RLGVG-00069V-Qu; Tue, 01 Nov 2011 11:43:55 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <871utr53i6.fsf@latte.josefsson.org> References: <871utr53i6.fsf@latte.josefsson.org> Date: Tue, 1 Nov 2011 11:43:41 -0400 To: Simon Josefsson From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-891960261==_ma============" Cc: lear@cisco.com, secdir@ietf.org, hmauldin@cisco.com Subject: Re: [secdir] review of draft-ietf-kitten-sasl-openid-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 15:43:58 -0000 --============_-891960261==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 3:19 PM +0100 11/1/11, Simon Josefsson wrote: >Stephen, >... > > >> A Diffie-Hellman exchange yields a shared secret value that typically >> is used to encrypt traffic, using a symmetric algorithm. But, the text >> says that the association created using Diffie-Hellman is used to >> "sign subsequent messages." I don't see how this occurs. Perhaps the >> authors meant to say that traffic sent via this connection will be >> integrity protected (not signed), but there is no mention here of the >> integrity mechanism that would be employed with the shared secret from >> the Diffie-Hellman exchange. Also, this step is cited as optional. If >> the option is not elected, what are the security implications for the >> remaining steps (5-11) of the protocol? This text needs to be modified >> to address these problems and questions. > >Isn't all that specified by the OpenID protocol? I don't see any IETF document that describes OpenID, and that concerns me. But, using Google, and searching for "openID protocol signature" I did find an intro doc at wiki.openid.net. That doc refers to "openid.sig = *base 64 encoded HMAC signature*" This is NOT a signature. It is a MAC (a message authentication code). So, please change the text to note the actual secruity mechanism being employed here. > > In 3.1, the document says "The GS2 header carries the optional >> authorization identity." It is not clear if this implies that the >> header MUST carry the auth identity, even though it is optional in the >> more general case, or if carriage of this identity is a >> MAY. Subsequent text does not clarify this ambiguity, e.g., "The >> "gs2-authzid" carries the optional authorization identity." > >The situation is a bit more complicated than a simple MUST/MAY, but I >believe everything is clear from the base SASL specification: > >https://tools.ietf.org/html/rfc4422#section-3.4.1 > >Authorization identities are always optional, but mechanisms are >required to be able to transfer them if they are used by the >application. That statement, if placed in the I-D, will resolve my question. >If you review the base SASL specification about authorization identity, >do you still believe this document needs to say more than it does here? yes, I believe it should include the concise, clear statement that you made :-). > >> In Section 5, the term "OpenID Consumer" is used for the first >> time. It is not defined anywhere in the document. Is "OpenID Consumer" >> the relying party? > >Yes. "Consumer" is OpenID 1.x terminology, this should be fixed. Thanks, Steve --============_-891960261==_ma============ Content-Type: text/html; charset="us-ascii" Re: review of draft-ietf-kitten-sasl-openid-06
At 3:19 PM +0100 11/1/11, Simon Josefsson wrote:
Stephen,
...
>
> A Diffie-Hellman exchange yields a shared secret value that typically
> is used to encrypt traffic, using a symmetric algorithm. But, the text
> says that the association created using Diffie-Hellman is used to
> "sign subsequent messages." I don't see how this occurs.  Perhaps the
> authors meant to say that traffic sent via this connection will be
> integrity protected (not signed), but there is no mention here of the
> integrity mechanism that would be employed with the shared secret from
> the Diffie-Hellman exchange. Also, this step is cited as optional. If
> the option is not elected, what are the security implications for the
> remaining steps (5-11) of the protocol? This text needs to be modified
> to address these problems and questions.
Isn't all that specified by the OpenID protocol?

I don't see any IETF document that describes OpenID, and that concerns me. But, using Google, and searching for "openID protocol signature" I did find an
intro doc at wiki.openid.net. That doc refers to "openid.sig = *base 64 encoded HMAC signature*"  This is NOT a signature. It is a MAC (a message authentication code).  So, please change the text to note the actual secruity mechanism being employed here.

> In 3.1, the document says "The GS2 header carries the optional
> authorization identity." It is not clear if this implies that the
> header MUST carry the auth identity, even though it is optional in the
> more general case, or if carriage of this identity is a
> MAY. Subsequent text does not clarify this ambiguity, e.g., "The
> "gs2-authzid" carries the optional authorization identity."

The situation is a bit more complicated than a simple MUST/MAY, but I
believe everything is clear from the base SASL specification:
https://tools.ietf.org/html/rfc4422#section-3.4.1

Authorization identities are always optional, but mechanisms are
required to be able to transfer them if they are used by the
application.

That statement, if placed in the I-D, will resolve my question.

If you review the base SASL specification about authorization identity,
do you still believe this document needs to say more than it does here?

yes, I believe it should include the concise, clear statement that you made :-).


> In Section 5, the term "OpenID Consumer" is used for the first
> time. It is not defined anywhere in the document. Is "OpenID Consumer"
> the relying party?
Yes.  "Consumer" is OpenID 1.x terminology, this should be fixed.

Thanks,

Steve
--============_-891960261==_ma============-- From lear@cisco.com Tue Nov 1 09:04:04 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CC711E80BE for ; Tue, 1 Nov 2011 09:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.932 X-Spam-Level: X-Spam-Status: No, score=-109.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDEgfPgE0XZi for ; Tue, 1 Nov 2011 09:04:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id F137511E812D for ; Tue, 1 Nov 2011 09:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=10886; q=dns/txt; s=iport; t=1320163442; x=1321373042; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=xrAnNjVosb9vUCfZpZHKnIdVI0CsUPRwXjKNnQoBXQ4=; b=ZvOnHgf+ddw3ZJhn3JMC5UgICBzd7gnEaeT1YP+Tp8aL7ug4tLkjLBJt 6Fw20QrBV+Gl/JjGT2/Tz0iLm6+1gwCyyOk+XH3XYkVVr8qOtuk4nNMcN EwrB4DbG8n1WVrd1nLncMesjHHF4NyHsQwuj8LrVkXSVlnzZfnl1xCOSY o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAF4XsE6Q/khN/2dsb2JhbAA5CYR3pESBBYFyAQEBAwESARBEEQYLCxgCAgUWCwICCQMCAQIBRQYBDAgBAR6HYJZrAYxLkWYEgTCEKYIagRQElA+RYA X-IronPort-AV: E=Sophos;i="4.69,438,1315180800"; d="scan'208";a="120530020" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 01 Nov 2011 16:03:59 +0000 Received: from dhcp-10-61-102-245.cisco.com (dhcp-10-61-102-245.cisco.com [10.61.102.245]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA1G3wWw003712; Tue, 1 Nov 2011 16:03:58 GMT Message-ID: <4EB0186D.8040200@cisco.com> Date: Tue, 01 Nov 2011 17:03:57 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Stephen Kent , secdir , draft-lear-ietf-sasl-openid.all@tools.ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] review of draft-ietf-kitten-sasl-openid-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 16:04:04 -0000 Steve, Hannes, can you send me the specific authorization identity text you agreed to? That wasn't clear. Thanks for the review. For my part... On 11/1/11 1:46 PM, Stephen Kent wrote: > I reviewed this document (draft-ietf-kitten-sasl-openid-06) 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. > > Overall comment: the document contains a number of typos, and odd > English constructions. These problems detract from its readability, > and need to be addressed. > > This document describes how to map OpenID to GSS-API and SASL. OpenID > is a protocol used to enable single sign-on (SSO) in a three party > (client, server, id provider) scheme. SASL is an IETF standard used to > "modularize" authentication (and other security mechanisms) so that > new mechanisms can easily be added, as needed. GSS-API is an IETF > framework intended to enable use of various authentication mechanisms > via a uniform interface. Thus there is overlap between SASL and > GSS-API. This document defines a "pure" SASL mechanism but it also > offers a GSS-API G2 interface as well. > > The document says that it attempts to reuse as much of the OpenID > mechanism as possible, and notes that it targets browser environments. > The proposal preserves the OpenID provider interface, but requires > "enhancements" (a euphemism for changes) to both the client and > relying party (e.g., server). The design consideration is that identity providers (OPs) and browsers should remain untouched, since these are likely the components that are most difficult to change. The mechanism itself requires few changes to clients. The heavy lifting is done by the SASL server or RP. > The document says that use of TLS is a MUST, for protection of OpenID > transactions. Consistent with this requirement, the document says that > "the client MUST successfully validate the server certificate" but > then includes an ambiguous phrase "or similar integrity protected and > authenticated channels." RFC 6091 is really what I have in mind (perhaps other authors had other things in mind) but I take your point. Will remove the phrase. > The two cites provided here are to the current PKIX base standard (RFC > 5280) and to the recent standard on how to use ID info extracted from > a certificate in the TLS context (RFC 6125). Thus the cites provide no > hints about what the latter phrase really means. > > Although the introduction says "This specification is appropriate for > use when a browser is available." Section 2 is titled "Applicability > for non-HTTP Use Cases" a surprising start to the non-intro portion of > the document! The point is to make use of the web-based identity infrastructure for other application protocols. I've reworded this as follows: Applicability for application protocols other than HTTP > > In examining the processing steps described in Section 2, I was > confused by step 4, on page 6. The text says: > > 4. The Relying Party and the OP optionally establish an association > -- a shared secret established using Diffie-Hellman Key Exchange. The > OP uses an association to sign subsequent messages and the Relying > Party to verify those messages; this removes the need for subsequent > direct requests to verify the signature after each authentication > request/response. > > A Diffie-Hellman exchange yields a shared secret value that typically > is used to encrypt traffic, using a symmetric algorithm. But, the text > says that the association created using Diffie-Hellman is used to > "sign subsequent messages." I don't see how this occurs. Perhaps the > authors meant to say that traffic sent via this connection will be > integrity protected (not signed), but there is no mention here of the > integrity mechanism that would be employed with the shared secret from > the Diffie-Hellman exchange. Also, this step is cited as optional. If > the option is not elected, what are the security implications for the > remaining steps (5-11) of the protocol? This text needs to be modified > to address these problems and questions. This is informational text that references standard OpenID 2.0. Please see Section 8 of the referenced specification. If you prefer we can simply shorten this text to indicate something along the lines of "... establish an association for use as described in Section 8 of..." > > The diagram that describes these protocol steps (and which has no > label) is a good way to augment the text description of the 11 steps. > However, the diagram includes tags "gt" and "lt" that do not appear in > legends anywhere in this document. I don't see those tags in my copy of the draft... > > Section 2.1 is very brief, and a bit confusing. It discusses the > potential need for a relying party to place a nonce or ID into URIs. > The text gives only generic examples of how to do this, suggesting > that there is no need to define a standard representation. If this is > true, the text should be expanded a bit to make clear why this is > true. At the end of Section 2.2, (page 9) the document says "A > transaction id, MUST be included by the RP by appending it to the > return_to URL." This text in 2.2 and the text in 2.1 seem to > contradict one another. Thanks. We'll combine. The intent is that there must be a nonce, but the format can be internal to the RP. > > > Section 2.2 uses the acronym "IPC" which appears nowhere else, and is > not defined. Expanded. > The phrasing in the second paragraph is very odd in several places. I > suggest enlisting the help of a native English speaker to improve the > text here. > > At the end of 2.2 (page 9) the wording is confusing, i.e., "OpenID is > also meant to be used in serial within the web." Also, there is no > specification for the transaction id that is a MUST at the end of 2.2. > An explanation is needed here, i.e., why is a transaction id required, > but there is no need for a spec for this id. Ok, this is cleaned up. The key point: when you are 100% within a browser, you can stick transaction ids in a browser cookie that gets retrieved by the RP. With an application in the middle you lose that ability. > > In 3.1, the document says "The GS2 header carries the optional > authorization identity." It is not clear if this implies that the > header MUST carry the auth identity, even though it is optional in the > more general case, or if carriage of this identity is a MAY. > Subsequent text does not clarify this ambiguity, e.g., "The > "gs2-authzid" carries the optional authorization identity." > > In 3.2, the document clarifies that the format of the transaction ID > is not mandated. However, the admonition "but SHOULD be large enough > to be resistant to being guessed or attacked." is not very helpful. > Guidance ought to be included here. That depends on the state of capabilities of computing devices, I suppose. Got guidance? > > The opening paragraph for section 4 is too long and needs to be reworded. > > In Section 5, the term "OpenID Consumer" is used for the first time. > It is not defined anywhere in the document. Is "OpenID Consumer" the > relying party? Since the example here does not entail an association > between the OP and the OpenID Consumer is it a suitably representative > example? > > The Secruity Considerations Section (#6) addresses security topics > only in the context of OpenID when used with SASL and GSS-API. I > think this is appropriate, and a reference to an OpenID-specific > security considerations is OK. But, the cite provided is not to an > IETF document, and thus I do not consider it adequate. Steve, the base specification we're working from is a non-IETF document. I don't want to simply copy their spec (that would be rude, to say the least). > > Section 6.1 is very fluffy in its discussion of what is needed to > ensure that the mapping between an OpenID and an authorization ID is > appropriate/secure. Also, the term "server" is as used here, which may > be ambiguous. I assume the relying party is the server in question, right? I've tried to make the text less woolly: As specified in , the server is responsible for binding credentials to a specific authorization identity. It is therefore necessary that either a registration process takes place in advance that binds specific OpenIDs to specific authorization identities, or that only specific trusted OpenID Providers be allowed, where a mapping is predefined. (for example where it is known that "https://example.com/user" maps to "user" for purposes of authorization.) > > The security issue highlighted in 6.2 is worthy of the discussion, > but, again, the advice is a bit fluffy. Saying that an implementation > should "carefully analyze URLs received" is not especially helpful. > The RECOMMENDATION to restrict the URL to http or https is the only > concrete guidance. How's this: To mitigate this attack, implementations should carefully analyze URLs received, eliminating any that would in some way be privileged. One mitigation would be for RPs to have a list of authorized URI bases. OPs SHOULD only redirect to RPs with the same domain component of the base URI. RPs MUST NOT automatically retry on failed attempts. A log of those sites that fail SHOULD be kept, and limitations on queries from clients SHOULD be imposed, just as with any other authentication attempt. Applications should not invoke browsers to communicate with OPs that they are not themselves configured with. > > I find the discussion in Section 7 to not be very useful. It provides > a vague suggestion about the utility of a SASL client signaling the > beginning of a sensitive transaction, to trigger "increased scrutiny." > Since this document describes how to use SASL (and GSS-API) with > OpenID in a fashion that preserves the current OpenID interface, a > vague suggestion about how that interface might be improved seems out > of place. Ok, you're the Umpteenth person to say this, so we're going to pull the text. The idea here was that VAST number of applications DO make use of web-based authentication, and there probably should be some study into signaling between applications on a device. How that happens is ABSOLUTELY beyond the scope of this document, but I didn't want to lose the thought entirely. Again, thanks for taking the time to do the review. Eliot From kent@bbn.com Wed Nov 2 08:52:39 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B76821F9071 for ; Wed, 2 Nov 2011 08:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.456 X-Spam-Level: X-Spam-Status: No, score=-106.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6i+rfKX90dbF for ; Wed, 2 Nov 2011 08:52:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 58F0D21F8F85 for ; Wed, 2 Nov 2011 08:52:35 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38880 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RLcNp-00059F-8g; Wed, 02 Nov 2011 11:05:42 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4EB0186D.8040200@cisco.com> References: <4EB0186D.8040200@cisco.com> Date: Wed, 2 Nov 2011 09:49:23 -0400 To: Eliot Lear From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: draft-lear-ietf-sasl-openid.all@tools.ietf.org, secdir Subject: Re: [secdir] review of draft-ietf-kitten-sasl-openid-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 15:52:39 -0000 >... > > >> The document says that it attempts to reuse as much of the OpenID >> mechanism as possible, and notes that it targets browser environments. >> The proposal preserves the OpenID provider interface, but requires >> "enhancements" (a euphemism for changes) to both the client and >> relying party (e.g., server). > >The design consideration is that identity providers (OPs) and browsers >should remain untouched, since these are likely the components that are >most difficult to change. The mechanism itself requires few changes to >clients. The heavy lifting is done by the SASL server or RP. That's not the impression one gets from reading the text cited above. The text could be changed to emphasize that the client changes are very minor, but the clients are still the biggest population (among client, RPs, and OPs) right, and so change to them are potentially the hardest. >... >> Although the introduction says "This specification is appropriate for >> use when a browser is available." Section 2 is titled "Applicability >> for non-HTTP Use Cases" a surprising start to the non-intro portion of >> the document! > >The point is to make use of the web-based identity infrastructure for >other application protocols. I've reworded this as follows: > >Applicability for application protocols other than HTTP But doesn't thus section talk about how to use SASL and OpenID in support of the common, browser use case? > > In examining the processing steps described in Section 2, I was > > confused by step 4, on page 6. The text says: >> >> 4. The Relying Party and the OP optionally establish an association >> -- a shared secret established using Diffie-Hellman Key Exchange. The >> OP uses an association to sign subsequent messages and the Relying >> Party to verify those messages; this removes the need for subsequent >> direct requests to verify the signature after each authentication >> request/response. >> >> A Diffie-Hellman exchange yields a shared secret value that typically >> is used to encrypt traffic, using a symmetric algorithm. But, the text >> says that the association created using Diffie-Hellman is used to >> "sign subsequent messages." I don't see how this occurs. Perhaps the >> authors meant to say that traffic sent via this connection will be >> integrity protected (not signed), but there is no mention here of the >> integrity mechanism that would be employed with the shared secret from >> the Diffie-Hellman exchange. Also, this step is cited as optional. If >> the option is not elected, what are the security implications for the >> remaining steps (5-11) of the protocol? This text needs to be modified >> to address these problems and questions. > >This is informational text that references standard OpenID 2.0. Please >see Section 8 of the referenced specification. If you prefer we can >simply shorten this text to indicate something along the lines of "... >establish an association for use as described in Section 8 of..." As noted in my reply to Simon, I did look at the OpenID spec, and discovered that it uses the wrong terminology in this context. (I am bothered by the fact that we don't have an RFC version of the OpenID spec, and that the spec we're citing contains errors of this sort. But, those are issues outside the scope of this review.) I think it appropriate to cite the relevant section of the OpenID spec, but also to note that what they refer to as a signature, is actually a MAC. > > The diagram that describes these protocol steps (and which has no > > label) is a good way to augment the text description of the 11 steps. >> However, the diagram includes tags "gt" and "lt" that do not appear in >> legends anywhere in this document. > >I don't see those tags in my copy of the draft... That's what I saw when I downloaded the I-D as a text file. But, looking at the PDF and the version displayed in my browser, I don't see the offending characters either. So, never mind ... > > In 3.1, the document says "The GS2 header carries the optional > > authorization identity." It is not clear if this implies that the >> header MUST carry the auth identity, even though it is optional in the >> more general case, or if carriage of this identity is a MAY. >> Subsequent text does not clarify this ambiguity, e.g., "The >> "gs2-authzid" carries the optional authorization identity." >> >> In 3.2, the document clarifies that the format of the transaction ID >> is not mandated. However, the admonition "but SHOULD be large enough >> to be resistant to being guessed or attacked." is not very helpful. >> Guidance ought to be included here. > >That depends on the state of capabilities of computing devices, I >suppose. Got guidance? The security community likes bit-length measures of entropy. In this case, the entropy is needed to achieve a high likelihood of uniqueness. it is not clear to me, from reading this doc (vs. the full OpenID spec) what is the required scope for the uniqueness. If an adversary has an unlimited number of attempts in a brief time window (e.g, Kamisky DNS attack), then the IETF community no longer believes that 2**16 is a big enough space. So, if you can characterize the attack surface, we can probably pick a suitable entropy target. >... > > >> The Secruity Considerations Section (#6) addresses security topics >> only in the context of OpenID when used with SASL and GSS-API. I >> think this is appropriate, and a reference to an OpenID-specific >> security considerations is OK. But, the cite provided is not to an >> IETF document, and thus I do not consider it adequate. > >Steve, the base specification we're working from is a non-IETF >document. I don't want to simply copy their spec (that would be rude, >to say the least). In the past we have created RFCs from docs that are products from other SDOs or companies, with their permission. I'm not saying that this is a requirement, but I am concerned, especially given the error I discovered, and some of the comments in this I-D, e.g., "Portions of the authentication stream are only defined in the crudest sense." > > Section 6.1 is very fluffy in its discussion of what is needed to > > ensure that the mapping between an OpenID and an authorization ID is >> appropriate/secure. Also, the term "server" is as used here, which may >> be ambiguous. I assume the relying party is the server in question, right? >I've tried to make the text less woolly: > > > As specified in , the server is > responsible for binding credentials to a specific authorization > identity. It is therefore necessary that either > a registration process takes place in advance that binds specific > OpenIDs to specific authorization identities, or that only specific > trusted OpenID Providers be allowed, where a mapping is predefined. > (for example where it is known that "https://example.com/user" maps to > "user" for purposes of authorization.) The content is good, but a single sentence that runs on for > 5 lines ... > > The security issue highlighted in 6.2 is worthy of the discussion, > > but, again, the advice is a bit fluffy. Saying that an implementation >> should "carefully analyze URLs received" is not especially helpful. >> The RECOMMENDATION to restrict the URL to http or https is the only >> concrete guidance. > >How's this: > > To mitigate this attack, implementations should carefully analyze > URLs received, eliminating any that would in some way be > privileged. One mitigation would be for RPs to have a list of authorized > URI bases. OPs SHOULD only redirect to RPs with the same domain > component of the base URI. RPs MUST NOT automatically retry on failed > attempts. A log of those sites that fail SHOULD be kept, and > limitations on queries from clients SHOULD be imposed, just as with > any other authentication attempt. Applications should not invoke > browsers to communicate with OPs that they are not themselves > configured with. > This is better. I'd say that what we can expect is a simple set of simple syntactic checks by an implementation, not really "careful analysis." Would you be comfortable making the list of "authorized URI bases" be a RECOMMENDATION, or is it just an example? Steve From jhutz@cmu.edu Wed Nov 2 10:01:46 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D099811E8109 for ; Wed, 2 Nov 2011 10:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeCAPRwX6Dec for ; Wed, 2 Nov 2011 10:01:46 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABE611E80F8 for ; Wed, 2 Nov 2011 10:01:46 -0700 (PDT) Received: from [192.168.202.155] (pool-74-109-253-27.pitbpa.fios.verizon.net [74.109.253.27]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id pA2H1XwW023879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Nov 2011 13:01:34 -0400 (EDT) From: Jeffrey Hutzelman To: Stephen Kent In-Reply-To: <16815_1320162240_pA1FhxC9012735_p06240806cad5c0c575be@[193.0.26.186]> References: <871utr53i6.fsf@latte.josefsson.org> <16815_1320162240_pA1FhxC9012735_p06240806cad5c0c575be@[193.0.26.186]> Content-Type: text/plain; charset="UTF-8" Date: Wed, 02 Nov 2011 13:01:32 -0400 Message-ID: <1320253292.28149.753.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: hmauldin@cisco.com, Simon Josefsson , secdir@ietf.org, lear@cisco.com, jhutz@cmu.edu Subject: Re: [secdir] review of draft-ietf-kitten-sasl-openid-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 17:01:46 -0000 On Tue, 2011-11-01 at 11:43 -0400, Stephen Kent wrote: > > The situation is a bit more complicated than a simple MUST/MAY, but > > I > > believe everything is clear from the base SASL specification: > > https://tools.ietf.org/html/rfc4422#section-3.4.1 > > > > Authorization identities are always optional, but mechanisms are > > required to be able to transfer them if they are used by the > > application. > > > That statement, if placed in the I-D, will resolve my question. That statement is not within the scope of this I-D. It's descriptive of SASL itself, and is covered in the SASL base specification. In particular, the requirement is one placed on SASL mechanisms (such as the present I-D) by SASL itself. Implementation of this mechanism requires an understanding of the SASL base specification (unless one is implementing only the underlying GSS-API mechanism, in which case the section in question is not relevant at all). I don't think it's necessary for every SASL mechanism to restate all of SASL's requirements, and it may even be harmful, because then it looks like you're trying to say something _different_ than what the SASL spec says. Do you really think any SASL implementor is going to be confused by this? From stpeter@stpeter.im Wed Nov 2 15:27:09 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C2211E80B3; Wed, 2 Nov 2011 15:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0HKrNrcFElf; Wed, 2 Nov 2011 15:27:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B6D3F11E8089; Wed, 2 Nov 2011 15:27:07 -0700 (PDT) Received: from squire.local (unknown [63.145.238.4]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CA9C741FE4; Wed, 2 Nov 2011 16:32:11 -0600 (MDT) Message-ID: <4EB1C399.7070408@stpeter.im> Date: Wed, 02 Nov 2011 15:26:33 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Stephen Hanna References: In-Reply-To: X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 02 Nov 2011 15:33:31 -0700 Cc: "draft-ietf-vcarddav-kind-app.all@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-vcarddav-kind-app-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 22:27:09 -0000 On 10/20/11 3:00 AM, Stephen Hanna 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 new value for the vCard kind property: > application. This value is to be used for vCards that represent > software applications. > > The Security Considerations section of this document states: > > Use of vCards to represent software applications is not envisioned to > introduce security considerations beyond those specified for vCards > in general as described in [VCARD]. > > However, the Security Considerations section of [VCARD] doesn't > seem adequate to the task. It merely points out that vCards don't > have any security protections and therefore SHOULD be transported > over a secure mechanism such as S/MIME or PGP if security is a > concern. This advice may be adequate if the vCard is only used > to transmit contact information for a person but it's generally > not adequate when the vCard contains information about a software > application. For example, this draft suggests that the KEY property > can be used to convey a public key associated with an application. > What a weak way to convey a public key! Will the recipient be able > to determine whether the key is accurate? How might the key be > revoked if necessary? No provisions are made for this. Other vCard > properties such as URL may cause problems if malicious. > > Without proper security protections, the application vCard kind > seems like a great tool for phishing and social engineering. > Attackers can forge an email apparently from a trusted party, > including an application vCard and instructions to click on it > to see something cool. A naive email client may easily decide > that clicking on an application vCard should run the application > referenced in the vCard or visit the URL in the vCard or whatever. > > I suggest that the Security Considerations section of the draft > be updated to include specific warnings that the contents of an > application vCard should be considered untrustworthy and dangerous > unless they have been securely delivered from a trustworthy source. > Even then, there's a real possibility that the source may have > been compromised before the vCard was sent. So information > obtained from vCards should not be regarded as ipso facto > trustworthy. Software should not act on information contained > in a vCard unless there's a strong reason to believe it's > accurate. And the KEY property SHOULD NOT be used for an > application. Instead, more robust techniques for managing > software public keys should be used. That all seems reasonable, and in general the deployment I have seen enables an entity to obtain the vCard from the application itself (e.g., in XMPP a server can advertise its own vCard, so it is the canonical source of information about itself, and that information can be obtained over a TLS-protected channel). However, I think the same concerns you raise apply to vCards in general and really belong in the core vCard specification (RFC 6350 or its replacement) -- for example, an attacker could append someone else's vCard to an email message directed to me, and if I (or my email client) blindly accepts the vCard then I could accept the vCard information (including URLs, KEYs, etc.), thus leading me to be misdirected (phishing), to use the wrong KEY when interacting with someone, etc. What in your concern is *specific* to vCards containing a KIND value of "application"? Peter -- Peter Saint-Andre https://stpeter.im/ From clonvick@cisco.com Wed Nov 2 16:16:13 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0C21F0C6A; Wed, 2 Nov 2011 16:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2g9G2OvwbsJL; Wed, 2 Nov 2011 16:16:12 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 99EB91F0C36; Wed, 2 Nov 2011 16:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=clonvick@cisco.com; l=1614; q=dns/txt; s=iport; t=1320275772; x=1321485372; h=date:from:to:subject:message-id:mime-version; bh=ckByEDOLEu30wGw8MswMzNE8bG+ZOPQmEJoVUWZLsBE=; b=Rpnk/Ts1o2mHw2CI1lvqmBMynJhe/trjAL/lic21u9yrWKfXkJa5Dafn FTvLSvlzOC7g2Tjvht16x5v8R8k1GJdr3k72+t+F2mM1dPsHm3EPMDJLW McQB6g9EqqMYPpey35xPQtCY+QcgJdXSAj/Eu5r0bZxpSqg/JTLd9r/je c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAFAB7PsU6rRDoI/2dsb2JhbABEmjsBjzuBBYILASUCgX40nh8BnnyJEASIB54S X-IronPort-AV: E=Sophos;i="4.69,446,1315180800"; d="scan'208";a="12015600" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 02 Nov 2011 23:16:12 +0000 Received: from sjc-cde-021.cisco.com (sjc-cde-021.cisco.com [171.69.20.56]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA2NGCJm006997; Wed, 2 Nov 2011 23:16:12 GMT Date: Wed, 2 Nov 2011 16:16:12 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-hui-6man-rpl-routing-header.all@tools.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [secdir] SECDIR review of draft-hui-6man-rpl-routing-header X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 23:16:13 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I havn't seen source routing in a long time so I had to wrap my head around that again. I tried working through some examples on how this would work for verious network conditions, but gave up before my head started hurting. :) Overall, it looks like the security concerns are addressed in the document. I do have some minor nits that the authors may wish to discuss. 1. I don't think that the following sentence in Section 6.1 is needed: "Furthermore, it is RECOMMENDED that non-RPL routers and firewalls drop packets with a SRH by default." That is already discussed in RFC 5095. Having it here is therefore redundant. 2. I'm not sure that I am correctly following all of your pseudocode in Section 4.2. In most places it looks like separate instructions within curly braces are separated by blank lines. From that, I'm not sure of what is meant by a semicolon in the following: else { decrement Segments Left by 1; compute i, the index of the next address to be visited in the address vector, by subtracting Segments Left from n if Address[i] or the IPv6 Destination Address is multicast { discard the packet } Hope this helps, Chris From d3e3e3@gmail.com Wed Nov 2 20:06:45 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303B81F0C36; Wed, 2 Nov 2011 20:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.157 X-Spam-Level: X-Spam-Status: No, score=-104.157 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjfn6erB+qiV; Wed, 2 Nov 2011 20:06:44 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA491F0C38; Wed, 2 Nov 2011 20:06:43 -0700 (PDT) Received: by faas12 with SMTP id s12so1293372faa.31 for ; Wed, 02 Nov 2011 20:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=p8rhI36eenW0VlV4Ds22ZvDh3NKqGU0u2JR/a6DGgQM=; b=ko0BirtQVPbvSjtQHf9fuCgLOHfCuLTWyWUPYANVHWbFenjHo8iEPl9dvYAWjV4TMv sNchO4G8GTULapfq+1gd6XLj3Chz/Ocp3OAZYFpmC2HIvh5DcAz4SloSNkL045aymweU qZcarMFWXH/Fn73is3rdf266ip9pNZ9mM8C2Y= Received: by 10.223.75.150 with SMTP id y22mr12913902faj.29.1320289603268; Wed, 02 Nov 2011 20:06:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.43.4 with HTTP; Wed, 2 Nov 2011 20:06:19 -0700 (PDT) From: Donald Eastlake Date: Wed, 2 Nov 2011 23:06:19 -0400 Message-ID: To: draft-ietf-savi-framework.all@tools.ietf.org, IETF Discussion Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: secdir@ietf.org Subject: [secdir] draft-ietf-savi-framework-05 SECDIR review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 03:06:45 -0000 draft-ietf-savi-framework-05.txt This document is a high level framework for SAVI and references a number of other documents. As such, I think, that the Security Considerations section is probably of adequate depth. However, there are a number of wording problems, both clarity and grammar, that I believe should be fixed, particularly in the Security Consideration section (Section 10) where there is one sentence I really didn't understand. See below. Also, as an Information document, it cannot have Normative References and all such should be reclassified as Informative. In the first sentence of the last paragraph of Section 3.1, it is a bit hard to tell that "single" is supposed to modify "method" rather ant "IP Address". I suggest replacing "each single IP address configuration method" with "each single method for IP address configuration individually". Unless, of course, I am more confused by this document than I think and "single" was supposed to modify "IP Address". Section 3.2, first bullet, suggest adding a reference to RFC 5342. Section 7, second setence has problems. Suggest replacing with "This document suggests 3 prefix configuration mechanisms for SAVI devices:". Section 7, first bullet, the acronym SLACC is used without definition or reference. Since it is only used twice, both instances being in this bullet, I suggest it bet spelled out in full. Section 7, first bullet item, what does "feasible" mean? Should "a feasible" by reaplced with "an allowed"? Section 7, second bullet item, the acronym RA is used without definition or reference. Since it is only used twice, both instances being in this bullet, I suggest it bet spelled out in full. Section 7, third bullet item, the acronym DHCP-PD is used without defintion or reference. Since it is only used twice, both instances being in this bullet, I suggest it bet spelled out in full (not "DHCP", just "PD"). Section 7, last sentence: the word "present" seems to be used in the sense of displaying to someone. How and to whom is this presentation? Section 10: I was a bit befuddled by the sentence "Besides, the binding may not accord with the address management requirement, which can be more specified for each client." The word "client" is used nowhere else in this document. What does this sentence mean and to what does "client" refer? Smaller Nits: People will probably figure it out but the first occurrence of Source Address Validation Improvement in the Introduction (and Abstract) should be followed by "(SAVI)". In the first sentence of Section 3.1, I would replace "traces" with "monitors" or "snoops". (The word "snoop" is used elsewhere in the document.) Section 5, third bullet, "in hosts to communicate" -> "in hosts communicating". Section 6, first paragraph, last sentence, "in mix scenario" -> "in this mixed scenario". Section 6, second paragraph, last three sentences have problems. Suggest "Current address assignment method standards documents have implied a prioritized relationship in general cases. However, in some scenarios, the default prioritizing may not be suitable. Configurable prioritization levels should be supported in a SAVI solution for the mixed scenario." Section 7, next to last sentence/paragraph, "is" -> "are" and insert "the" after "implies". Section 10, last sentence, suggest replacing with "Cryptographically based authentication is the only way to meet a requirement for strong security of IP addresses." Thanks, Donald =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 =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From kent@bbn.com Thu Nov 3 04:10:30 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25F01F0C89 for ; Thu, 3 Nov 2011 04:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.471 X-Spam-Level: X-Spam-Status: No, score=-106.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBLZJebp3-4c for ; Thu, 3 Nov 2011 04:10:29 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 66CD51F0C5F for ; Thu, 3 Nov 2011 04:10:29 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:44036 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RLvAj-0006RU-I3; Thu, 03 Nov 2011 07:09:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1320253292.28149.753.camel@destiny.pc.cs.cmu.edu> References: <871utr53i6.fsf@latte.josefsson.org> <16815_1320162240_pA1FhxC9012735_p06240806cad5c0c575be@[193.0.26.186]> <1320253292.28149.753.camel@destiny.pc.cs.cmu.edu> Date: Thu, 3 Nov 2011 04:16:57 -0400 To: Jeffrey Hutzelman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: hmauldin@cisco.com, Simon Josefsson , secdir@ietf.org, lear@cisco.com, jhutz@cmu.edu Subject: Re: [secdir] review of draft-ietf-kitten-sasl-openid-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 11:10:30 -0000 At 1:01 PM -0400 11/2/11, Jeffrey Hutzelman wrote: >On Tue, 2011-11-01 at 11:43 -0400, Stephen Kent wrote: > >> > The situation is a bit more complicated than a simple MUST/MAY, but >> > I >> > believe everything is clear from the base SASL specification: >> > https://tools.ietf.org/html/rfc4422#section-3.4.1 >> > >> > Authorization identities are always optional, but mechanisms are >> > required to be able to transfer them if they are used by the >> > application. >> >> >> That statement, if placed in the I-D, will resolve my question. > > >That statement is not within the scope of this I-D. It's descriptive of >SASL itself, and is covered in the SASL base specification. In >particular, the requirement is one placed on SASL mechanisms (such as >the present I-D) by SASL itself. > >Implementation of this mechanism requires an understanding of the SASL >base specification (unless one is implementing only the underlying >GSS-API mechanism, in which case the section in question is not relevant >at all). I don't think it's necessary for every SASL mechanism to >restate all of SASL's requirements, and it may even be harmful, because >then it looks like you're trying to say something _different_ than what >the SASL spec says. > >Do you really think any SASL implementor is going to be confused by >this? Since I am not a SASL implementer, I can't say. I can say that as a reasonably intelligent reader, I found the wording ambiguous. I am opposed to ambiguous statement in RFCs :-). Steve From simon@josefsson.org Thu Nov 3 04:21:21 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C38311E8088 for ; Thu, 3 Nov 2011 04:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sd6uENObP9iV for ; Thu, 3 Nov 2011 04:21:19 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfa.amsl.com (Postfix) with ESMTP id 3872211E8080 for ; Thu, 3 Nov 2011 04:21:19 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id pA3BKPf7015732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Nov 2011 12:20:27 +0100 From: Simon Josefsson To: Stephen Kent References: <871utr53i6.fsf@latte.josefsson.org> <16815_1320162240_pA1FhxC9012735_p06240806cad5c0c575be@[193.0.26.186]> <1320253292.28149.753.camel@destiny.pc.cs.cmu.edu> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:111103:hmauldin@cisco.com::kRU4OLpnhtIsaXma:Z2s X-Hashcash: 1:22:111103:jhutz@cmu.edu::PTWjiSEp5sBxPfVt:0maf X-Hashcash: 1:22:111103:kent@bbn.com::FhvgO83ncWWCqN3n:2at3 X-Hashcash: 1:22:111103:lear@cisco.com::ccU/PjzKx3o+0COe:7MEI X-Hashcash: 1:22:111103:secdir@ietf.org::9LL5O+0/DxZMkq5n:Wjrq Date: Thu, 03 Nov 2011 12:20:25 +0100 In-Reply-To: (Stephen Kent's message of "Thu\, 3 Nov 2011 04\:16\:57 -0400") Message-ID: <8762j1qwp2.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.2 at yxa-v X-Virus-Status: Clean Cc: hmauldin@cisco.com, secdir@ietf.org, lear@cisco.com, Jeffrey Hutzelman Subject: Re: [secdir] review of draft-ietf-kitten-sasl-openid-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 11:21:21 -0000 Stephen Kent writes: > At 1:01 PM -0400 11/2/11, Jeffrey Hutzelman wrote: >>On Tue, 2011-11-01 at 11:43 -0400, Stephen Kent wrote: >> >>> > The situation is a bit more complicated than a simple MUST/MAY, but >>> > I >>> > believe everything is clear from the base SASL specification: >>> > https://tools.ietf.org/html/rfc4422#section-3.4.1 >>> > >>> > Authorization identities are always optional, but mechanisms are >>> > required to be able to transfer them if they are used by the >>> > application. >>> >>> >>> That statement, if placed in the I-D, will resolve my question. >> >> >>That statement is not within the scope of this I-D. It's descriptive of >>SASL itself, and is covered in the SASL base specification. In >>particular, the requirement is one placed on SASL mechanisms (such as >>the present I-D) by SASL itself. >> >>Implementation of this mechanism requires an understanding of the SASL >>base specification (unless one is implementing only the underlying >>GSS-API mechanism, in which case the section in question is not relevant >>at all). I don't think it's necessary for every SASL mechanism to >>restate all of SASL's requirements, and it may even be harmful, because >>then it looks like you're trying to say something _different_ than what >>the SASL spec says. >> >>Do you really think any SASL implementor is going to be confused by >>this? > > Since I am not a SASL implementer, I can't say. I can say that as a > reasonably intelligent reader, I found the wording ambiguous. I am > opposed to ambiguous statement in RFCs :-). Perhaps the solution is to remove text rather than add more? I share Jeff's concern that adding text here may give the impression that it implies something different than what a SASL implementer would expect to follow automatically from the normative references. How about removing this sentence: The GS2 header carries the optional authorization identity. from section 3.1 and modify the other paragraph in section 3.1 into The syntax and semantics of the "gs2-header" is specified in [RFC5801], and we use it here with the following limitations. The "gs2-nonstd-flag" MUST NOT be present. The "gs2-cb- flag" MUST be "n" because channel binding is not supported by this mechanism. The document is already clear elsewhere that the mechanism supports the concept of authorization identities (see beginning of section 3). The syntax and semantics of the authorization identity field is covered normatively by the base SASL specification and the GS2 document. /Simon From lear@cisco.com Thu Nov 3 06:54:59 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072BE11E8087 for ; Thu, 3 Nov 2011 06:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.216 X-Spam-Level: X-Spam-Status: No, score=-110.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJIiDWnw6SrN for ; Thu, 3 Nov 2011 06:54:58 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA9511E8127 for ; Thu, 3 Nov 2011 06:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=3976; q=dns/txt; s=iport; t=1320328498; x=1321538098; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/Ah0mzeU1PeWmAjH809qr16ffFeOs5iJN5UerJloOUM=; b=D74FInLPuDQKwMlmPBfKIZTkHn+hKlgPj+g62sSr4//qx9fPFeNTBK+P 9/ELJv2DuJemiryR8SBWIXS5yeJNjyC+62UYxTzqIwk2xyP2ZH/EcdVMC j3IeUQQzp3KQ5w3+wDaBGyz+dJSb3vZxcBxC2GNAqfMjcvAqcDL3W5Nd/ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAP6bsk6Q/khN/2dsb2JhbAA7CYR5pH2BBYFyAQEBAwESARBWBQsLGAICBSECAg8CRgYNAQcBARAOh2CWHQGMS5IqgTCEQIIagRUElBiRZg X-IronPort-AV: E=Sophos;i="4.69,450,1315180800"; d="scan'208";a="120720380" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 03 Nov 2011 13:54:53 +0000 Received: from dhcp-10-61-103-23.cisco.com (dhcp-10-61-103-23.cisco.com [10.61.103.23]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA3DsqSO008046; Thu, 3 Nov 2011 13:54:52 GMT Message-ID: <4EB29D2C.40907@cisco.com> Date: Thu, 03 Nov 2011 14:54:52 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Stephen Kent References: <4EB0186D.8040200@cisco.com> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-kitten-sasl-openid.all@tools.ietf.org, secdir Subject: Re: [secdir] review of draft-ietf-kitten-sasl-openid-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 13:54:59 -0000 Steve, On 11/2/11 2:49 PM, Stephen Kent wrote: >> The design consideration is that identity providers (OPs) and browsers >> should remain untouched, since these are likely the components that are >> most difficult to change. The mechanism itself requires few changes to >> clients. The heavy lifting is done by the SASL server or RP. > > That's not the impression one gets from reading the text cited above. > The text could be changed to emphasize that the client changes are > very minor, but the clients are still the biggest population (among > client, RPs, and OPs) right, and so change to them are potentially the > hardest. I appreciate this point, but (a) any mechanism addition to SASL requires a client change and (b) with little exception the client in this case is just passing a funny URL to a browser component (one way or another) and then awaits an answer from the server. Therefore, I would accept your advise to improve the clarity of the above, as follows: > Minimal changes are required to non-web applications, > as most > of the transaction occurs through a normal web browser. Hence, > this specification is only appropriate for use when such a > browser is > available. > >> Applicability for application protocols other than HTTP > > > But doesn't thus section talk about how to use SASL and OpenID in > support of the common, browser use case? Think about the example: a mail client (like Thunderbird) gets a new SASL mechanism that takes as a single configuration parameter a URL. That is passed to the browser (modulo some checks we discussed) and we're off to the races. And so the web infrastructure is leveraged by non-web components. > > As noted in my reply to Simon, I did look at the OpenID spec, and > discovered that it uses the wrong terminology in this context. (I am > bothered by the fact that we don't have an RFC version of the OpenID > spec, and that the spec we're citing contains errors of this sort. > But, those are issues outside the scope of this review.) I think it > appropriate to cite the relevant section of the OpenID spec, but also > to note that what they refer to as a signature, is actually a MAC. Ok. How about this: The Relying Party and the OP optionally establish an association -- a shared secret established using Diffie-Hellman Key Exchange. This shared secret is used to generate and check what the OpenID specification calls a signature but what others might call a message authentication code (MAC). This process is described in Section 8 of . > The security community likes bit-length measures of entropy. In this > case, > the entropy is needed to achieve a high likelihood of uniqueness. it > is not clear to me, from reading this doc (vs. the full OpenID spec) > what is the required scope for the uniqueness. If an adversary has an > unlimited number of attempts in a brief time window (e.g, Kamisky DNS > attack), then the IETF community no longer believes that 2**16 is a > big enough space. So, if you can characterize the attack surface, we > can probably pick a suitable entropy target. In this case, since we're requiring TLS, the only function here is to disambiguate transactions. The attack surface, therefore is fairly small. I would suggest 2^16 is probably a bit small, even so (UNIX pids are bigger than that), but that 2^32 would be more than sufficient. Again, this is really an internal matter for the RP. [...] > This is better. I'd say that what we can expect is a simple set of > simple syntactic checks by an implementation, not really "careful > analysis." Would you be comfortable making the list of "authorized URI > bases" be a RECOMMENDATION, or is it just an example? As a recommendation, yes. From kent@bbn.com Thu Nov 3 08:58:07 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDDC11E80FC for ; Thu, 3 Nov 2011 08:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.49 X-Spam-Level: X-Spam-Status: No, score=-106.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys4xyhapoleu for ; Thu, 3 Nov 2011 08:58:05 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B104811E80D8 for ; Thu, 3 Nov 2011 08:58:02 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:40013 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RLzfu-0009wQ-EG; Thu, 03 Nov 2011 11:57:54 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <8762j1qwp2.fsf@latte.josefsson.org> References: <871utr53i6.fsf@latte.josefsson.org> <16815_1320162240_pA1FhxC9012735_p06240806cad5c0c575be@[193.0.26.186]> <1320253292.28149.753.camel@destiny.pc.cs.cmu.edu> <8762j1qwp2.fsf@latte.josefsson.org> Date: Thu, 3 Nov 2011 11:44:35 -0400 To: Simon Josefsson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: hmauldin@cisco.com, secdir@ietf.org, lear@cisco.com, Jeffrey Hutzelman Subject: Re: [secdir] review of draft-ietf-kitten-sasl-openid-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 15:58:07 -0000 At 12:20 PM +0100 11/3/11, Simon Josefsson wrote: >Stephen Kent writes: > >... > >Perhaps the solution is to remove text rather than add more? > >I share Jeff's concern that adding text here may give the impression >that it implies something different than what a SASL implementer would >expect to follow automatically from the normative references. > >How about removing this sentence: > > The GS2 header carries the optional authorization identity. OK with me. >from section 3.1 and modify the other paragraph in section 3.1 into > > The syntax and semantics of the "gs2-header" is specified in > [RFC5801], and we use it here with the following limitations. The > "gs2-nonstd-flag" MUST NOT be present. The "gs2-cb- flag" MUST be > "n" because channel binding is not supported by this mechanism. > >The document is already clear elsewhere that the mechanism supports the >concept of authorization identities (see beginning of section 3). > >The syntax and semantics of the authorization identity field is covered >normatively by the base SASL specification and the GS2 document. OK. Steve From kent@bbn.com Thu Nov 3 09:04:36 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB031F0C81 for ; Thu, 3 Nov 2011 09:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nbv3rV4ciIKx for ; Thu, 3 Nov 2011 09:04:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 191C91F0C7C for ; Thu, 3 Nov 2011 09:04:36 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:50240 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RLzmN-000A2S-Bk; Thu, 03 Nov 2011 12:04:35 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4EB29D2C.40907@cisco.com> References: <4EB0186D.8040200@cisco.com> <4EB29D2C.40907@cisco.com> Date: Thu, 3 Nov 2011 11:55:56 -0400 To: Eliot Lear From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: draft-ietf-kitten-sasl-openid.all@tools.ietf.org, secdir Subject: Re: [secdir] review of draft-ietf-kitten-sasl-openid-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 16:04:36 -0000 At 2:54 PM +0100 11/3/11, Eliot Lear wrote: >.... >Ok. How about this: > > The Relying Party and the OP optionally establish an > association -- a shared secret established using > Diffie-Hellman Key Exchange. This shared secret is used > to generate and check what the OpenID specification calls > a signature but what others might call a message > authentication code (MAC). This process is > described in Section 8 of . Your text makes it sound as though both terms have equal pedigree. They don't. See the Interent Security Glossary (RFC 4949). > > The security community likes bit-length measures of entropy. In this >... > >In this case, since we're requiring TLS, the only function here is to >disambiguate transactions. The attack surface, therefore is fairly >small. I would suggest 2^16 is probably a bit small, even so (UNIX pids >are bigger than that), but that 2^32 would be more than sufficient. >Again, this is really an internal matter for the RP. Since, as you noted, this is within a TLS session, I'd agree with 2**16. > >[...] >> This is better. I'd say that what we can expect is a simple set of >> simple syntactic checks by an implementation, not really "careful >> analysis." Would you be comfortable making the list of "authorized URI >> bases" be a RECOMMENDATION, or is it just an example? > >As a recommendation, yes. OK. From jhutz@cmu.edu Thu Nov 3 09:06:10 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30231F0C81 for ; Thu, 3 Nov 2011 09:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOw1h7fwJne4 for ; Thu, 3 Nov 2011 09:06:10 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id D6BDD1F0C7C for ; Thu, 3 Nov 2011 09:06:09 -0700 (PDT) Received: from [192.168.202.133] (pool-74-109-253-27.pitbpa.fios.verizon.net [74.109.253.27]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id pA3G60kt028146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Nov 2011 12:06:01 -0400 (EDT) References: <871utr53i6.fsf@latte.josefsson.org> <16815_1320162240_pA1FhxC9012735_p06240806cad5c0c575be@[193.0.26.186]> <1320253292.28149.753.camel@destiny.pc.cs.cmu.edu> <8762j1qwp2.fsf@latte.josefsson.org> User-Agent: K-9 Mail for Android In-Reply-To: <8762j1qwp2.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Jeffrey Hutzelman Date: Thu, 03 Nov 2011 12:05:57 -0400 To: Simon Josefsson , Stephen Kent Message-ID: <284f7a38-99c6-44d8-814a-01aae1fe4668@email.android.com> X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: hmauldin@cisco.com, lear@cisco.com, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-kitten-sasl-openid-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 16:06:10 -0000 Simon Josefsson wrote: >Perhaps the solution is to remove text rather than add more? > >I share Jeff's concern that adding text here may give the impression >that it implies something different than what a SASL implementer would >expect to follow automatically from the normative references. > >How about removing this sentence: > > The GS2 header carries the optional authorization identity. > >from section 3.1 and modify the other paragraph in section 3.1 into > > The syntax and semantics of the "gs2-header" is specified in > [RFC5801], and we use it here with the following limitations. The > "gs2-nonstd-flag" MUST NOT be present. The "gs2-cb- flag" MUST be > "n" because channel binding is not supported by this mechanism. > >The document is already clear elsewhere that the mechanism supports the >concept of authorization identities (see beginning of section 3). > >The syntax and semantics of the authorization identity field is covered >normatively by the base SASL specification and the GS2 document. So, the reason not to do that is that we've decided (I think) that people doing pure-SASL implementations of dual-stack mechanisms such as this one should normally not have to read the GS2 spec, since it specifies a layer of abstraction that they don't care about. OTOH, I think we can be clearer. The new text you just proposed is a good start; we can refer to GS2 for clarification without annoying pure-SASL implementers too much. But instead of removing references to "optional authorization identity", what if we change them to "SASL authorization identity, when used" ? This makes it clear that an autzid might _not_ be used, provides a hint where to look to learn more about autzids (SASL), and avoids the impression that we are applying the word OPTIONAL to anything. >/Simon From culler@EECS.Berkeley.EDU Thu Nov 3 09:10:21 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBDD1F0C7C; Thu, 3 Nov 2011 09:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhiqRj0fgEBi; Thu, 3 Nov 2011 09:10:20 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCF921F8D25; Thu, 3 Nov 2011 09:10:20 -0700 (PDT) Received: from [192.168.43.97] (mobile-166-190-135-213.mycingular.net [166.190.135.213] (may be forged)) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.5/8.13.5) with ESMTP id pA3GA747018752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 3 Nov 2011 09:10:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: David Culler In-Reply-To: Date: Thu, 3 Nov 2011 09:10:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Chris Lonvick X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 03 Nov 2011 09:28:55 -0700 Cc: draft-hui-6man-rpl-routing-header.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-hui-6man-rpl-routing-header X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 16:10:22 -0000 Chris, Thanks very much. It should be natural to address these comments. D. On Nov 2, 2011, at 4:16 PM, Chris Lonvick wrote: > 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 > I havn't seen source routing in a long time so I had to wrap my head = around that again. I tried working through some examples on how this = would work for verious network conditions, but gave up before my head = started hurting. :) >=20 > Overall, it looks like the security concerns are addressed in the = document. >=20 > I do have some minor nits that the authors may wish to discuss. >=20 > 1. I don't think that the following sentence in Section 6.1 is needed: > "Furthermore, it is RECOMMENDED that non-RPL > routers and firewalls drop packets with a SRH by default." > That is already discussed in RFC 5095. Having it here is therefore = redundant. >=20 > 2. I'm not sure that I am correctly following all of your pseudocode = in Section 4.2. In most places it looks like separate instructions = within curly braces are separated by blank lines. =46rom that, I'm not = sure of what is meant by a semicolon in the following: > else { > decrement Segments Left by 1; > compute i, the index of the next address to be visited in > the address vector, by subtracting Segments Left from n >=20 > if Address[i] or the IPv6 Destination Address is multicast { > discard the packet > } >=20 > Hope this helps, > Chris From barryleiba.mailing.lists@gmail.com Mon Nov 7 19:54:42 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F0F11E8096 for ; Mon, 7 Nov 2011 19:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.936 X-Spam-Level: X-Spam-Status: No, score=-102.936 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4uHmM6rwexw for ; Mon, 7 Nov 2011 19:54:41 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9080C11E80B9 for ; Mon, 7 Nov 2011 19:54:41 -0800 (PST) Received: by gye5 with SMTP id 5so108379gye.31 for ; Mon, 07 Nov 2011 19:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=m+GDJ4dmfIYMby8pifaAIf7AIZw9xAWCCPe5E2BLJI4=; b=sdfMNVR1PPFbYlQjezoseL4Xx3YqKseW/4hkKRpcMCihHUzmLHnGytPUJK6QDuCAp8 SDfahULyZA4xZA8W57Gr1ipEcFxtgHQKzbE5Dqj5FtIEukscw+OOssOT8ZEGcFX7q/QR 66id+8Vpxm7Sumpixf4wU9lWJvVl/Cph/C2Ow= MIME-Version: 1.0 Received: by 10.236.197.103 with SMTP id s67mr40440136yhn.5.1320724481159; Mon, 07 Nov 2011 19:54:41 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.250.14 with HTTP; Mon, 7 Nov 2011 19:54:41 -0800 (PST) In-Reply-To: <4EAA6553.2060202@cs.tcd.ie> References: <20111027171437.F117321F8B5A@ietfa.amsl.com> <4EAA6553.2060202@cs.tcd.ie> Date: Mon, 7 Nov 2011 22:54:41 -0500 X-Google-Sender-Auth: wTpnCm4ZqfIp2py-6w-JcOI1EGc Message-ID: From: Barry Leiba To: secdir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [secdir] IETF 82 - Meeting and Venue Information X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 03:54:42 -0000 >>> =A0 =A0 =A0 =A0No food or beverages shall be brought into the Center fr= om >>> =A0 =A0 =A0 =A0outside vendors. >>> >>> =A0 =A0 =A0 =A0No food or beverages are allowed to be brought into the >>> =A0 =A0 =A0 =A0meeting rooms and =A0working group sessions unless speci= fically >>> =A0 =A0 =A0 =A0served by TICC Catering. >> >> These rules, if taken seriously, will cause some interference with the >> secdir lunch meeting. > > Good point. Checking... Any news on this, or on a room assignment for the lunch/meeting? Barry From weiler+secdir@watson.org Mon Nov 7 21:28:22 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469A211E80F5 for ; Mon, 7 Nov 2011 21:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeKw3LztvxI1 for ; Mon, 7 Nov 2011 21:28:21 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7D83A11E80F4 for ; Mon, 7 Nov 2011 21:28:20 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id pA85SI7Y094788 for ; Tue, 8 Nov 2011 00:28:18 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id pA85SGDx094781 for ; Tue, 8 Nov 2011 00:28:16 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 8 Nov 2011 00:28:14 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 08 Nov 2011 00:28:19 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 05:28:22 -0000 In the last batch of assignments there were many last-minute requests for reviews of docs on the 3 November IESG agenda. Many of those weren't reviewed. Since it's my fault for not giving you more warning, I'm not sending nasty-grams, but I may be assigning those folks some new docs next week. The next telechat isn't until 1 December. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Derek Atkins is next in the rotation. For telechat 2011-12-01 Steve Hanna TR2011-07-20 draft-ietf-dime-priority-avps-05 Kathleen Moriarty T 2011-11-07 draft-ietf-krb-wg-gss-cb-hash-agility-08 Sandy Murphy T 2011-11-10 draft-ietf-v6ops-happy-eyeballs-05 Vincent Roca T 2011-11-09 draft-ietf-sieve-convert-05 Tina TSOU T 2011-11-15 draft-ietf-ippm-loss-episode-metrics-03 Carl Wallace T 2011-11-07 draft-davis-t-langtag-ext-06 Tom Yu TR2011-10-19 draft-ietf-codec-guidelines-06 Larry Zhu T 2011-11-29 draft-ietf-trill-rbridge-mib-04 Glen Zorn T 2011-11-21 draft-ietf-tsvwg-sctp-strrst-12 Last calls and special requests: Phillip Hallam-Baker - draft-irtf-hiprg-dht-04 Matt Lepinski 2011-10-31 draft-ietf-6man-rpl-option-04 Catherine Meadows R2011-04-13 draft-ietf-speechsc-mrcpv2-26 Ondrej Sury 2011-11-16 draft-ietf-hokey-arch-design-08 Tina TSOU 2011-04-23 draft-shin-augmented-pake-08 Carl Wallace 2011-11-28 draft-ietf-netconf-access-control-06 Brian Weis 2011-11-28 draft-ietf-netconf-system-notifications-06 Nico Williams 2011-11-17 draft-ietf-simple-msrp-cema-03 Tom Yu 2011-11-21 draft-ietf-tcpm-rfc3782-bis-03 From stephen.farrell@cs.tcd.ie Tue Nov 8 00:42:41 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A6C21F8C32 for ; Tue, 8 Nov 2011 00:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMYEvzaM+vpp for ; Tue, 8 Nov 2011 00:42:41 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7272521F8C2F for ; Tue, 8 Nov 2011 00:42:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B998A1536F1; Tue, 8 Nov 2011 08:42:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1320741755; bh=aUeM7 bclTwtAoKi5Rl8ROVjCYsi6QJPTiv6AzxBx3jE=; b=cGWydJzHhL5waZiyDw/8W s6XaY/BJq7bYCXXHwi7ErDTSV1ZOS6DAiQbH91mPULlkIGCsUMZp8L47XIdOEfl4 rAgDbCHbX+rCg/nZ8vOUdJ21qKlMhyWdjtYRPuX2VGPU/JTLNKIAknRJcn2iGuGe OUpQYNiZzM6bT9lktpu2XN60czYA6W/nIqI8pCpaDzBbpFj03Hif/ampraj/k1vR AKuO8DHpAJaKH3k7ZrtPCHZ6lVZQMHw4i7ioY876Sa1cZbKukJ/DBI3YMFm2RshN yxT7b/y4+VrNqemznqcMQSFOoVdKgEIo3Umpl3NhBghxlbHAOV3ey4ujFbcrCwHO A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 8VZzQGPcs7DI; Tue, 8 Nov 2011 08:42:35 +0000 (GMT) Received: from [10.54.31.88] (mobileinternet4.o2.ie [62.40.32.14]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B64DC1536F0; Tue, 8 Nov 2011 08:42:33 +0000 (GMT) References: <20111027171437.F117321F8B5A@ietfa.amsl.com> <4EAA6553.2060202@cs.tcd.ie> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <6E3E64CD-D05E-4448-A9E6-5617CBA63492@cs.tcd.ie> X-Mailer: iPhone Mail (9A334) From: Stephen Farrell Date: Tue, 8 Nov 2011 08:42:27 +0000 To: Barry Leiba Cc: secdir Subject: Re: [secdir] IETF 82 - Meeting and Venue Information X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 08:42:41 -0000 On 8 Nov 2011, at 03:54, Barry Leiba wrote: >>>> No food or beverages shall be brought into the Center from >>>> outside vendors. >>>>=20 >>>> No food or beverages are allowed to be brought into the >>>> meeting rooms and working group sessions unless specifically >>>> served by TICC Catering. >>>=20 >>> These rules, if taken seriously, will cause some interference with the >>> secdir lunch meeting. >>=20 >> Good point. Checking... >=20 > Any news on this, or on a room assignment for the lunch/meeting? Don't have the room assignment, but at least some rooms now seem to allow gr= ub, according to the announcement mail. I'll check again before time but I s= uspect this'll be ok. (Secretariat ate traveling now so it'll be a few days a= t least.) S >=20 > Barry > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From stephen.farrell@cs.tcd.ie Thu Nov 10 23:45:30 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59C01F0C35 for ; Thu, 10 Nov 2011 23:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnbDxJPUTWIw for ; Thu, 10 Nov 2011 23:45:30 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBC51F0C34 for ; Thu, 10 Nov 2011 23:45:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 41134157629 for ; Fri, 11 Nov 2011 07:45:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1320997523; bh=MfR+OvACFLdXP1uYCuPhxgRO Dnbpj9OeQgr/Mc8sdME=; b=XBC8gsFQRr9pIqN5pJwCm8bkJ3XsRusHA5tAH+va JO7rOP/ngZnRh/isrm82vFx2Jif7suDdxjoznSXJihSnNuhD7MdrlNZbUOqGZ1pM wh+oo4p+s10oblYHyv6zJr8vIx6ZSpzolvWSOKBL4wpHGD+t/I7uJUevowLJf0S3 qOGoNjxEK68uHHTWMA3/D+geHnpHgK2jrwdjDAksbb4sdl4lKHiXncTp+sNNMiYJ hV8WCuRGaeKN8qHrrEcgHuSjXhjZU/A5W1lfYkexhIC2Gfx6jFiosN7vWEB2Alh6 FtDtm75ItB3G2Ze3YrqnZPNwI32iaakk7T6AsH7HLPxegQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id uFEkOgRB8qGZ for ; Fri, 11 Nov 2011 07:45:23 +0000 (GMT) Received: from [109.79.49.48] (unknown [109.79.49.48]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id EC70015761C for ; Fri, 11 Nov 2011 07:45:20 +0000 (GMT) Message-ID: <4EBCD28F.4020500@cs.tcd.ie> Date: Fri, 11 Nov 2011 07:45:19 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "secdir@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] secdir lunch location... X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 07:45:31 -0000 ...is "3F North Lounge" That is one of the "foodie" rooms so we shouldn't starve. As usual, get your own food somewhere and bring it along. Cheers, S From stephen.farrell@cs.tcd.ie Fri Nov 11 00:31:20 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3729621F847B for ; Fri, 11 Nov 2011 00:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zubtGykqaf5v for ; Fri, 11 Nov 2011 00:31:18 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A376A21F846C for ; Fri, 11 Nov 2011 00:31:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B988F157629 for ; Fri, 11 Nov 2011 08:31:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1321000277; bh=JUW70hblSSuVtI HBzc/+W35WFiiO1blJ9TVtvh2+/Eo=; b=ypeA/t5Dyt32SM3CtVlEUJ2o+2IqRn Ll5W8dfEgX4sS/1A4lGWsPXCp9i5n9v3hh26zXYiIJDznhWDDuk/StYfM0/wknB6 nHNX2rXPMcczfN+WJyZOzEsrlL7qzmHpJdDxPJs7v5apGSTeDL5TVC3BaLzFmiNB 1yuGOvOOUdPGcS6KR2P1uWdpp8ZLHMqhGoJ9ckJTzI8u3AH8YOroF2rdNNnWsekG U728hBGi6R3rRiAZbnoC34V1lsRtYPL7EHxXMjE358Q58Ho2D5e7ECtatNbPzx01 Jx850juhdE/n4zRbodSI8geb/dy5t9B+Pzw6RCAIovIGKjk2VqxE0XFQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id byh8v2fUcd-C; Fri, 11 Nov 2011 08:31:17 +0000 (GMT) Received: from [109.79.49.48] (unknown [109.79.49.48]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D58D215761D; Fri, 11 Nov 2011 08:31:16 +0000 (GMT) Message-ID: <4EBCDD53.8080004@cs.tcd.ie> Date: Fri, 11 Nov 2011 08:31:15 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Stephen Farrell References: <4EBCD28F.4020500@cs.tcd.ie> In-Reply-To: <4EBCD28F.4020500@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "secdir@ietf.org" Subject: Re: [secdir] secdir lunch location... X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 08:31:20 -0000 I should of course have said that this is on Tuesday from 1130ish to 1pm. S On 11/11/2011 07:45 AM, Stephen Farrell wrote: > > ...is "3F North Lounge" > > That is one of the "foodie" rooms so we shouldn't starve. As > usual, get your own food somewhere and bring it along. > > Cheers, > S > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From stephen.farrell@cs.tcd.ie Sat Nov 12 17:42:50 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B79C11E808A for ; Sat, 12 Nov 2011 17:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id he7Nar-Q8rcn for ; Sat, 12 Nov 2011 17:42:45 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 424A111E8082 for ; Sat, 12 Nov 2011 17:42:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 8D625171C8B for ; Sun, 13 Nov 2011 01:42:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1321148562; bh=wqVJbiMc5RPbmMwXSm5tDZcp AN+T2yrX0sS0eSIESdY=; b=BY4LyohI0duef4JwQhf/SYwtlsWWpApnnOmmFWCO ws0cKiAk/qDDqD2T8/FY62UqFfT81iHj4p/55BzOy4s5+C+KBTvd3Xk1pWWJAvgF TqexbSr/NekOacXwqW5pFLCvtSNcmvEEYvvzmK7VYgIk6AR8cKa9+noYQiHi5gi5 WnVDoDrgF3rI2+S9nYySSFaH8X9ffo9rFIKteG/HVa21NnHrd1MPiDFQodx3953/ xhSpAk8f36Rak0xoLAHKOqVwK8/gak8f7SBv4x/DR3027C+PmU7NL8wc2Q9mJ6R2 uJRaYdmS6R5ckCgreZ4gfpJowKDwzybw9tdApXf7WCSxkQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id rMgIbNjH9Wgc for ; Sun, 13 Nov 2011 01:42:42 +0000 (GMT) Received: from [130.129.103.171] (dhcp-67ab.meeting.ietf.org [130.129.103.171]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 672CF171C51 for ; Sun, 13 Nov 2011 01:42:41 +0000 (GMT) Message-ID: <4EBF208E.6060100@cs.tcd.ie> Date: Sun, 13 Nov 2011 01:42:38 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "secdir@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] No SEC WGs have posted slides so far... X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 01:42:50 -0000 Folks, The meeting materials page [1] shows that *none* of the security WGs have posted any slides at all so far. There will be remote participants and its generally useful to have meeting slides in advance so can you please start to upload materials for your meeting. Thanks, Stephen. [1] https://datatracker.ietf.org/meeting/82/materials.html From turners@ieca.com Sun Nov 13 21:02:44 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A301F11E81D6 for ; Sun, 13 Nov 2011 21:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.276 X-Spam-Level: X-Spam-Status: No, score=-102.276 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoXpisoT-5C0 for ; Sun, 13 Nov 2011 21:02:44 -0800 (PST) Received: from gateway.websitewelcome.com (gateway12.websitewelcome.com [69.93.35.2]) by ietfa.amsl.com (Postfix) with ESMTP id 28D8711E81D5 for ; Sun, 13 Nov 2011 21:02:44 -0800 (PST) Received: by gateway.websitewelcome.com (Postfix, from userid 5007) id A97204589DF3E; Sun, 13 Nov 2011 23:02:43 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway.websitewelcome.com (Postfix) with ESMTP id 9B8B04589DF17 for ; Sun, 13 Nov 2011 23:02:43 -0600 (CST) Received: from [130.129.38.246] (port=52067 helo=dhcp-26f6.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RPogt-00080h-BV for secdir@ietf.org; Sun, 13 Nov 2011 23:02:43 -0600 Message-ID: <4EC0A0F1.2040207@ieca.com> Date: Mon, 14 Nov 2011 13:02:41 +0800 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: dhcp-26f6.meeting.ietf.org [130.129.38.246]:52067 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [secdir] lunch options X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 05:02:44 -0000 There's a buffet on the second floor but I'm not sure it'll work for secdir lunch. There's apparently a sandwich available on the 1st floor, but I haven't tried it. Did anybody try it today? spt From rbarnes@bbn.com Sun Nov 13 21:29:22 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65B611E810D for ; Sun, 13 Nov 2011 21:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKON6W1FpaXf for ; Sun, 13 Nov 2011 21:29:22 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1427311E80B2 for ; Sun, 13 Nov 2011 21:29:22 -0800 (PST) Received: from [128.89.254.173] (port=55746) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RPp6f-0005Ks-Ae; Mon, 14 Nov 2011 00:29:21 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: <4EC0A0F1.2040207@ieca.com> Date: Mon, 14 Nov 2011 13:29:17 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <30BC2950-4CFF-4B17-A520-BE44FC866E9B@bbn.com> References: <4EC0A0F1.2040207@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1251.1) Cc: secdir@ietf.org Subject: Re: [secdir] lunch options X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 05:29:22 -0000 We may need more than a sandwich to feed us all. There's also a supermarket over in TPE101, which may have some options. --Richard On Nov 14, 2011, at 1:02 PM, Sean Turner wrote: > There's a buffet on the second floor but I'm not sure it'll work for = secdir lunch. There's apparently a sandwich available on the 1st floor, = but I haven't tried it. Did anybody try it today? >=20 > spt > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From ondrej.sury@nic.cz Mon Nov 14 02:03:46 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10D621F8E4D; Mon, 14 Nov 2011 02:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfb6oNRcR9kO; Mon, 14 Nov 2011 02:03:40 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7628D21F8B9E; Mon, 14 Nov 2011 02:01:32 -0800 (PST) Received: from [IPv6:2001:df8::96:cdfb:283e:c8fa:7331] (unknown [IPv6:2001:df8:0:96:cdfb:283e:c8fa:7331]) by mail.nic.cz (Postfix) with ESMTPSA id B610A2A2F20; Mon, 14 Nov 2011 11:01:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1321264888; bh=cuhhVhoGh1o6gZte4lNfz8Oy6f7sf+AL8vJaDi+njCU=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:Cc:To:Mime-Version; b=cZwd8fliXAHzMK4zq4mwLyFd4K89wPhTs8cLMDYm40QZR549uuRg+uNAQq8m0Ldce 2r5XxEpH93zuq3R8yC+zDKh3BPJEYwpO0DL7gY4XTGi2hgRz/qwYH4j1GdNTJ59Ro8 h26TFoqVPyA4gW80Q4vr1dyDKsvYgibVo+Qj6ix0= From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2011 18:01:23 +0800 Message-Id: <13B04C3C-8B22-45CA-A9FE-356F44AE2E2E@nic.cz> To: secdir@ietf.org, The IESG Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: draft-ietf-hokey-arch-design.all@tools.ietf.org Subject: [secdir] review of draft-ietf-hokey-arch-design-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 10:03:46 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I haven't been following HOKEY at all, so the comments are basically from innocent bystander who knows as much about EAP as needed to type the password for WiFi in the 802.1x (and is user of eduroam network). The HOKEY architectural document seems to be clearly written and can be understood even by me. It does not introduce neither any new = protocol nor security issues and is just a summary of existing standards or I-Ds, so there are no security concerns in this particular document. Some security concerns are referenced to other RFCs (Section 7), but they are just #includes from other documents and not something new introduced by this document. One minor nit: - You suddenly start to use rRK and DSrRK in the tables (4 and 5) in = section 5. It would help readability to explain somewhere what these abbreviations = mean. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From william.polk@nist.gov Mon Nov 14 13:43:26 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F27811E8100; Mon, 14 Nov 2011 13:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GH0rNqk9WOfk; Mon, 14 Nov 2011 13:43:25 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 036D211E80FB; Mon, 14 Nov 2011 13:43:25 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 14 Nov 2011 16:43:19 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 14 Nov 2011 16:43:22 -0500 From: "Polk, William T." To: "saag@ietf.org" , "secdir@ietf.org" , "privacydir@ietf.org" Date: Mon, 14 Nov 2011 16:38:50 -0500 Thread-Topic: Meeting on Privacy-Enchancing Cyrptography: Dec 8-9, 2011 Thread-Index: Acyi2ZH/n8Sl1c/cTRSiJ2hP8952JAAPDpR4 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: [secdir] FW: Meeting on Privacy-Enchancing Cyrptography: Dec 8-9, 2011 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 21:43:26 -0000 FYI - I thought this meeting at NIST would be of interest to some on these lists. Thanks, Tim Polk ________________________________________ From: Caswell, Sara J. Sent: Monday, November 14, 2011 9:27 AM To: Polk, William T. Subject: Meeting on Privacy-Enchancing Cyrptography: Dec 8-9, 2011 Meeting on Privacy-Enhancing Cryptography: "Working with encrypted data without decrypting" December 8-9, 2011 NIST Gaithersburg, Maryland USA This workshop will discuss how modern cryptographic techniques can help protect privacy in an environment where many players are collaborating and competing as consumers and producers of digital goods and services. Among the discussion topics are medical databases, on-line auctions, privacy-friendly smart-meters, and identity management as envisioned by the National Strategy for Trusted Identities in Cyberspace. The target audience is industry, the research and academic communities, and Government. Registration Fee: $165.00 USD (Registration deadline December 1) Additional details can be found at: http://www.nist.gov/itl/csd/ct/pec-workshop.cfm From stephen.farrell@cs.tcd.ie Mon Nov 14 19:54:19 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848701F0C90 for ; Mon, 14 Nov 2011 19:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGTCnbSK6iT9 for ; Mon, 14 Nov 2011 19:54:18 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 317851F0C45 for ; Mon, 14 Nov 2011 19:54:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1A95A171C90 for ; Tue, 15 Nov 2011 03:54:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1321329256; bh=OGkbNEKy/Q0q/xdxxOftut8j 2JfeY5t46SFbHuokGKQ=; b=qhpWvzSj9I8UVHK3tTJ+lOmZqxWCsk2dBApxNJ6o Yd5hFIBeuB+zzXOW4Ed0PPCUXR3qduP+pALYUZOGTlU/P5aZledIr1/okv8hoHe7 TJvnmAkWOTqkbPuaMCgK9gBDvGLTj0nt2qjTz6RUWFXl6Jv0iNu5PDM5oF2IESH8 Dkals0moAbqySQXzz9BUQx0T5CniNS1Y/sUjD3+wpHA/2WoVl4aCXaUA3kmbLh3u +7qZEojye6NdBu5Zuin6qUEPffbytpcXBSqL0TENk7SYb1G0bcS36pUTu1v/SDo3 bzhr4yU2H1yBFe2nbDENKALAT0bIdjRreRuIXl8de1h4Qw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id iGIZjzeua63a for ; Tue, 15 Nov 2011 03:54:16 +0000 (GMT) Received: from [130.129.21.10] (dhcp-150a.meeting.ietf.org [130.129.21.10]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 40964171C8F for ; Tue, 15 Nov 2011 03:54:15 +0000 (GMT) Message-ID: <4EC1E262.2070004@cs.tcd.ie> Date: Tue, 15 Nov 2011 03:54:10 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "secdir@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] crypto rfcs info X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 03:54:19 -0000 http://www.mindspring.com/~dmcgrew/ic/internet-crypto.html From weiler@watson.org Tue Nov 15 00:16:48 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E714911E808C for ; Tue, 15 Nov 2011 00:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psK+4ad9jSyM for ; Tue, 15 Nov 2011 00:16:45 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id F03DD11E814F for ; Tue, 15 Nov 2011 00:16:44 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id pAF8GhZk099015 for ; Tue, 15 Nov 2011 03:16:43 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id pAF8GhKt099008 for ; Tue, 15 Nov 2011 03:16:43 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 15 Nov 2011 03:16:43 -0500 (EST) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 15 Nov 2011 03:16:44 -0500 (EST) Subject: [secdir] Who wants to review LISP docs? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 08:16:48 -0000 Would one of you be especially interested in the two LISP docs that are in last call 'til 30 November? They are: draft-ietf-lisp and draft-ietf-lisp-alt. They are 92 and 30 pages, respectively, so I figured a departure from the usual round-robin might be in order. Feel free to tell me if you want to do both or just one of the two. The below is a list of folks who recently dropped reviews, including the last minute assignments from October 28th. I previously promised to assign some out-of-order reviews to these folks. If your name is on this list, you might want to give special thought to volunteering. Rob Austein Uri Blumenthal Dave Cridland Alan DeKok Sam Hartman Love Hornquist-Astrand Jeffrey Hutzelman Warren Kumari Julien Laganier Matt Lepinski David McGrew Catherine Meadows Russ Mundy Magnus Nystrom Hilarie Orman Radia Perlman Tim Polk Eric Rescorla Larry Zhu From mcgrew@cisco.com Tue Nov 15 10:00:44 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0111F0C67 for ; Tue, 15 Nov 2011 10:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.343 X-Spam-Level: X-Spam-Status: No, score=-106.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrSQTNgw4lSp for ; Tue, 15 Nov 2011 10:00:43 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2C51F0C62 for ; Tue, 15 Nov 2011 10:00:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=464; q=dns/txt; s=iport; t=1321380043; x=1322589643; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=2bJsONcnWbI0N1w0dvCL8cRFa0T4Z6dV3jpvlZiDvDM=; b=Yd1hUz4iwC6QA5Jf6emuj/EhV9sUloTsAQevv+/wP2ojarm0SY2YDYJl u/6g6sbi8G2k94O1vCiEwtH3RDQVXXEllUfz2J42MCVqongbmOfdJeXFL EidMRJsesB8BQwLrJ8cqkkKKy2rph/c2CHOx0CWcgGksa6xVVxsBjCwOX M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABKowk6rRDoG/2dsb2JhbABDFqlYgQWBcgEBAQQBAQEPASUCNAsQC0YnMAYTIodomgkBnlqJLmMEiBOMH4U7jGA X-IronPort-AV: E=Sophos;i="4.69,516,1315180800"; d="scan'208";a="12671561" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 15 Nov 2011 18:00:43 +0000 Received: from [10.32.254.210] ([10.32.254.210]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAFI0gFv004614; Tue, 15 Nov 2011 18:00:42 GMT Message-Id: <4C0725EA-E2EA-4C50-8F7E-9225C537A4A0@cisco.com> From: David McGrew To: Stephen Farrell In-Reply-To: <4EC1E262.2070004@cs.tcd.ie> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 15 Nov 2011 10:00:41 -0800 References: <4EC1E262.2070004@cs.tcd.ie> X-Mailer: Apple Mail (2.936) Cc: secdir@ietf.org Subject: Re: [secdir] crypto rfcs info X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 18:00:44 -0000 Hi Stephen, I recently updated the pages to include SM3, which Sean Shen recently submitted as draft-shen-sm3-hash-00. David On Nov 14, 2011, at 7:54 PM, Stephen Farrell wrote: > > http://www.mindspring.com/~dmcgrew/ic/internet-crypto.html > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From acmorton@att.com Tue Nov 15 20:26:00 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8C711E80B5 for ; Tue, 15 Nov 2011 20:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.925 X-Spam-Level: X-Spam-Status: No, score=-104.925 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYn3L0G4wVjB for ; Tue, 15 Nov 2011 20:25:59 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 9183A11E80A6 for ; Tue, 15 Nov 2011 20:25:59 -0800 (PST) X-Env-Sender: acmorton@att.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1321417557!1260727!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21489 invoked from network); 16 Nov 2011 04:25:57 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-6.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Nov 2011 04:25:57 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAG4QP4w010587 for ; Tue, 15 Nov 2011 23:26:25 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAG4QJrA010555 for ; Tue, 15 Nov 2011 23:26:20 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pAG4Ppn1017983 for ; Tue, 15 Nov 2011 23:25:51 -0500 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pAG4Podb017964 for ; Tue, 15 Nov 2011 23:25:50 -0500 Message-Id: <201111160425.pAG4Podb017964@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-8-119.vpn.west.att.com[135.70.8.119](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20111116042451gw100e4ldce>; Wed, 16 Nov 2011 04:24:53 +0000 X-Originating-IP: [135.70.8.119] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 15 Nov 2011 23:26:38 -0500 To: Tina TSOU , "secdir@ietf.org" From: Al Morton References: Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Cc: "draft-ietf-ippm-loss-episode-metrics@tools.ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-ippm-loss-episode-metrics-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 04:26:00 -0000 Tina, thanks for your review.
I'll clarify a few points below,
Al

At 09:15 PM 11/15/2011, Tina TSOU wrote:
I had reviewed the draft already, but I have no knowledge to comment on the metric model. As far as security issue is concerned, since this is a active measurement, it suffers the drawbacks of injection of measurement traffic which is listed well in section 9.

Yes, as the latest metric in a long series of RFCs on
metrics for Active measurement, there are no new issues.

They should see if their model complies with RFC 1262: guideline for Internet measurement activities.

Although 1262 is a general guideline mostly for passive collection,
there are some general implications for active measurement as well.
However, RFC 2330 covers this topic far more extensively and
specifically for active measurement in IPPM.

 It can also help if they can mention what is the threshold percentage of measurement traffic that is tolerable and if they can quote an approximate percentage of measurement traffic needed to inject according to their loss metric and if it is acceptable.
 

This threshold has been requested by SecDir and other reviewers
outside of IPPM, but there is no value which is applicable to all
measurement circumstances. Even 1262 and 2330 decline to do this,
using general wording without providing a single numerical threshold.
Thus, the coverage of this draft is consistent with RFC 2330 and
previous metric RFCs on the topics load and amount of measurement
needed (accuracy is a design problem that goes beyond the metric definition).
From stephen.farrell@cs.tcd.ie Tue Nov 15 23:27:39 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF5121F9210 for ; Tue, 15 Nov 2011 23:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+0-SKkZ7ELT for ; Tue, 15 Nov 2011 23:27:34 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7535321F920A for ; Tue, 15 Nov 2011 23:27:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 206C9171CD0 for ; Wed, 16 Nov 2011 07:27:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1321428451; bh=UhNylkoEgpGinb+8EOyuXlNz T1Hjb47jc210lCzsY9M=; b=MkT83LcbOp2pSUFWudhr6gpLTRDnEIJMdU8IK5AH JJs7PK4nEADrQV9QYbdtW7HAk3vaflRZpP5Rf6vTkhs1rWNwC3MorqdFLoCy5AJv ko2JOIIf5FtjLyJPgQdG5s0UzlJIb3yda+bU5F+16IiKAa3+sMMxCPAW0SYIniXM nA/TW+Xlglzz+XZWf/2LQcXRLEeD3/7Xr7DhqKYYA6O6npPuwuPk1BXvj2xfZP0/ VysWUyddeICNG6watAeov/2Vu0ddUlJIHu4FPFCInt3z+moi4gqwB0LCgVCaDFga +rGg3PkZL5NrnxepphsNCV+C4IoaTuNLrrnJrqC2W4rD7w== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id cExthfbjUDv3 for ; Wed, 16 Nov 2011 07:27:31 +0000 (GMT) Received: from [130.129.37.121] (dhcp-2579.meeting.ietf.org [130.129.37.121]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 34CD9171CCF for ; Wed, 16 Nov 2011 07:27:30 +0000 (GMT) Message-ID: <4EC365DC.9090602@cs.tcd.ie> Date: Wed, 16 Nov 2011 07:27:24 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "secdir@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] wg summaries X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 07:27:39 -0000 Folks, Can you send summaries of your wg meetings to saag as usual? (Thanks to Shawn for starting.) Thanks, Stephen. From new-work-bounces@ietf.org Thu Nov 10 20:47:29 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CA321F85AE; Thu, 10 Nov 2011 20:47:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320986849; bh=cwoCjMgEpS7+65cAZLgMNYEAd2elLxnwdSVCQfwM8tI=; h=From:Date:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=ebbgBPtBthF4dMf9lxRHBGdHEzKWx2sZNiROcPDoHyPv3oHZT4QznrjqMm1zS86HV uRg4RfHuRhoDMb4m06n7uRMnXqRqZdXyLjEUZa4yyejt1GXk6x00KJz/BxGG8dDgyl tPsStuyo2cO6Iwn7oOkhjs6hlgpEclfyamtwAYPE= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392C621F85AE for ; Thu, 10 Nov 2011 20:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXiz3+6XcVhF for ; Thu, 10 Nov 2011 20:47:27 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id B61B521F8549 for ; Thu, 10 Nov 2011 20:47:27 -0800 (PST) Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1ROj1R-0000A3-Cf; Thu, 10 Nov 2011 23:47:25 -0500 From: Ian Jacobs Date: Thu, 10 Nov 2011 22:47:25 -0600 To: new-work@ietf.org Message-Id: <4D680428-A863-46F1-B86A-B906180A899A@w3.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Thu, 17 Nov 2011 17:28:49 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Multimodal Interaction Working Group (until 2011-12-09) 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, 11 Nov 2011 04:47:29 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Multimodal InteractionActivity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Multimodal Interaction Working Group: http://www.w3.org/2011/03/mmi-charter As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2011-12-09 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Kazuyuki Ashimura, Activity Lead . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2002/mmi/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From Tina.Tsou.Zouting@huawei.com Tue Nov 15 18:15:56 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AF911E810A for ; Tue, 15 Nov 2011 18:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.065 X-Spam-Level: X-Spam-Status: No, score=-6.065 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVuBUjD3C2Li for ; Tue, 15 Nov 2011 18:15:56 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id C9BF621F8DF2 for ; Tue, 15 Nov 2011 18:15:55 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ005OEEAHII@szxga03-in.huawei.com> for secdir@ietf.org; Wed, 16 Nov 2011 10:15:53 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ00MZMEAFFP@szxga03-in.huawei.com> for secdir@ietf.org; Wed, 16 Nov 2011 10:15:52 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFA11164; Wed, 16 Nov 2011 10:15:26 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Nov 2011 10:15:21 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.40]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 10:15:02 +0800 Date: Wed, 16 Nov 2011 02:15:01 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.212.245.37] To: "secdir@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_GS1uR8kY+4oNtRU8DjvTPQ)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: SECDIR review of draft-ietf-ippm-loss-episode-metrics-03 Thread-index: AQHMpAWLA+DJPYSYsEqiRMmXpLHvBA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: X-Mailman-Approved-At: Thu, 17 Nov 2011 17:28:49 -0800 Cc: "draft-ietf-ippm-loss-episode-metrics@tools.ietf.org" Subject: [secdir] SECDIR review of draft-ietf-ippm-loss-episode-metrics-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 02:15:56 -0000 --Boundary_(ID_GS1uR8kY+4oNtRU8DjvTPQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, I had reviewed the draft already, but I have no knowledge to comment on the metric model. As far as security issue is concerned, since this is a active measurement, it suffers the drawbacks of injection of measurement traffic which is listed well in section 9. They should see if their model complies with RFC 1262: guideline for Internet measurement activities. It can also help if they can mention what is the threshold percentage of measurement traffic that is tolerable and if they can quote an approximate percentage of measurement traffic needed to inject according to their loss metric and if it is acceptable. Tina --Boundary_(ID_GS1uR8kY+4oNtRU8DjvTPQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi all,
I had reviewed the draft already, but I have no knowledge to comment on the metric model. As far as security issue is concerned, since this is a active measurement, it suffers the drawbacks of injection of measurement traffic which is listed well in section 9.
They should see if their model complies with RFC 1262: guideline for Internet measurement activities. It can also help if they can mention what is the threshold percentage of measurement traffic that is tolerable and if they can quote an approximate percentage of measurement traffic needed to inject according to their loss metric and if it is acceptable.
 
Tina
 
 --Boundary_(ID_GS1uR8kY+4oNtRU8DjvTPQ)-- From glenzorn@gmail.com Tue Nov 22 00:10:52 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE6921F8557; Tue, 22 Nov 2011 00:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhenNO0aObiI; Tue, 22 Nov 2011 00:10:51 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 46A8721F8551; Tue, 22 Nov 2011 00:10:51 -0800 (PST) Received: by iaeo4 with SMTP id o4so10075599iae.31 for ; Tue, 22 Nov 2011 00:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dSwQEInK09dWGaLApAOWqRxkZeMqeOlU7uqgIFHjt+I=; b=sHZrgTSFlT5brjGz5rK4BfpJXVKGBzs5thgCuZ1e9KcmGk+wlbk+HVa75XTejkzyK+ LbRpv/vaTuGUhIMdMEEjfLXw9j1YfBUR66Iv3VOgn+ZmRZjbGJVc82pdnlgtl0xwN+2f hnYT4X7r+M3jGyHoevfzAvq1ijbiMcn16Eoz4= Received: by 10.50.85.129 with SMTP id h1mr18513274igz.47.1321949450946; Tue, 22 Nov 2011 00:10:50 -0800 (PST) Received: from [192.168.1.98] (ppp-171-96-13-213.revip8.asianet.co.th. [171.96.13.213]) by mx.google.com with ESMTPS id z10sm56859561ibv.9.2011.11.22.00.10.40 (version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 00:10:49 -0800 (PST) Message-ID: <4ECB58FC.4030702@gmail.com> Date: Tue, 22 Nov 2011 15:10:36 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= References: <13B04C3C-8B22-45CA-A9FE-356F44AE2E2E@nic.cz> In-Reply-To: <13B04C3C-8B22-45CA-A9FE-356F44AE2E2E@nic.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: draft-ietf-hokey-arch-design.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-hokey-arch-design-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 08:10:52 -0000 On 11/14/2011 5:01 PM, OndÅ™ej Surý wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > I haven't been following HOKEY at all, so the comments are basically > from innocent bystander who knows as much about EAP as needed to type > the password for WiFi in the 802.1x (and is user of eduroam network). > > The HOKEY architectural document seems to be clearly written and can > be understood even by me. It does not introduce neither any new protocol > nor security issues and is just a summary of existing standards or I-Ds, > so there are no security concerns in this particular document. Some > security concerns are referenced to other RFCs (Section 7), but they > are just #includes from other documents and not something new introduced > by this document. > > One minor nit: > > - You suddenly start to use rRK and DSrRK in the tables (4 and 5) in section 5. > It would help readability to explain somewhere what these abbreviations mean. How's this: 2. Terminology This document contains no normative language, hence [RFC2119] language does not apply. This document reuses terms defined in Section 2.2 of Ohba, et al. [RFC5836] and Section 2 of Wu, et al. [I-D.ietf-hokey-rfc5296bis]. In addition, it defines the following: DSrRK Domain-Specific reauthentication Root Key. ... From ondrej.sury@nic.cz Tue Nov 22 00:35:40 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C107B21F8C9E; Tue, 22 Nov 2011 00:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.35 X-Spam-Level: X-Spam-Status: No, score=-1.35 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvEYhwSK7bs4; Tue, 22 Nov 2011 00:35:40 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0227821F8C9D; Tue, 22 Nov 2011 00:35:40 -0800 (PST) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id CD37E2A2F12; Tue, 22 Nov 2011 09:35:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1321950938; bh=BASJOxfXmLQenx2UNP9KqeJFeMDkRqArG2zYcWyv4PU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Nyp4HVPhYZh8LMqY8tVM86V8PKyQ/G/9z0AxXQDtQccTkFhbyMpaMKCeVf1/NNg3c cZZFgekBz3V54nbGRPhva8H47Wo8h5e7kOEjkEtUDb2Ri+xQXu9Q0X4BR6svOsliV/ Sdbkl+YOA+7qtsdZ+sa4tTqr6PJ4N0Zcj8NTOV3A= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4ECB58FC.4030702@gmail.com> Date: Tue, 22 Nov 2011 09:35:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <40BC5A8D-B07C-4228-8322-21E372221165@nic.cz> References: <13B04C3C-8B22-45CA-A9FE-356F44AE2E2E@nic.cz> <4ECB58FC.4030702@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: draft-ietf-hokey-arch-design.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-hokey-arch-design-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 08:35:40 -0000 On 22. 11. 2011, at 9:10, Glen Zorn wrote: > On 11/14/2011 5:01 PM, Ond=C5=99ej Sur=C3=BD wrote: >> 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 >> I haven't been following HOKEY at all, so the comments are basically >> from innocent bystander who knows as much about EAP as needed to type >> the password for WiFi in the 802.1x (and is user of eduroam network). >>=20 >> The HOKEY architectural document seems to be clearly written and can >> be understood even by me. It does not introduce neither any new = protocol >> nor security issues and is just a summary of existing standards or = I-Ds, >> so there are no security concerns in this particular document. Some >> security concerns are referenced to other RFCs (Section 7), but they >> are just #includes from other documents and not something new = introduced >> by this document. >>=20 >> One minor nit: >>=20 >> - You suddenly start to use rRK and DSrRK in the tables (4 and 5) in = section 5. >> It would help readability to explain somewhere what these = abbreviations mean. >=20 > How's this: >=20 > 2. Terminology >=20 > This document contains no normative language, hence [RFC2119] > language does not apply. >=20 > This document reuses terms defined in Section 2.2 of Ohba, et al. > [RFC5836] and Section 2 of Wu, et al. [I-D.ietf-hokey-rfc5296bis]. > In addition, it defines the following: >=20 > DSrRK > Domain-Specific reauthentication Root Key. >=20 > ... That's fine by me. My sole point was that you did a pretty good job in explaining all the used terms in the document, so it was readable even for outsider, with exception of these two. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From tlyu@mit.edu Tue Nov 22 22:59:47 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04EB21F8B16; Tue, 22 Nov 2011 22:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.974 X-Spam-Level: X-Spam-Status: No, score=-103.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5Khj3FJnQGp; Tue, 22 Nov 2011 22:59:47 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF0121F852E; Tue, 22 Nov 2011 22:59:46 -0800 (PST) X-AuditID: 1209190e-b7f4a6d0000008e5-e2-4ecc99e121f9 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id D1.CB.02277.1E99CCE4; Wed, 23 Nov 2011 01:59:45 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id pAN6xi06012238; Wed, 23 Nov 2011 01:59:45 -0500 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pAN6xeed025890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Nov 2011 01:59:42 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id pAN6xeY5004966; Wed, 23 Nov 2011 01:59:40 -0500 (EST) To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tcpm-rfc3782-bis.all@tools.ietf.org From: Tom Yu Date: Wed, 23 Nov 2011 01:59:40 -0500 Message-ID: Lines: 60 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixG6novtw5hk/g97bJhZr1kpbzPgzkdni w8KHLA7MHkuW/GTy+HL5M1sAUxSXTUpqTmZZapG+XQJXRuvvdcwFX0UqXiyfy9jAuEugi5GT Q0LARGLB2w4WCFtM4sK99WxdjFwcQgL7GCVa97exgiSEBDYwSqzbXwSRuMIk8fB3G1RVF6PE y+mr2EGqRASiJU4t+wQ2SljAQmL9/j1ANgcHm4C0xNHFZSBhFgFViW+XNjOC2LxAJU33jzOD 2DwCnBK3br5lh4gLSpyc+QRsDLOAlsSNfy+ZJjDyzUKSmoUktYCRaRWjbEpulW5uYmZOcWqy bnFyYl5eapGusV5uZoleakrpJkZQoHFK8u1g/HpQ6RCjAAejEg9v5MnTfkKsiWXFlbmHGCU5 mJREeb1mnPET4kvKT6nMSCzOiC8qzUktPsQowcGsJMJb3weU401JrKxKLcqHSUlzsCiJ867e 4eAnJJCeWJKanZpakFoEk5Xh4FCS4A0ERpSQYFFqempFWmZOCUKaiYMTZDgP0PCDIIt5iwsS c4sz0yHypxgVpcR5VUGaBUASGaV5cL2wRPCKURzoFWFec5AqHmASget+BTSYCWjwtLUnQAaX JCKkpBoYuYM+uzQd7W19o8X6R8+w9bJNpYeJ8bb65EZdDZGb2c1+n3U6ShqLr1kdi/yw74eT /PqFEdVeJvWG0m1XSl17RVovbMu2/WQs+rxZ76tokL5Qfg1j4lXGSbcf9t0PPcccx7o91+dE XIYNb0GOatLKldM8y3utP56sPu5/5cAlh7f32OMSzZRYijMSDbWYi4oTATb7dSLfAgAA Subject: [secdir] secdir review of draft-ietf-tcpm-rfc3782-bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 06:59:47 -0000 The Security Considerations section of this document says: [RFC5681] discusses general security considerations concerning TCP congestion control. This document describes a specific algorithm that conforms with the congestion control requirements of [RFC5681], and so those considerations apply to this algorithm, too. There are no known additional security concerns for this specific algorithm. I believe this assessment is accurate. Editorial: I found it really confusing where Section 4 appears to directly copy text from RFC 3782 with no fixups of section references and step numbers. For example, 4.1 refers to a Step 1B of Section 3. There is no Step 1B in this document, and the relevant section is actually Section 3.2. Also, Section 4.2 refers to a Step 1A of Section 3, when it probably means Step 2 of Section 3.2 of RFC 5681. In Appendix B, first paragraph: In [RFC3782], the cwnd after Full ACK reception will be set to (1) min (ssthresh, FlightSize + SMSS) or (2) ssthresh. However, there is a risk in the first logic which results in performance degradation. With the first logic, if FlightSize is zero, the result will be 1 SMSS. This means TCP can transmit only 1 segment at this moment, which can cause delay in ACK transmission at receiver due to delayed ACK algorithm. The phrase "first logic" sounds awkward, and should probably be "first option", to align with the wording in Section 3.2. In Appendix B, end of second paragraph: Even if window size is not small, loss of ACK packets or receive buffer shortage during fast recovery can also increase the possibility to fall into this situation. should probably end with "...can also increase the possibility of falling into this situation." In the third paragraph of Appendix B: The proposed fix in this document ensures that sender TCP transmits at least two segments on Full ACK reception. I initially couldn't determine exactly what changes in this document achieve the purported fix, but I'm not an expert at TCP. The text in step 3 of Section 3.2 of this document is substantially the same when describing the Full ACK behavior, and the prescribed options for resetting the value of cwnd looked the same as in RFC 3782 until I carefully compared them side by side. Perhaps more clearly identifying the change, using text like: The proposed fix in this document, which sets cwnd to at least 2*SMSS if the implementation uses option 1 in the Full ACK behavior, ensures that sender TCP transmits at least two segments on Full ACK reception. would be better. From weiler@watson.org Thu Nov 24 05:30:35 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B09D21F8B2D for ; Thu, 24 Nov 2011 05:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CwCVxrNqfjD for ; Thu, 24 Nov 2011 05:30:35 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id ECB0A21F8A71 for ; Thu, 24 Nov 2011 05:30:34 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id pAODUXvL044084 for ; Thu, 24 Nov 2011 08:30:33 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id pAODUXEe044077 for ; Thu, 24 Nov 2011 08:30:33 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 24 Nov 2011 08:30:33 -0500 (EST) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 24 Nov 2011 08:30:33 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 13:30:35 -0000 For those in the US, happy Thanksgiving! I hope you enjoy the holiday! On Tue, 8 Nov 2011, Samuel Weiler wrote: > In the last batch of assignments there were many last-minute > requests for reviews .... Many of those weren't reviewed. Since > it's my fault for not giving you more warning, I'm not sending > nasty-grams, but I may be assigning those folks some new docs next > week. As above, all of the "new" assignments this week are out-of-order: Mr. Lepinski, Ms. Meadows, Mr. Mundy, Mr. Hallam-Baker, and Mr. DeKok have new assignments. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Derek Atkins is (still) next in the rotation. I still have about ten names on that out-of-order assignment list, so Derek won't be seeing an assignment for some time. For telechat 2011-12-01 Reviewer LC end Draft Steve Hanna TR2011-07-20 draft-ietf-dime-priority-avps-05 Scott Kelly TR2011-10-25 draft-ietf-geopriv-policy-uri-03 Matt Lepinski T 2011-11-30 draft-ietf-lisp-16 Matt Lepinski T 2011-10-31 draft-ietf-6man-rpl-option-05 Catherine Meadows TR2011-11-30 draft-ietf-speechsc-mrcpv2-27 Catherine Meadows T - draft-ietf-lisp-alt-09 Kathleen Moriarty T 2011-11-07 draft-ietf-krb-wg-gss-cb-hash-agility-08 Sandy Murphy T 2011-11-10 draft-ietf-v6ops-happy-eyeballs-05 Vincent Roca T 2011-11-09 draft-ietf-sieve-convert-05 Carl Wallace T 2011-11-07 draft-davis-t-langtag-ext-06 Carl Wallace T 2011-11-28 draft-ietf-netconf-access-control-06 Brian Weis T 2011-11-28 draft-ietf-netconf-system-notifications-06 Tom Yu TR2011-10-19 draft-ietf-codec-guidelines-06 Larry Zhu T 2011-11-29 draft-ietf-trill-rbridge-mib-04 Glen Zorn T 2011-11-21 draft-ietf-tsvwg-sctp-strrst-12 Last calls and special requests: Reviewer LC end Draft Alan DeKok 2011-12-05 draft-ietf-6man-exthdr-05 Phillip Hallam-Baker 2011-12-07 draft-gerhards-syslog-plain-tcp-11 Russ Mundy 2011-11-30 draft-ietf-ppsp-problem-statement-07 Tina TSOU 2011-04-23 draft-shin-augmented-pake-08 Nico Williams 2011-11-17 draft-ietf-simple-msrp-cema-03 From meadows@itd.nrl.navy.mil Mon Nov 28 08:53:55 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE0021F8CE9; Mon, 28 Nov 2011 08:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-ldItZFr93a; Mon, 28 Nov 2011 08:53:54 -0800 (PST) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by ietfa.amsl.com (Postfix) with ESMTP id BBC8021F8CE6; Mon, 28 Nov 2011 08:53:53 -0800 (PST) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id pASGrquZ003318; Mon, 28 Nov 2011 11:53:52 -0500 (EST) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id pASGrmVV019383; Mon, 28 Nov 2011 11:53:51 -0500 (EST) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011112811534704798 ; Mon, 28 Nov 2011 11:53:47 -0500 From: Catherine Meadows Content-Type: multipart/alternative; boundary=Apple-Mail-7-595257620 Date: Mon, 28 Nov 2011 12:04:01 -0500 Message-Id: To: iesg@ietf.org, secdir@ietf.org, draft-ietf-lisp-alt.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 28 Nov 2011 08:58:09 -0800 Cc: Catherine Meadows Subject: [secdir] SecDir Review of draft-ietf-lisp-alt-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 16:53:55 -0000 --Apple-Mail-7-595257620 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = =20 These comments were written primarily for the benefit of the security = area directors.=20 Document editors and WG chairs should treat these comments just like any = other last call comments.=20 This document describes a distributed index system to be used by the Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR) which holds the mapping information for a particular Endpoint Identifier (EID). The ITR or MR can then query the ETR to get the information it needs. This index, or Alternate Logical Topology, is = built as an overlay network on the Internet using the Border Gateway Protocol (BGP) and the Generic Routing Encapsulation (GRE). Since LISP+ALT relies on BGP, the authors correctly point out that that = it shares many of the security characteristics of BGP. They should be commended, however, = for not merely pointing to the BGP document, but also addressing any new = vulnerabilities that could arise from using LISP+ALT. These are mainly potential = denial-of-service attacks, for which suggested countermeasures are included. Another is the possibility that EID-prefixes would be more vulnerable to leakage since = they will be more widely propagated out to the global network. The authors point out that addressing this problem = requires more strict prefix filtering and authentication on the global routing system. The authors also discuss, in a final = paragraph (10.3), the potential use of emerging BGP security mechanisms that would provide this authentication. All in all, I think this is a very thorough and well-though-out = discussion of the security considerations. My only suggestion would be = to include a forward reference to paragraph 10.3 in the discussion of prefix = leakage. =20 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 --Apple-Mail-7-595257620 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. =  
These comments were written primarily for the benefit of the = security area directors. 
Document editors and WG chairs = should treat these comments just like any other last call = comments. 


This document = describes a distributed index system to be used
by = the Locator/ID Separation Protocol (LISP) Ingress Tunnel = Router
   (ITR) or Map Resolver (MR) to find the Egress = Tunnel Router (ETR)
   which holds the mapping = information for a particular Endpoint
   Identifier = (EID).  The ITR or MR can then query the ETR to get = the
information it needs.  This index, or Alternate = Logical Topology, is built as an overlay
network on the = Internet using the Border Gateway Protocol (BGP) and = the
Generic Routing Encapsulation = (GRE).

Since LISP+ALT relies on BGP, the = authors correctly point out that that it shares many of
the = security characteristics of BGP.  They should be commended, = however, for not
merely pointing to the BGP document, but also = addressing any new vulnerabilities
that could arise from using = LISP+ALT.  These are mainly potential denial-of-service attacks, = for which suggested
countermeasures are included. =  Another is the
possibility that EID-prefixes would be = more vulnerable to leakage since they will be more widely propagated out = to
the global network.  The authors point out that = addressing this problem requires more strict prefix filtering and = authentication
on  the global routing system.  The = authors also discuss, in a final paragraph (10.3), the potential use of = emerging
BGP security mechanisms that would provide this = authentication.

All in all, I think this is a = very thorough and well-though-out discussion of the security = considerations.  My only suggestion would be to include
a = forward reference to paragraph 10.3 in the discussion of prefix = leakage.



 
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

= --Apple-Mail-7-595257620-- From kathleen.moriarty@emc.com Mon Nov 28 11:54:22 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2CD11E80E2; Mon, 28 Nov 2011 11:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9aKP0ntp19m; Mon, 28 Nov 2011 11:54:22 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id EEE1A11E80E1; Mon, 28 Nov 2011 11:54:21 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id pASJsJMw005440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Nov 2011 14:54:21 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 28 Nov 2011 14:54:00 -0500 Received: from mxhub27.corp.emc.com (mxhub27.corp.emc.com [10.254.110.183]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id pASJrwM1029413; Mon, 28 Nov 2011 14:53:58 -0500 Received: from mx06a.corp.emc.com ([169.254.1.145]) by mxhub27.corp.emc.com ([10.254.110.183]) with mapi; Mon, 28 Nov 2011 14:53:57 -0500 From: To: , , Date: Mon, 28 Nov 2011 14:53:56 -0500 Thread-Topic: SecDir review of draft-ietf-krb-wg-gss-cb-hash-agility-08 Thread-Index: AcyuB3bVe3mChMdnTMCnKZoWHwL2ZA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [secdir] SecDir review of draft-ietf-krb-wg-gss-cb-hash-agility-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 19:54:22 -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 ot= her last call comments. Description: This document updates RFC4121 to allow channel bindings using algorithms negotiated based on Kerberos= crypto framework as defined in RFC3961= . In addition, because this update makes use of the last extensible field = in the Kerberos client-server exchange message, extensions are defined to a= llow future protocol extensions. I think the document is ready. The only suggestion would be to consider ex= panding out the security consideration section to list any risks with using= or not using channel bindings. Right now, it states it is up to the appli= cation's policy, which is fine, but may leave developers with questions. Telechat is on 12-30-2011 Thank you, Kathleen From nico@cryptonector.com Mon Nov 28 13:00:49 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E4A1F0C92; Mon, 28 Nov 2011 13:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5cD8fxIL+5f; Mon, 28 Nov 2011 13:00:49 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 20F2B1F0C8F; Mon, 28 Nov 2011 13:00:49 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id BEB605408B; Mon, 28 Nov 2011 13:00:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Uumx19Ii0T0d8AyMRVy6Ns8WIzUxPrTTM1Qmv+EiYKEX /D3hXPv/20tLpv/PQCtXfhRQ+Dipz8u8Xn9ON7fIN75ZQoWJQ0lwRdafsoGKrX0w fmBhynn4g7NNVhcLI7uqNQFhTxEzZHOkf707n1JapW3TfWdFx4UFMO9P2oVzSEU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=kjL2MnVpVE6ovL5L5oy508NGq0o=; b=FelPKx0ULBF tRmPKzRoBb6qooewxrZX99BPqJ0WIb41UiPTlThZTXvL98g9klV/kk65Mv49hHOg kLPBoSb9Y9Q9CjMYOtL13kwSdVe6RdZG33TqOc/kV5fegM+ig8FsPUKx5EpI6A6V As0N7WLGh2yD1yO3qyBOCTC8EuNHg8z0= Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 80A73541E4; Mon, 28 Nov 2011 12:13:48 -0800 (PST) Received: by ggnp4 with SMTP id p4so6894031ggn.31 for ; Mon, 28 Nov 2011 12:13:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.12.199 with SMTP id a7mr56428493pbc.58.1322511224640; Mon, 28 Nov 2011 12:13:44 -0800 (PST) Received: by 10.68.192.70 with HTTP; Mon, 28 Nov 2011 12:13:44 -0800 (PST) In-Reply-To: References: Date: Mon, 28 Nov 2011 14:13:44 -0600 Message-ID: From: Nico Williams To: kathleen.moriarty@emc.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-krb-wg-gss-cb-hash-agility.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-krb-wg-gss-cb-hash-agility-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 21:00:49 -0000 On Mon, Nov 28, 2011 at 1:53 PM, wrote: > I think the document is ready. =C2=A0The only suggestion would be to cons= ider expanding out the security consideration section to list any risks wit= h using or not using channel bindings. =C2=A0Right now, it states it is up = to the application's policy, which is fine, but may leave developers with q= uestions. This document is not really of interest to GSS-API application protocol developers -- they should be using RFCs 2743 and 5554. This doc is intended primarily for Kerberos GSS mechanism implementors. That said, informative references to RFC 5056 and 5554 wouldn't hurt, and in any case I'm not opposed to the proposed change. Nico -- From carl@redhoundsoftware.com Mon Nov 28 13:48:51 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A61021F8C99; Mon, 28 Nov 2011 13:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXEo4cI4y1Wr; Mon, 28 Nov 2011 13:48:50 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9834E21F8C28; Mon, 28 Nov 2011 13:48:50 -0800 (PST) Received: by vbbez10 with SMTP id ez10so5805518vbb.31 for ; Mon, 28 Nov 2011 13:48:50 -0800 (PST) Received: by 10.52.26.230 with SMTP id o6mr6980043vdg.20.1322516929946; Mon, 28 Nov 2011 13:48:49 -0800 (PST) Received: from [192.168.1.5] (pool-173-79-170-49.washdc.fios.verizon.net. [173.79.170.49]) by mx.google.com with ESMTPS id df14sm36986668vdb.0.2011.11.28.13.48.44 (version=SSLv3 cipher=OTHER); Mon, 28 Nov 2011 13:48:49 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Mon, 28 Nov 2011 16:48:34 -0500 From: Carl Wallace To: Message-ID: Thread-Topic: secdir review of draft-davis-t-langtag-ext-06 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-davis-t-langtag-ext-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 21:48:51 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies an Extension to BCP 47 which provides sub tags for specifying the source language or script of transformed content. The Security Considerations section simply references BCP 47, which seems fine. From carl@redhoundsoftware.com Mon Nov 28 13:48:53 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B961521F8C28; Mon, 28 Nov 2011 13:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68v7-G-0IyEY; Mon, 28 Nov 2011 13:48:53 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 097EE21F8D2F; Mon, 28 Nov 2011 13:48:52 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so5835505vcb.31 for ; Mon, 28 Nov 2011 13:48:52 -0800 (PST) Received: by 10.220.142.8 with SMTP id o8mr5391828vcu.38.1322516932508; Mon, 28 Nov 2011 13:48:52 -0800 (PST) Received: from [192.168.1.5] (pool-173-79-170-49.washdc.fios.verizon.net. [173.79.170.49]) by mx.google.com with ESMTPS id df14sm36986668vdb.0.2011.11.28.13.48.50 (version=SSLv3 cipher=OTHER); Mon, 28 Nov 2011 13:48:51 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Mon, 28 Nov 2011 16:48:38 -0500 From: Carl Wallace To: Message-ID: Thread-Topic: secdir review of draft-ietf-netconf-access-control-06 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-netconf-access-control-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 21:48:53 -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 such an access control model to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. I am not familiar with NETCONF or YANG so my review may be off-base. I found the frequent references to "recovery sessions" and "non-recovery sessions" unnecessary and somewhat confusing. Couldn't this concept be described once and omitted from the various lists of steps? There are probably some inconsistencies in the RFC 2119 language around the "recovery session" concept. For example, section 3.4.4 provides a bulleted list of steps that MUST be followed. Included in this list is an exception for recovery sessions. Section 3.3.1 says a "server MAY support a "recovery session" mechanism". Should 3.3.1 be a MUST? Section 3.1.1 references both "recovery session" and the ability to disable the entire access control model "during operation, in order to debug operational problems". What does the latter bullet that mentions debugging refer to in the model? Is this bullet just a second reference to recovery session? In section 3.2.4, copy operations may be partially performed while "nodes to which the client does not have read access are silently omitted". Why is this OK? It seems inconsistent with section 3.1.3, which says "If the user is authorized to perform the requested access operation on the requested data, then processing continues", implying that processing does not continue otherwise. The same silent skipping of items appears elsewhere as well, including edit config. At a minimum, some rationale describing why these silent omissions are acceptable should be provided. From vaf@cisco.com Mon Nov 28 14:51:13 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2966C11E80E7; Mon, 28 Nov 2011 14:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxlMsEVnXQk4; Mon, 28 Nov 2011 14:51:12 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 68FB611E80D7; Mon, 28 Nov 2011 14:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=650; q=dns/txt; s=iport; t=1322520668; x=1323730268; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=BHbrSOzqDsezvqgXhYWwhilxZjQA0SHf2hYUrnZcKjY=; b=QzyB+diZmOidUAMCgx1XoRPr30xsQZqkmo2g6JE45EO4OSZq0WJJgOnb FMNEQEIlbHNPdmAz2dazdB8ulnPF4lcO2hzCaPbkW+KeQuj6arUrHEhV+ IvVj+J0mC6urePSQ6vyN0nGp7dJk9u04tkPvTTqoON5vtp71r8Fkbu1wv I=; X-IronPort-AV: E=Sophos;i="4.69,587,1315180800"; d="scan'208";a="39514429" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 28 Nov 2011 22:51:08 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pASMp7m7015158; Mon, 28 Nov 2011 22:51:08 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 3E79C1A7BE16; Mon, 28 Nov 2011 14:51:07 -0800 (PST) Date: Mon, 28 Nov 2011 14:51:07 -0800 From: Vince Fuller To: Catherine Meadows Message-ID: <20111128225107.GB17970@vaf-mac1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Mon, 28 Nov 2011 14:56:37 -0800 Cc: vaf@cisco.com, draft-ietf-lisp-alt.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir Review of draft-ietf-lisp-alt-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 22:51:13 -0000 Thank you for the review. > All in all, I think this is a very thorough and well-though-out > discussion of the security considerations. My only suggestion would > be to include a forward reference to paragraph 10.3 in the > discussion of prefix leakage. I can certainly add such a reference as part of the forthcoming -10 draft. Can you be more specific about where you feel that the reference belongs? It looks like the topic of "route leakage" is mentioned on page 5 in the Intoduction section, then in section 6.2 where the suggestion of a separate SAFI for LISP+ALT is made, and, finally, in section 10.1. Thanks, --Vince From meadows@itd.nrl.navy.mil Mon Nov 28 15:37:40 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C8A21F8C34; Mon, 28 Nov 2011 15:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnF+hZNh+P08; Mon, 28 Nov 2011 15:37:40 -0800 (PST) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0686821F8B3F; Mon, 28 Nov 2011 15:37:39 -0800 (PST) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id pASNbbws017648; Mon, 28 Nov 2011 18:37:37 -0500 (EST) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id pASNbaMT020623; Mon, 28 Nov 2011 18:37:36 -0500 (EST) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011112818373605596 ; Mon, 28 Nov 2011 18:37:36 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-18-619484849 From: Catherine Meadows In-Reply-To: <20111128225107.GB17970@vaf-mac1.cisco.com> Date: Mon, 28 Nov 2011 18:47:48 -0500 Message-Id: <4DE4BC20-2C43-4311-BDB7-DEF871460580@itd.nrl.navy.mil> References: <20111128225107.GB17970@vaf-mac1.cisco.com> To: Vince Fuller X-Mailer: Apple Mail (2.1084) Cc: iesg@ietf.org, secdir@ietf.org, Catherine Meadows , draft-ietf-lisp-alt.all@tools.ietf.org Subject: Re: [secdir] SecDir Review of draft-ietf-lisp-alt-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 23:37:40 -0000 --Apple-Mail-18-619484849 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii My apologies, I was thinking of the discussion in 10.1. Cathy 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 On Nov 28, 2011, at 5:51 PM, Vince Fuller wrote: > Thank you for the review. > >> All in all, I think this is a very thorough and well-though-out >> discussion of the security considerations. My only suggestion would >> be to include a forward reference to paragraph 10.3 in the >> discussion of prefix leakage. > > I can certainly add such a reference as part of the forthcoming -10 draft. > > Can you be more specific about where you feel that the reference belongs? > It looks like the topic of "route leakage" is mentioned on page 5 in the > Intoduction section, then in section 6.2 where the suggestion of a separate > SAFI for LISP+ALT is made, and, finally, in section 10.1. > > Thanks, > --Vince > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --Apple-Mail-18-619484849 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii My = apologies, I was thinking of the discussion in = 10.1.

Cathy

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

On Nov 28, 2011, at 5:51 PM, Vince Fuller wrote:

Thank = you for the review.

All in all, I think = this is a very thorough and well-though-out
discussion of the security considerations.  My only = suggestion would
be to include = a forward reference to paragraph 10.3 in the
discussion of prefix leakage.

I can = certainly add such a reference as part of the forthcoming -10 = draft.

Can you be more specific about where you feel that the = reference belongs?
It looks like the topic of "route leakage" is = mentioned on page 5 in the
Intoduction section, then in section 6.2 = where the suggestion of a separate
SAFI for LISP+ALT is made, and, = finally, in section 10.1.

Thanks,
= --Vince
_______________________________________________
secdi= r mailing list
secdir@ietf.org
https://www.ietf.or= g/mailman/listinfo/secdir
wiki: = http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

= --Apple-Mail-18-619484849-- From bew@cisco.com Mon Nov 28 16:05:09 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B0011E80CE; Mon, 28 Nov 2011 16:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhu8aVsjS+fW; Mon, 28 Nov 2011 16:05:09 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id EA84911E80CA; Mon, 28 Nov 2011 16:05:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=1889; q=dns/txt; s=iport; t=1322525108; x=1323734708; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=Bzz8RQfmafnvL1Wza7a8bSrVju1WoOFQOa1gLVHs+Uk=; b=FboAM898zvuBsjbK8suxlJogrzsYZomT4rT/ef/BNJ5e5r5yH51Tr9IP JabQqtXyXb6BJ4ezaOnHox/kirlsIePDaErshqj9nW2dVqwDGsy1Ldsnx zFiWC7WauWsyrhaWS44qw4+7SictPk2Z9nH+lKLXKectyAHR9PBKUgmeb k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAIIh1E6rRDoJ/2dsb2JhbABDqnaBBYILASc9AoE+ATSgNQGeYIl/YwSIIYwpkiw X-IronPort-AV: E=Sophos;i="4.69,587,1315180800"; d="scan'208";a="14927573" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 29 Nov 2011 00:05:07 +0000 Received: from dhcp-128-107-151-81.cisco.com (dhcp-128-107-151-81.cisco.com [128.107.151.81]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAT057DI013621; Tue, 29 Nov 2011 00:05:07 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Nov 2011 16:05:07 -0800 Message-Id: To: secdir@ietf.org, The IESG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-netconf-system-notifications.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-netconf-system-notifications-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 00:05:09 -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 YANG module that allows a NETCONF client to = receive notifications for some common system events. Events reported = include change of system configuration, start or stop of of a NETCONF = client, and the like. These are important notifications for the purposes = of accounting and auditing. I have two comments on the Security Considerations text: 1) The first paragraph indicates that SSH is mandatory-to-implement for = the transport layer and cites RFC 6242 ("Using the NETCONF Protocol over = Secure Shell (SSH)". This is certainly good and acceptable, but I'm not = sure where the statement is made that says RFC 6242 MUST be implemented = as part of a NETCONF implementation. It would be good to cite that RFC = as well. 2) The second paragraph wisely states that read access to the data nodes = described in this memo should be controlled. It would be helpful to give = some advice how the control can be done. For example, this could be an = authorization step by the SSH server as part of authenticating a client. = Or it could be true because authentication credentials known by server = are only given to users who are authorized to have read access. The = first paragraph of RFC 62642's Security Considerations discusses this a = bit and seems to imply the latter authorization model. If that's the = intention here, a statement recommending giving out authentication = credentials only to users/devices authorized to read the NETCONF = notifications would be sufficient. Brian= From vaf@cisco.com Mon Nov 28 16:11:45 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9024E21F8CD3; Mon, 28 Nov 2011 16:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVQLc8c99q-Q; Mon, 28 Nov 2011 16:11:44 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE7921F8C2A; Mon, 28 Nov 2011 16:11:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=202; q=dns/txt; s=iport; t=1322525504; x=1323735104; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=RRMlzEyoKDVZ3B+v3GgKq8zA6j6htfweW12GUAlJr4Y=; b=P8BeGZkM9kzLUKEyn6sBUnvAiCfbXTH0s7O6krlZ3gP87K1i5otXVBtv FOFVxHj8eHFzG3GiF8FiBDFeSYWMLANXZvDdohdedgtFxzV4rMba4wdPL AowxX7PjbSis/87D6/p+LMR2GCWPRUUXzDYsVbxGdOxsC89CQtUBb1Lyu g=; X-IronPort-AV: E=Sophos;i="4.69,587,1315180800"; d="scan'208";a="16619477" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 29 Nov 2011 00:11:28 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAT0BSkd016981; Tue, 29 Nov 2011 00:11:28 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 676DB1A7CAC1; Mon, 28 Nov 2011 16:11:27 -0800 (PST) Date: Mon, 28 Nov 2011 16:11:27 -0800 From: Vince Fuller To: Catherine Meadows Message-ID: <20111129001127.GA23294@vaf-mac1.cisco.com> References: <20111128225107.GB17970@vaf-mac1.cisco.com> <4DE4BC20-2C43-4311-BDB7-DEF871460580@itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DE4BC20-2C43-4311-BDB7-DEF871460580@itd.nrl.navy.mil> User-Agent: Mutt/1.4.2.3i Cc: vaf@cisco.com, secdir@ietf.org, draft-ietf-lisp-alt.all@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] SecDir Review of draft-ietf-lisp-alt-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 00:11:45 -0000 On Mon, Nov 28, 2011 at 06:47:48PM -0500, Catherine Meadows wrote: > My apologies, I was thinking of the discussion in 10.1. OK. I added a reference from 10.1 to 10.3 to the -10 draft. --Vince From shawn.emery@oracle.com Mon Nov 28 22:39:03 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C224F21F8BB1; Mon, 28 Nov 2011 22:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aRoPvtZW4ld; Mon, 28 Nov 2011 22:39:03 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED5821F8B6D; Mon, 28 Nov 2011 22:39:03 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAT6cx9C030963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Nov 2011 06:38:59 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pAT6cwuT005061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Nov 2011 06:38:58 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pAT6cpJ1026625; Tue, 29 Nov 2011 00:38:51 -0600 Received: from [10.159.208.113] (/10.159.208.113) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Nov 2011 22:38:50 -0800 Message-ID: <4ED47DD9.90209@oracle.com> Date: Mon, 28 Nov 2011 23:38:17 -0700 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:7.0.1) Gecko/20111008 Thunderbird/7.0.1 MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4ED47E04.0037,ss=1,re=0.000,fgs=0 Cc: draft-ietf-krb-wg-gss-cb-hash-agility.all@tools.ietf.org, kathleen.moriarty@emc.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-krb-wg-gss-cb-hash-agility-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 06:39:03 -0000 On 11/28/11 01:13 PM, Nico Williams wrote: > On Mon, Nov 28, 2011 at 1:53 PM, wrote: >> I think the document is ready. The only suggestion would be to consider expanding out the security consideration section to list any risks with using or not using channel bindings. Right now, it states it is up to the application's policy, which is fine, but may leave developers with questions. > This document is not really of interest to GSS-API application > protocol developers -- they should be using RFCs 2743 and 5554. This > doc is intended primarily for Kerberos GSS mechanism implementors. Perhaps I should mention something like this in the sec cons section and remove the second paragraph? > That said, informative references to RFC 5056 and 5554 wouldn't hurt, > and in any case I'm not opposed to the proposed change. See above. Shawn. -- From tlyu@mit.edu Tue Nov 29 12:19:29 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAC71F0CAE; Tue, 29 Nov 2011 12:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l26QG6AekxGj; Tue, 29 Nov 2011 12:19:29 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id F23211F0CAD; Tue, 29 Nov 2011 12:19:28 -0800 (PST) X-AuditID: 12074424-b7ef76d0000008dc-a5-4ed53e4e7bef Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 0E.57.02268.E4E35DE4; Tue, 29 Nov 2011 15:19:27 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id pATKJPjE015854; Tue, 29 Nov 2011 15:19:26 -0500 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pATKJI7r018979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Nov 2011 15:19:23 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id pATKJIIp024734; Tue, 29 Nov 2011 15:19:18 -0500 (EST) To: iesg@ietf.org, secdir@ietf.org, draft-ietf-codec-guidelines.all@tools.ietf.org From: Tom Yu Date: Tue, 29 Nov 2011 15:19:18 -0500 Message-ID: Lines: 15 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUixCmqretvd9XPoH25sMWrbZdYLGb8mchs 8WHhQxYHZo8lS34yeXy5/JktgCmKyyYlNSezLLVI3y6BK2P5rhVMBTdYK94desPawHiKpYuR k0NCwETi0uGHjBC2mMSFe+vZuhi5OIQE9jFKvL28khXC2cAo8aH/IAuEc4VJYuudh1BlXYwS vTcmsoL0iwhES6z785EJxBYWsJbomvoLyObgYBOQlji6uAwkzCKgKrHi9DQWkDCvgIXEl5Ng YR4BTommJbuZQWxeAUGJkzOfgF3HLKAlcePfS6YJjHyzkKRmIUktYGRaxSibklulm5uYmVOc mqxbnJyYl5dapGuul5tZopeaUrqJERRq7C4qOxibDykdYhTgYFTi4Z0ldtVPiDWxrLgy9xCj JAeTkijvImugEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHex2ZAOd6UxMqq1KJ8mJQ0B4uSOK/N Tgc/IYH0xJLU7NTUgtQimKwMB4eSBG+jLVCjYFFqempFWmZOCUKaiYMTZDgP0PCdIDW8xQWJ ucWZ6RD5U4yKUuK8/SAJAZBERmkeXC8sFbxiFAd6RZi3AaSKB5hG4LpfAQ1mAhrcPvkKyOCS RISUVAPjxNYyhb8nVCLspvD8Zlj+UY7T908Ui99trn2uyycnHz19fWXGpGUnv7Qf2fRzmpfG neiZ2zSF56nU7uD++lZKXZ1Vuf6yl6uAavlWtlnV1b+NLyyKvq2tGpMaYOjDlO54OjrxdkNT 5z9le/7dB25yHNk9y8OXcYX3zHuuhmZJXHECk+PtFXmUWIozEg21mIuKEwE6Dfcv4AIAAA== Subject: [secdir] secdir re-review of draft-ietf-codec-guidelines-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 20:19:29 -0000 The revised draft includes a reference to RFC 6366, as requested. There is no mention of my concern that independent implementations of a codec can have shared vulnerabilities due to the nature of the encodings. (I admit this probably belongs in a update to RFC 6366.) Has the working group considered this concern, either during the writing of RFC 6366, or as an update to RFC 6366 (which this document might be an appropriate vehicle for)? Editorial: It's still not clear whether the intent of the document is to deal only with audio codecs. The body text implies that it does, but it would be helpful to confirm that in the title and/or abstract. Thanks for disambiguating "RF" (by removing the acronym). From vincent.roca@inria.fr Wed Nov 30 09:44:33 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F15321F8B92; Wed, 30 Nov 2011 09:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAJT0LHG0a72; Wed, 30 Nov 2011 09:44:32 -0800 (PST) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by ietfa.amsl.com (Postfix) with ESMTP id 39C4D21F8BDE; Wed, 30 Nov 2011 09:44:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.69,597,1315173600"; d="scan'208";a="121551162" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.0.10]) ([82.236.155.50]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 30 Nov 2011 18:44:30 +0100 From: Vincent Roca Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 30 Nov 2011 18:44:29 +0100 Message-Id: <6D739C51-20A3-4065-9027-C4FC54D3A894@inria.fr> To: IESG , secdir@ietf.org, draft-ietf-sieve-convert.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] Secdir review of draft-ietf-sieve-convert-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 17:44:33 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The authors explain there is no additional security considerations resulting from combining the two technologies. I'm not an expert in the domain and I have no strong opinion on this claim. So let's trust the authors. However these technologies do have strong security implications, as explained in [RFC5259] and [RFC5228]. So the authors should perhaps highlight this and be more directive. Regards, Vincent From barryleiba.mailing.lists@gmail.com Wed Nov 30 13:13:03 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11B011E80D5; Wed, 30 Nov 2011 13:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.173 X-Spam-Level: X-Spam-Status: No, score=-103.173 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGAFcG3BbuRU; Wed, 30 Nov 2011 13:13:03 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3489D11E80C0; Wed, 30 Nov 2011 13:13:03 -0800 (PST) Received: by ggnp4 with SMTP id p4so1328445ggn.31 for ; Wed, 30 Nov 2011 13:13:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YKjFSL9ykTsgebUozPfXBxNtTEXH8xDxO6rFWXsuQRo=; b=j+mIkl1xrdgznHXHWaMuAVpAGRPHbJB6vy0TXxnzDaTui2O63lMaBFeIICsSBuufCq UvMeUN8kqOBEIR8Z13N3cRrS6CvVpHp0ULCGq35Cvj1Rm6XTZM7pgaW+rd3KzPkStgpm 9FirC7UZE+8BlvHcl2q4eAGHFg1yahDHE2K0Q= MIME-Version: 1.0 Received: by 10.236.181.234 with SMTP id l70mr6871597yhm.49.1322687582844; Wed, 30 Nov 2011 13:13:02 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.107.9 with HTTP; Wed, 30 Nov 2011 13:13:02 -0800 (PST) In-Reply-To: <6D739C51-20A3-4065-9027-C4FC54D3A894@inria.fr> References: <6D739C51-20A3-4065-9027-C4FC54D3A894@inria.fr> Date: Wed, 30 Nov 2011 16:13:02 -0500 X-Google-Sender-Auth: c48HnrY18XGGSlzjOK02E1EYdo0 Message-ID: From: Barry Leiba To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-sieve-convert.all@tools.ietf.org, IESG Subject: Re: [secdir] Secdir review of draft-ietf-sieve-convert-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:13:04 -0000 Hi, Vincent, and thanks for the review. > However these technologies do have strong security implications, as > explained in [RFC5259] and [RFC5228]. So the authors should perhaps > highlight this and be more directive. They do, indeed, and those documents do explain it. I believe the text that's here is customary and adequate. That said, I have no objection to adding a sentence or two that says, "No, really. Pay attention!", or perhaps something slightly less flippant. If the ADs want that, please let me know and we'll work something up. Barry From mlepinski@bbn.com Wed Nov 30 13:23:34 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C3211E80C0; Wed, 30 Nov 2011 13:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMQGehDBLtz3; Wed, 30 Nov 2011 13:23:34 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id EEEE511E80AF; Wed, 30 Nov 2011 13:23:33 -0800 (PST) Received: from [128.89.255.204] (port=4368) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RVrcq-000Otm-Bq; Wed, 30 Nov 2011 16:23:32 -0500 Message-ID: <4ED69EE7.8040307@bbn.com> Date: Wed, 30 Nov 2011 16:23:51 -0500 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-6man-rpl-option.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SECDIR review of draft-ietf-6man-rpl-option-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:23:34 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies an IPv6 option for use in attaching RPL routing information to data packets within an RPL network. Initially (I believe) the information included in the option is for use only in loop avoidance and detection, but the syntax of the option is extensible and allows for arbitrary TLVs, for inclusion in RPL option, to be specified in a later document. There is no integrity protection for this option and so there exists a potential attack where a malicious party fabricates data packets with "bogus" information in the RPL option and sends them to an RPL router. The security considerations in this document describe such an attack and suggest a countermeasure. I believe that the principal secure concern (regarding an attack where a malicious party falsifies data in the RPL option) is that setting the 'O' bit and the 'Rank' field improperly can cause an RPL router to detect a "Rank Error" that does not exist. My understanding of RPL is that when a "Rank Error" is detected that the router resets its "DIO Trickle Timer" [see Note below]. The document suggests a potential counter-measure to such an attack where a router limits the rate at which it is willing to reset its DIO Trickle Timer in response to RPL option receipt to be less than some constant number of resets per hour. (This rate is a parameter of the system and the document suggests 20 as a reasonable parameter value). Personally, I believe that the counter-measure suggested is appropriate given the lack of integrity protection for the RPL option. However, I don't understand Trickle well enough to know what the ramifications would be (i.e., what an adversary would accomplish) by causing a router to reset its DIO Trickle Timer too often. (I assume that this generates some combination of churn in routing state and/or flood of additional RPL control traffic, which the adversary would use to effect a denial of service attack on the network.) Note: With regard to document clarity, it was somewhat difficult for me as reader to track down what happens when the Rank field in the RPL option is set improperly. In particular, the RPL option document refers to Section 11.2 in the RPL specification for information on the semantics of the data fields in the RPL option. Section 11.2 of the RPL specification describes (in particular) the Rank and 'O'-bits and indicates the circumstances in which a "rank inconsistency" occurs. However, Section 11.2 of the RPL specification does not specifically indicate what an RPL router does when such a rank inconsistency occurs. (That information is found in Section 8.3 of the RPL specification) Therefore, I would find it helpful to have in the security considerations section a reference to Section 8.3 of the RPL specification. Additionally, I find the use of the word "triggers" to be confusing in the Security Considerations section. (I believe the authors are using the word "triggers" to refer to triggering a reset of the DIO Trickle Timer, but that was not clear to me when I first read the document.) From shanna@juniper.net Wed Nov 30 15:22:24 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A5021F8C59; Wed, 30 Nov 2011 15:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.19 X-Spam-Level: X-Spam-Status: No, score=-106.19 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1kYv79JV-8h; Wed, 30 Nov 2011 15:22:23 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id D8E9421F8C5A; Wed, 30 Nov 2011 15:22:22 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTta6j0eoVAySwARgTgVVd5UxpKzOdSEZ@postini.com; Wed, 30 Nov 2011 15:22:22 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 30 Nov 2011 15:14:30 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 30 Nov 2011 18:14:29 -0500 From: Stephen Hanna To: "ietf@ietf.org" , "secdir@ietf.org" , "draft-ietf-dime-priority-avps.all@tools.ietf.org" Date: Wed, 30 Nov 2011 18:14:27 -0500 Thread-Topic: Secdir review of draft-ietf-dime-priority-avps-05 Thread-Index: AcxHTu34hXvg7biARZewSRVBSgbUbxoYjJ/w Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-dime-priority-avps-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 23:22:24 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This standards track document defines Diameter AVPs that can be used to convey a variety of priority parameters. In July 2011, I conducted a secdir review of a previous revision of this document (-04) and found that the Security Considerations section was inadequate because it did not include any analysis of the specific security issues related to priority systems. I'm pleased to say that the authors have attempted to address this issue in their new draft. They added a reference to the Security Considerations section of RFC 5866, which is thorough and sound. In addition, they explicitly identify one threat: unauthorized changes to QoS parameters in transit. However, the countermeasure proposed is confusing. The document now says "integrity protected values SHOULD be ignored". I would expect the reverse. Values that are not integrity protected SHOULD be ignored. Am I wrong? I'm concerned that the other threats described in RFC 5866 are not addressed in this document. Lack of authentication and confidentiality protection for QoS parameters can have serious negative impacts, as described in RFC 5866. In the IETF spirit of "send text", I suggest the following paragraph be added to the Security Considerations section of this draft: As described in [RFC5866], failure to provide adequate authentication and confidentiality protection for QoS parameters may result in serious failures that undermine the very purpose of QoS. Countermeasures such as Diameter communication security should be employed as appropriate. I will supply a further optional suggestion to clarify the text recently added regarding integrity. I recommend that the first paragraph of the Security Considerations section be stripped to just its first sentence and that the following paragraph be used in place of the new text that was added at the end of that paragraph: The values in the AVPs defined in this draft are not supposed to be changed by any of the Diameter servers or any other intermediaries. In fact, changes to these AVPs in transit could result in serious problems such as inability to complete high-priority emergency phone calls. Therefore, source integrity protection SHOULD be employed for those AVPs (e.g., the use of S/MIME with the SIP RPH, or an INTEGRITY object within a POLICY_DATA object). The text that I wrote may well be incorrect or misguided. I'm just trying to provide helpful suggestions from a security perspective. If the authors would like to have a further chat about this topic, I'd be glad to do so. And if they want to keep the text that they added on integrity protection, that's OK. I just found it a bit lacking in describing the threat and its consequences and in providing an effective countermeasure. Thanks, Steve