From secdir-bounces@ietf.org Thu Jan 1 13:21:47 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A88B93A69B9; Thu, 1 Jan 2009 13:21:47 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 624CE3A69EA; Thu, 1 Jan 2009 12:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCdytZw+0EMR; Thu, 1 Jan 2009 12:32:05 -0800 (PST) Received: from mailout06.yourhostingaccount.com (mailout06.yourhostingaccount.com [65.254.253.51]) by core3.amsl.com (Postfix) with ESMTP id 854BE3A6916; Thu, 1 Jan 2009 12:32:05 -0800 (PST) Received: from mailscan06.yourhostingaccount.com ([10.1.15.6] helo=mailscan06.yourhostingaccount.com) by mailout06.yourhostingaccount.com with esmtp (Exim) id 1LIUCv-0004JS-7J; Thu, 01 Jan 2009 15:31:53 -0500 Received: from impout02.yourhostingaccount.com ([10.1.55.2] helo=impout02.yourhostingaccount.com) by mailscan06.yourhostingaccount.com with esmtp (Exim) id 1LIUCu-000502-Ff; Thu, 01 Jan 2009 15:31:52 -0500 Received: from authsmtp04.yourhostingaccount.com ([10.1.18.4]) by impout02.yourhostingaccount.com with NO UCE id yLXs1a00305G96J0000000; Thu, 01 Jan 2009 15:31:52 -0500 X-EN-OrigOutIP: 10.1.18.4 X-EN-IMPSID: yLXs1a00305G96J0000000 Received: from c-98-216-48-22.hsd1.ma.comcast.net ([98.216.48.22] helo=Familyroom) by authsmtp04.yourhostingaccount.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim) id 1LIUCu-0005wB-1O; Thu, 01 Jan 2009 15:31:52 -0500 Received: from Familyroom by Familyroom (PGP Universal service); Thu, 01 Jan 2009 15:31:50 -0500 X-PGP-Universal: processed; by Familyroom on Thu, 01 Jan 2009 15:31:50 -0500 From: "Patrick Cain" To: , , Date: Thu, 1 Jan 2009 15:31:23 -0500 Message-ID: <013f01c96c4f$f5865ed0$e0931c70$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclP3fpZIOZKnRFLS9uHMmGOrLYfeA== Content-Language: en-us X-EN-UserInfo: 058f9b27fa04b0cf04458fb359a831ba:155e17fc3c7b3afdad05516cd0497062 X-EN-AuthUser: pcain@coopercain.com X-EN-OrigIP: 98.216.48.22 X-EN-OrigHost: c-98-216-48-22.hsd1.ma.comcast.net Cc: geopriv-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: [secdir] Security review of draft-ietf-geopriv-pdif-lo-profile-14 (resend) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org [You may have seen this message before. Many recipients apparently have not. :( ] 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. Document synopsis (snipped): There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in the RFC 4119 (PIDF-LO). This document makes recommendations on how to constrain, represent and interpret locations in a PIDF-LO. ----- The document looks fine to me from a security standpoint. The security considerations correctly points out that this is mostly a formatting document and other places define and recommend proper usage and protection of the data. Pat Cain _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Jan 1 19:27:48 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B6BC28C15F; Thu, 1 Jan 2009 19:27:48 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D2D28C0EE; Thu, 1 Jan 2009 19:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dp5T2goPK6AG; Thu, 1 Jan 2009 19:27:45 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 8659928C18D; Thu, 1 Jan 2009 19:27:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,316,1228089600"; d="scan'208";a="57940561" Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 02 Jan 2009 03:26:54 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id n023Qsvd029550; Thu, 1 Jan 2009 19:26:54 -0800 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n023QomH003368; Fri, 2 Jan 2009 03:26:51 GMT From: Cullen Jennings To: Volker Hilt In-Reply-To: <49502FCF.7080800@alcatel-lucent.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB94FD46@il-ex01.ad.checkpoint.com> <49502FCF.7080800@alcatel-lucent.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 1 Jan 2009 20:26:45 -0700 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11708; t=1230866814; x=1231730814; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20secdir=20review=20of=20draft-ietf-sip-s ession-policy-framework-05 |Sender:=20; bh=DdYkW7XNXaMlzYRam+z9D09GjSvdd+YVh1Q2/KglljE=; b=z2whyZnik/J3Dp/QHJQ+lhqV0YzW6ZPAvzVQfehCE0f8ml7AKOhJt0aWtZ UQsL8Ak2Z6SMAxKPHycEJg6DJfqfFK4YP6k+00SZ+yQiq/Re2hXv3TmKEmV8 K8baEUCvvK; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); Cc: "secdir@ietf.org" , Keith Drage , "draft-ietf-sip-session-policy-framework@tools.ietf.org" , "iesg@ietf.org" , Dean Willis Subject: Re: [secdir] secdir review of draft-ietf-sip-session-policy-framework-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org I'd like to put the draft on the call for next Thursday so if any changes are needed to address these, please send me an RFC Editor note by Wednesday. If more time is needed, let me know and I will move it to a future call. Thanks, Cullen On Dec 22, 2008, at 5:24 PM, Volker Hilt wrote: > Yaron, > >> 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. > Thanks for the comments! My responses are inline. >> I have reviewed a policy framework document that (5 years in the >> making) presumably represents the consensus of the SIP community. >> But reviewing it from a security point of view is rather >> challenging. In an environment where a dozen entities (*) may be >> involved in setting up a single session, it is difficult to define >> a threat model, let alone define a security solution. And indeed I >> find the security aspects of this document to be less than >> satisfactory. >> (*) UA1, local network's discovery point (DHCP?), local network's >> Policy Server (PS), registrar proxy, service provider's PS, MVNO >> call proxy (why not?), MVNO PS, physical service provider's proxy, >> service provider's PS, destination provider's proxy, destination >> provider's PS, and UA2. That's 12 in all. > While it is possible that many entities have session policies, a > more realistic case is one where there is a policy server in the > local network of the UAC and possibly another one in the local network > of the UAS. >> The top security issues I have identified are: >> - By most common definitions of the term Policy, a Policy is a set >> of rules which must be obeyed; failing to obey them is a security >> failure. However the current document skirts the issue of policy >> enforcement almost completely, and any mention of such is as an >> optional component. When looking at this document from a service >> provider's point of view, enforcing the policy is definitely a >> security property. Of course most of this enforcement needs to >> happen on the media path. > Yes, most enforcement needs to happen on the media path. And in > fact, this is what is already happening. Enforcement mechanisms are > used to enforce policies but currently they have no means of > notifying the UAs about policies they are enforcing (apart from > modifying SDP announcements). In other words, the policy enforcement > mechanisms already exist but what is missing is a mechanism to > signal the policies that are enforced to UAs. Without such > signaling, UAs have no way of finding out what the correct behavior > is to comply with all policies (apart from trial and error). This > piece is provided by this draft. Section 4.1 discusses the overall > architecture. > >> - A SIP User Agent can rarely be trusted (in a security sense) with >> anything, being deployed in the weakest part of the system - on the >> end device. However the document seems to assume (e.g. the Note in >> Sec. 4.4.2) that the UA will enforce the policy it receives from >> policy servers. > > No. Enforcement is done in the network. > > As mentioned above, enforcement mechanisms are outside of the scope > of this document and usually operate on the media path. This draft > enables the signaling of policies to the UA, which will allow the UA > to comply with them (if it wishes to do so). > > A compliant UA will follow the policies or refrain from setting up a > session. A non-compliant UA could ignore these policies but will > then encounter the enforcement mechanisms. > >> The document also emphasizes that the UA MUST fully disclose its >> policy, although a malicious UA has good reasons to lie. > Again, a malicious UA may lie or ignore policies. However, it will > then run into the policy enforcement mechanisms of the network. > > However, by signaling policies, a compliant UA can avoid errors > caused by enforcement mechanisms by setting up a compliant session > in the first place. > >> - Policies may be obtained from the local network (which may be >> trusted to some extent) or from basically anybody on the SIP path >> to the peer UA. The document mentions, correctly, that a malicious >> policy can easily disable the UA. So it is completely unrealistic >> to trust policies received from remote policy servers, even if they >> "authenticate" (present a certificate someone sold them). > Not sure I understand. If a policy comes from an entity the user > trusts and this entity is authenticated, the user should be able to > trust these policies. > > It is important to remember that only entities in the SIP signaling > path can submit a session policy. If there is a completely untrusted > entity in the path, this entity can choose to do whatever it wants > with the SIP message. A much simpler way to disable a specific call > than setting up a bad policy would be to simply route the message to > a malicious UAS. > > Also, a session policy only affects the current session. A malicious > policy server cannot generally "reconfigure" a UA. I therefore don't > see how session policies would pose an increased security risk. > >> - Policy is used for clearly security-sensitive tasks (disallowing >> sessions when you've run out of credit), but on the other hand, >> policy is optional - sessions can be started even if policy servers >> are unavailable. > No. Enforcement mechanisms will prevent this from happening. > However, with session policies a UA will know why the call is not > going trough instead of just getting silence from the other end. > >> - TLS is used as a security fix-all, even though the UA has neither >> direct contact nor trust with any but the first proxy. So in >> reality hop-by-hop TLS will be used to obtain policy servers' URIs. > The UA sets up a direct session with the policy server and can > authenticate this server. > >> Detailed Comments >> - Sec. 1: most of the discussion in the section is centered on >> proxies. This is a bit confusing because they are not the >> motivation for session-independent policies. > This section is introducing the fundamental problem: there is no > mechanism for an intermediary entity (i.e., the entity running a > proxy) to signal session policies to the UA. Session independent > policies provide this capability, even though they do not make > direct use of a proxy. > >> - Sec. 3.1: I suggest to add as step (0): discovery of one or more >> policy servers. > Indeed. Will add this step. > >> - Sec. 3.2.1: the conditions to resubscribe to a policy, and the >> restriction on retrying, mean that it's difficult to deploy a new >> policy in a network where previously there was none. Compare, e.g., >> with a retry every 24 hours. > Good point. It would probably make sense ask a UA to retry at a very > low rate, e.g., once every 24 or 48 hours. That way, a new policy > server would be known to all UAs within 2 days. > > I'll add a statement to the draft. > >> - Sec. 3.2.2: there are things it's reasonable to accept from the >> local domain's policy server, but not from a remote proxy. Is there >> any definition (or advice) on which policy elements are applicable >> where? > The policy dataset drafts provide guidelines on how to merge > policies from different servers. These rules can differ between > elements and are well specified in dataset drafts. Based on all the > discussions around this issue, I don't think we can draw a clear > distinction on which elements can reasonably come from which domains. > >> - Sec. 4: the use of policy to block out-of-credit users from >> creating media streams is puzzling. Are they still allowed to issue >> INVITE requests? > In this case, the policy server would return this policy only when > the UA tries to establish a session to another user. The user may > still be allowed, e.g., to access his voicemail or a IVR system to > recharge the account. These sessions would through, i.e., they would > be policed differently. > > Session specific policies only apply to a single session, they do > not generally prohibit an action of the UA (e.g., the creation of > INVITE messages). > >> - Sec. 4.2, step #3: the Framework should clarify if policy changes >> can be trigerred by different session-related events, e.g. a new >> party joining a call. > The events that can change a policy are at the discretion of the > policy server administrator. A party joining a call is a possible > event. However, in this case, the conference bridge would probably > directly re-negotiate the session with users. > >> - Sec. 4.3.1: I don't understand how UA A can request a new policy >> from PS A (in the last 2 steps) after it has already committed to B >> regarding their actual parameters. What if PS A comes up with any >> surprises? > The last two steps are necessary if PS A needs to see the answer > since has not yet seen it yet. Because the answer is based on the > offer, there should be no surprises and no need to return surprise > policies here. This step is needed, e.g., if the policy server wants > to see or modify the IP addresses contained in the answer to include > a media intermediary. Of course, PS A can always choose to terminate > a session. > >> - Sec. 4.4.1, step (6): discloses => disclose. > Good catch. Thanks!! (I'm assuming this is 4.3.1 step (6)) > >> - Sec. 4.4.1 (paragraph describing caching of local domain's PS): >> how does the UA identify its local domain's PS? We cannot simply >> assume the first PS the UA becomes aware of is local - maybe there >> is no local PS at all. > Good point. I'll add a clarification to the draft. Essentially it is > a policy server provided by an outbound proxy that is in the path > for all requests. > >> - Sec. 4.4.2 (Policy-Id paragraph): is enforcement of the correct >> policy really dependent on retransmitted messages being routed over >> exactly the same path as the originals? Can't the UA influence this >> routing? > A domain can have a load balancer that routes initial INVITE > requests. Since a retransmission of an INVITE after a 488 is a new > INVITE request, the first and second INVITE request could be > forwarded to different proxies with different policy servers. To > avoid that a request keeps bouncing between these proxies, a domain > can use the token field to route subsequent requests to the same > proxy. > >> - Sec. 4.5.1: allowing the UA to continue normal processing when >> the PS cannot be contacted means that the UA is also free to not >> contact the PS at all (and pretend that the requests were lost) or >> to ignore the returned policy (and pretend that the responses were >> lost). > Yes. As mentioned above, if it deliberately ignores the policy > server or policies, it will have to deal with an enforcement > mechanism. > > Again, session policies help a UA to do the right thing - they do > not enforce a policy. > >> - Sec. 4.5.2: why should the PS believe a policy it receives from a >> UA? What's there to prevent the UA from lying? > See above. > > Thanks! > > Volker > _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Jan 2 02:11:26 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5060F3A6999; Fri, 2 Jan 2009 02:11:26 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96B863A6999 for ; Fri, 2 Jan 2009 02:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ls8PqK2eLqSL for ; Fri, 2 Jan 2009 02:11:23 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3A8983A6906 for ; Fri, 2 Jan 2009 02:11:22 -0800 (PST) Received: (qmail invoked by alias); 02 Jan 2009 10:11:09 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp007) with SMTP; 02 Jan 2009 11:11:09 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+/vsZeACe/YrBKpgAWcQO2F7MozAvounA4H7xV1D aOwtNHex7kiPvX From: "Hannes Tschofenig" To: "'Patrick Cain'" , , References: <013f01c96c4f$f5865ed0$e0931c70$@com> Date: Fri, 2 Jan 2009 12:11:32 +0200 Message-ID: <01e701c96cc2$7f8222a0$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <013f01c96c4f$f5865ed0$e0931c70$@com> thread-index: AclP3fpZIOZKnRFLS9uHMmGOrLYfeAc5HvKQ X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Cc: geopriv-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Security review of draft-ietf-geopriv-pdif-lo-profile-14(resend) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Thanks for your review Patrick! >-----Original Message----- >From: secdir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] >On Behalf Of Patrick Cain >Sent: 01 January, 2009 22:31 >To: Hannes.Tschofenig@gmx.net; martin.thomson@andrew.com; >james.winterbottom@andrew.com >Cc: geopriv-chairs@tools.ietf.org; iesg@ietf.org; secdir@ietf.org >Subject: [secdir] Security review of >draft-ietf-geopriv-pdif-lo-profile-14(resend) > >[You may have seen this message before. Many recipients >apparently have not. >:( ] > >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. > >Document synopsis (snipped): > >There is growing interest in being able to use location >information contained in a PIDF-LO for routing applications. >To allow successful interoperability between applications, >location information needs to be normative and more tightly >constrained than is currently specified in the RFC 4119 >(PIDF-LO). This document makes recommendations on how to >constrain, represent and interpret locations in a PIDF-LO. > >----- > >The document looks fine to me from a security standpoint. The >security considerations correctly points out that this is >mostly a formatting document and other places define and >recommend proper usage and protection of the data. > >Pat Cain > >_______________________________________________ >secdir mailing list >secdir@ietf.org >https://www.ietf.org/mailman/listinfo/secdir > _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Jan 2 11:51:39 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08E2F3A69A4; Fri, 2 Jan 2009 11:51:39 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E9D3A6979 for ; Fri, 2 Jan 2009 11:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.415 X-Spam-Level: X-Spam-Status: No, score=-4.415 tagged_above=-999 required=5 tests=[AWL=2.184, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+2TkCbRx3r0 for ; Fri, 2 Jan 2009 11:51:36 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id C443B3A6A1E for ; Fri, 2 Jan 2009 11:51:15 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n02Jp1FT005014 for ; Fri, 2 Jan 2009 14:51:01 -0500 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n02Jou0k005006 for ; Fri, 2 Jan 2009 14:50:56 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n02JoppX000845 for ; Fri, 2 Jan 2009 14:50:51 -0500 (EST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id A15AF128C923 for ; Fri, 2 Jan 2009 14:50:30 -0500 (EST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 1FF4750822; Fri, 2 Jan 2009 12:06:49 -0800 (PST) Date: Fri, 02 Jan 2009 12:06:48 -0800 From: Eric Rescorla To: secdir@mit.edu, iesg@ietf.org, draft-ietf-dkim-ssp@tools.ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20090102200649.1FF4750822@romeo.rtfm.com> X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: dkim@ietf.org, ietf@ietf.org Subject: [secdir] Review of draft-ietf-dkim-ssp-08 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org $Id: draft-ietf-dkim-ssp-08-rev.txt,v 1.1 2009/01/02 19:05:45 ekr Exp $ This document describes a way for domains to publish their policy vis-a-vis signing emails with DKIM. The idea here is that when you receive an email that is not signed you would like to be able to distinguish (at least) two cases: - The domain doesn't sign. - This is a forgery. This document (hereafter called ADSP) allows the domain to advertise its signing policy, thus allowing recipients to distinguish these (and some other) cases. Generally, this approach and the protocol it describes seem sound. However, I have some concerns as detailed below. One general question: I see you're using TXT here. I know this is a hot button for the DNS people. If you haven't cleared this with them, that might be good. If you have, then ignore this comment. TECHNICAL S 3. Hosts can look up the ADSP information of the domain(s) specified by the Author Address(es) as described in Section 4.3. If a message has multiple Author Addresses the ADSP lookups SHOULD be performed independently on each address. This document does not address the process a host might use to combine the lookup results. I'd like to see some security analysis of why this is OK. Naively, it seems like one might be able to get around ADSP using this feature. I.e., I want to forge a message apparently from example.com, which has "dkim-all". I generate a message with "From: ekr@example.com, ekr@example.org" where I control example.org. I then serve a record for example.org indicating that I don't sign. If this is accepted, that seems potentially problematic. S 4.3. Check Domain Scope: An ADSP checker implementation MUST determine whether a given Author Domain is within scope for ADSP. Given the background in Section 3.1 the checker MUST decide which degree of approximation is acceptable. The checker MUST return an appropriate error result for Author Domains that are outside the scope of ADSP. I don't really undersand how the second (and maybe third) MUSTs are operationalizable. How would I not "decide"? I mean, I could just ignore the issue and do exact match. Would that constitute "deciding"? What would not "deciding"? S 6.2. An attacker might attack the DNS infrastructure in an attempt to impersonate ADSP records to influence a receiver's decision on how it will handle mail. However, such an attacker is more likely to attack at a higher level, e.g., redirecting A or MX record lookups in order to capture traffic that was legitimately intended for the target domain. These DNS security issues are addressed by DNSSEC [RFC4033]. I don't understand why an attacker is more likely to redirect A or MX. These are different attacks with different objectives. If I'm doing phishing, then forgery seems more useful to the attacker. In addition, to the extent to which the point of security considerations is to give the reader an accurate picture of the security of the system, I don't think this works that well, as due to the very low deployment of DNSSEC, in practice these records are easily forged. EDITORIAL S 2.7. For example, if a message has a Valid Signature, with the DKIM- Signature field containing "i=a@domain.example", then domain.example is asserting that it takes responsibility for the message. If the message's From: field contains the address "b@domain.example" and an ADSP query produces a "dkim=all" or "dkim=discardable" result, that would mean that the message does not have a valid Author Signature. Even though the message is signed by the same domain, it fails to satisfy ADSP. I think this example might benefit from a bit more explanation. As I understand it, this signature is invalid per DKIM and so it needs to be treated as unsigned, and that's where ADSP kicks in. But I may have misunderstood, so some clarity here might help. S 3.1. Note: The results from DNS queries that are intended to validate a domain name unavoidably approximate the set of Author Domains that can appear in legitimate email. For example, a DNS A record could belong to a device that does not even have an email implementation. It is up to the checker to decide what degree of approximation is acceptable. I don't really understand this graf. Can you rephrase? -Ekr _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Jan 2 12:22:57 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BC763A6903; Fri, 2 Jan 2009 12:22:57 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3561C3A6809 for ; Fri, 2 Jan 2009 12:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.012 X-Spam-Level: X-Spam-Status: No, score=-5.012 tagged_above=-999 required=5 tests=[AWL=1.587, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRsr-vzRbdWO for ; Fri, 2 Jan 2009 12:22:54 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 026903A6A33 for ; Fri, 2 Jan 2009 12:21:30 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n02KLIBT011472 for ; Fri, 2 Jan 2009 15:21:18 -0500 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n02KLG8u011468 for ; Fri, 2 Jan 2009 15:21:16 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n02KL9Nv004872 for ; Fri, 2 Jan 2009 15:21:10 -0500 (EST) Received: from cs.tau.ac.il (anna.cs.tau.ac.il [132.67.192.229]) by mit.edu (Spam Firewall) with ESMTP id 9F5D71190314 for ; Fri, 2 Jan 2009 15:20:48 -0500 (EST) Received: from localhost.localdomain (nova.cs.tau.ac.il [132.67.192.133]) by cs.tau.ac.il (Postfix) with ESMTP id 60E79145AABD; Fri, 2 Jan 2009 22:20:47 +0200 (IST) Received: by localhost.localdomain (Postfix, from userid 3106) id 43A0A133F96C; Fri, 2 Jan 2009 22:20:47 +0200 (IST) Received: from localhost (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 41FE217018A9; Fri, 2 Jan 2009 22:20:47 +0200 (IST) Date: Fri, 2 Jan 2009 22:20:47 +0200 (IST) From: Ran Canetti X-X-Sender: canetti@nova.cs.tau.ac.il To: Ran Canetti In-Reply-To: Message-ID: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: ospf@ietf.org, secdir@mit.edu, mw.chandra@gmail.com, akr@cisco.com Subject: [secdir] Security review of draft-ietf-ospf-manet-or-01 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org *I have reviewed these documents as part of the security directorate's *ongoing effort to review all IETF documents being processed by the *IESG. These comments were written primarily for the benefit of the *security area directors. Document editors and WG chairs should treat *these comments just like any other last call comments. The document describes extensions to OSPF for adapting it to deal with mobile ad-hoc networks (MANETs). In general, the document seems well thought out and detailed. However, some security concerns seem to have not been addressed. (In fact, the security considerations section is quite terse, with only 8 lines.) For instance: * In MANETs practically anyone can be a router (or at least this is the philosophy, in order to maximize connectivity). This means that route and connectivity announcements can be trusted to a much lesser extent, and a network needs to have ways to recover from false attestations. Note that authentication provides only a very partial solution here, since a bad attestation can be 100% authentic, in the sense that it really came from the claimed (malicious) source. * One of the stated motivations for extending OSPF is to provide a "seamless" connection between a wired network and a MANET. However, such a "seamless" connection might be a source for instability of the wired network, since the wireless part might be much less stable, and perhaps maliciously so. So it seems that curbs must be put in order to protect the stability of the wired part of the network. * It might be hard to locate and disconnect an undesirable endpoint (say, a bot, spammer or a DOS-attacker) when it comes from a MANET. Hope this helps, Ran _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Jan 2 13:34:21 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776DE3A68A5; Fri, 2 Jan 2009 13:34:21 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4003A68A5 for ; Fri, 2 Jan 2009 13:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.468 X-Spam-Level: X-Spam-Status: No, score=-4.468 tagged_above=-999 required=5 tests=[AWL=2.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnTrDp6sMxjI for ; Fri, 2 Jan 2009 13:34:19 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id BF2F13A680D for ; Fri, 2 Jan 2009 13:34:19 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n02LY7Jt022188 for ; Fri, 2 Jan 2009 16:34:07 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n02LY3m7022175 for ; Fri, 2 Jan 2009 16:34:03 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n02LXwSC028222 for ; Fri, 2 Jan 2009 16:33:58 -0500 (EST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 5F2E9116FC5C for ; Fri, 2 Jan 2009 16:33:37 -0500 (EST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id BD92350822; Fri, 2 Jan 2009 13:49:55 -0800 (PST) Date: Fri, 02 Jan 2009 13:49:55 -0800 From: Eric Rescorla To: secdir@mit.edu, iesg@ietf.org, draft-ietf-dkim-ssp@tools.ietf.org In-Reply-To: <20090102200649.1FF4750822@romeo.rtfm.com> References: <20090102200649.1FF4750822@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20090102214955.BD92350822@romeo.rtfm.com> X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: dkim@ietf.org, ietf@ietf.org Subject: Re: [secdir] Review of draft-ietf-dkim-ssp-08 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org At Fri, 02 Jan 2009 12:06:48 -0800, Eric Rescorla wrote: > TECHNICAL > S 3. > > Hosts can look up the ADSP information of the domain(s) specified by > the Author Address(es) as described in Section 4.3. If a message has > multiple Author Addresses the ADSP lookups SHOULD be performed > independently on each address. This document does not address the > process a host might use to combine the lookup results. > > I'd like to see some security analysis of why this is OK. Naively, > it seems like one might be able to get around ADSP using this feature. > I.e., I want to forge a message apparently from example.com, which > has "dkim-all". I generate a message with "From: ekr@example.com, ekr@example.org" > where I control example.org. I then serve a record for example.org > indicating that I don't sign. If this is accepted, that seems > potentially problematic. In retrospect, this isn't very clear. In the case where there is one author and no signature, it seems to me that ADSP allows you to differentiate two cases: (1) The domain does not do DKIM signing [or more precisely hasn't bothered to publish a policy.] (2) The domain DKIM signs and this is a forgery [or an error or something.] Obviously a message that falls into case (2) should be treated with extreme skepticism (and presumably discarded if discardability is set). By contrast, a message that falls into category (1) probably would be treated with less skepticism. Now, let's try to extend that question to a message with multiple signers. Consider the following policy for combining the results: "If any author lacks an ADSP record, act is af no ADSP record is available." ISTM that this allows an attacker to generate a message with a nominal author list that includes a domain that DKIM signs but get it treated as if it were in case (1). To the extent to which such messages get less skepticism, that seems undesirable. By contrast, a policy which said "treat the most strict policy as applying to all signers" would have a very different set of security properties. Obviously, these questions interact a lot with what treatment messages get which fall into various categories, something I appreciate that DKIM has tried to be agnostic about in general. Unfortunately, I think this is somewhere where you need to consider some plausible treatments and the effect of various policies in the face of the natural attacker behaviors. -Ekr _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Jan 2 16:52:52 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 754493A69AA; Fri, 2 Jan 2009 16:52:52 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F07A28C18A for ; Fri, 2 Jan 2009 16:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.518 X-Spam-Level: X-Spam-Status: No, score=-4.518 tagged_above=-999 required=5 tests=[AWL=2.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9c1VQ9pGHLL for ; Fri, 2 Jan 2009 16:52:50 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 3C8613A687E for ; Fri, 2 Jan 2009 16:52:50 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n030qcBO013006 for ; Fri, 2 Jan 2009 19:52:38 -0500 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n030qZZk013003 for ; Fri, 2 Jan 2009 19:52:35 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n030qQC7005848 for ; Fri, 2 Jan 2009 19:52:27 -0500 (EST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 52976CF4BD0 for ; Fri, 2 Jan 2009 19:52:08 -0500 (EST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 7D19150822; Fri, 2 Jan 2009 17:08:26 -0800 (PST) Date: Fri, 02 Jan 2009 17:08:26 -0800 From: Eric Rescorla To: John R Levine In-Reply-To: References: <20090102200649.1FF4750822@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20090103010826.7D19150822@romeo.rtfm.com> X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: dkim@ietf.org, draft-ietf-dkim-ssp@tools.ietf.org, iesg@ietf.org, secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Review of draft-ietf-dkim-ssp-08 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org At Fri, 2 Jan 2009 19:22:25 -0500 (EST), John R Levine wrote: > > > This document (hereafter called ADSP) allows the domain to advertise > > its signing policy, thus allowing recipients to distinguish these > > (and some other) cases. > > ADSP is a very, very narow design, that attempts to deal with only a > single threat: exact forgery of an address on the From: line. There's a > lot of other threats, arguably more important to address, but ADSP doesn't > deal with them. OK. > > TECHNICAL > > S 3. > > > > Hosts can look up the ADSP information of the domain(s) specified by > > the Author Address(es) as described in Section 4.3. If a message has > > multiple Author Addresses the ADSP lookups SHOULD be performed > > independently on each address. This document does not address the > > process a host might use to combine the lookup results. > > > > I'd like to see some security analysis of why this is OK. Naively, > > it seems like one might be able to get around ADSP using this feature. > > Since we don't have any real experience with signed mail with multi > address From: lines, any analysis would just be a guess, and not a very > well informed one at that, so we figured it was better not to. Consider > these From: lines: > > From: security@paypal.com, crook@phishpharm.biz ; ADSP fail, pass > > From: security@paypalsecurity.com, crook@phishpharm.biz ; ADSP unknown, pass > > From: friend@knowndomain.com, someone@somewhere.com; ADSP pass, unknown > > The first and second cases are probably bad guys, but the third could be > someone you know and trust and his friend who you don't happen to know > yet. > > We don't see any way to tell these apart without consulting external > reputation databases, which are way outside the scope of ADSP and DKIM. OK, but I don't see how it helps to put the job of making this judgement on the implementor, who probably has less expertise and time to think about this than the DKIM WG has, especially as there is at least one policy that more or less obviates ADSP (treat all addresses as having the weakest policy advertised by any of them). > > S 6.2. > > An attacker might attack the DNS infrastructure in an attempt to > > impersonate ADSP records to influence a receiver's decision on how it > > will handle mail. However, such an attacker is more likely to attack > > at a higher level, e.g., redirecting A or MX record lookups in order > > to capture traffic that was legitimately intended for the target > > domain. These DNS security issues are addressed by DNSSEC [RFC4033]. > > > > I don't understand why an attacker is more likely to redirect A or MX. > > These are different attacks with different objectives. If I'm doing > > phishing, then forgery seems more useful to the attacker. > > Why phish if you can hijack the real traffic to the target? Because the legitimate URL the user is dereferencing uses TLS? > > S 2.7. > > > > For example, if a message has a Valid Signature, with the DKIM- > > Signature field containing "i=a@domain.example", then domain.example > > is asserting that it takes responsibility for the message. If the > > message's From: field contains the address "b@domain.example" and an > > ADSP query produces a "dkim=all" or "dkim=discardable" result, that > > would mean that the message does not have a valid Author Signature. > > Even though the message is signed by the same domain, it fails to > > satisfy ADSP. > > > > I think this example might benefit from a bit more explanation. > > As I understand it, this signature is invalid per DKIM > > It's valid DKIM, but ADSP has additional semantics that are incompatible > with common auditing usage of the DKIM i= field. The -09 draft will have > a note pointing this out with a workaround. For an example of usage of > i=, see the DKIM signature on this message. > > > Note: The results from DNS queries that are intended to validate a > > domain name unavoidably approximate the set of Author Domains that > > can appear in legitimate email. For example, a DNS A record could > > belong to a device that does not even have an email > > implementation. It is up to the checker to decide what degree of > > approximation is acceptable. > > > > I don't really understand this graf. Can you rephrase? > > Many people have pointed out that in practice you can trivially circumvent > ADSP by using lookalike domains, e.g. paypalsecurity.com or > www.paypal.com. One way to address this would be to check to see if the > domain is in use at all for e-mail, since the number of domains in use for > mail is a tiny fraction of all of the names in the DNS. Unfortunately, > due to the ancient SMTP rule that use an A record, and now also AAAA, for > fallback if a domain has no MX record, any name with an A or AAAA record > can potentially be used for mail. There's a range of more or less > aggressive heuristics to see if a name with an A/AAAA record really is > used for mail (e.g., try to connect to port 25 and see if you get a hard > rejection), but there's no agreement on which if any an ADSP client should > use. I would suggest that some explanation like this should go in the document. -Ekr _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sat Jan 3 02:50:39 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 147733A6946; Sat, 3 Jan 2009 02:50:39 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8097A3A68F1; Sat, 3 Jan 2009 02:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE4s46EntNfa; Sat, 3 Jan 2009 02:50:36 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 1D5043A6880; Sat, 3 Jan 2009 02:50:34 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D7A8F29C002; Sat, 3 Jan 2009 12:50:21 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D0E8C29C001; Sat, 3 Jan 2009 12:49:56 +0200 (IST) X-CheckPoint: {495F4103-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n03AntfE004466; Sat, 3 Jan 2009 12:49:56 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sat, 3 Jan 2009 12:49:55 +0200 From: Yaron Sheffer To: Volker Hilt Date: Sat, 3 Jan 2009 12:49:55 +0200 Thread-Topic: secdir review of draft-ietf-sip-session-policy-framework-05 Thread-Index: AclklOkJTxoHKa4uQ4Gt1nTaJiwDfwI+LoEQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E56C8F7@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB94FD46@il-ex01.ad.checkpoint.com> <49502FCF.7080800@alcatel-lucent.com> In-Reply-To: <49502FCF.7080800@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "draft-ietf-sip-session-policy-framework@tools.ietf.org" , Dean Willis , Keith Drage , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-sip-session-policy-framework-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Volker, Thanks for your detailed response. Overall I accept your clarifications, but I think the document could have done a much better job on being self explanatory, e.g. by: - Mentioning that policy enforcement on the media path is mandatory, even if it is not specified here - otherwise, what's the use? - Mentioning explicitly that the UA is *not* tasked with enforcing the policy. It is only obeying the policy to avoid unnecessary error cases. Moreover, the security of the system does not rely on the UA's behavior WRT policy. - Possibly changing the document's name from "policy framework" to "policy publication framework", because this is the aspect of policy we are discussing, as opposed to enforcement. One more word on terminology. The document is about "session policies", which consist of "session independent policies" and "session specific policies". I find it mighty confusing, and suggest to replace "session policies" by the (to me) clearer name "media policies". Per your explanation, session-independent policies become the most sensitive part (because they persistently change the behavior of the UA). So the Security Considerations should have a section on how the UA can ensure that these policies are trustworthy (e.g. by being configured with the specific local policy servers). And "RECOMMENDING that the UA authenticates the PS" is not strong enough. You should also explain in the Security Consideration that we are punting on securing session-specific policies, because they are non-persistent and because any proxy on the session path can affect such policies anyway. Thanks, and a Happy New Year! Yaron > -----Original Message----- > From: Volker Hilt [mailto:volkerh@alcatel-lucent.com] > Sent: Tuesday, December 23, 2008 2:25 > To: Yaron Sheffer > Cc: secdir@ietf.org; iesg@ietf.org; draft-ietf-sip-session-policy- > framework@tools.ietf.org; Dean Willis; Keith Drage > Subject: Re: secdir review of draft-ietf-sip-session-policy-framework-05 > > Yaron, > > > 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. > > > Thanks for the comments! My responses are inline. > > > > I have reviewed a policy framework document that (5 years in the > > making) presumably represents the consensus of the SIP community. But > > reviewing it from a security point of view is rather challenging. In > > an environment where a dozen entities (*) may be involved in setting > > up a single session, it is difficult to define a threat model, let > > alone define a security solution. And indeed I find the security > > aspects of this document to be less than satisfactory. > > > > (*) UA1, local network's discovery point (DHCP?), local network's > > Policy Server (PS), registrar proxy, service provider's PS, MVNO call > > proxy (why not?), MVNO PS, physical service provider's proxy, service > > provider's PS, destination provider's proxy, destination provider's > > PS, and UA2. That's 12 in all. > > > While it is possible that many entities have session policies, a more > realistic case is one where there is a policy server in the local network > of the UAC and possibly another one in the local network of the UAS. > > > > The top security issues I have identified are: > > > > - By most common definitions of the term Policy, a Policy is a set of > > rules which must be obeyed; failing to obey them is a security failure. > > However the current document skirts the issue of policy enforcement > > almost completely, and any mention of such is as an optional component. > > When looking at this document from a service provider's point of view, > > enforcing the policy is definitely a security property. Of course most > > of this enforcement needs to happen on the media path. > > > Yes, most enforcement needs to happen on the media path. And in fact, this > is what is already happening. Enforcement mechanisms are used to enforce > policies but currently they have no means of notifying the UAs about > policies they are enforcing (apart from modifying SDP announcements). In > other words, the policy enforcement mechanisms already exist but what is > missing is a mechanism to signal the policies that are enforced to UAs. > Without such signaling, UAs have no way of finding out what the correct > behavior is to comply with all policies (apart from trial and error). This > piece is provided by this draft. > Section 4.1 discusses the overall architecture. > > > - A SIP User Agent can rarely be trusted (in a security sense) with > > anything, being deployed in the weakest part of the system - on the > > end device. However the document seems to assume (e.g. the Note in Sec. > > 4.4.2) that the UA will enforce the policy it receives from policy > > servers. > > No. Enforcement is done in the network. > > As mentioned above, enforcement mechanisms are outside of the scope of > this document and usually operate on the media path. This draft enables > the signaling of policies to the UA, which will allow the UA to comply > with them (if it wishes to do so). > > A compliant UA will follow the policies or refrain from setting up a > session. A non-compliant UA could ignore these policies but will then > encounter the enforcement mechanisms. > > > The document also emphasizes that the UA MUST fully disclose its > > policy, although a malicious UA has good reasons to lie. > > > Again, a malicious UA may lie or ignore policies. However, it will then > run into the policy enforcement mechanisms of the network. > > However, by signaling policies, a compliant UA can avoid errors caused by > enforcement mechanisms by setting up a compliant session in the first > place. > > > - Policies may be obtained from the local network (which may be > > trusted to some extent) or from basically anybody on the SIP path to > > the peer UA. The document mentions, correctly, that a malicious policy > > can easily disable the UA. So it is completely unrealistic to trust > > policies received from remote policy servers, even if they > "authenticate" > > (present a certificate someone sold them). > > > Not sure I understand. If a policy comes from an entity the user trusts > and this entity is authenticated, the user should be able to trust these > policies. > > It is important to remember that only entities in the SIP signaling path > can submit a session policy. If there is a completely untrusted entity in > the path, this entity can choose to do whatever it wants with the SIP > message. A much simpler way to disable a specific call than setting up a > bad policy would be to simply route the message to a malicious UAS. > > Also, a session policy only affects the current session. A malicious > policy server cannot generally "reconfigure" a UA. I therefore don't see > how session policies would pose an increased security risk. > > > - Policy is used for clearly security-sensitive tasks (disallowing > > sessions when you've run out of credit), but on the other hand, policy > > is optional - sessions can be started even if policy servers are > > unavailable. > > > No. Enforcement mechanisms will prevent this from happening. However, with > session policies a UA will know why the call is not going trough instead > of just getting silence from the other end. > > > - TLS is used as a security fix-all, even though the UA has neither > > direct contact nor trust with any but the first proxy. So in reality > > hop-by-hop TLS will be used to obtain policy servers' URIs. > > > The UA sets up a direct session with the policy server and can > authenticate this server. > > > Detailed Comments > > > > - Sec. 1: most of the discussion in the section is centered on proxies. > > This is a bit confusing because they are not the motivation for > > session-independent policies. > > > This section is introducing the fundamental problem: there is no mechanism > for an intermediary entity (i.e., the entity running a proxy) to signal > session policies to the UA. Session independent policies provide this > capability, even though they do not make direct use of a proxy. > > > - Sec. 3.1: I suggest to add as step (0): discovery of one or more > > policy servers. > > > Indeed. Will add this step. > > > - Sec. 3.2.1: the conditions to resubscribe to a policy, and the > > restriction on retrying, mean that it's difficult to deploy a new > > policy in a network where previously there was none. Compare, e.g., > > with a retry every 24 hours. > > > Good point. It would probably make sense ask a UA to retry at a very low > rate, e.g., once every 24 or 48 hours. That way, a new policy server would > be known to all UAs within 2 days. > > I'll add a statement to the draft. > > > - Sec. 3.2.2: there are things it's reasonable to accept from the > > local domain's policy server, but not from a remote proxy. Is there > > any definition (or advice) on which policy elements are applicable > where? > > > The policy dataset drafts provide guidelines on how to merge policies from > different servers. These rules can differ between elements and are well > specified in dataset drafts. Based on all the discussions around this > issue, I don't think we can draw a clear distinction on which elements can > reasonably come from which domains. > > > - Sec. 4: the use of policy to block out-of-credit users from creating > > media streams is puzzling. Are they still allowed to issue INVITE > requests? > > > In this case, the policy server would return this policy only when the UA > tries to establish a session to another user. The user may still be > allowed, e.g., to access his voicemail or a IVR system to recharge the > account. These sessions would through, i.e., they would be policed > differently. > > Session specific policies only apply to a single session, they do not > generally prohibit an action of the UA (e.g., the creation of INVITE > messages). > > > - Sec. 4.2, step #3: the Framework should clarify if policy changes > > can be trigerred by different session-related events, e.g. a new party > > joining a call. > > > The events that can change a policy are at the discretion of the policy > server administrator. A party joining a call is a possible event. > However, in this case, the conference bridge would probably directly re- > negotiate the session with users. > > > - Sec. 4.3.1: I don't understand how UA A can request a new policy > > from PS A (in the last 2 steps) after it has already committed to B > > regarding their actual parameters. What if PS A comes up with any > surprises? > > > The last two steps are necessary if PS A needs to see the answer since has > not yet seen it yet. Because the answer is based on the offer, there > should be no surprises and no need to return surprise policies here. > This step is needed, e.g., if the policy server wants to see or modify the > IP addresses contained in the answer to include a media intermediary. Of > course, PS A can always choose to terminate a session. > > > - Sec. 4.4.1, step (6): discloses => disclose. > > > Good catch. Thanks!! (I'm assuming this is 4.3.1 step (6)) > > > - Sec. 4.4.1 (paragraph describing caching of local domain's PS): how > > does the UA identify its local domain's PS? We cannot simply assume > > the first PS the UA becomes aware of is local - maybe there is no > > local PS at all. > > > Good point. I'll add a clarification to the draft. Essentially it is a > policy server provided by an outbound proxy that is in the path for all > requests. > > > - Sec. 4.4.2 (Policy-Id paragraph): is enforcement of the correct > > policy really dependent on retransmitted messages being routed over > > exactly the same path as the originals? Can't the UA influence this > routing? > > > A domain can have a load balancer that routes initial INVITE requests. > Since a retransmission of an INVITE after a 488 is a new INVITE request, > the first and second INVITE request could be forwarded to different > proxies with different policy servers. To avoid that a request keeps > bouncing between these proxies, a domain can use the token field to route > subsequent requests to the same proxy. > > > - Sec. 4.5.1: allowing the UA to continue normal processing when the > > PS cannot be contacted means that the UA is also free to not contact > > the PS at all (and pretend that the requests were lost) or to ignore > > the returned policy (and pretend that the responses were lost). > > > Yes. As mentioned above, if it deliberately ignores the policy server or > policies, it will have to deal with an enforcement mechanism. > > Again, session policies help a UA to do the right thing - they do not > enforce a policy. > > > - Sec. 4.5.2: why should the PS believe a policy it receives from a UA? > > What's there to prevent the UA from lying? > > > See above. > > Thanks! > > Volker > > > Scanned by Check Point Total Security Gateway. Email secured by Check Point _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Jan 4 00:55:57 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9D143A6A19; Sun, 4 Jan 2009 00:55:57 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E6A3A69FC; Sun, 4 Jan 2009 00:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.814 X-Spam-Level: X-Spam-Status: No, score=-5.814 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBNUHDA7pmf3; Sun, 4 Jan 2009 00:55:55 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 701543A69DD; Sun, 4 Jan 2009 00:55:55 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n048th0o008753; Sun, 4 Jan 2009 08:55:43 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KCX00B01V7LVJ00@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM); Sun, 04 Jan 2009 01:55:43 -0700 (MST) Received: from [10.0.0.5] ([206.124.31.184]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KCX00EV6VGUQR60@mail-amer.sun.com>; Sun, 04 Jan 2009 01:55:43 -0700 (MST) Date: Sun, 04 Jan 2009 01:55:11 -0700 From: Shawn M Emery In-reply-to: <493D6E18.7010701@sun.com> To: secdir@ietf.org Message-id: <4960796F.3030204@sun.com> MIME-version: 1.0 References: <493D6E18.7010701@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081125) Cc: draft-ietf-mediactrl-mixer-control-package@tools.ietf.org, mediactrl-chairs@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-mediactrl-mixer-control-package-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes a protocol set for managing media connection and conference mixers. Auditing elements are also specified in this ID which allows capability and server discovery. The security consideration section does exist and discusses potential attacks against the protocol if the messaging is not secure. Another DoS attack not discussed in the section could be from an attacker impersonating an MS by sending error conditions back to the AS. The section then continues with access control guidelines for responses, notifications, auditing, and rejection. This paragraph should also make clear that this is only useful for secure, confidential, and integrity protected channels. Do the authors believe that RTP should be mentioned in this section and a reference to securing these sessions? Editorial comment(s): Thanks for including the definitions in this ID and the examples in the relevant sections (and in a dedicated section), very helpful. s/containing a a /containing a/ 4.2.1.4.3.1. Priority assignment It seems that the default priority value of 100 is arbitrary. Why not make the default 0 (zero), which would be undefined, with the highest priority at 1 (one), etc.? This draft makes a normative reference to ietf-mediactrl-sip-control-framework, which is still an ID. Shawn. -- _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Jan 4 21:43:10 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C083A6A97; Sun, 4 Jan 2009 21:43:10 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5EA63A68B0; Sun, 4 Jan 2009 21:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.299 X-Spam-Level: X-Spam-Status: No, score=-107.299 tagged_above=-999 required=5 tests=[AWL=2.700, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyFoz5IyPhfo; Sun, 4 Jan 2009 21:43:07 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 639FC3A681C; Sun, 4 Jan 2009 21:43:07 -0800 (PST) Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sun, 4 Jan 2009 21:42:54 -0800 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) with Microsoft SMTP Server id 8.1.291.1; Sun, 4 Jan 2009 21:42:54 -0800 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32]) with mapi; Sun, 4 Jan 2009 21:44:12 -0800 From: Larry Zhu To: "jari.arkko@piuha.net" , "cpignata@cisco.com" Date: Sun, 4 Jan 2009 21:42:53 -0800 Thread-Topic: Review of draft-arkko-arp-iana-rules-05 Thread-Index: Aclu+HPlqXZg68fWTjWn/iwDs4d5Rg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "iesg@ietf.org" , "secdir@ietf.org" Subject: [secdir] Review of draft-arkko-arp-iana-rules-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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. Document: draft-arkko-arp-iana-rules-05 Title: IANA Allocation Guidelines for the Address Resolution Protocol (ARP) Overall, the document is clear and easy to read. I have the following comments. 1) The following text in the "acknowledgements" section fits better into the "introduction" section. The lack of any current rules has come up as new values were requested from IANA. <<>> When no rules exist, IANA consults the IESG for approval of the new values. The purpose of this specification is to establish the rules and allow IANA to operate based on the rules, without requiring confirmation from the IESG. In addition, the above text somewhat contradicts to the fact that the assignment of ar$op values does require IESG approval. Hence I would recommend to replace OLD: The purpose of this specification is to establish the rules and allow IANA to operate based on the rules, without requiring confirmation from the IESG. With NEW: The purpose of this specification is to establish the rules and allow IANA to manage number assignments based on these rules, to ensure consistent interpretations in different implementations. 2) This document does not seem to fit exactly with RFC5226. Given there is an existing registry at http://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml, I would recommend either spell exactly how to update it or how to create a new one to replace the existing one, and populate the new registry with the existing entries as "initial" assignments. I find no specific security issues with this document. --Larry Zhu _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Jan 4 22:55:57 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D1B3A6AC5; Sun, 4 Jan 2009 22:55:57 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7923C3A695E for ; Fri, 2 Jan 2009 16:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.657 X-Spam-Level: X-Spam-Status: No, score=-10.657 tagged_above=-999 required=5 tests=[AWL=-3.958, BAYES_00=-2.599, RCVD_IN_BSP_OTHER=-0.1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-254ZYtQPkH for ; Fri, 2 Jan 2009 16:22:52 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 22D1A3A6953 for ; Fri, 2 Jan 2009 16:22:51 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n030Mbo8009354 for ; Fri, 2 Jan 2009 19:22:37 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n030MYmT009346 for ; Fri, 2 Jan 2009 19:22:34 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n030MR9g022120 for ; Fri, 2 Jan 2009 19:22:27 -0500 (EST) X-ASG-Whitelist: Barracuda Reputation Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 14A2C118B0B2 for ; Fri, 2 Jan 2009 19:22:26 -0500 (EST) Received: (qmail 73863 invoked from network); 3 Jan 2009 00:22:26 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 3 Jan 2009 00:22:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=k0812; i=johnl@user.iecc.com; bh=iaLcI5XmobxZqCSz6xGLsSWSAYkDBcZVbfLKZo669/U=; b=iKsdSmAyGR6c0j/lflKCsM0H7MRJYhW7eTrlTjc6ek782K1jpYGHzwZoV6hMykjngXP6F6XPTTR9MGG5segOeYfqxnGVtT5kMDPOFVM7FQakqqcrgURHG7OLcjZtdwz++i0Q0rRKi682FIyaQYu+2+oF/ffOwOvMO8XedlgDivU= Date: Fri, 2 Jan 2009 19:22:25 -0500 (EST) From: John R Levine To: Eric Rescorla In-Reply-To: <20090102200649.1FF4750822@romeo.rtfm.com> Message-ID: References: <20090102200649.1FF4750822@romeo.rtfm.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Sun, 04 Jan 2009 22:55:55 -0800 Cc: ietf@ietf.org, draft-ietf-dkim-ssp@tools.ietf.org, dkim@ietf.org, secdir@mit.edu, iesg@ietf.org Subject: Re: [secdir] Review of draft-ietf-dkim-ssp-08 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org > This document (hereafter called ADSP) allows the domain to advertise > its signing policy, thus allowing recipients to distinguish these > (and some other) cases. ADSP is a very, very narow design, that attempts to deal with only a single threat: exact forgery of an address on the From: line. There's a lot of other threats, arguably more important to address, but ADSP doesn't deal with them. > One general question: I see you're using TXT here. I know this > is a hot button for the DNS people. ADSP records are in the same _domainkey subtree as DKIM TXT records, so they should be as OK. > TECHNICAL > S 3. > > Hosts can look up the ADSP information of the domain(s) specified by > the Author Address(es) as described in Section 4.3. If a message has > multiple Author Addresses the ADSP lookups SHOULD be performed > independently on each address. This document does not address the > process a host might use to combine the lookup results. > > I'd like to see some security analysis of why this is OK. Naively, > it seems like one might be able to get around ADSP using this feature. Since we don't have any real experience with signed mail with multi address From: lines, any analysis would just be a guess, and not a very well informed one at that, so we figured it was better not to. Consider these From: lines: From: security@paypal.com, crook@phishpharm.biz ; ADSP fail, pass From: security@paypalsecurity.com, crook@phishpharm.biz ; ADSP unknown, pass From: friend@knowndomain.com, someone@somewhere.com; ADSP pass, unknown The first and second cases are probably bad guys, but the third could be someone you know and trust and his friend who you don't happen to know yet. We don't see any way to tell these apart without consulting external reputation databases, which are way outside the scope of ADSP and DKIM. > S 4.3. > Check Domain Scope: An ADSP checker implementation MUST determine > whether a given Author Domain is within scope for ADSP. Given the > background in Section 3.1 the checker MUST decide which degree of > approximation is acceptable. The checker MUST return an > appropriate error result for Author Domains that are outside the > scope of ADSP. > > I don't really undersand how the second (and maybe third) MUSTs are > operationalizable. How would I not "decide"? You're right, the second isn't really anything you can do. The third says that if, e.g., the domain doesn't exist at all, it has to return an error. > S 6.2. > An attacker might attack the DNS infrastructure in an attempt to > impersonate ADSP records to influence a receiver's decision on how it > will handle mail. However, such an attacker is more likely to attack > at a higher level, e.g., redirecting A or MX record lookups in order > to capture traffic that was legitimately intended for the target > domain. These DNS security issues are addressed by DNSSEC [RFC4033]. > > I don't understand why an attacker is more likely to redirect A or MX. > These are different attacks with different objectives. If I'm doing > phishing, then forgery seems more useful to the attacker. Why phish if you can hijack the real traffic to the target? > S 2.7. > > For example, if a message has a Valid Signature, with the DKIM- > Signature field containing "i=a@domain.example", then domain.example > is asserting that it takes responsibility for the message. If the > message's From: field contains the address "b@domain.example" and an > ADSP query produces a "dkim=all" or "dkim=discardable" result, that > would mean that the message does not have a valid Author Signature. > Even though the message is signed by the same domain, it fails to > satisfy ADSP. > > I think this example might benefit from a bit more explanation. > As I understand it, this signature is invalid per DKIM It's valid DKIM, but ADSP has additional semantics that are incompatible with common auditing usage of the DKIM i= field. The -09 draft will have a note pointing this out with a workaround. For an example of usage of i=, see the DKIM signature on this message. > Note: The results from DNS queries that are intended to validate a > domain name unavoidably approximate the set of Author Domains that > can appear in legitimate email. For example, a DNS A record could > belong to a device that does not even have an email > implementation. It is up to the checker to decide what degree of > approximation is acceptable. > > I don't really understand this graf. Can you rephrase? Many people have pointed out that in practice you can trivially circumvent ADSP by using lookalike domains, e.g. paypalsecurity.com or www.paypal.com. One way to address this would be to check to see if the domain is in use at all for e-mail, since the number of domains in use for mail is a tiny fraction of all of the names in the DNS. Unfortunately, due to the ancient SMTP rule that use an A record, and now also AAAA, for fallback if a domain has no MX record, any name with an A or AAAA record can potentially be used for mail. There's a range of more or less aggressive heuristics to see if a name with an A/AAAA record really is used for mail (e.g., try to connect to port 25 and see if you get a hard rejection), but there's no agreement on which if any an ADSP client should use. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Cambridge UK "I dropped the toothpaste", said Tom, crestfallenly. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Jan 4 22:55:57 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1406828C13E; Sun, 4 Jan 2009 22:55:57 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B8E728C0EC for ; Fri, 2 Jan 2009 17:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.61 X-Spam-Level: X-Spam-Status: No, score=-14.61 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAO93G0IO0lM for ; Fri, 2 Jan 2009 17:25:38 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 17E323A6A50 for ; Fri, 2 Jan 2009 17:25:38 -0800 (PST) Received: (qmail 15291 invoked from network); 3 Jan 2009 01:25:23 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 3 Jan 2009 01:25:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=k0812; i=johnl@user.iecc.com; bh=lnB8hLHkzQaybICvzpFiOoJ0saCtWRziVwn32hShcn0=; b=Astz8tNV3fFOLlnS6oIjhwhECaS5MOsJHxD01sH5T0xo2KdhWfbWSERXmhfFuqRM4Zz+D+OpA3UAxCSxfAtbsuKMC8xHXvolKOqJg6mXl3vYrFwDTKejl3Zr5hSRfWlatnJoM/fUeSiioSUyvH9fnL+4G3EYanZxF4i38fRh8aw= Date: Fri, 2 Jan 2009 20:25:20 -0500 (EST) From: John L To: Eric Rescorla In-Reply-To: <20090103010826.7D19150822@romeo.rtfm.com> Message-ID: References: <20090102200649.1FF4750822@romeo.rtfm.com> <20090103010826.7D19150822@romeo.rtfm.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 04 Jan 2009 22:55:55 -0800 Cc: draft-ietf-dkim-ssp@tools.ietf.org, ietf@ietf.org, iesg@ietf.org, dkim@ietf.org, secdir@ietf.org Subject: Re: [secdir] [taugh.com-standards] Re: Review of draft-ietf-dkim-ssp-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org >> We don't see any way to tell these apart without consulting external >> reputation databases, which are way outside the scope of ADSP and DKIM. > > OK, but I don't see how it helps to put the job of making this > judgement on the implementor, who probably has less expertise > and time to think about this than the DKIM WG has Honest, we thought about it and have no advice to give. Different mail users will have different tradeoffs between losing real mail and accepting bogus mail, and we really have no experience at all with signed mail with multi-address From: other than contrived examples. > especially as there is at least one policy that more or less > obviates ADSP (treat all addresses as having the weakest policy > advertised by any of them). That's certainly one policy you might use if your tradeoff avoids losing real mail. >>> These are different attacks with different objectives. If I'm doing >>> phishing, then forgery seems more useful to the attacker. >> >> Why phish if you can hijack the real traffic to the target? > > Because the legitimate URL the user is dereferencing uses TLS? True, although we were thinking of mail. Again, lacking any experience at all here we're just guessing. >> Many people have pointed out that in practice you can trivially circumvent >> ADSP by using lookalike domains, e.g. paypalsecurity.com or >> www.paypal.com. One way to address this would be to check to see if the >> domain is in use at all for e-mail, since the number of domains in use for >> mail is a tiny fraction of all of the names in the DNS. Unfortunately, >> due to the ancient SMTP rule that use an A record, and now also AAAA, for >> fallback if a domain has no MX record, any name with an A or AAAA record >> can potentially be used for mail. There's a range of more or less >> aggressive heuristics to see if a name with an A/AAAA record really is >> used for mail (e.g., try to connect to port 25 and see if you get a hard >> rejection), but there's no agreement on which if any an ADSP client should >> use. > > I would suggest that some explanation like this should go in the document. My recollection is that there was less consensus than one might hope on that particular explanation. R's, John _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Jan 4 22:55:57 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2492428C144; Sun, 4 Jan 2009 22:55:57 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A77A63A6804; Fri, 2 Jan 2009 18:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0UOkMgl01ng; Fri, 2 Jan 2009 18:16:35 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id DDEDA3A68C9; Fri, 2 Jan 2009 18:16:34 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01N3TVN3O1Q800PAIQ@mauve.mrochek.com>; Fri, 2 Jan 2009 18:16:14 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01N3RVK8JHOW00007A@mauve.mrochek.com>; Fri, 02 Jan 2009 18:16:09 -0800 (PST) Date: Fri, 02 Jan 2009 17:43:56 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 02 Jan 2009 20:25:20 -0500 (EST)" To: John L Message-id: <01N3TVN1J1U800007A@mauve.mrochek.com> MIME-version: 1.0 References: <20090102200649.1FF4750822@romeo.rtfm.com> <20090103010826.7D19150822@romeo.rtfm.com> X-Mailman-Approved-At: Sun, 04 Jan 2009 22:55:55 -0800 Cc: secdir@ietf.org, draft-ietf-dkim-ssp@tools.ietf.org, iesg@ietf.org, dkim@ietf.org, ietf@ietf.org Subject: Re: [secdir] [taugh.com-standards] Re: Review of draft-ietf-dkim-ssp-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org > >> We don't see any way to tell these apart without consulting external > >> reputation databases, which are way outside the scope of ADSP and DKIM. > > > > OK, but I don't see how it helps to put the job of making this > > judgement on the implementor, who probably has less expertise > > and time to think about this than the DKIM WG has > Honest, we thought about it and have no advice to give. Different > mail users will have different tradeoffs between losing real mail and > accepting bogus mail, and we really have no experience at all with > signed mail with multi-address From: other than contrived examples. As a practical matter the issue of how multiple From: fields are handled has become largely moot, in my experience at least. The mail client I use is one that supports generation of this construct, but the last half-dozen times I've tried it something has gone wrong every time - the receiving client mishandled it, the message was blocked by overly aggressive filters, etc. etc. After the last times, when a message to an IETF list was silently dropped and i was forced to ask one of the other recipients to resend it (having neglected to keep a copy myself), I've given up on this construct, even though I find it's semantics to be valuable. As always, the plural of anecdote is not data, so there may be places I'm unaware of where this construct is in use and doesn't cause any problems. But given the mainstream nature of the various agents I've seen fail to handle multivalued From: fields sensibly, my suspicion is there aren't very many such places. Now, I suppose an argument could be made that this points to the need for ADSP to specify semantics for handling multivalued From: fields in order not to break multivalued From: even more. But that argument only makes sense if we believe that there's a single semantic we can assign that is broadly applicable, and I don't think anyone believes that. And given a choice between ADSP and not causing some additional breakage to a mostly broken minor capability, I think the right choice is pretty clear. Ned _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Jan 4 22:55:57 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9F828C149; Sun, 4 Jan 2009 22:55:57 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29BD73A67B1; Sat, 3 Jan 2009 12:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bb1zf7oSz6l; Sat, 3 Jan 2009 12:03:03 -0800 (PST) Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 9F2B33A6767; Sat, 3 Jan 2009 12:03:02 -0800 (PST) Received: from [192.168.0.4] (adsl-68-122-33-158.dsl.pltn13.pacbell.net [68.122.33.158]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n03K2fui001885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Jan 2009 12:02:43 -0800 Message-ID: <495FC460.4030700@dcrocker.net> Date: Sat, 03 Jan 2009 12:02:40 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 References: <20090102200649.1FF4750822@romeo.rtfm.com> <20090103010826.7D19150822@romeo.rtfm.com> <01N3TVN1J1U800007A@mauve.mrochek.com> In-Reply-To: <01N3TVN1J1U800007A@mauve.mrochek.com> X-Virus-Scanned: ClamAV 0.92/8833/Sat Jan 3 09:36:37 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 03 Jan 2009 12:02:44 -0800 (PST) X-Mailman-Approved-At: Sun, 04 Jan 2009 22:55:55 -0800 Cc: ietf@ietf.org, draft-ietf-dkim-ssp@tools.ietf.org, dkim@ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] [taugh.com-standards] Re: Review of draft-ietf-dkim-ssp-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org ned+ietf@mauve.mrochek.com wrote: > As always, the plural of anecdote is not data, so there may be places I'm > unaware of where this construct is in use and doesn't cause any problems. ... > Now, I suppose an argument could be made that this points to the need for > ADSP to specify semantics for handling multivalued From: fields in order not > to break multivalued From: even more. But that argument only makes sense if > we believe that there's a single semantic we can assign that is broadly > applicable, and I don't think anyone believes that. This thread's taking place on the main IETF list, so it's probably worth noting some deeper issues that your observations raise: 1. Should an adjunct protocol modify core semantics of the primary protocol, rather than add semantics to it? If yes, when yes and when no? The issue, in this particular case, is a challenge between waiting to deprecate a feature in one protocol, versus potentially introducing interoperability instabilities by failing to support that feature -- that is, effectively deprecating it -- within a follow-on, adjunct protocol. Cavalierly modifying core semantics creates incompatible variants, and distributes their definition into unlikely places. Since the likely answer to these sort of experience-generated questions is usually "yes, but only sometimes", the real questions are when and how? 2. If a protocol has a features that remain unexercised for a long time, when is it appropriate to deprecate it? To make the exercise a bit more challenging, take note of situations in which the protocol is modeling well-established behavior from elsewhere in the world, but which nonetheless is not a behavior that has (yet) shown up in use of the protocol. RFC5322 models the world of memos. Paper messages and other human communications can be, and sometimes are, "from" multiple authors. That's not just theory; it's real-world practice. If the Internet's email format drops that construct from the only place in the message that provides a structured designation of authorship, how are legitimate occurrences of multiple authors to be indicated? What we have here is a case of a protocol's supplying functional variety that models the real-world, but which has remained virtually unused for 30 years. One can easily argue that the deeper "problem" is that Internet Mail remains a limited functionality that will yet expand to fill the roles we know -- from the paper world -- are yet needed. But even if we restrict the historical review to the start of the mass market Internet (1994) we are still looking at 15 years of not expanding into that available functionality. Failure to use a feature for that long makes a strong case for deprecating it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Jan 5 09:01:40 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370773A6942; Mon, 5 Jan 2009 09:01:40 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35BE23A68A2 for ; Mon, 5 Jan 2009 09:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awpeGcEKe1g7 for ; Mon, 5 Jan 2009 09:01:38 -0800 (PST) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 8344B3A6887 for ; Mon, 5 Jan 2009 09:01:38 -0800 (PST) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id zs3k1a00116AWCUA9t1TNx; Mon, 05 Jan 2009 17:01:27 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id zt1Q1a00i0UQ6dC8St1R2w; Mon, 05 Jan 2009 17:01:26 +0000 From: "David Harrington" To: , Date: Mon, 5 Jan 2009 12:01:23 -0500 Message-ID: <00eb01c96f57$3e7172b0$6905a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AclvVz0aZ6PyIeBkQjWxg7plkuT15g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: "'Benoit Claise \(bclaise\)'" , ippm-chairs@ietf.org, acmorton@att.com Subject: [secdir] secdir review of draft-ietf-ippm-delay-var-as-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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. Document: draft-ietf-ippm-delay-var-as-01 Title: Packet delay Variation Applicability Statement I found no new security issues relevant to this document. The document reads like a research paper, rather than IETF document, but the nature of the discussion seems to call for this. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Jan 6 09:07:28 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78DC43A6807; Tue, 6 Jan 2009 09:07:28 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D553A6807; Tue, 6 Jan 2009 09:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWEI8IyTAJ4M; Tue, 6 Jan 2009 09:07:26 -0800 (PST) Received: from leela.webpack.hosteurope.de (leela.webpack.hosteurope.de [217.115.142.65]) by core3.amsl.com (Postfix) with ESMTP id 059F63A63D2; Tue, 6 Jan 2009 09:07:25 -0800 (PST) Received: from 78-86-27-62.zone2.bethere.co.uk ([78.86.27.62] helo=[192.168.1.64]); authenticated by leela.webpack.hosteurope.de running ExIM using esmtpa id 1LKFOU-0006fX-ER; Tue, 06 Jan 2009 18:07:06 +0100 Message-ID: <496381C1.8020609@gondrom.org> Date: Tue, 06 Jan 2009 17:07:29 +0100 From: Tobias Gondrom User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: secdir@ietf.org X-bounce-key: webpack.hosteurope.de; tobias.gondrom@gondrom.org; 1231261633; acf652f7; Cc: cyrus@daboo.name, timmartin@alumni.cmu.edu, lisa@osafoundation.org, iesg@ietf.org Subject: [secdir] secdir review of draft-ietf-sieve-managesieve-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGly ZWN0b3JhdGUncyBvbmdvaW5nCmVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJl aW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlCmNvbW1lbnRzIHdlcmUgd3JpdHRlbiBw cmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhCmRpcmVjdG9ycy4g IERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVu dHMganVzdApsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuCgpUaGUgZHJhZnQgaGFz IGJlZW4gdXBkYXRlZCB0byB2ZXJzaW9uIDA2IG9uIEphbi0xIDIwMDksIHNvIHRoaXMgcmV2aWV3 CmlzIG9uIHRoaXMgY3VycmVudCAoYW5kIG1vc3QgcmVjZW50KSB2ZXJzaW9uLgoKVGhpcyBkb2N1 bWVudCBjb250YWlucyBhIHNlY3VyaXR5IHNlbnNpdGl2ZSBwcm90b2NvbC4KSSBzdWdnZXN0IHRo ZSBmb2xsb3dpbmcgY29tbWVudHMgYmUgZGlzY3Vzc2VkIGJlZm9yZSBwdWJsaWNhdGlvbi4KCgpD T01NRU5UUzoKMS4gU2VjdGlvbiAxLjMKcy9UaGlzIGEgbGluZSBvcmllbnRlZCBwcm90b2NvbCBt dWNoIGxpa2UgW0lNQVBdIG9yIFtBQ0FQXS4vVGhpcyBpcyBhCmxpbmUgb3JpZW50ZWQgcHJvdG9j b2wgbXVjaCBsaWtlIFtJTUFQXSBvciBbQUNBUF0uCgoyLiBUaGUgZGVzaWduIGRlY2lzaW9uIHRv IHVzZSBDUkxGIGFzIGEgc2VwYXJhdG9yIGZvciBhIHByb3RvY29sIHNlZW1zIGEKYml0IG9kZCwg ZGlmZmVyZW50IE9TIG1pZ2h0IHVzZSBkaWZmZXJlbnQgbWVhbnMgdG8gc2lnbmFsIGEgQ1JMRi4g SVMKdGhlcmUgcG90ZW50aWFsIGZvciBtaXNpbnRlcnByZXRhdGlvbj8KCjMuIHNlY3Rpb24gMS4z OgpJZiBhIHNlcnZlciBoYXMgYW4gaW5hY3Rpdml0eSB0aW1lb3V0IHJlc3VsdGluZyBpbiBjbGll bnQgYXV0b2xvZ291dCBpdApNVVNUIGJlIG5vIGxlc3MgdGhhbiAzMCBtaW51dGVzIGFmdGVyIHN1 Y2Nlc3NmdWwgYXV0aGVudGljYXRpb24uClFVRVNUSU9OOiBXaHkgMzAgbWludXRlcz8/Pz8KCjQu IFRSQU5TSVRJT04tTkVFREVECnRoaXMgY29tbWFuZCBzZWVtcyB0byBiZSB0aGVyZSBhcyBhIGtp bmQgb2YgYnlwYXNzLCB0aGUgcmVhc29uIHdoeSB0aGUKY2xpZW50IHNob3VsZCBiZSBpbmZvcm1l ZCBvZiB0aGUgdmFsaWRpdHkgb2YgYSB1c2VybmFtZSBpbiB0aGlzIGNhc2UgaXMKbm90IGNsZWFy IHRvIG1lPyBDb3VsZCB0aGUgY2xpZW50IG5vdCBqdXN0IGJlIHJldHVybmVkIGEgZGVueSBhbmQg aXQgaGFzCnRvIHRyeSB0aGUgYWx0ZXJuYXRlIGF1dGhlbnRpY2F0aW9uPwoKNS4gU2VjdGlvbiAx Ljg6ClF1ZXN0aW9uIGZvciBteSB1bmRlcnN0YW5kaW5nIGFib3V0OgrigJxTVEFSVFRMUyAtIElm IFRMUyBbVExTXSBpcyBzdXBwb3J0ZWQgYnkgdGhpcyBpbXBsZW1lbnRhdGlvbi4gIEJlZm9yZQog ICBhZHZlcnRpc2luZyB0aGlzIGNhcGFiaWxpdHkgYSBzZXJ2ZXIgTVVTVCB2ZXJpZnkgdG8gdGhl IGJlc3Qgb2YgaXRzCiAgIGFiaWxpdHkgdGhhdCBUTFMgY2FuIGJlIHN1Y2Nlc3NmdWxseSBuZWdv dGlhdGVkIGJ5IGEgY2xpZW50IHdpdGgKICAgY29tbW9uIGNpcGhlciBzdWl0ZXMuICBTcGVjaWZp Y2FsbHksIGEgc2VydmVyIHNob3VsZCB2ZXJpZnkgdGhhdCBhCiAgIHNlcnZlciBjZXJ0aWZpY2F0 ZSBoYXMgYmVlbiBpbnN0YWxsZWQgYW5kIHRoYXQgdGhlIFRMUyBzdWJzeXN0ZW0gaGFzCiAgIHN1 Y2Nlc3NmdWxseSBpbml0aWFsaXplZC4gIFRoaXMgY2FwYWJpbGl0eSBTSE9VTEQgTk9UIGJlIGFk dmVydGlzZWQKICAgb25jZSBTVEFSVFRMUyBvciBBVVRIRU5USUNBVEUgY29tbWFuZCBjb21wbGV0 ZXMgc3VjY2Vzc2Z1bGx5LiAgQ2xpZW50CiAgIGFuZCBzZXJ2ZXIgaW1wbGVtZW50YXRpb25zIE1V U1QgaW1wbGVtZW50IHRoZSBTVEFSVFRMUyBleHRlbnNpb24u4oCdCgpBdCB0aGUgYmVnaW5uaW5n IG9mIHRoZSBwYXJhZ3JhcGggaXQgaXMgc3RhdGVkIOKAnGlmIFRMUyBpcyBzdXBwb3J0ZWTigJ0g YW5kCmF0IHRoZSBlbmQgb2YgdGhlIHBhcmFncmFwaCBpdCBpcyBzdGF0ZWQgdGhhdCDigJxjbGll bnQgYW5kIHNlcnZlcgppbXBsZW1lbnRhdGlvbnMgTVVTVCBpbXBsZW1lbnQgLi4u4oCdLiBTbyBp cyB0aGVyZSBhIGNhc2Ugd2hlcmUgaXQgaXMgbm90CmltcGxlbWVudGVkL3N1cHBvcnRlZD8KCjYu IHRoZSBWRVJTSU9OIGNhcGFiaWxpdHk6CuKAnExhY2sgb2YgdGhpcyBjYXBhYmlsaXR5IG1lYW5z IHRoYXQgdGhlIHNlcnZlciBwcmVkYXRlcyB0aGlzCnNwZWNpZmljYXRpb24gYW5kIHRodXMgZG9l c24ndCBzdXBwb3J0IHRoZSBmb2xsb3dpbmcgY29tbWFuZHM6ClJFTkFNRVNDUklQVCwgQ0hFQ0tT Q1JJUFQgYW5kIE5PT1Au4oCdIHRoZSBmaXJzdCBwYXJ0IG9mIHRoZSBzZW50ZW5jZSBpcwpvaywg YnV0IEkgc2hvdWxkIG5vdCBkZWZpbmUgd2hpY2ggZnVuY3Rpb25zIGFyZSBub3Qgc3VwcG9ydGVk IGZvciBhCnByb3RvY29sIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoaXMgc3RhbmRhcmQgKHdp dGhvdXQgdGhlIFZFUlNJT04KY29tbWFuZCkuIEltcGxlbWVudGF0aW9ucyBvdXRzaWRlIGNvdWxk IGhhdmUgYW55IGJlaGF2aW91cyB3aGljaCBzaG91bGQKbm90IGJlIGd1ZXNzZWQgKGFsdGhvdWdo IEkgYXNzdW1lIHRoZXJlIGlzIG9uZSB0ZXN0IGltcGxlbWVudGF0aW9uIGJ5CnRoZSBhdXRob3Jz IG9mIHRoZSBkcmFmdCB3aGljaCBiZWhhdmVzIGFzIGRlc2NyaWJlZC4uLikKQXMgaXQgY2xlYXJs eSBzdGF0ZXMgaW4gdGhlIGRyYWZ0OiDigJxBIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBNVVNUIHJl dHVybgpTSUVWRSwgSU1QTEVNRU5UQVRJT04gYW5kIFZFUlNJT04gY2FwYWJpbGl0aWVzLuKAnQoK Ny4gYW5kIGxhc3QgYnV0IG5vdCBsZWFzdCBpbiBzZWN0aW9uIDI6CuKAnFByaW9yIHRvIHN1Y2Nl c3NmdWwgYXV0aGVudGljYXRpb24gb25seSB0aGUgQVVUSEVOVElDQVRFLCBDQVBBQklMSVRZLApT VEFSVFRMUywgTE9HT1VUIGFuZCBOT09QIOKAnApRVUVTVElPTjogV2h5IGlzIE5PT1AgYXZhaWxh YmxlIHVuYXV0aGVudGljYXRlZD8gVGhpcyBzZWVtcyBsaWtlIGEKcG90ZW50aWFsIHVubmVjZXNz YXJ5IERvUyB2dWxuZXJhYmlsaXR5PwpRVUVTVElPTjogV2h5IGlzIExPR09VVCBhdmFpbGFibGUg dW5hdXRoZW50aWNhdGVkPwoKQmVzdCByZWdhcmRzLCBUb2JpYXMKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnNlY2RpciBtYWlsaW5nIGxpc3QKc2VjZGly QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2VjZGlyCg== From secdir-bounces@ietf.org Tue Jan 6 14:13:54 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF4763A69D2; Tue, 6 Jan 2009 14:13:54 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B493A3A69B1; Tue, 6 Jan 2009 14:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.028 X-Spam-Level: X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXtqxiFrLMJm; Tue, 6 Jan 2009 14:13:52 -0800 (PST) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id AEE923A67AC; Tue, 6 Jan 2009 14:13:52 -0800 (PST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n06MDWtl022362; Tue, 6 Jan 2009 17:13:32 -0500 (EST) 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 n06MDTo1009182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Jan 2009 17:13:31 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id n06MDThB002402; Tue, 6 Jan 2009 17:13:29 -0500 (EST) To: secdir@ietf.org, iesg@ietf.org, jouni@gmail.com, ulf.s.nilsson@teliasonera.com From: Tom Yu Date: Tue, 06 Jan 2009 17:13:28 -0500 Message-ID: Lines: 29 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 Subject: [secdir] secdir review of draft-korhonen-mip4-service-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org This document seems largely parallel to RFC 5149. (Which, incidentally, does not appear to have come up for secdir review, at least according to my mail archives.) The Security Considerations section appears to adequately describe considerations for the confidentiality protection for the service identifier. There may be denial of service vulnerabilities due to the requirements that the parties terminate an existing binding upon experiencing an authorization failure of a registration attempt that requests a change of service selection. An attacker capable of forging a registration request selecting a service for which the purported user lacks authorization could maliciously terminate an existing binding. If the request is authenticated (with a sufficiently strong mechanism) prior to the processing of the service selection, this is not a problem. I did not extensively research whether any current IPv4 Mobility authentication mechanisms are sufficiently strong to thwart this sort of attack, though I expect that at least some of the mechanisms are sufficiently strong. It would be nice to have some additional text emphasizing that the sort of authorization process that may result in the home agent's termination of the binding should only occur after the home agent successfully authenticates the content of the request. I think it is not a strong requirement to include such text, because a creator of a quality implementation could probably infer the need for this behavior from existing text in the document. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Jan 7 06:48:54 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F6E3A694D; Wed, 7 Jan 2009 06:48:54 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D26F3A6921; Wed, 7 Jan 2009 06:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZl+sNPPctGN; Wed, 7 Jan 2009 06:41:37 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 64CD53A6858; Wed, 7 Jan 2009 06:41:37 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so3499008yxg.49 for ; Wed, 07 Jan 2009 06:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=oE7oZyHT2HTL7VFoNJFf5YF0BDV7ZBNPXyLEhqXes2k=; b=CvwMEQEGLZNA48+eRBiDoLCytQjuKEbcnqXxNMs4JI4HJcP8pkEmOmrSqxPZdS5XoI eFvuqIkVqCBQEqxXYqKn9waBKW7jjtCbKCTu5ivbB3uLMYNv6CIc3yBk2pmq3c36O1oK 89v7ohv/KDbnko2wFfb9UPkD5yMrmPsCyosKo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=ICwW5ygclCXRLIu51HNGvVrH3ig1Pt1Z7UX/PN+RWugJaB6ZY2yZQwBJdx1Y3kjQ4n CVILvlXkFGPdi6C91vVHs22zaTwyk5bROzuQ8ODf2TZ/Gg0aqp+wVIDnZxhW+Wkc8NDk Mf5hDdzLEhZJcDiBdtFptRftbiJNfU5b+Q8E8= Received: by 10.142.177.5 with SMTP id z5mr9678513wfe.89.1231339283433; Wed, 07 Jan 2009 06:41:23 -0800 (PST) Received: by 10.143.42.15 with HTTP; Wed, 7 Jan 2009 06:41:23 -0800 (PST) Message-ID: <29d3c4cb0901070641g42293970pb7fbb94580d9ecad@mail.gmail.com> Date: Wed, 7 Jan 2009 15:41:23 +0100 From: "Alexey Melnikov" To: "Tobias Gondrom" In-Reply-To: <496381C1.8020609@gondrom.org> MIME-Version: 1.0 References: <496381C1.8020609@gondrom.org> X-Google-Sender-Auth: 70e97333a03efa0a Cc: cyrus@daboo.name, timmartin@alumni.cmu.edu, lisa@osafoundation.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-sieve-managesieve-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0713553273==" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org --===============0713553273== Content-Type: multipart/alternative; boundary="----=_Part_312249_22460334.1231339283430" ------=_Part_312249_22460334.1231339283430 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Tobias, Thank you for you review! My comments are below: On Tue, Jan 6, 2009 at 5:07 PM, Tobias Gondrom 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. > > The draft has been updated to version 06 on Jan-1 2009, so this review > is on this current (and most recent) version. > > This document contains a security sensitive protocol. > I suggest the following comments be discussed before publication. > > > COMMENTS: > 1. Section 1.3 > s/This a line oriented protocol much like [IMAP] or [ACAP]./This is a > line oriented protocol much like [IMAP] or [ACAP]. Fixed, thanks. > 2. The design decision to use CRLF as a separator for a protocol seems a > bit odd, different OS might use different means to signal a CRLF. It is not odd, it is very common in text based protocols, especially email related (just to name some: IMAP, POP, SMTP) > IS there potential for misinterpretation? No. CRLF is always a 2 byte sequence. Neither bare CRs, nor bare LFs are allowed as end of command/response delimiters. > 3. section 1.3: > If a server has an inactivity timeout resulting in client autologout it > MUST be no less than 30 minutes after successful authentication. > QUESTION: Why 30 minutes???? 30 minutes is used by IMAP. The value is somewhat arbitrary, but it is in the document in order to improve interoperability: a client that uses long lived connections will have to issue a command before timeout is over (or deal with the server disconnecting the client). > > > 4. TRANSITION-NEEDED > this command seems to be there as a kind of bypass, the reason why the > client should be informed of the validity of a username in this case is > not clear to me? Could the client not just be returned a deny and it has > to try the alternate authentication? Handling of this response code in the client might be different from the standard handling of a failed authentication. Thus the response code. When the client sees the TRANSITION-NEEDED response code, it can try PLAIN right away. But if it doesn't, it might end up unnecessary trying other SASL mechanisms that would fail in the same way. But yes, there are security implications of using this response code. Not every server developer would chose to implement it. > 5. Section 1.8: > Question for my understanding about: > "STARTTLS - If TLS [TLS] is supported by this implementation. Before > advertising this capability a server MUST verify to the best of its > ability that TLS can be successfully negotiated by a client with > common cipher suites. Specifically, a server should verify that a > server certificate has been installed and that the TLS subsystem has > successfully initialized. This capability SHOULD NOT be advertised > once STARTTLS or AUTHENTICATE command completes successfully. Client > and server implementations MUST implement the STARTTLS extension." > > At the beginning of the paragraph it is stated "if TLS is supported" and > at the end of the paragraph it is stated that "client and server > implementations MUST implement ...". So is there a case where it is not > implemented/supported? No. The requirement to require TLS came later on, so in some places the text is not fully updated. ------=_Part_312249_22460334.1231339283430 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Tobias,
Thank you for you review! My comments are below:
 
On Tue, Jan 6, 2009 at 5:07 PM, Tobias Gondrom <tobias.gondrom@gondrom.org> 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.

The draft has been updated to version 06 on Jan-1 2009, so this review
is on this current (and most recent) version.

This document contains a security sensitive protocol.
I suggest the following comments be discussed before publication.


COMMENTS:
1. Section 1.3
s/This a line oriented protocol much like [IMAP] or [ACAP]./This is a
line oriented protocol much like [IMAP] or [ACAP].
Fixed, thanks.
2. The design decision to use CRLF as a separator for a protocol seems a
bit odd, different OS might use different means to signal a CRLF.
It is not odd, it is very common in text based protocols, especially email related (just to name some: IMAP, POP, SMTP)
IS there potential for misinterpretation?
No. CRLF is always a 2 byte sequence. Neither bare CRs, nor bare LFs are allowed as end of command/response delimiters.
3. section 1.3:
If a server has an inactivity timeout resulting in client autologout it
MUST be no less than 30 minutes after successful authentication.
QUESTION: Why 30 minutes????
30 minutes is used by IMAP. The value is somewhat arbitrary, but it is in the document in order to improve interoperability: a client that uses long lived connections will have to issue a command before timeout is over (or deal with the server disconnecting the client).


4. TRANSITION-NEEDED
this command seems to be there as a kind of bypass, the reason why the
client should be informed of the validity of a username in this case is
not clear to me? Could the client not just be returned a deny and it has
to try the alternate authentication?
 
Handling of this response code in the client might be different from the standard handling of a failed authentication. Thus the response code.
 
When the client sees the TRANSITION-NEEDED response code, it can try PLAIN right away. But if it doesn't, it might end up unnecessary trying other SASL mechanisms that would fail in the same way.
 
But yes, there are security implications of using this response code. Not every server developer would chose to implement it.
 
5. Section 1.8:
Question for my understanding about:
"STARTTLS - If TLS [TLS] is supported by this implementation.  Before
  advertising this capability a server MUST verify to the best of its
  ability that TLS can be successfully negotiated by a client with
  common cipher suites.  Specifically, a server should verify that a
  server certificate has been installed and that the TLS subsystem has
  successfully initialized.  This capability SHOULD NOT be advertised
  once STARTTLS or AUTHENTICATE command completes successfully.  Client
  and server implementations MUST implement the STARTTLS extension."

At the beginning of the paragraph it is stated "if TLS is supported" and
at the end of the paragraph it is stated that "client and server
implementations MUST implement ...". So is there a case where it is not
implemented/supported?
No.
The requirement to require TLS came later on, so in some places the text is not fully updated.
------=_Part_312249_22460334.1231339283430-- --===============0713553273== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir --===============0713553273==-- From secdir-bounces@ietf.org Wed Jan 7 10:42:03 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140F128C14F; Wed, 7 Jan 2009 10:42:03 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 500613A6A86; Wed, 7 Jan 2009 10:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2o+xHes6c0I; Wed, 7 Jan 2009 10:42:01 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 494AD3A6932; Wed, 7 Jan 2009 10:42:00 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so9441989wfd.31 for ; Wed, 07 Jan 2009 10:41:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=RqTQzNSQ2k1ft9H2pECLJxyLxyQiWAaYyOPRzzf6I8Y=; b=DGnNQa6H7tyW/sUTngqgyVj2LSeNM96kyg0BdMbxCZjiIVOdn9jz4Li8DESPx5LDF3 IDs0T8hN5W6m+Ad0qNH7qqrxGrCFfm0PWrB5GYd9eH1A7NiTqIIxd2/7L9P2R6SRKRpU jALHM41TFTco85zrj4NAu18OI82H9wpT9cPy4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=wCP9A4YaLVt1h/3uslMLia+F9+SqjzAhjs7z7D3PbPuWBWvk7c6M3qScFWbBBtNKGi L7VtA0BvoREnbutiDNpRGrHK3C3jFk3vwJbGIT5u9pMKx+SrL49FQtxN7yFDBkDB4vmV TmSK3hK+2OJVhFaLxTHzU4mZIZGSgUJPPoK/g= Received: by 10.142.84.11 with SMTP id h11mr9267320wfb.337.1231353706594; Wed, 07 Jan 2009 10:41:46 -0800 (PST) Received: by 10.143.42.15 with HTTP; Wed, 7 Jan 2009 10:41:46 -0800 (PST) Message-ID: <29d3c4cb0901071041u44de3768lbf749ff79c119103@mail.gmail.com> Date: Wed, 7 Jan 2009 19:41:46 +0100 From: "Alexey Melnikov" To: "Tobias Gondrom" In-Reply-To: <496381C1.8020609@gondrom.org> MIME-Version: 1.0 References: <496381C1.8020609@gondrom.org> X-Google-Sender-Auth: 68a0d713e3459db1 Cc: cyrus@daboo.name, timmartin@alumni.cmu.edu, lisa@osafoundation.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-sieve-managesieve-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1442124788==" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org --===============1442124788== Content-Type: multipart/alternative; boundary="----=_Part_2432_14471786.1231353706589" ------=_Part_2432_14471786.1231353706589 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Tobias, The second part of my reply is below: On Tue, Jan 6, 2009 at 5:07 PM, Tobias Gondrom wrote: > 6. the VERSION capability: > "Lack of this capability means that the server predates this > specification and thus doesn't support the following commands: > RENAMESCRIPT, CHECKSCRIPT and NOOP." the first part of the sentence is > ok, but I should not define which functions are not supported for a > protocol outside of the scope of this standard (without the VERSION > command). Implementations outside could have any behavious which should > not be guessed (although I assume there is one test implementation by > the authors of the draft which behaves as described...) Multiple existing implementations behave as described. I think it is important for the document to provide some guidance for client and server implementors that want to interoperate with (or upgrade) deployed software. > As it clearly states in the draft: "A server implementation MUST return > SIEVE, IMPLEMENTATION and VERSION capabilities." > > 7. and last but not least in section 2: > "Prior to successful authentication only the AUTHENTICATE, CAPABILITY, > STARTTLS, LOGOUT and NOOP " > QUESTION: Why is NOOP available unauthenticated? This was modelled on IMAP, which allows for NOOP in unauthenticated state. > This seems like a > potential unnecessary DoS vulnerability? Can you elaborate on what kind of DoS you had in mind? > QUESTION: Why is LOGOUT available unauthenticated? I don't see why this might be problem. LOGOUT is a nice-to-the-server way to shutdown a ManageSieve connection. ------=_Part_2432_14471786.1231353706589 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Tobias,
The second part of my reply is below:
 
On Tue, Jan 6, 2009 at 5:07 PM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:
6. the VERSION capability:
"Lack of this capability means that the server predates this
specification and thus doesn't support the following commands:
RENAMESCRIPT, CHECKSCRIPT and NOOP." the first part of the sentence is
ok, but I should not define which functions are not supported for a
protocol outside of the scope of this standard (without the VERSION
command). Implementations outside could have any behavious which should
not be guessed (although I assume there is one test implementation by
the authors of the draft which behaves as described...)
Multiple existing implementations behave as described.
I think it is important for the document to provide some guidance for client and server implementors that want to interoperate with (or upgrade) deployed software.
As it clearly states in the draft: "A server implementation MUST return
SIEVE, IMPLEMENTATION and VERSION capabilities."

7. and last but not least in section 2:
"Prior to successful authentication only the AUTHENTICATE, CAPABILITY,
STARTTLS, LOGOUT and NOOP "
QUESTION: Why is NOOP available unauthenticated?
 
This was modelled on IMAP, which allows for NOOP in unauthenticated state.
 
This seems like a
potential unnecessary DoS vulnerability?
 
Can you elaborate on what kind of DoS you had in mind?
 
QUESTION: Why is LOGOUT available unauthenticated?
 
 I don't see why this might be problem. LOGOUT is a nice-to-the-server way to shutdown a ManageSieve connection.
 
------=_Part_2432_14471786.1231353706589-- --===============1442124788== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir --===============1442124788==-- From secdir-bounces@ietf.org Thu Jan 8 03:58:49 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E30D3A6A4A; Thu, 8 Jan 2009 03:58:49 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AB8D3A6A4A for ; Thu, 8 Jan 2009 03:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sDx+EzSDi7x for ; Thu, 8 Jan 2009 03:58:46 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1D8FA3A691F for ; Thu, 8 Jan 2009 03:58:45 -0800 (PST) Received: (qmail invoked by alias); 08 Jan 2009 11:58:30 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp070) with SMTP; 08 Jan 2009 12:58:30 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18D2Ehr/ckD2P/+AnB0wFJhw8EqEvhwJtBZFF/5Uc G7F2N6d0+OrhzH From: "Hannes Tschofenig" To: Date: Thu, 8 Jan 2009 13:58:54 +0200 Message-ID: <00a701c97188$7f3301f0$d758a20a@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AclxiHqUN/KWwLQ1RgizBFWLgJA0vQ== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6899999999999999 Cc: Radia.Perlman@sun.com, erik.nordmark@sun.com, iesg@ietf.org, touch@isi.edu Subject: [secdir] secdir review of draft-ietf-trill-prob-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is a nicely written document. No issues found with it. I have only one minor question: Section 4 says: " A currently open question is whether a single Ethernet link subnet should contain only one TRILL solution instance, either of necessity of architecture or utility. " Did you decide on this issue already? Ciao Hannes _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Jan 8 23:08:21 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0003A67EF; Thu, 8 Jan 2009 23:08:21 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A69143A6909 for ; Thu, 8 Jan 2009 20:47:16 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgOjWlDWkHaL for ; Thu, 8 Jan 2009 20:47:15 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 84F8D3A67FD for ; Thu, 8 Jan 2009 20:47:15 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n094l1xK025538 for ; Thu, 8 Jan 2009 23:47:01 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n094krHa025506 for ; Thu, 8 Jan 2009 23:46:53 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n094klAW028432 for ; Thu, 8 Jan 2009 23:46:48 -0500 (EST) Received: from unobtainium.braintrust.co.nz (202-50-176-161.helix.net.nz [202.50.176.161]) by mit.edu (Spam Firewall) with ESMTP id BD7F31250638 for ; Thu, 8 Jan 2009 23:46:25 -0500 (EST) Received: from [192.168.0.51] (ip-118-90-105-213.xdsl.xnet.co.nz [118.90.105.213]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id E25F227521; Fri, 9 Jan 2009 17:46:22 +1300 (NZDT) Message-Id: <4D50A24E-E6AD-4096-895B-E4084EBEFB19@daork.net> From: Nathan Ward To: Brian E Carpenter In-Reply-To: <48FF8AEC.9060708@gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 9 Jan 2009 17:46:22 +1300 References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48FDFBCB.1090508@ericsson.com> <48FE4681.4070006@gmail.com> <5333EA69-337F-4373-A247-1852B61D96C0@daork.net> <48FF8AEC.9060708@gmail.com> X-Mailer: Apple Mail (2.929.2) X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Thu, 08 Jan 2009 23:08:20 -0800 Cc: Christian Huitema , Dave Thaler , Tim Polk , "secdir@mit.edu" , Suresh Krishnan , "v6ops@ops.ietf.org" , "Jim_Hoagland@symantec.com" Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On 23/10/2008, at 9:19 AM, Brian E Carpenter wrote: > As far as I can see, there's a general problem in attempting > to detect and block Teredo packets (I mean UDP/IPv4 packets > in Teredo format). But it seems to me that by running an > internal Teredo server, a site is much better placed to > track and trace Teredo users. This is important as Teredo > users really need to be running an IPv6-savvy host firewall. Nope, as remote Teredo relays and hosts will send traffic directly. I do not believe that it is not possible to restrict Teredo to a certain domain. Perhaps if the local Teredo server tells the local Teredo aware firewall what UDP ports on each IPv4 /32 are used for an address, then the firewall could inspect packets, but there are no such products currently. You also have to force end hosts to use that Teredo server. It's not immediately clear to me how you would do that. If you're in a position to operate a Teredo server in an end site organisation, you are better off doing ISATAP. That is what it is designed for. >>> I agree with you that there are real threats (or will be, once >>> there is enough deployment to make IPv6 tunnels an interesting >>> target). It's quite appropriate to document them. >> >> >> I need to preface these remarks by say that I haven't read the >> document >> apart from a quick skim read, so sorry if I'm saying something that's >> already in there, or is not relevant. >> >> I think it's important to distinguish between tunnels that end users' >> systems create automatically (ala 6to4, Teredo in Vista), and tunnels >> that end users create to work around firewalls. >> >> The former is easy to document solutions for, in fact, it seems to me >> that any tunnelling protocol RFC should include details as to how a >> network administrator can prevent these protocols passing through >> their >> network. For Teredo this means blocking port 3544/3545. For 6to4 this >> means blocking protocol 41 (preferably returning ICMPv6 messages >> encapsulated in 6to4 so the the application is told about it..). >> This is >> more about blocking things that do not work or perform poorly in a >> certain environment, rather than trying to secure a network. >> >> The latter is not so easy, and I think this document should simply >> point >> out that the only way to really do this is to completely control >> the end >> users' machines, and not allow any third party software or >> configuration >> changes. Anything else is instilling a false sense of security in the >> minds of network administrators who perhaps are not as fluent in >> these >> things as we are. > > Yes, but there are plenty of environments where that's impossible, > and default deny is unacceptable because it blocks legitimate usage. > I think the document needs to steer between the extremes, and suggest > scenarios that are reasonably safe. This is the security trade-off, and is up to the security people of each organisation I suppose. I don't think we can say what is or is not acceptable. Most organisations where I have been employed have used default deny, and required the use of an HTTP proxy. That worked fine for 99% of people, and the few of us who had different requirements had special ethernet ports, etc. I am very concerned about the direction we're heading in with firewall type stuff if we're requiring security people in organisations to understand (fairly) complex protocols like Teredo. I have a hard enough time explaining this to people who have worked in IP networking for a long time. An excellent example of this is Brian's comments in the first part of this email. Because of this, I feel that this document should list several options, and state that the only way to be sure is the default deny, option unless you *really* understand the protocols and can prove it. -- Nathan Ward _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Jan 8 23:52:24 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59033A67A4; Thu, 8 Jan 2009 23:52:24 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08AC33A67A4; Thu, 8 Jan 2009 23:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oh-JEUtMIdge; Thu, 8 Jan 2009 23:52:23 -0800 (PST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 890AF3A65A5; Thu, 8 Jan 2009 23:52:22 -0800 (PST) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n097q57O018895; Fri, 9 Jan 2009 08:52:07 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n097pxZ7002356; Fri, 9 Jan 2009 08:52:03 +0100 Received: from MCHP7IEA.ww902.siemens.net ([139.25.131.145]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 08:50:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jan 2009 08:50:50 +0100 Message-ID: In-Reply-To: <18712.22956.515766.864818@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-sip-media-security-requirements-07.txt Thread-Index: AclDTPrUI+4lqZ0UQNGunf5XIUcjewu4H9Ww References: <200810291237.m9TCbFow003149@fireball.kivinen.iki.fi><867F105F-6735-4E95-BEA7-9F89B4A54D07@softarmor.com> <18712.22956.515766.864818@fireball.kivinen.iki.fi> From: "Fries, Steffen" To: "Tero Kivinen" X-OriginalArrivalTime: 09 Jan 2009 07:50:51.0224 (UTC) FILETIME=[FDFFED80:01C9722E] Cc: sip-chairs@tools.ietf.org, draft-ietf-sip-media-security-requirements@tools.ietf.org, secdir@ietf.org, iesg@ietf.org, Dean Willis Subject: Re: [secdir] Review of draft-ietf-sip-media-security-requirements-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Tero, sorry for the long delay in replying to your last comments. > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Monday, November 10, 2008 4:56 PM > To: Fries, Steffen > Cc: Dean Willis; > draft-ietf-sip-media-security-requirements@tools.ietf.org; > sip-chairs@tools.ietf.org; secdir@ietf.org; iesg@ietf.org > Subject: RE: Review of > draft-ietf-sip-media-security-requirements-07.txt > > Fries, Steffen writes: > > > The biggest problem I had when I was reading the > document, was that > > > section 3, suddenly starts listing different requirements like > > > R-PASS-MEDIA, R-PASS-SIG etc, and there is no indication > where those > > > are described. I tried to look for them in the table of contents, > > > but couldn't find them listed there. > > [stf] I added a sentence at the beginning of section 4, which start > > using the requirement abbreviations. > > Throughout the subsections requirements are stated by using the > > nomenclature R- to state an explicit requirement. All > of the stated > > requirements are explanied in detail in section 5. The > requirements > > in section 5 are listed according their association to the key > > management protocol, to attack scenarios, and requirements > > which can be met inside the key management protocol or > outside of the > > key management protocol. > > As section 3 already refers to those R-* requirements, I > think it would be better to move the paragarph to section 2. > Terminology or at least also in the beginning of section 3. > [stf] done, it is now part of section 2 > > > > Reading forward I finally found those in the section 5, > but as they > > > are not as separate sections there, they were not listed in the > > > table of contents. It would be better to move each of those > > > requirement to separate subsection, i.e. make > > > "5.1.1 R-FORK-RETARGET" and so on, so those references > earlier could > > > point to section 5.1.1 and those would also be listed in > the table > > > of contents. > > [stf] I think it is sufficient to include the above > sentence instead > > of numbering the requirements in sections. > > It would be nice to be able to find the requirements from the > document by simply looking at the table contents. > Requirements section is now 5 pages long, so bit more > specific pointers would be useful in the table of contents. > [stf] we were discussing putting the requirements into separate section, but at the end, we decided to leave the requirements clustered as this better matches the application to use cases and scenarios. > > > There is also unexpanded acronym of UAC in section 4.2, > and I do not > > > what it means and it is not expanded or described in any > way. There > > > seemed to be also quite a lot of other acronyms, so it would be > > > useful to check out if those are really described (or expanded) > > > somewhere in the document. > > [stf] I included the following statement at the beginning of the > > terminology section: > > Furthermore, the terminology described in SIP > > () regarding functions and > > components > > are used throughout the document > > Unfortunately at least I didn't want to read 269 pages to > just get all the terminology about SIP when reading this > document. I would still suggest replacing it with "User agent > client (UAC)" in that one place where it is used in this document. [stf] done, I misunderstood your comment in the first place. Sorry for that. > > > The description of R-RTP-VALID seems bit odd. It says > that "...key > > > negotiation packets MUST NOT pass the RTP validity > check...". That > > > seems bit odd considering that the name is R-RTP-VALID > and it says > > > MUST NOT pass validity check. Is that description really correct? > > [stf] I did nothing here, as the stated requirements is correct. > Why is there requirement that key negotiation packets MUST > fail the validity check? Or is this trying to say that they > are not processed at all by the validity check operations, > i.e. they bypass them. This requirement sound really wierd, > and I do not really have any idea why it is here and what it > is trying to say, but as I do not know that much about SIP, > it might be that I just do not understand something. [stf] we changed the requirement name to R-RTP-CHECK to not let it sound like a negative requirement to be met. > > > > Section A.4.3. SSRC and ROC has typo in word binding: > > > "Another, used by Security Descriptions, is to use "late > bindng" -- > > > ... > > [stf] changed to > > Another, used by Security Descriptions, is to apply "late > > bindng ... > > But it is still saying "late bindng" there, and "late > binding" in other places. I would guess the "bindng" should > be "binding" here too. [stf] hoops, missed that one. Changed to "binding" We will submit an updated version soon. Steffen > -- > kivinen@iki.fi > _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Jan 9 12:43:41 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90B953A6784; Fri, 9 Jan 2009 12:43:41 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30CF13A63D2 for ; Fri, 9 Jan 2009 12:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhHwMVCWXUdQ for ; Fri, 9 Jan 2009 12:43:40 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 51EB33A6784 for ; Fri, 9 Jan 2009 12:43:39 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n09KhOND007994 for ; Fri, 9 Jan 2009 15:43:24 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n09KhO4O007991 for ; Fri, 9 Jan 2009 15:43:24 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 9 Jan 2009 15:43:24 -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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (fledge.watson.org [127.0.0.1]); Fri, 09 Jan 2009 15:43:25 -0500 (EST) Subject: [secdir] Assignments delayed X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org While there is another telehcat this coming week, I'm not going to make new assignments today. Those who have unreviewed docs on the telechat agenda have received a separate reminder from me. Expect new assignments early next week. -- Sam _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Jan 9 13:57:18 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA103A695B; Fri, 9 Jan 2009 13:57:18 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21DE53A695B for ; Fri, 9 Jan 2009 13:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.571 X-Spam-Level: X-Spam-Status: No, score=-4.571 tagged_above=-999 required=5 tests=[AWL=2.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oO2sYcKKwhyN for ; Fri, 9 Jan 2009 13:57:17 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id D8C793A6933 for ; Fri, 9 Jan 2009 13:57:16 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n09Lv1W9005500 for ; Fri, 9 Jan 2009 16:57:01 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n09LusQ7005425 for ; Fri, 9 Jan 2009 16:56:54 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n09LunWk001174 for ; Fri, 9 Jan 2009 16:56:49 -0500 (EST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by mit.edu (Spam Firewall) with ESMTP id 10F77D1DFC7 for ; Fri, 9 Jan 2009 16:56:27 -0500 (EST) Received: by ti-out-0910.google.com with SMTP id w4so8375071tib.14 for ; Fri, 09 Jan 2009 13:56:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=MUVNBqLB1LF7qbGxKM4Zz5gdYUuEd4WRdn2UBmdixSQ=; b=LatU6DIeSfq214CHRFF97V88UDk5fhDN/cvE9bMmgQHcRAgglSFBzj5ZocUoihsO/X x+/js+MqQS7l1HVbP28KBfl832o76FJUmgacpO4vnO5xpARMZJJ4xuFA8UztEIoOqNEo DLWgPPEw6hbPou/UFW6I6GXBErd5FPesru/YI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=qVqAO8gS2hjHJ44clQ77/VRmO2uqCva2NtG75G04MA1/oGvm77MbTgs7BamTrwC5eF n6pXpkH3DElnuStyYm1fBWK8AlZjd3/xVXESR+cRBFpOMnz4LteGWh7diWSsvkevDTE5 auId3VTNH4X5GyiGlrcbHv8cj6p7UfF+vHDk0= Received: by 10.110.86.3 with SMTP id j3mr6060090tib.32.1231538185983; Fri, 09 Jan 2009 13:56:25 -0800 (PST) Received: from ?10.1.1.4? (118-93-185-90.dsl.dyn.ihug.co.nz [118.93.185.90]) by mx.google.com with ESMTPS id 2sm4736220tif.39.2009.01.09.13.56.21 (version=SSLv3 cipher=RC4-MD5); Fri, 09 Jan 2009 13:56:25 -0800 (PST) Message-ID: <4967C803.7060803@gmail.com> Date: Sat, 10 Jan 2009 10:56:19 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Nathan Ward References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48FDFBCB.1090508@ericsson.com> <48FE4681.4070006@gmail.com> <5333EA69-337F-4373-A247-1852B61D96C0@daork.net> <48FF8AEC.9060708@gmail.com> <4D50A24E-E6AD-4096-895B-E4084EBEFB19@daork.net> In-Reply-To: <4D50A24E-E6AD-4096-895B-E4084EBEFB19@daork.net> X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: Christian Huitema , Dave Thaler , Tim Polk , "secdir@mit.edu" , Suresh Krishnan , "v6ops@ops.ietf.org" , "Jim_Hoagland@symantec.com" Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Nathan, On 2009-01-09 17:46, Nathan Ward wrote: > On 23/10/2008, at 9:19 AM, Brian E Carpenter wrote: > >> As far as I can see, there's a general problem in attempting >> to detect and block Teredo packets (I mean UDP/IPv4 packets >> in Teredo format). But it seems to me that by running an >> internal Teredo server, a site is much better placed to >> track and trace Teredo users. This is important as Teredo >> users really need to be running an IPv6-savvy host firewall. > > Nope, as remote Teredo relays and hosts will send traffic directly. I do > not believe that it is not possible to restrict Teredo to a certain domain. No, and that's not what I meant to suggest. I meant that by operating a local Teredo server, the local management can find out who is actively using Teredo and ensure that they are adequately protected at the host level. It certainly isn't reasonable to expect a site firewall to be doing the necessary deep packet inspection. > > Perhaps if the local Teredo server tells the local Teredo aware firewall > what UDP ports on each IPv4 /32 are used for an address, then the > firewall could inspect packets, but there are no such products currently. > > You also have to force end hosts to use that Teredo server. It's not > immediately clear to me how you would do that. Quoting you out of context: " Alternatively, a network may force customers to use its Teredo servers by 'spoofing' DNS names or IPv4 addresses. " Were you planning to follow up on draft-nward-v6ops-teredo-server-selection-00? > > If you're in a position to operate a Teredo server in an end site > organisation, you are better off doing ISATAP. That is what it is > designed for. Yes, but my concern was more about users who are spontaneously using Teredo. The above type of spoofing is a way to find them, however unpleasant it may be. > >>>> I agree with you that there are real threats (or will be, once >>>> there is enough deployment to make IPv6 tunnels an interesting >>>> target). It's quite appropriate to document them. >>> >>> >>> I need to preface these remarks by say that I haven't read the document >>> apart from a quick skim read, so sorry if I'm saying something that's >>> already in there, or is not relevant. >>> >>> I think it's important to distinguish between tunnels that end users' >>> systems create automatically (ala 6to4, Teredo in Vista), and tunnels >>> that end users create to work around firewalls. >>> >>> The former is easy to document solutions for, in fact, it seems to me >>> that any tunnelling protocol RFC should include details as to how a >>> network administrator can prevent these protocols passing through their >>> network. For Teredo this means blocking port 3544/3545. For 6to4 this >>> means blocking protocol 41 (preferably returning ICMPv6 messages >>> encapsulated in 6to4 so the the application is told about it..). This is >>> more about blocking things that do not work or perform poorly in a >>> certain environment, rather than trying to secure a network. >>> >>> The latter is not so easy, and I think this document should simply point >>> out that the only way to really do this is to completely control the end >>> users' machines, and not allow any third party software or configuration >>> changes. Anything else is instilling a false sense of security in the >>> minds of network administrators who perhaps are not as fluent in these >>> things as we are. >> >> Yes, but there are plenty of environments where that's impossible, >> and default deny is unacceptable because it blocks legitimate usage. >> I think the document needs to steer between the extremes, and suggest >> scenarios that are reasonably safe. > > > This is the security trade-off, and is up to the security people of each > organisation I suppose. I don't think we can say what is or is not > acceptable. > > Most organisations where I have been employed have used default deny, > and required the use of an HTTP proxy. That worked fine for 99% of > people, and the few of us who had different requirements had special > ethernet ports, etc. > > I am very concerned about the direction we're heading in with firewall > type stuff if we're requiring security people in organisations to > understand (fairly) complex protocols like Teredo. I have a hard enough > time explaining this to people who have worked in IP networking for a > long time. An excellent example of this is Brian's comments in the first > part of this email. > > Because of this, I feel that this document should list several options, > and state that the only way to be sure is the default deny, option > unless you *really* understand the protocols and can prove it. That seems very reasonable, and I would prefer it to what looks like firm recommmendations right now. Brian _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sat Jan 10 13:56:33 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B85D3A6A41; Sat, 10 Jan 2009 13:56:33 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C02083A69DB; Sat, 10 Jan 2009 13:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx80mC-rMDRC; Sat, 10 Jan 2009 13:56:30 -0800 (PST) Received: from bacon.cs.umd.edu (server-nat-4.cs.umd.edu [128.8.127.147]) by core3.amsl.com (Postfix) with ESMTP id B00113A6921; Sat, 10 Jan 2009 13:56:30 -0800 (PST) X-CSD-MailScanner-Watermark: 1232229371.07565@cuLoYPfNOWP+1xpVSkry5A Received: from [127.0.0.1] (pool-98-117-33-198.bltmmd.fios.verizon.net [98.117.33.198]) (authenticated bits=0) by bacon.cs.umd.edu (8.13.1/8.14.1) with ESMTP id n0ALu9il031228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Jan 2009 16:56:09 -0500 Message-ID: <49691973.2060906@ltsnet.net> Date: Sat, 10 Jan 2009 16:56:03 -0500 From: Charles Clancy User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: secdir@ietf.org, draft-ietf-pce-dste@tools.ietf.org, pce-chairs@tools.ietf.org, rcallon@juniper.net, iesg@ietf.org X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (bacon.cs.umd.edu [172.24.3.34]); Sat, 10 Jan 2009 16:56:10 -0500 (EST) X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-MailScanner-ID: n0ALu9il031228 X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-50, required 5, autolearn=not spam, ALL_TRUSTED -50.00) X-CSD-MailScanner-From: clancy@ltsnet.net Subject: [secdir] secdir review of draft-ietf-pce-dste-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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. Title: Diff-Serv Aware Class Type Object for Path Computation Element Communication Protocol This document specifies a CLASSTYPE object for diffserv-aware traffic engineering, where path computation uses the path computation element (PCE) defined in draft-ietf-pce-pcep-18. This document has extremely sparse security considerations, stating that since it is simply defining a CLASSTYPE it doesn't change the security implications of PCE, as described in detail in draft-ietf-pce-pcep-18. Given the circumstances, this seems reasonable. -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Jan 11 12:35:44 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4824028C0EF; Sun, 11 Jan 2009 12:35:44 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5673A6940 for ; Sun, 11 Jan 2009 12:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.486 X-Spam-Level: X-Spam-Status: No, score=-4.486 tagged_above=-999 required=5 tests=[AWL=2.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5yhCJXTdPSH for ; Sun, 11 Jan 2009 12:35:42 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 41C6A3A67B6 for ; Sun, 11 Jan 2009 12:35:41 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0BKZRT8005405 for ; Sun, 11 Jan 2009 15:35:27 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0BKZLre005372 for ; Sun, 11 Jan 2009 15:35:21 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n0BKZG99012610 for ; Sun, 11 Jan 2009 15:35:16 -0500 (EST) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.249]) by mit.edu (Spam Firewall) with ESMTP id F02411455EF7 for ; Sun, 11 Jan 2009 15:35:15 -0500 (EST) Received: by rv-out-0708.google.com with SMTP id f25so13908275rvb.18 for ; Sun, 11 Jan 2009 12:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=BnWYSJ9rKmwLfBVRrTroLygj+HNo/51Lm0+4iQJvvWc=; b=vdgnVKfDAwqxC4TRyZ1KpT/L3jCsy0ys0jCc2dwDnU9yOhUVQkuGj3T+lRg0o2K0S7 rUyMGQbmLKydhURTkqNX526t2SR1HRZJtoPZ69XNWDhsrywFi38Uip34wkdCGsSwGQ32 d4CuXy8HmA+v2PS5o4m4t58oN7CzG7UAEAnO0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=k8DoqIGHSmKR1eQKQvf6jtUa5RjxOPememyxnAO7/wMT13ocO3XZvu5/k/iKQjl3hO x9uvXlw0yUXCkNmXi0fkz6Poa4E+3MwLHPixMb2gP7bvzAWZ2fQN7AaHRkK0CHcCdCvc 8rGbnz/kLr9reXuDET13VecN5p9e7wRCsWFAY= Received: by 10.141.198.9 with SMTP id a9mr13988657rvq.248.1231706115543; Sun, 11 Jan 2009 12:35:15 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id b8sm10029363rvf.9.2009.01.11.12.35.12 (version=SSLv3 cipher=RC4-MD5); Sun, 11 Jan 2009 12:35:15 -0800 (PST) Message-ID: <496A57FF.1000600@gmail.com> Date: Mon, 12 Jan 2009 09:35:11 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Nathan Ward References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48FDFBCB.1090508@ericsson.com> <48FE4681.4070006@gmail.com> <5333EA69-337F-4373-A247-1852B61D96C0@daork.net> <48FF8AEC.9060708@gmail.com> <4D50A24E-E6AD-4096-895B-E4084EBEFB19@daork.net> <4967C803.7060803@gmail.com> <8AAA7487-A80F-41CE-92C5-F8E189D5D3B1@daork.net> <39C363776A4E8C4A94691D2BD9D1C9A1056AAA7D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: Christian Huitema , Dave Thaler , Tim Polk , secdir@mit.edu, Suresh Krishnan , "Templin, Fred L" , v6ops@ops.ietf.org, jim_hoagland@symantec.com Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On 2009-01-11 18:13, Nathan Ward wrote: > On 10/01/2009, at 12:08 PM, Templin, Fred L wrote: > >>> Hmm, it's probably worth noting that I'm talking about Windows hosts >>> here. Linux hosts with a Teredo stack installed will not try ISATAP >>> first. >> >> I may be able to help with that. Tell me what behavior >> you want out of ISATAP on linux, and I'll code it... > > > Support in major distributions seems like a good first step. I note that > your code is now in 2.6.mumble though, that's a positive step. > > While we're here, OS X and BSD support would be nice too. > > There seems to be a bit of a lack of coherent vision for IPv6 support in > OSes other than Windows. There are components - ie. 6to4, Teredo and > ISATAP code - however there doesn't seem to be anything to relate them > to one another so that 'end users' without a bunch of knowledge can use > this stuff. A good first step would be to install+configure all three > together as part of the "Enable IPv6" option. Along with that, take a > DHCPv6 client, etc. etc. > "Enable IPv6" in most OSes means do stateless autoconfig for native > IPv6, and that's it. Because that was the ~1996 vision, and the current vision hasn't really been articulated clearly (RFC4294 is really just a laundry list). Kudos to Microsoft, but perhaps the IETF needs to write down what's needed. Brian _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Jan 11 22:49:36 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E99013A681D; Sun, 11 Jan 2009 22:49:36 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5C753A68DF for ; Fri, 9 Jan 2009 14:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.211 X-Spam-Level: X-Spam-Status: No, score=-5.211 tagged_above=-999 required=5 tests=[AWL=1.388, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwODJk5ysNR2 for ; Fri, 9 Jan 2009 14:44:40 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 90F033A6893 for ; Fri, 9 Jan 2009 14:44:39 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n09MiQmq013574 for ; Fri, 9 Jan 2009 17:44:26 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n09MiOru013570 for ; Fri, 9 Jan 2009 17:44:24 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n09MiJhC023916 for ; Fri, 9 Jan 2009 17:44:19 -0500 (EST) Received: from unobtainium.braintrust.co.nz (202-50-176-161.helix.net.nz [202.50.176.161]) by mit.edu (Spam Firewall) with ESMTP id 1D1BBD1C34B for ; Fri, 9 Jan 2009 17:44:01 -0500 (EST) Received: from [192.168.0.51] (ip-118-90-105-213.xdsl.xnet.co.nz [118.90.105.213]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id D6929271CC; Sat, 10 Jan 2009 11:43:58 +1300 (NZDT) Message-Id: <8AAA7487-A80F-41CE-92C5-F8E189D5D3B1@daork.net> From: Nathan Ward To: Brian E Carpenter In-Reply-To: <4967C803.7060803@gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 10 Jan 2009 11:43:57 +1300 References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48FDFBCB.1090508@ericsson.com> <48FE4681.4070006@gmail.com> <5333EA69-337F-4373-A247-1852B61D96C0@daork.net> <48FF8AEC.9060708@gmail.com> <4D50A24E-E6AD-4096-895B-E4084EBEFB19@daork.net> <4967C803.7060803@gmail.com> X-Mailer: Apple Mail (2.929.2) X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Sun, 11 Jan 2009 22:49:35 -0800 Cc: Christian Huitema , Dave Thaler , Tim Polk , "secdir@mit.edu" , Suresh Krishnan , "v6ops@ops.ietf.org" , "Jim_Hoagland@symantec.com" Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On 10/01/2009, at 10:56 AM, Brian E Carpenter wrote: > On 2009-01-09 17:46, Nathan Ward wrote: >> On 23/10/2008, at 9:19 AM, Brian E Carpenter wrote: >> >>> As far as I can see, there's a general problem in attempting >>> to detect and block Teredo packets (I mean UDP/IPv4 packets >>> in Teredo format). But it seems to me that by running an >>> internal Teredo server, a site is much better placed to >>> track and trace Teredo users. This is important as Teredo >>> users really need to be running an IPv6-savvy host firewall. >> >> Nope, as remote Teredo relays and hosts will send traffic directly. >> I do >> not believe that it is not possible to restrict Teredo to a certain >> domain. > > No, and that's not what I meant to suggest. I meant that by operating > a local Teredo server, the local management can find out who is > actively > using Teredo and ensure that they are adequately protected at the host > level. It certainly isn't reasonable to expect a site firewall to be > doing the necessary deep packet inspection. Seems feasible. The Teredo server could do some sort of look-up before responding. If they do not respond the interface will not come up. >> Perhaps if the local Teredo server tells the local Teredo aware >> firewall >> what UDP ports on each IPv4 /32 are used for an address, then the >> firewall could inspect packets, but there are no such products >> currently. >> >> You also have to force end hosts to use that Teredo server. It's not >> immediately clear to me how you would do that. > > Quoting you out of context: > > " Alternatively, a network may force customers to use its Teredo > servers by 'spoofing' DNS names or IPv4 addresses. " > > Were you planning to follow up on draft-nward-v6ops-teredo-server- > selection-00? Yes. I am at this minute looking at flights to SFO for IETF74, and if that is financially do-able then I'll update it and present it there. Few people seemed to be interested when I explained electronically, in person has worked better with various people since then, so in person will do well I'm sure. >> If you're in a position to operate a Teredo server in an end site >> organisation, you are better off doing ISATAP. That is what it is >> designed for. > > Yes, but my concern was more about users who are spontaneously using > Teredo. The above type of spoofing is a way to find them, > however unpleasant it may be. If they are spontaneously using Teredo (I assume by spontaneously, you mean automatically ala Vista etc. ?) then they are going to try ISATAP first. As ISATAP gives you unencapsulated traffic on your border router (or between your border and ISATAP routers if they are separate, etc. etc.) this seems like a better option, to me. I suppose this depends whether you want to control security at the border, or at the host. Hmm, it's probably worth noting that I'm talking about Windows hosts here. Linux hosts with a Teredo stack installed will not try ISATAP first. Of course, if the local management have sufficient access to the host to secure it (as you suggest in the first part of the email), they have sufficient access to simply disable Teredo - either by having the host part of a Windows domain, or by pushing the right bits in to the registry. This seems to me to be a superior strategy. -- Nathan Ward _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Jan 11 22:49:37 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DE6B3A68A5; Sun, 11 Jan 2009 22:49:37 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87D273A6AF1 for ; Fri, 9 Jan 2009 15:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMaFlCbC+j87 for ; Fri, 9 Jan 2009 15:09:52 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id A458E3A67AD for ; Fri, 9 Jan 2009 15:09:52 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n09N9cO8017339 for ; Fri, 9 Jan 2009 18:09:38 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n09N9aV9017331 for ; Fri, 9 Jan 2009 18:09:37 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n09N9Tm8015719 for ; Fri, 9 Jan 2009 18:09:30 -0500 (EST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id EDDD111A18B8 for ; Fri, 9 Jan 2009 18:09:08 -0500 (EST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n09N8qoS028444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2009 15:08:53 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n09N8qfk002533; Fri, 9 Jan 2009 15:08:52 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n09N8p4x002496; Fri, 9 Jan 2009 15:08:52 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 15:08:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jan 2009 15:08:49 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1056AAA7D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <8AAA7487-A80F-41CE-92C5-F8E189D5D3B1@daork.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SECDIR review: draft-ietf-v6ops-tunnel-concerns Thread-Index: AclyrO+ECzg9xJNvQuyH9tWX3byOuAAAckmg References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48FDFBCB.1090508@ericsson.com> <48FE4681.4070006@gmail.com> <5333EA69-337F-4373-A247-1852B61D96C0@daork.net> <48FF8AEC.9060708@gmail.com> <4D50A24E-E6AD-4096-895B-E4084EBEFB19@daork.net> <4967C803.7060803@gmail.com> <8AAA7487-A80F-41CE-92C5-F8E189D5D3B1@daork.net> From: "Templin, Fred L" To: "Nathan Ward" , "Brian E Carpenter" X-OriginalArrivalTime: 09 Jan 2009 23:08:50.0194 (UTC) FILETIME=[3B9FC720:01C972AF] X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id n09N9aV9017331 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Sun, 11 Jan 2009 22:49:35 -0800 Cc: Christian Huitema , Dave Thaler , Tim Polk , secdir@mit.edu, Suresh Krishnan , v6ops@ops.ietf.org, jim_hoagland@symantec.com Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org >Hmm, it's probably worth noting that I'm talking about Windows hosts >here. Linux hosts with a Teredo stack installed will not try ISATAP >first. I may be able to help with that. Tell me what behavior you want out of ISATAP on linux, and I'll code it... Fred fred.l.templin@boeing.com _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Jan 11 22:49:37 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8263A690B; Sun, 11 Jan 2009 22:49:37 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4773A6984 for ; Sat, 10 Jan 2009 21:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.211 X-Spam-Level: X-Spam-Status: No, score=-5.211 tagged_above=-999 required=5 tests=[AWL=1.388, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSdQzU8fRpKg for ; Sat, 10 Jan 2009 21:14:00 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 7807C3A6882 for ; Sat, 10 Jan 2009 21:14:00 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0B5DjKY002232 for ; Sun, 11 Jan 2009 00:13:45 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0B5De4W002143 for ; Sun, 11 Jan 2009 00:13:40 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n0B5DZup013939 for ; Sun, 11 Jan 2009 00:13:35 -0500 (EST) Received: from unobtainium.braintrust.co.nz (202-50-176-161.helix.net.nz [202.50.176.161]) by mit.edu (Spam Firewall) with ESMTP id 2C6BFD2D278 for ; Sun, 11 Jan 2009 00:13:07 -0500 (EST) Received: from [192.168.0.51] (ip-118-90-105-213.xdsl.xnet.co.nz [118.90.105.213]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id E3F6227930; Sun, 11 Jan 2009 18:13:03 +1300 (NZDT) Message-Id: From: Nathan Ward To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1056AAA7D@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 11 Jan 2009 18:13:02 +1300 References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48FDFBCB.1090508@ericsson.com> <48FE4681.4070006@gmail.com> <5333EA69-337F-4373-A247-1852B61D96C0@daork.net> <48FF8AEC.9060708@gmail.com> <4D50A24E-E6AD-4096-895B-E4084EBEFB19@daork.net> <4967C803.7060803@gmail.com> <8AAA7487-A80F-41CE-92C5-F8E189D5D3B1@daork.net> <39C363776A4E8C4A94691D2BD9D1C9A1056AAA7D@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.929.2) X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Sun, 11 Jan 2009 22:49:35 -0800 Cc: Christian Huitema , Dave Thaler , Tim Polk , secdir@mit.edu, Suresh Krishnan , Brian E Carpenter , v6ops@ops.ietf.org, jim_hoagland@symantec.com Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On 10/01/2009, at 12:08 PM, Templin, Fred L wrote: >> Hmm, it's probably worth noting that I'm talking about Windows hosts >> here. Linux hosts with a Teredo stack installed will not try ISATAP >> first. > > I may be able to help with that. Tell me what behavior > you want out of ISATAP on linux, and I'll code it... Support in major distributions seems like a good first step. I note that your code is now in 2.6.mumble though, that's a positive step. While we're here, OS X and BSD support would be nice too. There seems to be a bit of a lack of coherent vision for IPv6 support in OSes other than Windows. There are components - ie. 6to4, Teredo and ISATAP code - however there doesn't seem to be anything to relate them to one another so that 'end users' without a bunch of knowledge can use this stuff. A good first step would be to install+configure all three together as part of the "Enable IPv6" option. Along with that, take a DHCPv6 client, etc. etc. "Enable IPv6" in most OSes means do stateless autoconfig for native IPv6, and that's it. -- Nathan Ward _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Jan 12 06:49:47 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B92AC3A69F0; Mon, 12 Jan 2009 06:49:47 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B083A69F0; Mon, 12 Jan 2009 06:49:47 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XrqzFpK9LkC; Mon, 12 Jan 2009 06:49:46 -0800 (PST) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 16E4F3A6903; Mon, 12 Jan 2009 06:49:45 -0800 (PST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n0CEnOsg006831; Mon, 12 Jan 2009 09:49:25 -0500 (EST) Received: from morannon (ool-4353140e.dyn.optonline.net [67.83.20.14]) (authenticated bits=0) (User authenticated as uri@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n0CEnJZh007355 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Jan 2009 09:49:24 -0500 (EST) From: "Uri Blumenthal" To: References: Date: Mon, 12 Jan 2009 09:49:19 -0500 Organization: Massachusetts Institute of Technology Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Aclri9tD99cCPlFORHaTXYAzVOxjfgJNdPMg X-Scanned-By: MIMEDefang 2.42 Cc: iesg@ietf.org, phillipspagnolo@gmail.com, rich.ogier@gmail.com, secdir@ietf.org Subject: Re: [secdir] Assignment: draft-ietf-ospf-manet-mdr-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: uri@MIT.EDU List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org I've reviewed this draft (draft-ietf-ospf-manet-mdr-04). Its Security Considration section basically states "This is OSPFv3 extension and can use the same IPv6 security mechanisms as OSPFv3. No new security concerns." I know way too little of OSPF to meaningfully evaluate this statement. My intuition however says that mobility and Ad-Hoc-ness probably do introduce issues. For example, OSPFv3 Auth (RFC 4552) says that for multicast manual keying should be used for now, and KINK can be explored in the future. This extension uses multicast (section 2.3). How the keying would be done is unclear to me, and I wouldn't be very happy to hear "manually" in response (for an Ad-Hoc network!). Overall, I would like to see some kind of analysis and/or explanation of how the new features do not introduce any new threats and thus raise no new concerns. For example, are malicious entities a concern (shouldn't they be?)? Again, I don't know OSPF enough to do that analysis myself. Also, it speaks of OSPFv3 but refers to OSPFv2 (RFC 2328). Tnx! _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Jan 12 14:15:46 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2E3B3A69E5; Mon, 12 Jan 2009 14:15:46 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DA8D3A69D1 for ; Mon, 12 Jan 2009 14:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.431 X-Spam-Level: X-Spam-Status: No, score=-6.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xk2kgrJKukVe for ; Mon, 12 Jan 2009 14:15:45 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 2E9EB3A68F0 for ; Mon, 12 Jan 2009 14:15:44 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0CMFTvu013376 for ; Mon, 12 Jan 2009 17:15:29 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0CMFNhg013344 for ; Mon, 12 Jan 2009 17:15:24 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n0CMFHG8011542 for ; Mon, 12 Jan 2009 17:15:17 -0500 (EST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id ADF0112DC4BF for ; Mon, 12 Jan 2009 17:14:56 -0500 (EST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n0CMEUs7023709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Jan 2009 14:14:32 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n0CMEUDx024260; Mon, 12 Jan 2009 16:14:30 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n0CMEFIX023795; Mon, 12 Jan 2009 16:14:30 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Jan 2009 14:14:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Jan 2009 14:09:38 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1056AB0C6@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SECDIR review: draft-ietf-v6ops-tunnel-concerns Thread-Index: Aclzq0sAt29UE4hpT6W/IIzaoD8OygBVV8/w References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48FDFBCB.1090508@ericsson.com> <48FE4681.4070006@gmail.com> <5333EA69-337F-4373-A247-1852B61D96C0@daork.net> <48FF8AEC.9060708@gmail.com> <4D50A24E-E6AD-4096-895B-E4084EBEFB19@daork.net> <4967C803.7060803@gmail.com> <8AAA7487-A80F-41CE-92C5-F8E189D5D3B1@daork.net> <39C363776A4E8C4A94691D2BD9D1C9A1056AAA7D@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Nathan Ward" X-OriginalArrivalTime: 12 Jan 2009 22:14:27.0844 (UTC) FILETIME=[2259EC40:01C97503] X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id n0CMFNhg013344 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: Christian Huitema , Dave Thaler , Tim Polk , secdir@mit.edu, Suresh Krishnan , Brian E Carpenter , v6ops@ops.ietf.org, jim_hoagland@symantec.com Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Nathan, >-----Original Message----- >From: Nathan Ward [mailto:v6ops@daork.net] >Sent: Saturday, January 10, 2009 9:13 PM >To: Templin, Fred L >Cc: Brian E Carpenter; Suresh Krishnan; Christian Huitema; Kurt Zeilenga; Pasi Eronen; Tim Polk; >secdir@mit.edu; Jim_Hoagland@symantec.com; Dave Thaler; v6ops@ops.ietf.org >Subject: Re: SECDIR review: draft-ietf-v6ops-tunnel-concerns > >On 10/01/2009, at 12:08 PM, Templin, Fred L wrote: > >>> Hmm, it's probably worth noting that I'm talking about Windows hosts >>> here. Linux hosts with a Teredo stack installed will not try ISATAP >>> first. >> >> I may be able to help with that. Tell me what behavior >> you want out of ISATAP on linux, and I'll code it... > > >Support in major distributions seems like a good first step. I note >that your code is now in 2.6.mumble though, that's a positive step. > >While we're here, OS X and BSD support would be nice too. I'll check and see if there is still a FBSD port. If not, and if someone wants to port the linux implementation, that would be fine with me. Otherwise, I'll put it on my todo list. Thanks - Fred fred.l.templin@boeing.com >There seems to be a bit of a lack of coherent vision for IPv6 support >in OSes other than Windows. There are components - ie. 6to4, Teredo >and ISATAP code - however there doesn't seem to be anything to relate >them to one another so that 'end users' without a bunch of knowledge >can use this stuff. A good first step would be to install+configure >all three together as part of the "Enable IPv6" option. Along with >that, take a DHCPv6 client, etc. etc. >"Enable IPv6" in most OSes means do stateless autoconfig for native >IPv6, and that's it. > >-- >Nathan Ward > > > _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Jan 12 15:49:14 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B213A6836; Mon, 12 Jan 2009 15:49:14 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02FED3A6836 for ; Mon, 12 Jan 2009 15:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.484 X-Spam-Level: X-Spam-Status: No, score=-106.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuFln6sxmsTV for ; Mon, 12 Jan 2009 15:49:12 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id B39043A67DB for ; Mon, 12 Jan 2009 15:49:12 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0CNmu53028774 for ; Mon, 12 Jan 2009 18:48:58 -0500 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0CNmtQi028771 for ; Mon, 12 Jan 2009 18:48:55 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n0CNmjZe004333 for ; Mon, 12 Jan 2009 18:48:45 -0500 (EST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id EA907D35004 for ; Mon, 12 Jan 2009 18:48:21 -0500 (EST) X-IronPort-AV: E=Sophos;i="4.37,255,1231113600"; d="scan'208";a="59243293" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 12 Jan 2009 23:48:20 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0CNmKp2016118 for ; Mon, 12 Jan 2009 15:48:20 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0CNmKOb017804 for ; Mon, 12 Jan 2009 23:48:20 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jan 2009 15:48:20 -0800 Received: from stealth-10-32-244-220.cisco.com ([10.32.244.220]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jan 2009 15:48:20 -0800 Message-Id: <169DD93E-577A-4935-BCE1-351F145E836F@cisco.com> From: Fred Baker To: secdir@mit.edu Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 12 Jan 2009 15:48:19 -0800 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 12 Jan 2009 23:48:20.0630 (UTC) FILETIME=[3FC0DB60:01C97510] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1299; t=1231804100; x=1232668100; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Fwd=3A=20Agreement=20on=2025=20Most=20Dangerous =20Programming=20Errors=20-=20And=20How=20to=20Fix |Sender:=20; bh=LAwEsfOUCZ6iuGSCSYbgMBwwjKgKrIiWqJXQkXocYGM=; b=sDOQkezTfyb6K1/zbVbTWs17q/VGIUk+LAp/Hyvbszktsxx+qBk5U67YK5 tAa2PVGrlBBOztBsuDbETyVA0t2Q1pcY0ZWpZqy58bw6nU6I3xAruupsA0wT n6VkeNIKoG; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Subject: [secdir] Fwd: Agreement on 25 Most Dangerous Programming Errors - And How to Fix X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Dumb question... Back when I was the chair of the IETF, I asked our security folks for a list of obvious attacks, so I could make them available to other working groups asking them to think about them when designing whatever they designed. The security directorate didn't provide one, but I ultimately found something kinda sorta like that in a doctoral thesis somewhere, and put the information online. The information is long gone - someone decided it should disappear. Is there a good list of obvious attacks that could be used by the IETF to save you guys from having to find them? > > http://www.sans.org/top25errors/ > > "Buyers will require that software vendors certify in writing that > the code > they are delivering is free of these 25 programming errors. > Certification > shifts responsibility to the vendor for correcting the errors and > for any > damage caused by those errors. The standard procurement language under > development by the State of New York and other state governments > already is > being adjusted to use the Top 25 Errors. Over time the multi- > national Common > Criteria program may also adopt the Top 25 as one approach for > ensuring code > purchased by the US government is free of the Top 25 errors." _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Jan 13 06:19:28 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3689E3A6A60; Tue, 13 Jan 2009 06:19:28 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14033A6A60 for ; Tue, 13 Jan 2009 06:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.53 X-Spam-Level: X-Spam-Status: No, score=-4.53 tagged_above=-999 required=5 tests=[AWL=2.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzoHcsLaJVLA for ; Tue, 13 Jan 2009 06:19:26 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id AA6C03A6A5F for ; Tue, 13 Jan 2009 06:19:26 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0DEJ95m002238 for ; Tue, 13 Jan 2009 09:19:11 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0DEJ6vu002216 for ; Tue, 13 Jan 2009 09:19:06 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n0DEIx8p000757 for ; Tue, 13 Jan 2009 09:18:59 -0500 (EST) Received: from kilo.local (unknown [74.95.2.169]) by mit.edu (Spam Firewall) with ESMTP id C67951460FCE for ; Tue, 13 Jan 2009 09:18:35 -0500 (EST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.local (Postfix) with ESMTP id 672D5EAFAD; Tue, 13 Jan 2009 06:18:34 -0800 (PST) Date: Tue, 13 Jan 2009 06:18:34 -0800 From: Eric Rescorla To: Fred Baker In-Reply-To: <169DD93E-577A-4935-BCE1-351F145E836F@cisco.com> References: <169DD93E-577A-4935-BCE1-351F145E836F@cisco.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20090113141834.672D5EAFAD@kilo.local> X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: secdir@mit.edu Subject: Re: [secdir] Fwd: Agreement on 25 Most Dangerous Programming Errors - And How to Fix X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org At Mon, 12 Jan 2009 15:48:19 -0800, Fred Baker wrote: > > Dumb question... > > Back when I was the chair of the IETF, I asked our security folks for > a list of obvious attacks, so I could make them available to other > working groups asking them to think about them when designing whatever > they designed. The security directorate didn't provide one, but I > ultimately found something kinda sorta like that in a doctoral thesis > somewhere, and put the information online. The information is long > gone - someone decided it should disappear. > > Is there a good list of obvious attacks that could be used by the IETF > to save you guys from having to find them? http://www.isi.edu/in-notes/rfc3552.txt -Ekr _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Jan 13 07:32:46 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD04F28C164; Tue, 13 Jan 2009 07:32:46 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21E433A68BF for ; Tue, 13 Jan 2009 07:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.485 X-Spam-Level: X-Spam-Status: No, score=-106.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQsWsLDque5T for ; Tue, 13 Jan 2009 07:32:41 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 847E23A6805 for ; Tue, 13 Jan 2009 07:32:41 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0DFWOHQ018291 for ; Tue, 13 Jan 2009 10:32:26 -0500 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0DFWMn2018257 for ; Tue, 13 Jan 2009 10:32:22 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n0DFW7Q0003949 for ; Tue, 13 Jan 2009 10:32:10 -0500 (EST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 224DA12F1375 for ; Tue, 13 Jan 2009 10:31:43 -0500 (EST) X-IronPort-AV: E=Sophos;i="4.37,260,1231113600"; d="scan'208";a="228948412" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 13 Jan 2009 15:31:43 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0DFVh09018201; Tue, 13 Jan 2009 07:31:43 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0DFVhlh025738; Tue, 13 Jan 2009 15:31:43 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jan 2009 07:31:42 -0800 Received: from [192.168.0.136] ([10.21.114.92]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jan 2009 07:31:42 -0800 Message-Id: <9D37B7AC-B13D-4388-A85D-70F23E1DB332@cisco.com> From: Fred Baker To: Eric Rescorla In-Reply-To: <20090113141834.672D5EAFAD@kilo.local> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 13 Jan 2009 07:31:41 -0800 References: <169DD93E-577A-4935-BCE1-351F145E836F@cisco.com> <20090113141834.672D5EAFAD@kilo.local> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 13 Jan 2009 15:31:42.0473 (UTC) FILETIME=[0914AF90:01C97594] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=830; t=1231860703; x=1232724703; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[secdir]=20Fwd=3A=20Agreement=20on=2025 =20Most=20Dangerous=20Programming=20Errors=09-=09And=20How=2 0to=20Fix |Sender:=20; bh=NVWr/RQf56RkRFEECbxKAlnTer5Lkrwo5bNPqPPKN2I=; b=oRO4/lLBiOiHg1yTYpyUR1+qFtvtAnGiV+ciyFY9yUxRAj9V37ie8o9DAh RFmMYfM+ojjiiS8KjF+VJyT45e46f995yC9bptT0AzS2Zc6rOtB5UAwEOZN9 TdxN74pUhoyTnEvZqwUjS0dPZKTyIeUiB8/W09Jm+5JCn26EYTj8A=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: secdir@mit.edu Subject: Re: [secdir] Fwd: Agreement on 25 Most Dangerous Programming Errors - And How to Fix X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Thanks On Jan 13, 2009, at 6:18 AM, Eric Rescorla wrote: > At Mon, 12 Jan 2009 15:48:19 -0800, > Fred Baker wrote: >> >> Dumb question... >> >> Back when I was the chair of the IETF, I asked our security folks for >> a list of obvious attacks, so I could make them available to other >> working groups asking them to think about them when designing >> whatever >> they designed. The security directorate didn't provide one, but I >> ultimately found something kinda sorta like that in a doctoral thesis >> somewhere, and put the information online. The information is long >> gone - someone decided it should disappear. >> >> Is there a good list of obvious attacks that could be used by the >> IETF >> to save you guys from having to find them? > > http://www.isi.edu/in-notes/rfc3552.txt > > -Ekr _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Jan 15 04:31:57 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF7BE3A690B; Thu, 15 Jan 2009 04:31:57 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D4B3A68D8 for ; Thu, 15 Jan 2009 04:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNllVW2qNpBL for ; Thu, 15 Jan 2009 04:31:56 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id EF14828C0E9 for ; Thu, 15 Jan 2009 04:31:55 -0800 (PST) Received: from peirce.dave.cridland.net ([217.155.137.61]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 15 Jan 2009 12:31:29 +0000 Message-Id: <12062.1232022687.601541@peirce.dave.cridland.net> Date: Thu, 15 Jan 2009 12:31:27 +0000 From: Dave Cridland To: Security Area Directorate MIME-Version: 1.0 Cc: pce-chairs@tools.ietf.org, draft-ietf-pce-of@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-pce-of X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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. Apologies for the lateness - executive summary - nothing to worry about. The document descibes a mechanism for path computation clients to request and receive the criteria by which a route was selected. These criteria are classed as Objective Functions, and include such criteria as "shortest", "fastest", etc, and are defined elsewhere. The security considerations section is fairly short, and I think it covers everything. Specifically, it states that: a) The security provided by PCEP itself isn't changed by the addition of OF objects in messages - the new objects are attached to existing messages, and secured as part of the PCEP session itself. (PCEP itself uses TCP-MD5, which isn't hugely secure, but given the nature of the deployments, seems reasonable in the short term). b) The additional possibilities for an attack offered by the addition of OF objects are not considered significant. I agree with this assessment - objective functions need not be disclosed by the PCE, and a PCC's mandatory requests can be rejected. I don't see any useful attack that could be mounted purely by changing the routing criteria in a running session by injection, nor any useful disclosure found by passive observation of the objective functions used. Dave. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Jan 15 06:10:44 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69F413A696B; Thu, 15 Jan 2009 06:10:44 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5642C28C20D for ; Thu, 15 Jan 2009 05:00:40 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2eWI0xdEs6x for ; Thu, 15 Jan 2009 05:00:39 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 8B3DA28C200 for ; Thu, 15 Jan 2009 05:00:38 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0FD0NO5032180 for ; Thu, 15 Jan 2009 08:00:23 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0FD0GBU032150 for ; Thu, 15 Jan 2009 08:00:19 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n0FD09VG014098 for ; Thu, 15 Jan 2009 08:00:09 -0500 (EST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu (Spam Firewall) with ESMTP id 4272CD2B06B for ; Thu, 15 Jan 2009 07:59:51 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09DC528C240; Thu, 15 Jan 2009 05:00:05 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 12AED28C1E7; Thu, 15 Jan 2009 05:00:01 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090115130002.12AED28C1E7@core3.amsl.com> Date: Thu, 15 Jan 2009 05:00:02 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Approved-At: Thu, 15 Jan 2009 06:10:43 -0800 Subject: [secdir] [New-work] WG Review: Recharter of Network Configuration (netconf) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org A modified charter has been submitted for the Network Configuration (netconf) working group in the Operations and Management Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Thursday, January 22, 2009. Network Configuration (netconf) ================================ Last Modified: 2008-12-16 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/netconf Chair(s): Bert Wijnen Mehmet Ersue Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Technical Advisor(s): Charlie Kaufman Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: netconf-request@ietf.org In Body: in msg body: subscribe Archive: http://www.ietf.org/mail-archive/web/netconf/ Description of Working Group: Charlie Kaufman is Technical Advisor for Security Matters Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanisms or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF Working Group is chartered to produce a protocol suitable for network configuration, with the following characteristics: - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough so that vendors will provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) - Uses a textual data representation, that can be easily manipulated using non-specialized text manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports network wide configuration transactions (with features such as locking and rollback capability) - Is as transport-independent as possible - Provides support for asynchronous notifications. The NETCONF protocol is using XML for data encoding purposes, because XML is a widely deployed standard which is supported by a large number of applications. The NETCONF protocol should be independent of the data definition language and data models used to describe configuration and state data. However, the authorization model used in the protocol is dependent on the data model. Although these issues must be fully addressed to develop standard data models, only a small part of this work will be initially addressed. This group will specify requirements for standard data models in order to fully support the NETCONF protocol, such as: - identification of principals, such as user names or distinguished names - mechanism to distinguish configuration from non-configuration data - XML namespace conventions - XML usage guidelines The initial work started in 2003 and has already been completed and was restricted to following items: a) NETCONF Protocol Specification, which defines the operational model, protocol operations, transaction model, data model requirements, security requirements, and transport layer requirements. b) NETCONF over SSH Specification: Implementation Mandatory, c) NETCONF over BEEP Specification: Implementation Optional, d) NETCONF over SOAP Specification: Implementation Optional. These documents define how the NETCONF protocol is used with each transport protocol selected by the working group, and how it meets the security and transport layer requirements of the NETCONF Protocol Specification. e) NETCONF Notification Specification, which defines mechanisms that provide an asynchronous message notification delivery service for the NETCONF protocol. NETCONF Notification is an optional capability built on top of the base NETCONF definition and provides the capabilities and operations necessary to support this service. The NETCONF notification specification has been finished now as well. In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. Fine-grain locking: The base NETCONF protocol only provides a lock for the entire configuration datastore, which is not deemed to meet important operational and security requirements. The NETCONF working group will produce a standards-track RFC specifying a mechanism for fine-grain locking of the NETCONF configuration datastore. 2. NETCONF monitoring: It is considered best practice for IETF working groups to include management of their protocols within the scope of the solution they are providing. The NETCONF working group will produce a standards-track RFC with mechanisms allowing NETCONF itself to be used to monitor some aspects of NETCONF operation. 3. Schema advertisement: Currently the NETCONF protocol is able to advertise which protocol features are supported on a particular netconf-capable device. However, there is currently no way to discover which XML Schema are supported on the device. The NETCONF working group will produce a standards-track RFC with mechanisms making this discovery possible (this item may be merged with "NETCONF monitoring" into a single document). Note: The schema-advertisement material has been merged into the NETCONF monitoring document based on WG consensus. 4. NETCONF over TLS: Based on implementation experience there is a need for a standards track document to define NETCONF over TLS as an optional transport for the NETCONF protocol. 5. NETCONF default handling: NETCONF today does not define whether default values should be returned by the server in replies to requests for reading configuration and state data. Different clients have different needs to receive or not to receive default data. The NETCONF working group will produce a standards-track RFC defining a mechanism that allows NETCONF clients to control whether default data is returned by the netconf server. 6. NETCONF implementations have shown that the specification in RFC4741 is not 100% clear and has lead to different interpretations and implementations. Also some errors have been uncovered. So the WG will do an rfc4741bis with following constraints: - bug fixes are to be done - clarifications can be done - extensions can be done only when needed to fix bugs or inconsistencies (i.e. we are not doing a NETCONF V2) - The work can be started based on the discussion in IETF #73 (see http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf). Note: A technical errata has been posted on rfc4742. If the work on rfc4741bis uncovers any additional fixes/clarifications that need to be made to rfc4742, the WG may consider to also do a rfc4742bis as part of this work-item. The following items have been identified as important but are currently not considered in scope for re-chartering and may be candidates for work when there is community consensus to take them on: - NETCONF Notification content - Access Control requirements - NETCONF access to SMI-based MIB data Goals and Milestones: Done Working Group formed Done Submit initial Netconf Protocol draft Done Submit initial Netconf over (transport-TBD) draft Done Begin Working Group Last Call for the Netconf Protocol draft Done Begin Working Group Last Call for the Netconf over (transport-TBD) draft Done Submit final version of the Netconf Protocol draft to the IESG Done Submit final version of the Netconf over SOAP draft to the IESG Done Submit final version of the Netconf over BEEP draft to the IESG Done Submit final version of the Netconf over SSH draft to the IESG Done Update charter Done Submit first version of NETCONF Notifications document Done Begin WGLC of NETCONF Notifications document Done Submit final version of NETCONF Notifications document to IESG for consideration as Proposed Standard Done -00 draft for fine Grain Locking Done -00 draft for NETCONF over TLS Done -00 draft for NETCONF Monitoring Done -00 draft for Schema Advertisement Done Early Review of client authentication approach (for NETCONF over TLS) with the security community at IETF 71 N.A. WG Last Call on Schema Advertisement after IETF72 Schema Advertisement has been merged into Monitoring Done WG Last Call on NETCONF over TLS after IETF72 Done Netconf over TLS to IESG for consideration as Proposed Standards Dec 2008 WG Last Call on Fine Grain Locking after IETF73 Dec 2008 Send Partial Locking to IESG for consideration as Proposed Standards Jan 2009 Initial WG draft for with-defaults capability Feb 2009 Initial WG draft for rfc4741bis Mar 2009 WG Last Call on NETCONF Monitoring after IETF73 Apr 2009 WG Last Call on rfc4741bis Apr 2009 WG Last Call on with-defaults Jun 2009 rfc4741bis to IESG for considerations as Proposed Standard Jun 2009 with-defaults capability to IESG for considerations as Proposed Standard _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Jan 15 09:28:58 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 285FE3A69F6; Thu, 15 Jan 2009 09:28:58 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F353A6A35 for ; Thu, 15 Jan 2009 09:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.607 X-Spam-Level: X-Spam-Status: No, score=-105.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58xzCl5TGL47 for ; Thu, 15 Jan 2009 09:27:23 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 816553A69C7 for ; Thu, 15 Jan 2009 09:27:23 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0FHR8k3030345 for ; Thu, 15 Jan 2009 12:27:08 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0FHR4T5030326 for ; Thu, 15 Jan 2009 12:27:06 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n0FHQsnr023274 for ; Thu, 15 Jan 2009 12:26:57 -0500 (EST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu (Spam Firewall) with ESMTP id 27813D264FD for ; Thu, 15 Jan 2009 12:26:37 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D7528C24F; Thu, 15 Jan 2009 09:26:51 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 77F4B3A6AAD; Wed, 14 Jan 2009 12:32:49 -0800 (PST) From: IETF Secretariat To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090114203249.77F4B3A6AAD@core3.amsl.com> Date: Wed, 14 Jan 2009 12:32:49 -0800 (PST) X-Mailman-Approved-At: Thu, 15 Jan 2009 09:26:50 -0800 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Approved-At: Thu, 15 Jan 2009 09:28:56 -0800 Subject: [secdir] [New-work] WG Review: Recharter of IP Performance Metrics (ippm) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org A modified charter has been submitted for the IP Performance Metrics (ippm) working group in the Transport Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, January 21, 2009. IP Performance Metrics (ippm) -------------------------------------------- Last Modified: 2008-12-19 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/ippm Chair(s): Matthew Zekauskas [matt@internet2.edu] Henk Uijterwaal [henk@ripe.net] Transport Area Director(s): Magnus Westerlund magnus.westerlund@ericsson.com] Lars Eggert [lars.eggert@nokia.com] Transport Area Advisor: Lars Eggert [lars.eggert@nokia.com] Mailing Lists: General Discussion: ippm@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/ippm In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/ippm/index.html Description of Working Group: The IPPM WG has developed a set of standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services. These metrics are designed such that they can be performed by network operators, end users, or independent testing groups. It is important that the metrics not represent a value judgment (i.e. define "good" and "bad"), but rather provide unbiased quantitative measures of performance. Functions peripheral to Internet data delivery services, such as NOC/NIC services, are beyond the scope of this working group. The IPPM WG has produced documents that define specific metrics and procedures for accurately measuring and documenting these metrics. This is the current list of fundamental metrics and the existing set of derived metrics. - connectivity - one-way delay and loss - round-trip delay. - delay variation - loss patterns - packet reordering - bulk transport capacity - link bandwidth capacity - packet duplication The working group will advance these metrics along the standards track within the IETF. It will be guided by applicable IESG documents in this area. Additionally, the WG will produce Proposed Standard AS documents, comparable to applicability statements in RFC 2026, that will focus on procedures for measuring the individual metrics and how these metrics characterize features that are important to different service classes, such as bulk transport, periodic streams, packet bursts or multimedia streams. Each AS document will discuss the performance characteristics that are pertinent to a specified service class; clearly identify the set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of testing results. The AS documents can also discuss the use of the metrics to verify performance expectations, such as SLA's, report results to specific user groups or investigate network problems. The focus is, again, to define how this should be done, not to define a value judgment. The WG may define additional statistics for its metrics if needed. Specific topics of these AS documents must be approved by the Area Directors as charter additions. The WG will work on documents describing how to compose and decompose the results of its metrics over time or space. The WG has produced protocols to enable communication among test equipment that implements the one- and two-way metrics (OWAMP and TWAMP respectively). OWAMP and TWAMP will be advanced along the standards track. Further development of these protocols will also be done inside the WG. The metrics developed by the WG were developed inside an active measurement context, that is, the devices used to measure the metrics produce their own traffic. However, most metrics can be used inside a passive context as well. No work is planned is this area though, this may be changed with AD approval. The intent of the WG is to cooperate with other appropriate standards bodies and forums (such as ATIS IIF, ITU-T SG 12, 13 and 15, MEF) to promote consistent approaches and metrics. Within the IETF process, IPPM metrics definitions will be subject to as rigorous a scrutiny for usefulness, clarity, and accuracy as other protocol standards. The IPPM WG will interact with other areas of IETF activity whose scope intersect with the requirement of these specific metrics. The WG will, on request, provide input to other IETF WG on the use of these metrics. _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Jan 15 09:28:58 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A0333A6A5D; Thu, 15 Jan 2009 09:28:58 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DCBA3A69C7 for ; Thu, 15 Jan 2009 09:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qbCz4RpwFpJ for ; Thu, 15 Jan 2009 09:27:58 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 194B63A69AA for ; Thu, 15 Jan 2009 09:27:58 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0FHRh1Z030443 for ; Thu, 15 Jan 2009 12:27:43 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0FHRgnH030440 for ; Thu, 15 Jan 2009 12:27:42 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n0FHRWAk024286 for ; Thu, 15 Jan 2009 12:27:32 -0500 (EST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu (Spam Firewall) with ESMTP id 0144CD437C8 for ; Thu, 15 Jan 2009 12:26:37 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E676928C26C; Thu, 15 Jan 2009 09:26:51 -0800 (PST) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C655A3A6AAE for ; Wed, 14 Jan 2009 18:22:24 -0800 (PST) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARHOpboUE4vy for ; Wed, 14 Jan 2009 18:22:23 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 7C4163A679F for ; Wed, 14 Jan 2009 18:22:23 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1LNHru-0007b9-35 for public-new-work-dist@listhub.w3.org; Thu, 15 Jan 2009 02:22:02 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1LNHrg-0007aW-0e for public-new-work@listhub.w3.org; Thu, 15 Jan 2009 02:21:48 +0000 Received: from a.mail.sonic.net ([64.142.16.245]) by bart.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1LNHrP-00073Q-KE for public-new-work@w3.org; Wed, 14 Jan 2009 21:21:47 -0500 Received: from pickering (corp-241.mountainview.mozilla.com [63.245.220.241]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id n0F2L2bt027785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jan 2009 18:21:03 -0800 Received: by pickering (Postfix, from userid 1000) id 2C44B3A054; Thu, 15 Jan 2009 02:21:02 +0000 (UTC) Date: Wed, 14 Jan 2009 18:21:01 -0800 From: "L. David Baron" To: public-new-work@w3.org Message-ID: <20090115022101.GA5742@pickering.dbaron.org> References: <1228765514.1639.97.camel@localhost> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1228765514.1639.97.camel@localhost> User-Agent: Mutt/1.5.18 (2008-05-17) Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: bart.w3.org 1LNHrP-00073Q-KE 1c46b41859a56be9407d955b336c9200 X-Original-To: public-new-work@w3.org Archived-At: Resent-From: public-new-work@w3.org X-Mailing-List: archive/latest/37 X-Loop: public-new-work@w3.org Resent-Sender: public-new-work-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Thu, 15 Jan 2009 02:22:02 +0000 X-Mailman-Approved-At: Thu, 15 Jan 2009 09:26:50 -0800 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Approved-At: Thu, 15 Jan 2009 09:28:56 -0800 Subject: Re: [secdir] [New-work] Proposed W3C Charter: Fonts Working Group (until 2009-01-14) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On Monday 2008-12-08 19:45 +0000, Ian B. Jacobs wrote: > Today W3C Advisory Committee Representatives received a Proposal > for a new Fonts Activity [0] (see the W3C Process > Document description of Activity Proposals [1]). This proposal > includes a draft charter for the Fonts Working Group: > http://www.w3.org/Fonts/Misc/charter-2008-v2 The comments Mozilla sent as part of this Advisory Committee review are below. -David 4. Support for the Proposal =========================== My organization: ( ) supports this Activity Proposal as is. ( ) suggests changes to this Activity Proposal, but support the proposal whether or not the changes are adopted (your details below). (X) suggests changes to this Activity Proposal, and only support the proposal if the changes are adopted (your details below). ( ) opposes this Activity Proposal and requests that this group be closed (your details below). ( ) abstains from this review. Comments (or a URI pointing to your comments): Our most significant objection to the current charter is that, as described in http://lists.w3.org/Archives/Member/w3c-ac-forum/2008OctDec/0371.html , the scope section restricts the deliverables of the group to those in which the font resource is specific to a particular or set of documents. This is in spite of compromises being under discussion that did not have this restriction; for an example see http://lists.w3.org/Archives/Public/www-style/2008Nov/0415.html . An alternative wording for the charter that would address our concerns is contained in http://lists.w3.org/Archives/Member/w3c-ac-forum/2008OctDec/0410.html . Additionally, we are somewhat concerned given the churn on this charter about whether W3C really is a neutral forum here. There seems to be a pretty strong pull from W3C towards root string-based solutions, and I think the companies of both proposed WG chairs are advocating such solutions. Having a co-chair from the other side of this debate might help make the group a more neutral forum. 5. Participation ================ If this proposal is approved, my organization would be interested in participating in the following groups. Note: This answer is non-binding; after the review a formal Call for Participation will be sent for each approved charter. [X] Fonts Working Group 6. Support for Deliverables of the group ======================================== My organization: [X] intends to review drafts as they are published and send comments. [X] intends to develop experimental implementations and send experience reports (your details below). [X] intends to develop products based on this work (your details below). [ ] intends to apply this technology in our operations. [ ] would be interested in participating in any press activity connected with this group. Comments (or a URI pointing to your comments): 7. Expected Implementation Schedules ==================================== If you expect to implement some deliverables of this Activity, please indicate any known schedule for such implementations, without commitment. Comments (or a URI pointing to your comments): In Firefox 3.1, expected in the first half of this year, we expect to ship support for downloadable TrueType/OpenType fonts, with a default same-origin restriction that can be relaxed by the server providing the font using access-control. 8. Detailed Comments, Reasons, or Modifications =============================================== In addition to any comments you may have, please provide details about your answers. This may include, but is not restricted to, technical issues or issues associated with patent claims associated with the specification. Comments (or a URI pointing to your comments): Our review of the previous proposed charter contains a more general statement of our position on downloadable fonts; see http://lists.w3.org/Archives/Public/public-new-work/2008Nov/0001.html -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/ _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Jan 15 14:19:00 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9772F28C0F8; Thu, 15 Jan 2009 14:19:00 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CE9C28C0F8 for ; Thu, 15 Jan 2009 14:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zz5jPFsa-qaC for ; Thu, 15 Jan 2009 14:18:58 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 9B5C13A68F2 for ; Thu, 15 Jan 2009 14:18:58 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n0FMIg0C085851 for ; Thu, 15 Jan 2009 17:18:42 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n0FMIgfo085847 for ; Thu, 15 Jan 2009 17:18:42 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 15 Jan 2009 17:18:42 -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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (fledge.watson.org [127.0.0.1]); Thu, 15 Jan 2009 17:18:43 -0500 (EST) Subject: [secdir] Assignments for January 22nd X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org About twelve new assignments below. Chris Lonvick is next in the rotation. The next telechat is January 29th. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam Telechat, January 29th: Charlie Kaufman T draft-ietf-idr-flow-spec-03 Tero Kivinen T draft-ietf-pkix-rfc4055-update-01 Last calls and special requests: Derek Atkins draft-ietf-avt-post-repair-rtcp-xr-04 Rob Austein draft-ietf-dime-qos-parameters-08 Alan DeKok draft-ietf-roll-home-routing-reqs-06 Lakshminath Dondeti draft-ietf-speermint-terminology-17 Stephen Farrell draft-melnikov-sieve-imapext-metadata-08 Phillip Hallam-Baker draft-ietf-radext-design-05 Phillip Hallam-Baker draft-atlas-icmp-unnumbered-06 Steve Hanna draft-ietf-radext-management-authorization-06 Steve Hanna draft-ietf-eai-downgrade-10 Sam Hartman draft-farrel-rtg-common-bnf-07 Paul Hoffman draft-ietf-behave-turn-12 Love Hornquist-Astrand draft-ietf-ccamp-gr-description-03 Jeffrey Hutzelman draft-ietf-ccamp-pc-and-sc-reqs-06 Scott Kelly draft-ietf-tsvwg-rsvp-proxy-approaches-06 Scott Kelly draft-ietf-mediactrl-architecture-04 Stephen Kent draft-ietf-mediactrl-vxml-03 Angelos Keromytis draft-ietf-mext-nemo-mib-04 Julien Laganier draft-ietf-sip-certs-07 Marcus Leech draft-ietf-tls-ecdhe-psk-05 Barry Leiba draft-ietf-tls-psk-new-mac-aes-gcm-05 Catherine Meadows draft-ietf-speechsc-mrcpv2-17 Sandy Murphy draft-ietf-mpls-mpls-and-gmpls-security-framework-04 Vidya Narayanan draft-ietf-sip-saml-05 Eric Rescorla draft-wing-sipping-srtp-key-04 Susan Thomson draft-loreto-simple-im-srv-label-02 Sam Weiler draft-chown-v6ops-rogue-ra-02 Brian Weis draft-ietf-sieve-mime-loop-08 Brian Weis draft-ietf-pim-sm-linklocal-05 Nico Williams draft-ietf-v6ops-ra-guard-01 Larry Zhu draft-thaler-v6ops-teredo-extensions-02 Glen Zorn draft-andreasen-sipping-rfc3603bis-07 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Jan 16 02:05:17 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09F793A6AA8; Fri, 16 Jan 2009 02:05:17 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B58C63A6A9F; Fri, 16 Jan 2009 02:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpAkl+Jp9wY8; Fri, 16 Jan 2009 02:05:15 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 871BD3A6A99; Fri, 16 Jan 2009 02:05:14 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n0GA4t0H020426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 12:04:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0GA4sZQ001662; Fri, 16 Jan 2009 12:04:54 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18800.23494.272977.262435@fireball.kivinen.iki.fi> Date: Fri, 16 Jan 2009 12:04:54 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 10 min Cc: pkix-chairs@tools.ietf.org, draft-ietf-pkix-rfc4055-update@tools.ietf.org Subject: [secdir] Review of draft-ietf-pkix-rfc4055-update-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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 updates RFC4055 "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" by changing one SHOULD to MUST NOT for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field. I am not completely sure if the Security Considerations section is enough. Now it says: The security considerations from [RFC4055] apply. No new security considerations are introduced. but considering that this moves some bits away from the certificate and says that they should be negotiated in protocols that need to employ certificates, this might create new security issues, i.e. it might put some more emphasis on the security of the protocol used to negotiate those parameters. I do not really know enough, about what kind of parameters there are to be negotiated in the protocols employing certificates, to know if this is really the case. Perhaps someone who is understands better what is moved here, should look this issue. -- kivinen@iki.fi _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Jan 16 03:24:51 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEF8F28C245; Fri, 16 Jan 2009 03:24:51 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FB2328C24B; Fri, 16 Jan 2009 03:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYLsjuMJzZdl; Fri, 16 Jan 2009 03:24:49 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 4601228C247; Fri, 16 Jan 2009 03:24:48 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n0GBOVr9026150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 13:24:31 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0GBOUjq026718; Fri, 16 Jan 2009 13:24:30 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18800.28270.570094.42716@fireball.kivinen.iki.fi> Date: Fri, 16 Jan 2009 13:24:30 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 11 min Cc: draft-ietf-softwire-mesh-framework-05.txt@tools.ietf.org, softwire-chairs@tools.ietf.org Subject: [secdir] Review of draft-ietf-softwire-mesh-framework-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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 have already reviewed 04 version of this document at 2008-06-04 and the -05 version seems to take my comments in to account. I noticed one other comment. The current draft says: Since the softwires are set up dynamically as a byproduct of passing routing information, key distribution MUST be done automatically by means of IKEv2 [RFC4306], operating in main mode with preshared keys. First of all, the IKEv2 does not have "main mode" anymore, that term is from IKEv1. It would be best to remove that completely. Also this text seems to say that implementations MUST use preshared keys, i.e. certificates are not allowed, and I do not think that was what was meant. Especially as the next sentence says: If a PKI (Public Key Infrastructure) is not available, the IPsec Tunnel Authenticator sub-TLV described in [ENCAPS-IPSEC] MUST be used and validated before setting up an SA. So it is no clear what is mandated. The IKEv2 protocol already specifies that both RSA signatures and shared keys are mandatory to implement. This text here seems to mandate the operation part, and that sounds bit too strict. It might be better to just remove the ", operating in main mode with preshared keys." part completely and simply say that IKEv2 MUST be used. -- kivinen@iki.fi _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Jan 16 03:39:42 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF8928C256; Fri, 16 Jan 2009 03:39:42 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 092FA3A6917; Fri, 16 Jan 2009 03:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFh5WXqaGCpm; Fri, 16 Jan 2009 03:39:40 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 08B243A6821; Fri, 16 Jan 2009 03:39:39 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n0GBY8ru026337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 13:34:08 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0GBY8Rl003699; Fri, 16 Jan 2009 13:34:08 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18800.28848.478596.68840@fireball.kivinen.iki.fi> Date: Fri, 16 Jan 2009 13:34:08 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min Cc: draft-ietf-softwire-v4nlri-v6nh@tools.ietf.org, softwire-chairs@tools.ietf.org Subject: [secdir] Review of draft-ietf-softwire-v4nlri-v6nh-01.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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 have already reviewed 00 version of this document at 2008-04-15 and the -01 version seems to take my comments in to account. I have no more comments to this document. -- kivinen@iki.fi _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Jan 16 03:44:29 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D9513A6AA5; Fri, 16 Jan 2009 03:44:29 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E4C3A6917; Fri, 16 Jan 2009 03:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7WSqWnwj-b3; Fri, 16 Jan 2009 03:44:27 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 9FC6C3A684C; Fri, 16 Jan 2009 03:44:26 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n0GBiA7A020000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 13:44:10 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0GBiAG3016803; Fri, 16 Jan 2009 13:44:10 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18800.29450.18377.151298@fireball.kivinen.iki.fi> Date: Fri, 16 Jan 2009 13:44:10 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 3 min Cc: draft-ietf-softwire-encaps-safi@tools.ietf.org, softwire-chairs@tools.ietf.org Subject: [secdir] Review of draft-ietf-softwire-encaps-safi-04.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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 have already reviewed 02 version of this document at 2008-06-04 and the -04 version seems to take my comments in to account. I have no more comments to this document. -- kivinen@iki.fi _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Jan 16 04:01:33 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E5873A6821; Fri, 16 Jan 2009 04:01:33 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933413A68B0; Fri, 16 Jan 2009 04:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3BzjKTVgbfh; Fri, 16 Jan 2009 04:01:31 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id DD2F23A6821; Fri, 16 Jan 2009 04:01:30 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n0GC1Dn5010575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 14:01:13 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0GC1Dss027633; Fri, 16 Jan 2009 14:01:13 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18800.30473.456119.940467@fireball.kivinen.iki.fi> Date: Fri, 16 Jan 2009 14:01:13 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min Cc: draft-ietf-softwire-encaps-ipsec@tools.ietf.org, softwire-chairs@tools.ietf.org Subject: [secdir] Review of draft-ietf-softwire-encaps-ipsec-01.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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 have already reviewed 00 version of this document at 2008-04-08 and the -01 version seems to take my comments in to account. I have no more comments to this document. -- kivinen@iki.fi _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Jan 16 04:11:10 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A553F3A680E; Fri, 16 Jan 2009 04:11:10 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4BC928C1FB for ; Fri, 16 Jan 2009 03:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.403 X-Spam-Level: X-Spam-Status: No, score=-6.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7WvIe8+I5lF for ; Fri, 16 Jan 2009 03:06:31 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 0A8303A6824 for ; Fri, 16 Jan 2009 03:06:28 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0GB6BFd026416 for ; Fri, 16 Jan 2009 06:06:11 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0GB63IZ026405 for ; Fri, 16 Jan 2009 06:06:03 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n0GB5tY8012797 for ; Fri, 16 Jan 2009 06:05:55 -0500 (EST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 803BCD479A0 for ; Fri, 16 Jan 2009 06:05:33 -0500 (EST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1CC6E2050C; Fri, 16 Jan 2009 12:05:32 +0100 (CET) X-AuditID: c1b4fb3c-ae75fbb00000304c-36-497069fb48e2 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E3E9F2000F; Fri, 16 Jan 2009 12:05:31 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jan 2009 12:05:31 +0100 Received: from [159.107.24.233] ([159.107.24.233]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jan 2009 12:05:30 +0100 Message-ID: <497069FA.8010006@ericsson.com> Date: Fri, 16 Jan 2009 12:05:30 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090114 Shredder/3.0b2pre MIME-Version: 1.0 To: Richard Barnes References: <494AE067.8080201@bbn.com> In-Reply-To: <494AE067.8080201@bbn.com> X-OriginalArrivalTime: 16 Jan 2009 11:05:31.0061 (UTC) FILETIME=[589DDE50:01C977CA] X-Brightmail-Tracker: AAAAAA== X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Fri, 16 Jan 2009 04:11:09 -0800 Cc: draft-ietf-mmusic-file-transfer-mech@tools.ietf.org, SECDIR , IESG Subject: Re: [secdir] SECDIR review of draft-ietf-mmusic-file-transfer-mech-09 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Richard, Thanks for your review. Before addressing your comments, I would like to offer you a bit of background information. This draft addresses SDP and how SDP can be used to describe a file that is going to be transferred using "any other protocol". At the moment, the only "any other protocol" described in the document is MSRP, but there could be more in the future. Since the draft is about SDP, we try to avoid discussions about MSRP (including its security aspects). So, the goal is to extend SDP and use an off-the-shelf SIP (or any other higher layer signaling protocol) and MSRP (or any other file transfer protocol). We include a minimum discussion about MSRP, the minimum that is needed to implement the draft and provide interoperability. Please find some inline comments now. On 19/12/2008 0:44, Richard Barnes 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 describes an SDP syntax for signaling MSRP sessions that > are to be used *only* for a specific file transfer. I highlight the word > "only" because MSRP can already be used for file transfers, but the > intent of an SDP peer to use a particular MSRP session to transfer a > file cannot be signaled in SDP. This document adds syntax to SDP for > that signaling. > > Given the fact that MSRP can already handle file transfers, I was > expecting this document to address the security trade-offs associated > with explicitly signaling these transfers. The current Security > Considerations section focuses more on the traditional considerations > around confidentiality and integrity of files transferred over this > mechanism, without referencing the existing mechanisms in MSRP itself > (RFC 4975). As I indicated earlier, the document is focusing on SDP. Therefore, we should focus on SDP only, because when the implementor decides to use MSRP, it will use a standard off-the-shelf MSRP stack and he won't have a chance to change the security properties of MSRP. > > Overall, the document is well-written and comprehensible. However, there > are a few ambiguities in the main text, and some significant repairs > that need to be made to the Security Considerations. > > SECURITY COMMENTS: > > 1. The first paragraph of Section 10 is a non-sequitur: Lying about the > attributes defined in this document has nothing to do with > integrity-protection. The file sender can send a bad file that's still > bit-for-bit perfect as it goes over the wire. What this section should > recommend instead is that the file receiver MUST validate all available > parts of the file-selector attribute (in addition to integrity > protection). Similar text should be added to Section 8.2.2 and 8.3.2. > This validation prevents the file sender from lying about what he's > sending, and it prevents attackers that can't see the signaling from > sending bad files to the file receiver. I see your point. We need to distinguish between a rough file sender (who describes a file but sends another one) and an attacker that modifies the SDP. The latter can be easily tracked by using integrity protection in SDP. The former can only be tracked by validating the received file against the selectors of the file. I will add some text to mandate validation. With respect to Sections 8.2.2 and 8.3.2, there is already text in Section 8.2.2 to make the file receiver verify the hash (see second paragraph in 8.2.2). > > 2. The third paragraph of the Security Considerations (and parts of the > first two) should be replaced by a reference to RFC 4975, which has a > much more thorough discussion of integrity and confidentiality for MSRP. No, the third paragraph indicates how to protect the SDP Offer/answer, not how to protect the file transfer. As I said, the file transfer is not in the scope of the document. > > 3. There is no discussion of (1) authentication of file receivers or (2) > authorization of file transfers. Given that this extension enables the > "pull" pattern, this discussion is critical. For example, there's > nothing in this document to recommend that my UA not blindly return any > file that another UA asks for. I would recommend adding some text that > file transfers MUST be authorized by the file sender's local policy, and > that this authorization process MAY require that the file receiver be > authenticated. The latter requirement will need some discussion of > authentication, which can primarily be dealt with by referring to RFC 4975. > Right, there is a point. Essentially, we are assuming a high-level protocol, such as SIP, that brings some of this functions. For example, an SDP offer transported in a SIP INVITE request is generally never automatically accepted and typically always authenticated. I will add some text to the security considerations sections to highlight the assumptions on the high-level protocol. > OTHER COMMENTS: > > 1. The document discusses in detail when a change of file selector or > file-transfer-id should trigger a new transmission. The document also > seems to assume that a new transmission is only initiated after the > first transmission is canceled. It's not clear (to me, anyway) whether > this is in fact necessary, or whether a "new file transfer operation" > (as in Figure 3) could be initiated without canceling the current > operation. (Perhaps there's a port constraint here?) I think the text you are looking for is written in the first paragraph in Section 8.7, when we say that "one file equals one MSRP session". Therefore, it is not possible to re-use an existing MSRP session for sending a different file. This must not be confused with simultaneous MSRP sessions. It is possible to have two separate MSRP media streams, each sending a different file (or even one one being used for regular text chat). But each of these will be different MSRP sessions, and each MSRP session, one and only one file can be transmitted. > > 2. In Section 8.2.1, why is "name" a MAY for inclusion in the file > selector, while the others are MUSTs? The others (type, size, or hash) are not really mandatory. ONE of them is mandatory (anyone), but the others are optional. The reason: the sender has to include a minimum description of the file that is trying to send. This can be: here is a JPEG file, or here is a file or size xxx bytes, or here is a file whose hash is yyy. Or a combination of them. All these describe the file. However, the name is locally chosen, and does not describe the properties of the file. It is merely a label locally chosen by the sender, so, it does not describe the file nor it is of much value for the SDP answerer. > > 3. In Section 8.2.2, shouldn't it be "The file receiver ... MUST add at > least one of the selectors defined..." (instead of SHOULD)? What would > it mean for the recipient to send a blank file-selector? "Send me a > file! Any file!"? > That is right. I am changing it to MUST. There is one case where the file-selector attribute can be empty, but that is not part of the offer/answer model: it is to signal capabilities in a 200 response for an OPTIONS request (see Section 8.5 in the draft). Since the OPTIONS response is not part of the offer/answer model, then it is not impacted by the offer/answer procedures. Thanks for your review. We will be posting an updated version in the coming days. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Jan 16 06:37:19 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B12573A684F; Fri, 16 Jan 2009 06:37:19 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44B933A6836 for ; Fri, 16 Jan 2009 06:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPaR+CW6gr+m for ; Fri, 16 Jan 2009 06:37:16 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 07F163A684F for ; Fri, 16 Jan 2009 06:37:15 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0GEawj7008171 for ; Fri, 16 Jan 2009 09:36:58 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0GEaqAH008138 for ; Fri, 16 Jan 2009 09:36:52 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n0GEakqW025987 for ; Fri, 16 Jan 2009 09:36:47 -0500 (EST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 13BD814563F9 for ; Fri, 16 Jan 2009 09:36:26 -0500 (EST) Received: from col-dhcp33-244-160.bbn.com ([128.33.244.160] helo=Richard-Barnes-Laptop.local) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1LNpnw-00037N-AI; Fri, 16 Jan 2009 09:36:12 -0500 Message-ID: <49709B5B.40202@bbn.com> Date: Fri, 16 Jan 2009 09:36:11 -0500 From: Richard Barnes User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Miguel A. Garcia" References: <494AE067.8080201@bbn.com> <497069FA.8010006@ericsson.com> In-Reply-To: <497069FA.8010006@ericsson.com> X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-ietf-mmusic-file-transfer-mech@tools.ietf.org, SECDIR , IESG Subject: Re: [secdir] SECDIR review of draft-ietf-mmusic-file-transfer-mech-09 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Miguel, Thanks for your reply. A couple of responses below. (Some comments trimmed) --Richard > Thanks for your review. Before addressing your comments, I would like to > offer you a bit of background information. This draft addresses SDP and > how SDP can be used to describe a file that is going to be transferred > using "any other protocol". Thanks for the clarification. I still think a lot of my comments are still applicable, since they relate to how the SDP lines with the file-transfer protocol -- the part that's specific to this document. >> Given the fact that MSRP can already handle file transfers, I was >> expecting this document to address the security trade-offs associated >> with explicitly signaling these transfers. The current Security >> Considerations section focuses more on the traditional considerations >> around confidentiality and integrity of files transferred over this >> mechanism, without referencing the existing mechanisms in MSRP itself >> (RFC 4975). > > As I indicated earlier, the document is focusing on SDP. Therefore, we > should focus on SDP only, because when the implementor decides to use > MSRP, it will use a standard off-the-shelf MSRP stack and he won't have > a chance to change the security properties of MSRP. I agree with this, and think the document does a pretty good job of addressing the authenticity/integrity/confidentiality concerns for the SDP (my comment was poorly worded). However, what I meant to say was that the security properties of the file-transfer protocol are also important to the overall security of the file-transfer mechanism. So there should be some discussion of them here. For MSRP, it would suffice to cite RFC 4975; if you want to allow for others, you could include requirements for security features. >> 1. The first paragraph of Section 10 is a non-sequitur: Lying about the >> attributes defined in this document has nothing to do with >> integrity-protection. The file sender can send a bad file that's still >> bit-for-bit perfect as it goes over the wire. > I see your point. We need to distinguish between a rough file sender > (who describes a file but sends another one) and an attacker that > modifies the SDP. The latter can be easily tracked by using integrity > protection in SDP. The former can only be tracked by validating the > received file against the selectors of the file. I will add some text to > mandate validation. Thanks. I'll review this text when it's available. > With respect to Sections 8.2.2 and 8.3.2, there is already text in > Section 8.2.2 to make the file receiver verify the hash (see second > paragraph in 8.2.2). I saw that text, but I wondered why it's not a MUST. It would be nice to also have SHOULD-level requirements to verify other selector criteria as well. >> 2. The third paragraph of the Security Considerations (and parts of the >> first two) should be replaced by a reference to RFC 4975, which has a >> much more thorough discussion of integrity and confidentiality for MSRP. > > No, the third paragraph indicates how to protect the SDP Offer/answer, > not how to protect the file transfer. As I said, the file transfer is > not in the scope of the document. Acknowledged. I had misunderstood the intent of the first part of the Security Considerations. However, see my response above on the fact that the security of the file-transfer protocol needs to at least be mentioned in this document. > Right, there is a point. Essentially, we are assuming a high-level > protocol, such as SIP, that brings some of this functions. For example, > an SDP offer transported in a SIP INVITE request is generally never > automatically accepted and typically always authenticated. I will add > some text to the security considerations sections to highlight the > assumptions on the high-level protocol. That sounds good. It's OK to make assumptions like this, but there needs to be some text to say that it's necessary for the sender to be able to authenticate the receiver. (Otherwise, you end up with the moral equivalent of anonymous FTP!) >> 1. The document discusses in detail when a change of file selector or >> file-transfer-id should trigger a new transmission. The document also >> seems to assume that a new transmission is only initiated after the >> first transmission is canceled. It's not clear (to me, anyway) whether >> this is in fact necessary, or whether a "new file transfer operation" >> (as in Figure 3) could be initiated without canceling the current >> operation. (Perhaps there's a port constraint here?) > > I think the text you are looking for is written in the first paragraph > in Section 8.7, when we say that "one file equals one MSRP session". > Therefore, it is not possible to re-use an existing MSRP session for > sending a different file. > > This must not be confused with simultaneous MSRP sessions. It is > possible to have two separate MSRP media streams, each sending a > different file (or even one one being used for regular text chat). But > each of these will be different MSRP sessions, and each MSRP session, > one and only one file can be transmitted. Here's where I think the confusion lies: If I wanted to signal a new MSRP session to transfer a file with the same selector -- NOT cancel the current session, just initiate a second one -- my UA would send an offer that is identical to the first one except for the "file-transfer-id" attribute. This usage is not possible with the current text. This use case is not extraordinarily important, but it's not trivial either: E.g., if the selector had only the file-name and file-type portions filled in, then the same selector might match many files (say, different versions a log file that get rotated). I don't really care if this use case gets ruled out, but it would be helpful if you could clarify whether it's in or out. If it's out, no normative text needs to change. If it's in, you might need a different "cancel" mechanism than a change in file-transfer-id, but it seems like normal session-termination techniques (BYE) would apply. > That is right. I am changing it to MUST. There is one case where the > file-selector attribute can be empty, but that is not part of the > offer/answer model: it is to signal capabilities in a 200 response for > an OPTIONS request (see Section 8.5 in the draft). Since the OPTIONS > response is not part of the offer/answer model, then it is not impacted > by the offer/answer procedures. It's always nice to get something right :) It might be worth noting the special case, just so people are aware. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Jan 16 14:33:17 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2993A695E; Fri, 16 Jan 2009 14:33:17 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6587528B23E; Fri, 16 Jan 2009 14:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KzhlohqQene; Fri, 16 Jan 2009 14:33:07 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 520383A694C; Fri, 16 Jan 2009 14:33:07 -0800 (PST) Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.18.48) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 16 Jan 2009 14:34:26 -0800 Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.110.52]) by TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.18.48]) with mapi; Fri, 16 Jan 2009 14:32:51 -0800 From: Charlie Kaufman To: "'secdir@ietf.org'" , "'iesg@ietf.org'" , "roque@juniper.net" , "nsheth@juniper.net" , "raszuk@juniper.net" , "bgreene@juniper.net" , "danny@arbor.net" , "shares@ghs.com" , "yakov@juniper.net" , "rja@extremenetworks.com" , "schishol@nortel.com" Date: Fri, 16 Jan 2009 14:32:48 -0800 Thread-Topic: Secdir review of draft-ietf-idr-flow-spec-03.txt Thread-Index: Acl4Klwq+ZVKviSnR5G8YUub4tO7gA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-idr-flow-spec-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0996076601==" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org --===============0996076601== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_F009AC6CE159924ABD1E8B51049B9B5C711944A86CNAEXMSGC103re_" --_000_F009AC6CE159924ABD1E8B51049B9B5C711944A86CNAEXMSGC103re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am reviewing this document as part of the security directorate's ongoing = effort to review all IETF documents being processed by the IESG. These com= ments 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. Feel free to forward to any appropriate forum. This document specifies an extension to BGP to allow more granular filterin= g information for discriminating packet flows to be distributed between Aut= onomous Systems. The stated goal is to enable better protection from DDoS a= ttacks by pushing firewall style filtering upstream towards the initiators = of the DDoS traffic (though one could imagine other uses). So if a particul= ar destination is being attacked by enormous quantities of traffic from man= y sources but towards a particular address/port pair, upstream routers coul= d be asked to discard all traffic targeting that address/port pair. The sec= urity of the extended protocol leverages the security of BGP itself (such a= s it is), and it seems likely that any attacker who could exploit this prot= ocol to selectively block traffic would be able (even without this extensio= n) to block the same traffic - albeit in a less granular fashion). There are some issues that might have been discussed in the security consid= erations section but weren't: 1) There is no specification in this document as to whether the origi= n of the information in the extensions is manual or automated, and I don't = know whether this is likely to appear in a separate document. One could ant= icipate operational security problems if changes were not carefully managed= . For example, if the changes were automatically generated from an overwhel= med server, the rate at which the flow manipulation data could overwhelm BG= Ps ability to distribute it. I don't know whether BGP has built in lock-dow= n timers to prevent oscillation in networks or what the effects might be of= having BGP information in some ASs be several versions behind the BGP info= rmation in others. The size of the BGP information, which previously was ad= ministratively controlled, might also grow without bound with unknown effec= ts. 2) Using BGP to distribute information in response to attacks is cont= roversial (as discussed in the introduction of the document). An important = factor in its appropriateness is whether BGP can distribute the information= throughout the network quickly enough to be useful given the duration of t= he attacks. Some discussion of this issue (in particular estimated times) w= ould be helpful. 3) Enabling firewall-like capabilities in routers without centralized= management could make certain failures harder to diagnose. For example, wi= th the extensions it is possible to allow TCP packets to pass between a pai= r of addresses but not ICMP packets. It would also be possible to permit pa= ckets smaller than 900 or greater than 1000 bytes to pass between a pair of= addresses, but not packets whose length is in the range 900-1000. The Inte= rnet has become sufficiently aware of firewalls that such behavior is less = likely to be confusing than it was a few years ago, and there are no new ca= pabilities introduced by these extensions - just an increased likelihood th= at such capabilities will be used. 4) These extensions allow filtering based on TCP/UDP ports and other = detailed information in ordinary packets, but not in ESP or AH protected pa= ckets even when the packet contents are unencrypted. 5) Section 5 last paragraph: There is a statement that the neighborin= g AS must be the left-most field in the AS_PATH attribute for security reas= ons. What are the security reasons, and does this statement apply only to v= ersions of BGP processing this extension or to all versions. Some other issues that are not specifically security related: 1) There appears to be no explicit support for IPv6. It is not one of= the selection criteria, and address masks are specified with a prefix bit = length and a value. Since a prefix bit length and value could mean radicall= y different things in the IPv4 and IPv6 address spaces, this should be disa= mbiguated. (Or it's possible that separate instances of BGP exist for IPv4 = and IPv6, in which case there is no problem but it should probably mention = that in the spec when discussing address masks). 2) There were a large number of acronyms that were not defined (at le= ast not on first use). These are probably familiar to people working on BGP= , but it would be helpful to specify the RFCs in which acronym expansions/d= efinitions could be found. Among them: NLRI, RIBs, Loc-RIB, AS, VRF, and PE= . 3) Section 5 paragraph 2 references section 9.1.2. Since this documen= t has no section 9.1.2, I suspect it means section 9.1.2 of some other docu= ment. It should say which one. 4) Section 7 5th paragraph contains a number of grammatical errors (a= pparently based on editing a singular into a plural at the last minute. 5) Section 10 paragraph 3 requests that IANA allocate three constants= from the "BGP Extended Communities Type - Experimental Use" registry. Is t= his document targeting experimental status? If not, is that the right regis= try from which to get values? 6) Section 10 last paragraph says that future assignments to a regist= ry are to be made either through "Standards Action", "the Early IANA Alloca= tion process", or the "First Come First Served" policy. Doesn't each regist= ry (or at least each section of each registry) have to specify which of tho= se procedures is to be followed? --_000_F009AC6CE159924ABD1E8B51049B9B5C711944A86CNAEXMSGC103re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= I am reviewing this document as part of the security directorate's ongoing effor= t 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. Feel free to forward to any appropriate forum.

=  

= This document specifies an extension to BGP to allow more granular filtering information for discriminating packet flows to be distributed between Auton= omous Systems. The stated goal is to enable better protection from DDoS attacks b= y pushing firewall style filtering upstream towards the initiators of the DDo= S traffic (though one could imagine other uses). So if a particular destinati= on is being attacked by enormous quantities of traffic from many sources but t= owards a particular address/port pair, upstream routers could be asked to discard = all traffic targeting that address/port pair. The security of the extended prot= ocol leverages the security of BGP itself (such as it is), and it seems likely t= hat any attacker who could exploit this protocol to selectively block traffic w= ould be able (even without this extension) to block the same traffic – alb= eit in a less granular fashion).

=  

= There are some issues that might have been discussed in the security consideratio= ns section but weren’t:

=  

1)      = There is no specification in t= his document as to whether the origin of the information in the extensions is manual or automated, and I don’t know whether this is likely to appea= r in a separate document. One could anticipate operational security problems if changes were not carefully managed. For example, if the changes were automatically generated from an overwhelmed server, the rate at which the f= low manipulation data could overwhelm BGPs ability to distribute it. I don̵= 7;t know whether BGP has built in lock-down timers to prevent oscillation in networks or what the effects might be of having BGP information in some ASs= be several versions behind the BGP information in others. The size of the BGP information, which previously was administratively controlled, might also g= row without bound with unknown effects.

2)      = Using BGP to distribute inform= ation in response to attacks is controversial (as discussed in the introduction o= f the document). An important factor in its appropriateness is whether BGP ca= n distribute the information throughout the network quickly enough to be usef= ul given the duration of the attacks. Some discussion of this issue (in particular estimated times) would be helpful.

3)      = Enabling firewall-like capabil= ities in routers without centralized management could make certain failures harde= r to diagnose. For example, with the extensions it is possible to allow TCP pack= ets to pass between a pair of addresses but not ICMP packets. It would also be possible to permit packets smaller than 900 or greater than 1000 bytes to p= ass between a pair of addresses, but not packets whose length is in the range 900-1000. The Internet has become sufficiently aware of firewalls that such behavior is less likely to be confusing than it was a few years ago, and th= ere are no new capabilities introduced by these extensions – just an increased likelihood that such capabilities will be used.=

4)      = These extensions allow filteri= ng based on TCP/UDP ports and other detailed information in ordinary packets, = but not in ESP or AH protected packets even when the packet contents are unencrypted.

5)      = Section 5 last paragraph: Ther= e is a statement that the neighboring AS must be the left-most field in the AS_PAT= H attribute for security reasons. What are the security reasons, and does thi= s statement apply only to versions of BGP processing this extension or to all versions.

=  

= Some other issues that are not specifically security related:<= /p>

=  

1)      = There appears to be no explici= t support for IPv6. It is not one of the selection criteria, and address mask= s are specified with a prefix bit length and a value. Since a prefix bit leng= th and value could mean radically different things in the IPv4 and IPv6 addres= s spaces, this should be disambiguated. (Or it’s possible that separate instances of BGP exist for IPv4 and IPv6, in which case there is no problem= but it should probably mention that in the spec when discussing address masks).=

2)      = There were a large number of acronyms that were not defined (at least not on first use). These are proba= bly familiar to people working on BGP, but it would be helpful to specify the R= FCs in which acronym expansions/definitions could be found. Among them: NLRI, R= IBs, Loc-RIB, AS, VRF, and PE.

3)      = Section 5 paragraph 2 referenc= es section 9.1.2. Since this document has no section 9.1.2, I suspect it means section 9.1.2 of some other document. It should say which one.

4)      = Section 7 5th parag= raph contains a number of grammatical errors (apparently based on editing a sing= ular into a plural at the last minute.

5)      = Section 10 paragraph 3 request= s that IANA allocate three constants from the “BGP Extended Communities Type= – Experimental Use” registry. Is this document targeting experimental status? If not, is that the right registry from which to get values?

6)      = Section 10 last paragraph says= that future assignments to a registry are to be made either through “Stand= ards Action”, “the Early IANA Allocation process”, or the R= 20;First Come First Served” policy. Doesn’t each registry (or at least e= ach section of each registry) have to specify which of those procedures is to b= e followed?

 

 

--_000_F009AC6CE159924ABD1E8B51049B9B5C711944A86CNAEXMSGC103re_-- --===============0996076601== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir --===============0996076601==-- From secdir-bounces@ietf.org Sun Jan 18 23:11:20 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A801928C161; Sun, 18 Jan 2009 23:11:20 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3D063A6888; Fri, 16 Jan 2009 15:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.283 X-Spam-Level: X-Spam-Status: No, score=-6.283 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cfRJu+kPI7F; Fri, 16 Jan 2009 15:16:42 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 734853A6768; Fri, 16 Jan 2009 15:16:40 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSXEVQ5ALxLYOiF0MDDbyuP/wPftwh8H3@postini.com; Fri, 16 Jan 2009 15:16:27 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Fri, 16 Jan 2009 15:13:20 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jan 2009 15:13:20 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jan 2009 15:13:20 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jan 2009 15:13:19 -0800 Received: from sbalraj-t43.jnpr.net (cwlee-t43.jnpr.net [172.24.104.78] (may be forged)) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n0GNDIM98144; Fri, 16 Jan 2009 15:13:18 -0800 (PST) (envelope-from roque@juniper.net) Message-ID: <86B2DE82-98B0-48B4-B329-7150EEBBDFCA@juniper.net> From: Pedro Roque Marques To: Charlie Kaufman In-Reply-To: MIME-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 16 Jan 2009 15:13:18 -0800 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Jan 2009 23:13:19.0487 (UTC) FILETIME=[0506E0F0:01C97830] X-Mailman-Approved-At: Sun, 18 Jan 2009 23:11:20 -0800 Cc: "raszuk@juniper.net" , "schishol@nortel.com" , "nsheth@juniper.net" , "'secdir@ietf.org'" , "bgreene@juniper.net" , "rja@extremenetworks.com" , "danny@arbor.net" , "'iesg@ietf.org'" , "yakov@juniper.net" , "shares@ghs.com" Subject: Re: [secdir] Secdir review of draft-ietf-idr-flow-spec-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed"; DelSp="yes" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Charlie, I'll attempt to clarify some questions inline. On Jan 16, 2009, at 2:32 PM, Charlie Kaufman wrote: > I am reviewing 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. Feel = > free to forward to any appropriate forum. > > This document specifies an extension to BGP to allow more granular = > filtering information for discriminating packet flows to be = > distributed between Autonomous Systems. The stated goal is to enable = > better protection from DDoS attacks by pushing firewall style = > filtering upstream towards the initiators of the DDoS traffic = > (though one could imagine other uses). So if a particular = > destination is being attacked by enormous quantities of traffic from = > many sources but towards a particular address/port pair, upstream = > routers could be asked to discard all traffic targeting that address/ = > port pair. The security of the extended protocol leverages the = > security of BGP itself (such as it is), and it seems likely that any = > attacker who could exploit this protocol to selectively block = > traffic would be able (even without this extension) to block the = > same traffic =96 albeit in a less granular fashion). > > There are some issues that might have been discussed in the security = > considerations section but weren=92t: > > 1) There is no specification in this document as to whether = > the origin of the information in the extensions is manual or = > automated, and I don=92t know whether this is likely to appear in a = > separate document. We have seen deployments using automated detection systems (e.g. = Arbor) and manual configuration. > One could anticipate operational security problems if changes were = > not carefully managed. For example, if the changes were = > automatically generated from an overwhelmed server, the rate at = > which the flow manipulation data could overwhelm BGPs ability to = > distribute it. I believe this issue is no different from the origination of unicast = routes. Depending on the deployment, these can either be manually = configured or generated by provisioning systems / scripts. Would it suffice if the document spells out that when automated = systems are used care should be taken to their correctness and rate of = advertisement ? > I don=92t know whether BGP has built in lock-down timers to prevent = > oscillation in networks or what the effects might be of having BGP = > information in some ASs be several versions behind the BGP = > information in others. The size of the BGP information, which = > previously was administratively controlled, might also grow without = > bound with unknown effects. BGP has mechanisms to control these. e.g. it is common to limit the = number of prefixes that can be received from a particular peer. > 2) Using BGP to distribute information in response to attacks = > is controversial (as discussed in the introduction of the document). = > An important factor in its appropriateness is whether BGP can = > distribute the information throughout the network quickly enough to = > be useful given the duration of the attacks. Some discussion of this = > issue (in particular estimated times) would be helpful. This mechanism is appropriate to mitigate attacks that last dozens of = minutes or hours. It is not appropriate to address attacks that last = less than a minute. BGP propagation time is irrelevant in the equation. The detection time = is the bottleneck, specially when manual methods are considered. Today = that is the most common detection method: alarm raised in management = console, human intervention, phone call, manual config. > 3) Enabling firewall-like capabilities in routers without = > centralized management could make certain failures harder to = > diagnose. For example, with the extensions it is possible to allow = > TCP packets to pass between a pair of addresses but not ICMP = > packets. It would also be possible to permit packets smaller than = > 900 or greater than 1000 bytes to pass between a pair of addresses, = > but not packets whose length is in the range 900-1000. The Internet = > has become sufficiently aware of firewalls that such behavior is = > less likely to be confusing than it was a few years ago, and there = > are no new capabilities introduced by these extensions =96 just an = > increased likelihood that such capabilities will be used. That is a good point. You would like this reflected in the security = considerations ? > 4) These extensions allow filtering based on TCP/UDP ports and = > other detailed information in ordinary packets, but not in ESP or AH = > protected packets even when the packet contents are unencrypted. Correct. That is a typical limitation in filtering hardware. > 5) Section 5 last paragraph: There is a statement that the = > neighboring AS must be the left-most field in the AS_PATH attribute = > for security reasons. What are the security reasons, and does this = > statement apply only to versions of BGP processing this extension or = > to all versions. Since the verification procedure uses the neighbor AS in the AS_PATH = attribute [ b) no more-specific rules from a different AS], it becomes = necessary to enforce that the neighbor as is correct and as not been = faked. i.e. it must match the configuration. This rule is required = when this extension is in use. > > Some other issues that are not specifically security related: > > 1) There appears to be no explicit support for IPv6. It is not = > one of the selection criteria, and address masks are specified with = > a prefix bit length and a value. Since a prefix bit length and value = > could mean radically different things in the IPv4 and IPv6 address = > spaces, this should be disambiguated. (Or it=92s possible that = > separate instances of BGP exist for IPv4 and IPv6, in which case = > there is no problem but it should probably mention that in the spec = > when discussing address masks). IPv6 would be a different AFI, SAFI and go into a different BGP = database. > 2) There were a large number of acronyms that were not defined = > (at least not on first use). These are probably familiar to people = > working on BGP, but it would be helpful to specify the RFCs in which = > acronym expansions/definitions could be found. Among them: NLRI, = > RIBs, Loc-RIB, AS, VRF, and PE. Can easily be accommodated. > 3) Section 5 paragraph 2 references section 9.1.2. Since this = > document has no section 9.1.2, I suspect it means section 9.1.2 of = > some other document. It should say which one. The base BGP spec (RFC 4271). > 4) Section 7 5th paragraph contains a number of grammatical = > errors (apparently based on editing a singular into a plural at the = > last minute. > 5) Section 10 paragraph 3 requests that IANA allocate three = > constants from the =93BGP Extended Communities Type =96 Experimental = > Use=94 registry. Is this document targeting experimental status? If = > not, is that the right registry from which to get values? These are the values used in current deployments. At this point given = that the deployments are very limited in number it would be reasonable = to consider it experimental. > 6) Section 10 last paragraph says that future assignments to a = > registry are to be made either through =93Standards Action=94, =93the = > Early IANA Allocation process=94, or the =93First Come First Served=94 = > policy. Doesn=92t each registry (or at least each section of each = > registry) have to specify which of those procedures is to be followed? That is a good point. I'd be tempted to say that we should just follow = "first come first served". Would that be acceptable ? > > _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Jan 18 23:11:20 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC50828C17E; Sun, 18 Jan 2009 23:11:20 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632023A69DD; Fri, 16 Jan 2009 17:53:55 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEQxMKsX90Ae; Fri, 16 Jan 2009 17:53:53 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E839C3A698E; Fri, 16 Jan 2009 17:53:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,278,1231113600"; d="scan'208";a="231519830" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 17 Jan 2009 01:53:39 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n0H1rcd2004774; Fri, 16 Jan 2009 17:53:38 -0800 Received: from [171.70.225.15] (dhcp-171-70-225-15.cisco.com [171.70.225.15]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0H1rcVs026714; Sat, 17 Jan 2009 01:53:38 GMT Message-ID: <49713A22.8000708@cisco.com> Date: Fri, 16 Jan 2009 17:53:38 -0800 From: Abhay Roy User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Stephen Farrell References: <492D7E49.40101@cs.tcd.ie> <4949D751.4000508@cisco.com> <494A3DB5.30906@cs.tcd.ie> In-Reply-To: <494A3DB5.30906@cs.tcd.ie> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10977; t=1232157218; x=1233021218; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=akr@cisco.com; z=From:=20Abhay=20Roy=20 |Subject:=20Re=3A=20secdir=20review=20of=20draft-ietf-ospf- lls |Sender:=20; bh=x2T1L3AwMGkVkZc3d/tB2wZNBANDVu3gqlcmfKGOIIY=; b=rJM6BTjOFVqZmTNTqz/so0gnPB02mWrBRv/F5V1iWr9G4TOGKRNyuyt7G/ ZKQvnP8WoWQ8/DZ37k56tAFKtAyrElkPP04Ttwvr4+MIsAYuM53tabI+EjQ0 4y+DSjAUhq; Authentication-Results: sj-dkim-4; header.From=akr@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Mailman-Approved-At: Sun, 18 Jan 2009 23:11:20 -0800 Cc: secdir@ietf.org, ospf-chairs@ietf.org, draft-ietf-ospf-lls@tools.ietf.org, IESG Subject: Re: [secdir] secdir review of draft-ietf-ospf-lls X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Stephen, Thanks again for your comments. Please see inline: On 12/18/2008 4:10 AM, Stephen Farrell wrote: > Hiya, > > Abhay Roy wrote: >> Hi Stephen, >> >> Thanks for the very detailed review!. Please see inline: >> >> On 11/26/2008 8:50 AM, Stephen Farrell 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. >>> >>> The draft [1] specifies a way to add new extension TLVs to/after OSPF >>> packets and includes a way to authenticate those. >>> >>> I have a few things here that I think need attention, but they >>> can probably mostly be easily handled with additional clarifying >>> text. My comments are attached. >>> >>> Stephen. >>> >>> [1] http://tools.ietf.org/html/draft-ietf-ospf-lls >>> >>> >>> >>> >>> #1: Section 2.2 describes the use of the checksum field, but never >>> says what to >>> do if the checksum is wrong. Is just the LLS block igored or the >>> entire OSPF >>> message? >>> #2: Section 2.2 doesn't say whether the checksum bits (presumably >>> zero'd?) are >>> considered part of the LLS block when calculating the checksum. >> The behavior is the same as we do for standard OSPF packet, only >> difference being the scope is only the LLS block. I have added a >> clarifying text here (for the two points above): >> >> "The Checksum field contains the standard IP checksum for >> the entire contents of the LLS block. Before computing the >> checksum, the checksum field is set to 0. If the checksum >> is incorrect, LLS block MUST NOT be processed." > > Sorry to be dense, but does that mean that the entire > message is ignored or only the LLS block? I don't > really care, but think it ought be crystal clear. Only LLS block is discarded. I will revise this text a bit. >>> #3: I don't understand the reason for omitting the checksum if the >>> cryptographic authentication TLV is present. Since the spec doesn't >>> say what to >>> put in the checksum field in that case, the absence of the checksum >>> can't be >>> checked which'd lead the implementation to have to poke about looking >>> for the >>> crypto. TLV before it knows what to do. That seems error prone. At the >>> least, >>> more clarity as to the receiver actions is required. >> This is to keep things compatible with current OSPF standard. Please see >> the following quote from rfc2328 section D.4.3: >> >> (2) The checksum field in the standard OSPF header is not >> calculated, but is instead set to 0. >> >> I will add the explicit setting to 0 in the text: >> >> "Note that if the OSPF packet is cryptographically >> authenticated, the LLS data block MUST also be >> cryptographically authenticated. In this case, the regular >> LLS checksum is not calculated, but is instead set to 0." > > Fine. > >>> #4: If the OSPF packet is not cryptographically authenticated, is it >>> still ok >>> to include a cryptographic authentication TLV in the LLS? If so, what >>> should I >>> do if the LLS crypto. fails to validate? Simplest might be to insist that >>> either both are protected or neither is, but I don't know if that >>> matches the >>> requirements. >> It's not Ok as per this: >> "For the LLS block to >> be considered authentic, the Sequence Number in the CA-TLV MUST match >> the Sequence Number in the OSPFv2 packet header Authentication field. >> In the event of Sequence Number mismatch or Authentication failure, >> the whole LLS block MUST be ignored." > > Again I'm a bit dense, so I'd find it clearer if that said: "...MUST > match the Sequence Number in the OSPFv2 packet header Authentication > field (which MUST be present)." Sure, will add. >>> #5: Section 2.5 has no references and doesn't describe which algorithm >>> is to be >>> used, now how keying is achieved. Questions arising include: a) rfc 2328 >>> defines three types of authentication in appendix D, including Null >>> authentication - that one says to ignore the authentication field and >>> use the >>> checksum, which seems to conflict with what this draft says (if crypto >>> TLV >>> present, ignore checksum); >> In case of Null authentication, checksum is the only protection in both >> main OSPF payload and LLS block. In case of Crypto Authentication, >> checksums are set to 0, and digest is the one used to verify both parts. >> So I think they are consistent. > > Are you saying that Null authentication is allowed, and that in that > case there is no checksum, but that that's ok? If so, that is not at > all clear and seems quite odd - why add the Crypto Authentication TLV > to the LLS block at all then? Null auth requires checksum per rfc2328. Also, I will reword the text about CA-TLV to be present ONLY when the ospf message contains crypto digest. So Null auth or simple password (the case below) would never have a CA-TLV. >> b) similarly, the "simple password" method from 2328 >>> also seems to require checking the checksum. (It might be as easy to >>> just say >>> those two MUST NOT be used); >> If "simple password" is used it's just a way to deter a random >> miscofigured router from becoming part of OSPF routing domain. It's not >> exactly providing any protection, hence checksums are still necessary to >> protect both ospf payloads. > > But again, if simple password is allowed and the checksum is zero'd > (because the Crypto Authentication TLV is in the LLS block) then > something is broken. Also - why would you want to put the same > "simple password" in clear twice in the same message - once in the > OCSPv2 packet and once in the LLS? > > I think saying that the LLS Crypto Authentication TLV MUST use > the MD5 based scheme makes most sense. > >> c) I assume that the key lifecycle requirements >>> are the same as in 2328, appendix D.3 (if LLS is allowed to be >>> authenticated >>> when the OSPFv2 packet is not, then this could be an issue). >> Right. >> >>> #6: Is it ok to use the same key & alg on the different inputs if the >>> MD5 alg >>> from 2328 is re-used here with the same key and but different inputs? >>> In that >>> case the OSPFv2 packet will contain MD5(OSPFv2-packet||key||pad||len) >>> and the >>> LLS will contain MD5(LLS-data-block||key) where both the OSPFv2-packet >>> and the >>> LLS-data-block contain the same sequence number. I don't have a specific >>> problem that I can call out with that but do wonder if its ok. Ought >>> it be >>> looked at by some cryptgrapher? (If a HMAC option is available then >>> using that >>> would probably be better, or if a diiferent key, e.g. one derived from >>> the key >>> protecting the OSPFv2-packet, were used for the LLS that might also be >>> better. >>> But those would change the bits on the wire so might not be an option >>> anymore?) >> OSPFv2 packet MD5 is done with MD5(OSPFv2-packet) - note that it >> doesn't include the Authentication header. >> LLS block MD5 is done with MD5(LLS-data) - note that it doesn't include >> the CA-TLV. >> >> I know of implementation deployed with this algorithm for many years. > > Sure. I didn't imagine that this'd change, but its not the construct > that a crypto person'd choose (two related values being protected with > the same key based on a fairly broken hash function), so all I wanted > to say was that I think it might be good to get a cryptographer to > look it over if you (or someone) can. > > Separately, it might also be good to develop a new authentication > scheme not based on MD5 and (maybe) where a KDF is used to derive > a new key for the LLS block from the one used to protect the OCSP > packet. But of course, that'd be a bunch of work and I've no idea > if it'd be worthwhile or not. OSPF will also use SHA-1 and other SHA variants soon using the same CA type (please see draft-ietf-ospf-hmac-sha). So that should give us more stronger auth mechanisms. >>> #7: Presumably it is not ok to include a cryptographic authentiation >>> TLV in an >>> OSPFv3 packet? Might be worth a MUST NOT statement. >> Sure. Will add something to this effect. >> >>> #8: If the crypto TLV is not the last TLV, then are the subsequent TLVs >>> included in the "LLS data block" input to the crypto processing? I >>> think the >>> definition of the "LLS data block" as input to crypto processing needs >>> to be >>> clearer - maybe take D.4.3 from 2328 as an example if the same MD5 alg >>> is to be >>> used. >>> #9: If there are specific reasons why the crypto TLV might not be the >>> last one, >>> that'd be worth noting. >>> #10: The cryptographic TLV doesn't (I think) protect the overall >>> length of the >>> LLS (if I'm right in #8 above that TLVs following the crypto TLV are not >>> protected). In that case a single LLS mixes authenticated and >>> unauthenticated >>> TLVs, which could allow an attacker to replace those that follow the >>> crypto >>> TLV, or mess with the overall length or do other bad things. I think some >>> statement is required as to what a receiver MUST do in such cases, but >>> I don't >>> know enough to suggest any text. (Since the LLS can contain any >>> extension, how >>> do we know its ok to mix authenticated and unauthenticated TLVs like >>> that?) >> CA-TLV needs to be the last TLV (see Liem's email to Spencer). > > I don't recall that email. If the draft said it MUST be the last > TLV then that'd be fine, but the version I read said SHOULD. If the > SHOULD remains then I believe the draft really has to say what to do > if there are subsequent unauthenticated TLVs. Yes, it says MUST.. Regards, -Abhay > Cheers, > Stephen. > >> Conceptually it has similar semantics as to how a digest gets computed >> and attached at the end of a OSPF packet. >> >>> Nits/Typos: >>> >>> section 2.1 - "The L bit is only set in Hello and DD packets." Would >>> that be >>> better as: "The L bit MUST NOT be set except in Hello and DD packets that >>> conain LLS." Might be more likely to be picked up by implementers? >> Sure, will go with your suggestion. >> >>> section 2.3 - "...unique for each type of TLVs" s/TLVs/TLV/ >> changed >> >>> section 2.3 - Seems odd to have a mixture of length fields that're >>> sometimes in >>> 32-bit words and sometimes in bytes but I assume its too late to >>> change that >>> now. >>> >>> section 4 - "...since OSPF router not..." s/router/routers/ >> changed >> >>> section 5 - "...as OSPFv2 protocol..." s/OSPFv2/the OSPFv2/ >> changed >> >> Regards, >> -Abhay >> >> _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Jan 18 23:11:20 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC02328C184; Sun, 18 Jan 2009 23:11:20 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED53C3A6B18; Sat, 17 Jan 2009 06:42:20 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DY993JZBnCI; Sat, 17 Jan 2009 06:42:19 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id BE0C63A6947; Sat, 17 Jan 2009 06:42:19 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSXHuL5ShmRlgHcoxuqNXG6CV4E5/Ubeh@postini.com; Sat, 17 Jan 2009 06:42:04 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Sat, 17 Jan 2009 06:37:36 -0800 Received: from emailcorp9.jnpr.net ([66.129.254.19]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 17 Jan 2009 06:37:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 17 Jan 2009 06:35:49 -0800 Message-ID: <371607A219F15A4497263A55156CB30A02F63FA2@emailcorp9.jnpr.net> In-Reply-To: <86B2DE82-98B0-48B4-B329-7150EEBBDFCA@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secdir review of draft-ietf-idr-flow-spec-03.txt Thread-Index: Acl4MAYOEmrBqlpnQ062CIhMUCOGawAfFT7w References: <86B2DE82-98B0-48B4-B329-7150EEBBDFCA@juniper.net> From: Barry Greene To: "Pedro Marques" , "Charlie Kaufman" X-OriginalArrivalTime: 17 Jan 2009 14:37:35.0701 (UTC) FILETIME=[23819850:01C978B1] X-Mailman-Approved-At: Sun, 18 Jan 2009 23:11:20 -0800 Cc: Robert Raszuk , schishol@nortel.com, Nischal Sheth , secdir@ietf.org, Yakov Rekhter , rja@extremenetworks.com, danny@arbor.net, iesg@ietf.org, shares@ghs.com Subject: Re: [secdir] Secdir review of draft-ietf-idr-flow-spec-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org > > 1) There is no specification in this document as to whether > > the origin of the information in the extensions is manual or > > automated, and I don't know whether this is likely to appear in a > > separate document. > > We have seen deployments using automated detection systems (e.g. > Arbor) and manual configuration. To be more explicit, the triggering is controlled by a separate component - be it manual or by a "controller" (systems like Arbor Network's Peekflow or NARUS's equivalent). Right now, operators do not want "automatic" triggering of FlowSpec, dRTBH (Destination base Remote Triggered Black Hole), or sRTBH (Source based Remote Triggered Black Hole). What would be beneficial is to have a architecture document plugging in the following: -> RFC 3882 "Configuring BGP to Block Denial-of-Service Attacks" (dRTBH) -> draft-ietf-idr-flow-spec.txt -> draft-kumari-blackhole-urpf-02.txt (sRTBH) -> Trusted Information Distribution Protocol (TIDP) (when it get submitted as an ID) OPSEC would be the logical place for this work. > > One could anticipate operational security problems if > changes were not > > carefully managed. For example, if the changes were automatically > > generated from an overwhelmed server, the rate at which the flow > > manipulation data could overwhelm BGPs ability to distribute it. > > I believe this issue is no different from the origination of > unicast routes. Depending on the deployment, these can either > be manually configured or generated by provisioning systems / scripts. > > Would it suffice if the document spells out that when > automated systems are used care should be taken to their > correctness and rate of advertisement ? It might be spelled out better in the document. The three major areas of action in the architecture - the controller, the distribution of the policy (FlowSpec), and the behavior of the device which when encountering policy collisions or policy overloads are three separate areas. The later is a vendor specific issue - given that it is related to how the hardware is designed. > > I don't know whether BGP has built in lock-down timers to prevent > > oscillation in networks or what the effects might be of having BGP > > information in some ASs be several versions behind the BGP > information > > in others. The size of the BGP information, which previously was > > administratively controlled, might also grow without bound with > > unknown effects. > > BGP has mechanisms to control these. e.g. it is common to > limit the number of prefixes that can be received from a > particular peer. > > > 2) Using BGP to distribute information in response to > attacks > > is controversial (as discussed in the introduction of the > document). > > An important factor in its appropriateness is whether BGP can > > distribute the information throughout the network quickly > enough to be > > useful given the duration of the attacks. Some discussion of this > > issue (in particular estimated times) would be helpful. > > This mechanism is appropriate to mitigate attacks that last > dozens of minutes or hours. It is not appropriate to address > attacks that last less than a minute. > > BGP propagation time is irrelevant in the equation. The > detection time is the bottleneck, specially when manual > methods are considered. Today that is the most common > detection method: alarm raised in management console, human > intervention, phone call, manual config. Some might say it using BGP is "controversial," but BGP triggered mitigation _IS_ the #1 tool to mitigate DDOS attacks, whack down BOTNETs, and mitigate the badness on the Net. The selection of BGP was done specifically for its predictability and speed (as Pedro mentioned above). > > 3) Enabling firewall-like capabilities in routers without > > centralized management could make certain failures harder > to diagnose. > > For example, with the extensions it is possible to allow > TCP packets > > to pass between a pair of addresses but not ICMP packets. It would > > also be possible to permit packets smaller than 900 or greater than > > 1000 bytes to pass between a pair of addresses, but not > packets whose > > length is in the range 900-1000. The Internet has become > sufficiently > > aware of firewalls that such behavior is less likely to be > confusing > > than it was a few years ago, and there are no new capabilities > > introduced by these extensions - just an increased likelihood that > > such capabilities will be used. > > That is a good point. You would like this reflected in the > security considerations ? It is worth looking through the draft to see how we expressed this, but BGP triggered mechanisms (dRTBH, sRTBH, & FlowSpec) are marco filtering done for initial mitigation. It should not be confused with firewalls or firewall management. > > 4) These extensions allow filtering based on TCP/UDP > ports and > > other detailed information in ordinary packets, but not in > ESP or AH > > protected packets even when the packet contents are unencrypted. > > Correct. That is a typical limitation in filtering hardware. Or more explicit, FlowSpec is designed specific for the Router/Switch orientation of filtering on the box. If you need more granular filtering you would use BGP Shunts (where FlowSpec can be used), MPLS Shunts, or TIDP. Today Shunting to a Sink Hole or a DDOS mitigation/DPI device is used for granular filtering. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Jan 18 23:11:20 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE71328C18C; Sun, 18 Jan 2009 23:11:20 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59C1E3A6881; Sun, 18 Jan 2009 11:31:54 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynpSoRSHXt1E; Sun, 18 Jan 2009 11:31:53 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 60AFD3A6823; Sun, 18 Jan 2009 11:31:51 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSXODi1NL9XU1hOmKdR7zb7z81xOUmmpo@postini.com; Sun, 18 Jan 2009 11:31:37 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Sun, 18 Jan 2009 11:29:05 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Jan 2009 11:29:04 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Jan 2009 11:29:04 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Jan 2009 11:29:04 -0800 Received: from [172.26.250.98] ([172.26.250.98]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n0IJT0M11189; Sun, 18 Jan 2009 11:29:00 -0800 (PST) (envelope-from raszuk@juniper.net) Message-ID: <497382FA.606@juniper.net> Date: Sun, 18 Jan 2009 11:28:58 -0800 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Charlie Kaufman References: In-Reply-To: X-OriginalArrivalTime: 18 Jan 2009 19:29:04.0260 (UTC) FILETIME=[05E9AC40:01C979A3] X-Mailman-Approved-At: Sun, 18 Jan 2009 23:11:20 -0800 Cc: "schishol@nortel.com" , "nsheth@juniper.net" , "'secdir@ietf.org'" , "bgreene@juniper.net" , "rja@extremenetworks.com" , "roque@juniper.net" , "danny@arbor.net" , "'iesg@ietf.org'" , "yakov@juniper.net" , "shares@ghs.com" Subject: Re: [secdir] Secdir review of draft-ietf-idr-flow-spec-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@juniper.net List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Charlie, Based on your comments and replies from authors I have updated the draft = and proposed changes and clarifications are included in the -04 version. http://www.ietf.org/proceedings/staging/draft-ietf-idr-flow-spec-04.txt If there are any other questions or additional comments I will be happy = to incorporate them and issue -05 version of the document. Many thx for your excellent review, Robert Raszuk > I am reviewing 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. Feel free to = > forward to any appropriate forum. > = > = > = > This document specifies an extension to BGP to allow more granular = > filtering information for discriminating packet flows to be distributed = > between Autonomous Systems. The stated goal is to enable better = > protection from DDoS attacks by pushing firewall style filtering = > upstream towards the initiators of the DDoS traffic (though one could = > imagine other uses). So if a particular destination is being attacked by = > enormous quantities of traffic from many sources but towards a = > particular address/port pair, upstream routers could be asked to discard = > all traffic targeting that address/port pair. The security of the = > extended protocol leverages the security of BGP itself (such as it is), = > and it seems likely that any attacker who could exploit this protocol to = > selectively block traffic would be able (even without this extension) to = > block the same traffic =96 albeit in a less granular fashion). > = > = > = > There are some issues that might have been discussed in the security = > considerations section but weren=92t: > = > = > = > 1) There is no specification in this document as to whether the = > origin of the information in the extensions is manual or automated, and = > I don=92t know whether this is likely to appear in a separate document. = > One could anticipate operational security problems if changes were not = > carefully managed. For example, if the changes were automatically = > generated from an overwhelmed server, the rate at which the flow = > manipulation data could overwhelm BGPs ability to distribute it. I don=92= t = > know whether BGP has built in lock-down timers to prevent oscillation in = > networks or what the effects might be of having BGP information in some = > ASs be several versions behind the BGP information in others. The size = > of the BGP information, which previously was administratively = > controlled, might also grow without bound with unknown effects. > = > 2) Using BGP to distribute information in response to attacks is = > controversial (as discussed in the introduction of the document). An = > important factor in its appropriateness is whether BGP can distribute = > the information throughout the network quickly enough to be useful given = > the duration of the attacks. Some discussion of this issue (in = > particular estimated times) would be helpful. > = > 3) Enabling firewall-like capabilities in routers without = > centralized management could make certain failures harder to diagnose. = > For example, with the extensions it is possible to allow TCP packets to = > pass between a pair of addresses but not ICMP packets. It would also be = > possible to permit packets smaller than 900 or greater than 1000 bytes = > to pass between a pair of addresses, but not packets whose length is in = > the range 900-1000. The Internet has become sufficiently aware of = > firewalls that such behavior is less likely to be confusing than it was = > a few years ago, and there are no new capabilities introduced by these = > extensions =96 just an increased likelihood that such capabilities will b= e = > used. > = > 4) These extensions allow filtering based on TCP/UDP ports and = > other detailed information in ordinary packets, but not in ESP or AH = > protected packets even when the packet contents are unencrypted. > = > 5) Section 5 last paragraph: There is a statement that the = > neighboring AS must be the left-most field in the AS_PATH attribute for = > security reasons. What are the security reasons, and does this statement = > apply only to versions of BGP processing this extension or to all version= s. > = > = > = > Some other issues that are not specifically security related: > = > = > = > *1) **There appears to be no explicit support for IPv6. It is not = > one of the selection criteria, and address masks are specified with a = > prefix bit length and a value. Since a prefix bit length and value could = > mean radically different things in the IPv4 and IPv6 address spaces, = > this should be disambiguated. (Or it=92s possible that separate instances = > of BGP exist for IPv4 and IPv6, in which case there is no problem but it = > should probably mention that in the spec when discussing address masks).* > = > 2) There were a large number of acronyms that were not defined (at = > least not on first use). These are probably familiar to people working = > on BGP, but it would be helpful to specify the RFCs in which acronym = > expansions/definitions could be found. Among them: NLRI, RIBs, Loc-RIB, = > AS, VRF, and PE. > = > 3) Section 5 paragraph 2 references section 9.1.2. Since this = > document has no section 9.1.2, I suspect it means section 9.1.2 of some = > other document. It should say which one. > = > 4) Section 7 5^th paragraph contains a number of grammatical = > errors (apparently based on editing a singular into a plural at the last = > minute. > = > 5) Section 10 paragraph 3 requests that IANA allocate three = > constants from the =93BGP Extended Communities Type =96 Experimental Use= =94 = > registry. Is this document targeting experimental status? If not, is = > that the right registry from which to get values? > = > 6) Section 10 last paragraph says that future assignments to a = > registry are to be made either through =93Standards Action=94, =93the Ear= ly = > IANA Allocation process=94, or the =93First Come First Served=94 policy. = > Doesn=92t each registry (or at least each section of each registry) have = > to specify which of those procedures is to be followed? > = > = > = > = > = _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Jan 19 06:45:39 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453733A6B93; Mon, 19 Jan 2009 06:45:39 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1355728C1D3 for ; Mon, 19 Jan 2009 06:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhk1GWV-M2wq for ; Mon, 19 Jan 2009 06:45:36 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 9D90B3A69F1 for ; Mon, 19 Jan 2009 06:45:36 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0JEjK7L005541 for ; Mon, 19 Jan 2009 09:45:20 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0JEjG8C005524 for ; Mon, 19 Jan 2009 09:45:16 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n0JEj8nk008571 for ; Mon, 19 Jan 2009 09:45:08 -0500 (EST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 4CCE414710D4 for ; Mon, 19 Jan 2009 09:44:47 -0500 (EST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DEB41208D6; Mon, 19 Jan 2009 15:44:44 +0100 (CET) X-AuditID: c1b4fb3c-aa757bb00000304c-11-497491da452a Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 36F9920D3B; Mon, 19 Jan 2009 15:44:42 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 15:44:40 +0100 Received: from [159.107.24.250] ([159.107.24.250]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 15:44:39 +0100 Message-ID: <497491D7.3090104@ericsson.com> Date: Mon, 19 Jan 2009 15:44:39 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090118 Shredder/3.0b2pre MIME-Version: 1.0 To: Richard Barnes References: <494AE067.8080201@bbn.com> <497069FA.8010006@ericsson.com> <49709B5B.40202@bbn.com> In-Reply-To: <49709B5B.40202@bbn.com> X-OriginalArrivalTime: 19 Jan 2009 14:44:39.0626 (UTC) FILETIME=[7502EAA0:01C97A44] X-Brightmail-Tracker: AAAAAA== X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-ietf-mmusic-file-transfer-mech@tools.ietf.org, SECDIR , IESG Subject: Re: [secdir] SECDIR review of draft-ietf-mmusic-file-transfer-mech-09 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Richard: Some further discussion down. I have also trimmed to the relevant parts. On 16/01/2009 15:36, Richard Barnes wrote: > Hi Miguel, > > Thanks for your reply. A couple of responses below. > (Some comments trimmed) > > --Richard > >> With respect to Sections 8.2.2 and 8.3.2, there is already text in >> Section 8.2.2 to make the file receiver verify the hash (see second >> paragraph in 8.2.2). > > I saw that text, but I wondered why it's not a MUST. It would be nice to > also have SHOULD-level requirements to verify other selector criteria as > well. > The text under discussion says: If the SDP answer contains a supported hashing algorithm in the 'hash' selectors of the 'file-selector' attribute, then the file receiver SHOULD compute the hash of the file after its reception and check it against the hash received in the answer. There are several reasons for not upgrading this text to a MUST strength. 1) This is a local action that takes place entirely in one of the endpoints and does not affect interoperability. It is clear that there is a high recommendations for implementations to verify that the file has been correctly received, but on top of it there is a local policy or even implementation capabilities. Since interoperability is not affected, I don't see a big reason for having a MUST strength. 2) The 'hash' selector is optional. So, having a text that says "if you happen to know the hash please verify that the file computes to that hash" does not offer much security. Any rough implementation would simply not indicate the hash from the selector list. > > > >>> 1. The document discusses in detail when a change of file selector or >>> file-transfer-id should trigger a new transmission. The document also >>> seems to assume that a new transmission is only initiated after the >>> first transmission is canceled. It's not clear (to me, anyway) whether >>> this is in fact necessary, or whether a "new file transfer operation" >>> (as in Figure 3) could be initiated without canceling the current >>> operation. (Perhaps there's a port constraint here?) >> >> I think the text you are looking for is written in the first paragraph >> in Section 8.7, when we say that "one file equals one MSRP session". >> Therefore, it is not possible to re-use an existing MSRP session for >> sending a different file. >> >> This must not be confused with simultaneous MSRP sessions. It is >> possible to have two separate MSRP media streams, each sending a >> different file (or even one one being used for regular text chat). But >> each of these will be different MSRP sessions, and each MSRP session, >> one and only one file can be transmitted. > > Here's where I think the confusion lies: If I wanted to signal a new > MSRP session to transfer a file with the same selector -- NOT cancel the > current session, just initiate a second one -- my UA would send an offer > that is identical to the first one except for the "file-transfer-id" > attribute. This usage is not possible with the current text. So, you want to send once more the same file in a new MSRP session. So, then it is a DIFFERENT MSRP session, and this MSRP session is signaled in SDP in an additional m= line. It is also a different file transfer id as you mentioned. I don't see which parts of the draft will prevent this (weird) use case. I think Figure 3 allows it. In particular, the discussion around figure 3 lies about the comparison of two SDP offers emitted in different times. > > This use case is not extraordinarily important, but it's not trivial > either: E.g., if the selector had only the file-name and file-type > portions filled in, then the same selector might match many files (say, > different versions a log file that get rotated). Then, what you are trying to do is to finish a given file transfer operation (with the current methods for finishing MSRP sessions) and re-issuing a new file transfer operation, later in time, but with the same file. This new operation will contain a newly created file-transfer-id, preferable over a newly created MSRP session, since the old one is going to be over for quite some time. All in all, there is nothing that relates the old (completed) file transfer with the new one, except for the name of the file. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Jan 19 14:18:31 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CEE03A6944; Mon, 19 Jan 2009 14:18:31 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81E703A6944 for ; Mon, 19 Jan 2009 14:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxAtfxI83XhH for ; Mon, 19 Jan 2009 14:18:29 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3E3663A6912 for ; Mon, 19 Jan 2009 14:18:29 -0800 (PST) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LP2Rg-0005Le-Dw; Mon, 19 Jan 2009 17:18:12 -0500 Mime-Version: 1.0 Message-Id: Date: Mon, 19 Jan 2009 17:18:05 -0500 To: secdir@core3.amsl.com From: Stephen Kent Cc: Mark.Scott@genesyslab.com, jon.peterson@neustar.biz, daveburke@google.com Subject: [secdir] secdir review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0444777335==" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org --===============0444777335== Content-Type: multipart/alternative; boundary="============_-979719004==_ma============" --============_-979719004==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 SIP interface to VoiceXML media services and is an adjunct to the (full) MEDIACTRL protocol. The interface leverages a mechanism defined in RFC 4240, updating and extending it to match current VoiceXML specs from the W3C. The security considerations section of this document is very brief, i.e., about half a page. The security-relevant requirements cited in this section appear to be defined only here, not in the body of the spec. This seems a bit unusual, i.e., this section often is used to summarize security-relevant requirements that have been explicitly discussed previously in a document. More importantly, since the security requirements cited here appear nowhere else in this document, it is critical that the description provided here be sufficient for implementers to develop complaint products. Of the five security requirements (MUST or RECOMMENDED) cited here, only three meet this criteria. The first paragraph notes that offering network services via well-known ports may enable exploitation (of something) by adversaries, a pretty generic and vague statement. It then notes that an application server implementing this protocol MUST support digest authentication "of requesting endpoints." At a minimum there ought to be a cite to the relevant RFC (2617) here. Since the requesting endpoint in this context appears to be another server (vs. a person) it is not clear that a password-based authentication mechanism is the preferred choice here. Support for :https is mandated later, in a different context, so it is not clear why support for that form of authentication (preferably bi-directionally) is not required here as well. The second paragraph of this section notes that the transfer mechanism defined for this protocol could enable various types of attacks, by causing an application server to make outbound calls. Such calls consume resources (a DoS attack vector), may cost money (fraud), and might interfere with the ability of the calls to be traced (unintentional anonymity?). The document RECCOMMENDs that VoiceXML servers provide "local policies" to authorize and limit such calls, and audit trails to help resolve billing issues and provide traceability. This is not an appropriate recommendation for two reasons. First, this RFC is specifying what vendors of application servers are supposed to implement. Vendors can provide "mechanisms" that enforce local policies, but they are not creators of policies per se. So, the requirement is for mechanisms not policies. Second, this is a very vague recommendation; if is not clear how one would determine whether a set of mechanisms offered by a vendor satisfied the recommendation. To address confidentiality of data transferred to/from these servers, support for :sips and https: is mandated, which seems appropriate. SRTP also MUST be supported to provide various security services for media streams, another appropriate and well-specified requirement. The sections ends with another RECOMMENDATION described in terms of the need to support "local policies" that would help minimize DoS attacks launched from an application server. Here too the document should be stating the need for "mechanisms" that can be used to enforce local policies, as noted above. And, as above, the description is vague, giving just one example, to be used in evaluating whether a given product satisfies the recommendation. --============_-979719004==_ma============ Content-Type: text/html; charset="us-ascii" secdir review
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 SIP interface to VoiceXML media services and is an adjunct to the (full) MEDIACTRL protocol. The interface leverages a mechanism defined in RFC 4240, updating and extending it to match current VoiceXML specs from the W3C.
The security considerations section of this document is very brief, i.e., about half a page. The security-relevant requirements cited in this section appear to be defined only here, not in the body of the spec. This seems a bit unusual,  i.e., this section often is used to summarize security-relevant requirements that have been explicitly discussed previously in a document. More importantly, since the security requirements cited here appear nowhere else in this document, it is critical that the description provided here be sufficient for implementers to develop complaint products.  Of the five security requirements (MUST or RECOMMENDED) cited here, only three meet this criteria.

The first paragraph notes that offering network services via well-known ports may enable exploitation (of something) by adversaries, a pretty generic and vague statement. It then notes that an application server implementing this protocol MUST support digest authentication "of requesting endpoints." At a minimum there ought to be a cite to the relevant RFC (2617) here. Since the requesting endpoint in this context appears to be another server (vs. a person) it is not clear that a password-based authentication mechanism is the preferred choice here. Support for :https is mandated later, in a different context, so it is not clear why support for that form of authentication (preferably bi-directionally) is not required here as well.

The second paragraph of this section notes that the transfer mechanism defined for this protocol could enable various types of attacks, by causing an application server to make outbound calls. Such calls consume resources (a DoS attack vector), may cost money (fraud), and might interfere with the ability of the calls to be traced (unintentional anonymity?). The document RECCOMMENDs that VoiceXML servers provide "local policies" to authorize and limit such calls, and audit trails to help resolve billing issues and provide traceability. This is not an appropriate recommendation for two reasons. First, this RFC is specifying what vendors of application servers are supposed to implement. Vendors can provide "mechanisms" that enforce local policies, but they are not creators of policies per se. So, the requirement is for mechanisms not policies. Second, this is a very vague recommendation; if is not clear how one would determine whether a set of mechanisms offered by a vendor satisfied the recommendation.

To address confidentiality of data transferred to/from these servers, support for :sips and https: is mandated, which seems appropriate. SRTP also MUST be supported to provide various security services for media streams, another appropriate and well-specified requirement.

The sections ends with another RECOMMENDATION described in terms of the need to support "local policies" that would help minimize DoS attacks launched from an application server.  Here too the document should be stating the need for "mechanisms" that can be used to enforce local policies, as noted above. And, as above, the description is vague, giving just one example, to be used in evaluating whether a given product satisfies the recommendation.
--============_-979719004==_ma============-- --===============0444777335== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir --===============0444777335==-- From secdir-bounces@ietf.org Mon Jan 19 16:08:35 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E96128B23E; Mon, 19 Jan 2009 16:08:35 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0127728B23E for ; Mon, 19 Jan 2009 16:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.392 X-Spam-Level: X-Spam-Status: No, score=-4.392 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlowkA6jujuQ for ; Mon, 19 Jan 2009 16:08:34 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 08BE73A6A20 for ; Mon, 19 Jan 2009 16:08:33 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0K08HPP010975 for ; Mon, 19 Jan 2009 19:08:17 -0500 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0K03KMG005401 for ; Mon, 19 Jan 2009 19:03:44 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n0JMoNfd014973 for ; Mon, 19 Jan 2009 17:50:24 -0500 (EST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 3546CD48B3C for ; Mon, 19 Jan 2009 17:50:02 -0500 (EST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0JMmU6I007380 for ; Mon, 19 Jan 2009 17:48:30 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0JMo1rf188900 for ; Mon, 19 Jan 2009 17:50:01 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0JMo1uT005066 for ; Mon, 19 Jan 2009 17:50:01 -0500 Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n0JMo01L005063; Mon, 19 Jan 2009 17:50:00 -0500 Received: from 9.12.238.234:64854 ([9.12.238.234]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1232405401.501; Mon, 19 Jan 2009 17:50:01 -0400 Date: Mon, 19 Jan 2009 17:49:40 -0500 From: Barry Leiba To: secdir@mit.edu, iesg@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-ietf-tls-psk-new-mac-aes-gcm@tools.ietf.org, tls-chairs@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-tls-psk-new-mac-aes-gcm-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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 groups encryption/hash/key sizes into named cipher suites for TLS. I see no problem with the document. Barry -- Barry Leiba, Senior Technical Staff (leiba@watson.ibm.com) Internet Messaging Technology, IBM Research http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Jan 19 19:21:03 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3BF33A695E; Mon, 19 Jan 2009 19:21:03 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E64C3A695E for ; Mon, 19 Jan 2009 19:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[AWL=2.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OeZPMoGv0NM for ; Mon, 19 Jan 2009 19:21:02 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 51FD23A694C for ; Mon, 19 Jan 2009 19:21:01 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0K3Ka2q018661 for ; Mon, 19 Jan 2009 22:20:36 -0500 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0K3KWCK018658 for ; Mon, 19 Jan 2009 22:20:32 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n0K3KRih007709 for ; Mon, 19 Jan 2009 22:20:27 -0500 (EST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 9C047145B182 for ; Mon, 19 Jan 2009 22:20:06 -0500 (EST) Received: from [128.89.253.71] (helo=Richard-Barnes-Laptop.local) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LP79d-0005KZ-Ak; Mon, 19 Jan 2009 22:19:53 -0500 Message-ID: <497542D8.7030606@bbn.com> Date: Mon, 19 Jan 2009 22:19:52 -0500 From: Richard Barnes User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Miguel A. Garcia" References: <494AE067.8080201@bbn.com> <497069FA.8010006@ericsson.com> <49709B5B.40202@bbn.com> <497491D7.3090104@ericsson.com> In-Reply-To: <497491D7.3090104@ericsson.com> X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-ietf-mmusic-file-transfer-mech@tools.ietf.org, SECDIR , IESG Subject: Re: [secdir] SECDIR review of draft-ietf-mmusic-file-transfer-mech-09 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hey Miguel, A couple more comments, again trimmed. I think we're converging... --Richard >>> With respect to Sections 8.2.2 and 8.3.2, there is already text in >>> Section 8.2.2 to make the file receiver verify the hash (see second >>> paragraph in 8.2.2). >> >> I saw that text, but I wondered why it's not a MUST. It would be nice to >> also have SHOULD-level requirements to verify other selector criteria as >> well. > 1) This is a local action that takes place entirely in one of the > endpoints and does not affect interoperability. It is clear that there > is a high recommendations for implementations to verify that the file > has been correctly received, but on top of it there is a local policy or > even implementation capabilities. Since interoperability is not > affected, I don't see a big reason for having a MUST strength. Just because it's host-local doesn't mean it's out of scope. Checks values in a message are frequently specified at a MUST level (though not always, I admit). See, for example, the host identity checks in HTTPS (RFC 2818, Section3.1), or the validation techniques for PKIX certificates (RFC 5280, Section6). > 2) The 'hash' selector is optional. So, having a text that says "if you > happen to know the hash please verify that the file computes to that > hash" does not offer much security. Any rough implementation would > simply not indicate the hash from the selector list. That's a valid argument if the 'hash' selector is the only one that MUST be verified. To strengthen what I said above, it should be that *all* the selector attributes MUST be verified: Some selector will always be sent, and the file sender is misbehaving if he sends a file that does not match the selector. So whatever the selector is, there should be a requirement that the file sender MUST send only a file that matches that selector, and that the file receiver MUST verify that the file matches the selector, simply to ensure the correct operation of the protocol. > So, you want to send once more the same file in a new MSRP session. So, > then it is a DIFFERENT MSRP session, and this MSRP session is signaled > in SDP in an additional m= line. It is also a different file transfer id > as you mentioned. I don't see which parts of the draft will prevent this > (weird) use case. I think Figure 3 allows it. In particular, the > discussion around figure 3 lies about the comparison of two SDP offers > emitted in different times. Ah, I hadn't grokked what you were saying about the different sessions. Now that I understand, this makes sense. Comment retracted. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Jan 20 05:55:30 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 460203A6BC9; Tue, 20 Jan 2009 05:55:30 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08F173A693C; Mon, 19 Jan 2009 09:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd-TjMmAZ-xy; Mon, 19 Jan 2009 09:36:41 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id EADE93A68BF; Mon, 19 Jan 2009 09:36:40 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 403F8268674; Mon, 19 Jan 2009 10:36:25 -0700 (MST) Received: from jchouinard-sim-105.eng.ellacoya.com (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 19 Jan 2009 10:36:25 -0700 (MST) (envelope-from danny@arbor.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=55849; syn-fingerprint=65535:55:1:64:M1408,N,W3,N,N,T,S; data-bytes=0 Message-Id: From: Danny McPherson To: raszuk@juniper.net In-Reply-To: <497382FA.606@juniper.net> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 19 Jan 2009 10:36:23 -0700 References: <497382FA.606@juniper.net> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Tue, 20 Jan 2009 05:55:28 -0800 Cc: "schishol@nortel.com" , "nsheth@juniper.net" , "'secdir@ietf.org'" , "bgreene@juniper.net" , "roque@juniper.net" , "'iesg@ietf.org'" , "yakov@juniper.net" , "shares@ghs.com" , "rja@extremenetworks.com" Subject: Re: [secdir] Secdir review of draft-ietf-idr-flow-spec-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On Jan 18, 2009, at 12:28 PM, Robert Raszuk wrote: > Hi Charlie, > > Based on your comments and replies from authors I have updated the > draft and proposed changes and clarifications are included in the > -04 version. > > http://www.ietf.org/proceedings/staging/draft-ietf-idr-flow- > spec-04.txt > > If there are any other questions or additional comments I will be > happy to incorporate them and issue -05 version of the document. I would note that these changes, the IANA recommendations for the registry, and the fact that IPR disclosure occurred after WG last call all suggest that another WG LC is likely in order here. -danny _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Jan 21 03:42:27 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 484603A6AC3; Wed, 21 Jan 2009 03:42:27 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C246E3A6AC5 for ; Wed, 21 Jan 2009 03:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.427 X-Spam-Level: X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pueVmNwHkmo0 for ; Wed, 21 Jan 2009 03:42:24 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id BECDB3A6A95 for ; Wed, 21 Jan 2009 03:42:24 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0LBg5Jf017837 for ; Wed, 21 Jan 2009 06:42:05 -0500 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0LBg0br017824 for ; Wed, 21 Jan 2009 06:42:00 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n0LBfrh0017501 for ; Wed, 21 Jan 2009 06:41:54 -0500 (EST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 0EC06D628FC for ; Wed, 21 Jan 2009 06:41:32 -0500 (EST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 30A5A21EF7; Wed, 21 Jan 2009 12:40:31 +0100 (CET) X-AuditID: c1b4fb3c-aef60bb00000304c-79-4977097903d4 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 94D2021EFA; Wed, 21 Jan 2009 12:39:37 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 12:37:40 +0100 Received: from [159.107.24.250] ([159.107.24.250]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 12:37:40 +0100 Message-ID: <49770902.301@ericsson.com> Date: Wed, 21 Jan 2009 12:37:38 +0100 From: "Miguel A. Garcia" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Richard Barnes References: <494AE067.8080201@bbn.com> <497069FA.8010006@ericsson.com> <49709B5B.40202@bbn.com> <497491D7.3090104@ericsson.com> <497542D8.7030606@bbn.com> In-Reply-To: <497542D8.7030606@bbn.com> X-OriginalArrivalTime: 21 Jan 2009 11:37:40.0133 (UTC) FILETIME=[AA7FA550:01C97BBC] X-Brightmail-Tracker: AAAAAA== X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-ietf-mmusic-file-transfer-mech@tools.ietf.org, SECDIR , IESG Subject: Re: [secdir] SECDIR review of draft-ietf-mmusic-file-transfer-mech-09 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Richard. Some inlines comments. Richard Barnes wrote: > Hey Miguel, > A couple more comments, again trimmed. I think we're converging... > --Richard > > >>>> With respect to Sections 8.2.2 and 8.3.2, there is already text in >>>> Section 8.2.2 to make the file receiver verify the hash (see second >>>> paragraph in 8.2.2). >>> >>> I saw that text, but I wondered why it's not a MUST. It would be nice to >>> also have SHOULD-level requirements to verify other selector criteria as >>> well. > >> 1) This is a local action that takes place entirely in one of the >> endpoints and does not affect interoperability. It is clear that there >> is a high recommendations for implementations to verify that the file >> has been correctly received, but on top of it there is a local policy >> or even implementation capabilities. Since interoperability is not >> affected, I don't see a big reason for having a MUST strength. > > Just because it's host-local doesn't mean it's out of scope. Checks > values in a message are frequently specified at a MUST level (though not > always, I admit). See, for example, the host identity checks in HTTPS > (RFC 2818, Section3.1), or the validation techniques for PKIX > certificates (RFC 5280, Section6). I can replace the SHOULD with a MUST strength, but: a) It is not aligned with the conventions used by most of the other SIP RFCs. b) IMHO it is not aligned with the definition of "MUST" in RFC 2119, which says: 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. Obviously, checking that the hash of the file computes the advertised hash of the file, is far from being an "absolute requirement". But I can write a MUST to close this discussion. > >> 2) The 'hash' selector is optional. So, having a text that says "if >> you happen to know the hash please verify that the file computes to >> that hash" does not offer much security. Any rough implementation >> would simply not indicate the hash from the selector list. > > That's a valid argument if the 'hash' selector is the only one that MUST > be verified. To strengthen what I said above, it should be that *all* > the selector attributes MUST be verified: Some selector will always be > sent, and the file sender is misbehaving if he sends a file that does > not match the selector. So whatever the selector is, there should be a > requirement that the file sender MUST send only a file that matches that > selector, and that the file receiver MUST verify that the file matches > the selector, simply to ensure the correct operation of the protocol. Again, I disagree, but just to close the discussion, I will add text that indicates the MUST strength with respect the other selectors. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Jan 21 06:40:50 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 996C33A6B4A; Wed, 21 Jan 2009 06:40:50 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A86E3A6B4A for ; Wed, 21 Jan 2009 06:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.171 X-Spam-Level: X-Spam-Status: No, score=-6.171 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8p-kP6qt3MG0 for ; Wed, 21 Jan 2009 06:40:45 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 9CBAA3A67A1 for ; Wed, 21 Jan 2009 06:40:45 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0LEeTHZ026881 for ; Wed, 21 Jan 2009 09:40:29 -0500 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0LEeIBs026842 for ; Wed, 21 Jan 2009 09:40:18 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n0LEeCxc023562 for ; Wed, 21 Jan 2009 09:40:13 -0500 (EST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 3FC82146EB9C for ; Wed, 21 Jan 2009 09:39:52 -0500 (EST) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n0LEdeBe004231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 09:39:41 -0500 (EST) Date: Wed, 21 Jan 2009 09:39:44 -0500 From: Jeffrey Hutzelman To: "Miguel A. Garcia" , Richard Barnes Message-ID: <66B86FE85D73ED9C16CE5D7B@atlantis.pc.cs.cmu.edu> In-Reply-To: <200901211142.n0LBgGwZ001392@toasties.srv.cs.cmu.edu> References: <494AE067.8080201@bbn.com> <497069FA.8010006@ericsson.com> <49709B5B.40202@bbn.com> <497491D7.3090104@ericsson.com> <497542D8.7030606@bbn.com> <200901211142.n0LBgGwZ001392@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-ietf-mmusic-file-transfer-mech@tools.ietf.org, SECDIR , IESG Subject: Re: [secdir] SECDIR review of draft-ietf-mmusic-file-transfer-mech-09 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org --On Wednesday, January 21, 2009 12:37:38 PM +0100 "Miguel A. Garcia" wrote: > Hi Richard. Some inlines comments. > > Richard Barnes wrote: >> Hey Miguel, >> A couple more comments, again trimmed. I think we're converging... >> --Richard >> >> >>>>> With respect to Sections 8.2.2 and 8.3.2, there is already text in >>>>> Section 8.2.2 to make the file receiver verify the hash (see second >>>>> paragraph in 8.2.2). >>>> >>>> I saw that text, but I wondered why it's not a MUST. It would be nice >>>> to also have SHOULD-level requirements to verify other selector >>>> criteria as well. >> >>> 1) This is a local action that takes place entirely in one of the >>> endpoints and does not affect interoperability. It is clear that there >>> is a high recommendations for implementations to verify that the file >>> has been correctly received, but on top of it there is a local policy >>> or even implementation capabilities. Since interoperability is not >>> affected, I don't see a big reason for having a MUST strength. >> >> Just because it's host-local doesn't mean it's out of scope. Checks >> values in a message are frequently specified at a MUST level (though not >> always, I admit). See, for example, the host identity checks in HTTPS >> (RFC 2818, Section3.1), or the validation techniques for PKIX >> certificates (RFC 5280, Section6). > > I can replace the SHOULD with a MUST strength, but: > a) It is not aligned with the conventions used by most of the other SIP > RFCs. b) IMHO it is not aligned with the definition of "MUST" in RFC > 2119, which says: > > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the > definition is an absolute requirement of the specification. > > Obviously, checking that the hash of the file computes the advertised > hash of the file, is far from being an "absolute requirement". > > But I can write a MUST to close this discussion. You could, but I don't think you should. Generally, an RFC2119 MUST (or even SHOULD) is appropriate to use when not behaving as specified would have an impact on interoperability, security, or similar considerations, or would otherwise just make things not work. I don't believe that failing to verify a checksum on a received file has that sort of impact, given that the checksum is not a hash used to protect file integrity against deliberate attacks. >>> 2) The 'hash' selector is optional. So, having a text that says "if >>> you happen to know the hash please verify that the file computes to >>> that hash" does not offer much security. Any rough implementation >>> would simply not indicate the hash from the selector list. >> >> That's a valid argument if the 'hash' selector is the only one that MUST >> be verified. To strengthen what I said above, it should be that *all* >> the selector attributes MUST be verified: Some selector will always be >> sent, and the file sender is misbehaving if he sends a file that does >> not match the selector. So what? An receiver might wish to know if a sender is misbehaving in this way, but doing so doesn't actually break the protocol. >> So whatever the selector is, there should be a >> requirement that the file sender MUST send only a file that matches that >> selector This is a reasonable requirement, though I'm not sure I would make it stronger than SHOULD. I can think of situations where you'd want to ignore that requirement, but I don't know whether they'd acutally apply to this protocol. For example, it's kind of hard to send a hash or checksum of an indefinite-length stream. >> , and that the file receiver MUST verify that the file matches >> the selector, simply to ensure the correct operation of the protocol. Why? Checking that another protocol participant is behaving correctly requires extra time and complexity. If an implementation wishes to do so, that's fine, to an extent, but we should not require such checks unless they are actually necessary. -- Jeff _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Jan 21 06:48:41 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CABFE28C143; Wed, 21 Jan 2009 06:48:41 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD3A28C143 for ; Wed, 21 Jan 2009 06:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.821 X-Spam-Level: X-Spam-Status: No, score=-4.821 tagged_above=-999 required=5 tests=[AWL=1.778, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeKbgW7GhyXr for ; Wed, 21 Jan 2009 06:48:36 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 733973A6B4A for ; Wed, 21 Jan 2009 06:48:36 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0LEmKUc028742 for ; Wed, 21 Jan 2009 09:48:20 -0500 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0LEmIaS028739 for ; Wed, 21 Jan 2009 09:48:18 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n0LEmDkG004974 for ; Wed, 21 Jan 2009 09:48:13 -0500 (EST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 9B15811C72A8 for ; Wed, 21 Jan 2009 09:47:52 -0500 (EST) Received: from col-dhcp33-244-164.bbn.com ([128.33.244.164]) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1LPeMf-00054D-AW; Wed, 21 Jan 2009 09:47:33 -0500 Message-ID: <49773584.5050803@bbn.com> Date: Wed, 21 Jan 2009 09:47:32 -0500 From: Richard Barnes User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Miguel A. Garcia" References: <494AE067.8080201@bbn.com> <497069FA.8010006@ericsson.com> <49709B5B.40202@bbn.com> <497491D7.3090104@ericsson.com> <497542D8.7030606@bbn.com> <49770902.301@ericsson.com> In-Reply-To: <49770902.301@ericsson.com> X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-ietf-mmusic-file-transfer-mech@tools.ietf.org, SECDIR , IESG Subject: Re: [secdir] SECDIR review of draft-ietf-mmusic-file-transfer-mech-09 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hey Miguel, One more go-round.... --Richard >> Just because it's host-local doesn't mean it's out of scope. Checks >> values in a message are frequently specified at a MUST level (though >> not always, I admit). See, for example, the host identity checks in >> HTTPS (RFC 2818, Section3.1), or the validation techniques for PKIX >> certificates (RFC 5280, Section6). > > I can replace the SHOULD with a MUST strength, but: > a) It is not aligned with the conventions used by most of the other SIP > RFCs. > b) IMHO it is not aligned with the definition of "MUST" in RFC 2119, > > But I can write a MUST to close this discussion. I tend to side with the philosophy that you should only have a SHOULD when there are clear conditions when a host would *not* do what the document recommends. In this case, there doesn't seem to be a good reason why a host *wouldn't* verify the selectors. However, as long as there is a requirement that hosts verify the selectors, I would hold this draft up over a MUST/SHOULD debate. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Jan 22 02:00:17 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6E943A69B0; Thu, 22 Jan 2009 02:00:17 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36F0E3A69B0 for ; Thu, 22 Jan 2009 02:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.435 X-Spam-Level: X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyJoG+rGHYYC for ; Thu, 22 Jan 2009 02:00:16 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 1D4E73A683E for ; Thu, 22 Jan 2009 02:00:15 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0M9xxLt024987 for ; Thu, 22 Jan 2009 04:59:59 -0500 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n0M9xtQv024976 for ; Thu, 22 Jan 2009 04:59:55 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n0M9xlDi012802 for ; Thu, 22 Jan 2009 04:59:47 -0500 (EST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 937371478572 for ; Thu, 22 Jan 2009 04:59:26 -0500 (EST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6CE33201DA; Thu, 22 Jan 2009 10:59:25 +0100 (CET) X-AuditID: c1b4fb3e-af871bb00000429e-5c-4978437d466b Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3F3732039C; Thu, 22 Jan 2009 10:59:25 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 10:59:24 +0100 Received: from [159.107.24.250] ([159.107.24.250]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 10:59:24 +0100 Message-ID: <4978437C.3050801@ericsson.com> Date: Thu, 22 Jan 2009 10:59:24 +0100 From: "Miguel A. Garcia" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jeffrey Hutzelman References: <494AE067.8080201@bbn.com> <497069FA.8010006@ericsson.com> <49709B5B.40202@bbn.com> <497491D7.3090104@ericsson.com> <497542D8.7030606@bbn.com> <200901211142.n0LBgGwZ001392@toasties.srv.cs.cmu.edu> <66B86FE85D73ED9C16CE5D7B@atlantis.pc.cs.cmu.edu> In-Reply-To: <66B86FE85D73ED9C16CE5D7B@atlantis.pc.cs.cmu.edu> X-OriginalArrivalTime: 22 Jan 2009 09:59:24.0691 (UTC) FILETIME=[1AF45630:01C97C78] X-Brightmail-Tracker: AAAAAA== X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-ietf-mmusic-file-transfer-mech@tools.ietf.org, SECDIR , IESG Subject: Re: [secdir] SECDIR review of draft-ietf-mmusic-file-transfer-mech-09 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Jeff: I think Richard has came to the conclusion that SHOULD strength (for hash verifications) is enough in this case. Therefore, I will proceed according to it. Thanks for your comments. /Miguel Jeffrey Hutzelman wrote: > --On Wednesday, January 21, 2009 12:37:38 PM +0100 "Miguel A. Garcia" > wrote: > >> Hi Richard. Some inlines comments. >> >> Richard Barnes wrote: >>> Hey Miguel, >>> A couple more comments, again trimmed. I think we're converging... >>> --Richard >>> >>> >>>>>> With respect to Sections 8.2.2 and 8.3.2, there is already text in >>>>>> Section 8.2.2 to make the file receiver verify the hash (see second >>>>>> paragraph in 8.2.2). >>>>> >>>>> I saw that text, but I wondered why it's not a MUST. It would be nice >>>>> to also have SHOULD-level requirements to verify other selector >>>>> criteria as well. >>> >>>> 1) This is a local action that takes place entirely in one of the >>>> endpoints and does not affect interoperability. It is clear that there >>>> is a high recommendations for implementations to verify that the file >>>> has been correctly received, but on top of it there is a local policy >>>> or even implementation capabilities. Since interoperability is not >>>> affected, I don't see a big reason for having a MUST strength. >>> >>> Just because it's host-local doesn't mean it's out of scope. Checks >>> values in a message are frequently specified at a MUST level (though not >>> always, I admit). See, for example, the host identity checks in HTTPS >>> (RFC 2818, Section3.1), or the validation techniques for PKIX >>> certificates (RFC 5280, Section6). >> >> I can replace the SHOULD with a MUST strength, but: >> a) It is not aligned with the conventions used by most of the other SIP >> RFCs. b) IMHO it is not aligned with the definition of "MUST" in RFC >> 2119, which says: >> >> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the >> definition is an absolute requirement of the specification. >> >> Obviously, checking that the hash of the file computes the advertised >> hash of the file, is far from being an "absolute requirement". >> >> But I can write a MUST to close this discussion. > > You could, but I don't think you should. Generally, an RFC2119 MUST (or > even SHOULD) is appropriate to use when not behaving as specified would > have an impact on interoperability, security, or similar considerations, > or would otherwise just make things not work. > > I don't believe that failing to verify a checksum on a received file has > that sort of impact, given that the checksum is not a hash used to > protect file integrity against deliberate attacks. > >>>> 2) The 'hash' selector is optional. So, having a text that says "if >>>> you happen to know the hash please verify that the file computes to >>>> that hash" does not offer much security. Any rough implementation >>>> would simply not indicate the hash from the selector list. >>> >>> That's a valid argument if the 'hash' selector is the only one that MUST >>> be verified. To strengthen what I said above, it should be that *all* >>> the selector attributes MUST be verified: Some selector will always be >>> sent, and the file sender is misbehaving if he sends a file that does >>> not match the selector. > > So what? An receiver might wish to know if a sender is misbehaving in > this way, but doing so doesn't actually break the protocol. > >>> So whatever the selector is, there should be a >>> requirement that the file sender MUST send only a file that matches that >>> selector > > This is a reasonable requirement, though I'm not sure I would make it > stronger than SHOULD. I can think of situations where you'd want to > ignore that requirement, but I don't know whether they'd acutally apply > to this protocol. For example, it's kind of hard to send a hash or > checksum of an indefinite-length stream. > > > > >>> , and that the file receiver MUST verify that the file matches >>> the selector, simply to ensure the correct operation of the protocol. > > Why? Checking that another protocol participant is behaving correctly > requires extra time and complexity. If an implementation wishes to do > so, that's fine, to an extent, but we should not require such checks > unless they are actually necessary. > > -- Jeff -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Jan 22 09:07:41 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B50628C240; Thu, 22 Jan 2009 09:07:41 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 878EC28C19C for ; Thu, 22 Jan 2009 09:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytRVtQP8cZJK for ; Thu, 22 Jan 2009 09:07:39 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id BF1A028C233 for ; Thu, 22 Jan 2009 09:07:39 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4B709451D; Thu, 22 Jan 2009 12:07:18 -0500 (EST) From: Sam Hartman To: secdir@ietf.org Date: Thu, 22 Jan 2009 12:07:18 -0500 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Cc: draft-farrel-rtg-common-bnf@tools.ietf.org Subject: [secdir] secdir review of draft-farrel-rtg-common-bnf-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org I have reviewed this draft for the security directorate. It provides a description of the BNF varient used in RSVP and related protocols, both for completeness and for use in future protocols. The security considerations section states that this document introduces no new security issues. I believe that's true. Sometimes we'd ask people to discuss implementation bugs in decoders/encoders in a document like this; I do not believe doing so has significant value. --Sam _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Jan 22 17:58:36 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69CBB3A69E4; Thu, 22 Jan 2009 17:58:36 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B75D28C0D0 for ; Thu, 22 Jan 2009 17:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=-0.995, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rehajHhvfCLb for ; Thu, 22 Jan 2009 17:58:34 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id B478D3A6932 for ; Thu, 22 Jan 2009 17:58:33 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n0N1wGt2073467 for ; Thu, 22 Jan 2009 20:58:16 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n0N1wF0e073464 for ; Thu, 22 Jan 2009 20:58:16 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 22 Jan 2009 20:58:15 -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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (fledge.watson.org [127.0.0.1]); Thu, 22 Jan 2009 20:58:16 -0500 (EST) Subject: [secdir] Assignments for January 27th/29th X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Only one "new" assignment, to Chris Lonvick. Catherine Meadows is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-01-27 Stephen Farrell T draft-melnikov-sieve-imapext-metadata-08 Steve Hanna T draft-ietf-radext-management-authorization-06 Sam Hartman TR draft-stjohns-sipso-06 Marcus Leech T draft-ietf-tls-ecdhe-psk-05 Last calls and special requests: Derek Atkins draft-ietf-avt-post-repair-rtcp-xr-04 Rob Austein draft-ietf-dime-qos-parameters-09 Alan DeKok draft-ietf-roll-home-routing-reqs-06 Lakshminath Dondeti draft-ietf-speermint-terminology-17 Phillip Hallam-Baker draft-ietf-radext-design-05 Phillip Hallam-Baker draft-atlas-icmp-unnumbered-06 Steve Hanna draft-ietf-eai-downgrade-11 Paul Hoffman draft-ietf-behave-turn-12 Love Hornquist-Astrand draft-ietf-ccamp-gr-description-04 Jeffrey Hutzelman draft-ietf-ccamp-pc-and-sc-reqs-06 Scott Kelly draft-ietf-tsvwg-rsvp-proxy-approaches-06 Scott Kelly draft-ietf-mediactrl-architecture-04 Angelos Keromytis draft-ietf-mext-nemo-mib-04 Julien Laganier draft-ietf-sip-certs-07 Chris Lonvick draft-ietf-ccamp-path-key-ero-03 Catherine Meadows draft-ietf-speechsc-mrcpv2-17 Sandy Murphy draft-ietf-mpls-mpls-and-gmpls-security-framework-04 Vidya Narayanan draft-ietf-sip-saml-05 Eric Rescorla draft-wing-sipping-srtp-key-04 Susan Thomson draft-loreto-simple-im-srv-label-03 Sam Weiler draft-chown-v6ops-rogue-ra-02 Brian Weis draft-ietf-sieve-mime-loop-08 Brian Weis draft-ietf-pim-sm-linklocal-05 Nico Williams draft-ietf-v6ops-ra-guard-01 Larry Zhu draft-thaler-v6ops-teredo-extensions-02 Glen Zorn draft-andreasen-sipping-rfc3603bis-07 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Jan 23 18:24:50 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF513A688B; Fri, 23 Jan 2009 18:24:50 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0189F3A6851; Fri, 23 Jan 2009 18:24:49 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5a0wFH7GL8n; Fri, 23 Jan 2009 18:24:48 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 02F743A67C1; Fri, 23 Jan 2009 18:24:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,315,1231113600"; d="scan'208";a="235745343" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 24 Jan 2009 02:24:31 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n0O2OVwN028252; Fri, 23 Jan 2009 18:24:31 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n0O2OV14026888; Sat, 24 Jan 2009 02:24:31 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 18:24:31 -0800 Received: from [128.107.163.184] ([128.107.163.184]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 18:24:30 -0800 Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Brian Weis Date: Fri, 23 Jan 2009 18:25:46 -0800 To: iesg@ietf.org, secdir@ietf.org X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 24 Jan 2009 02:24:30.0676 (UTC) FILETIME=[E347A940:01C97DCA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1059; t=1232763871; x=1233627871; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:=20Brian=20Weis=20 |Subject:=20Secdir=20review=20of=20draft-ietf-sieve-mime-lo op-08 |Sender:=20; bh=HxVr0FE1n2U+gvZrEqvR1D77jrAjId+KsKYJOh/xGb8=; b=cWbixSewxkJsNRM7cds9VsmIJcvOPR4mptpF3xTGl9y5In5DAd6taMpmPf mFTwFCNdM3d4KfgBpO9PqOTHvkWcYg3tTfkeobsjvbQvY6f3eewl9WfoKalM FPi2hUg9vV; Authentication-Results: sj-dkim-3; header.From=bew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: draft-ietf-sieve-mime-loop@tools.ietf.org, sieve-chairs@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-sieve-mime-loop-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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. As stated in the abstract, the document defines extensions to the Sieve email filtering language to permit analysis and manipulation of the MIME body parts of an email message. In particular, it adds several new "actions" by which an entity evaluating the mail message can alter it. Altering the message invalidates any digital signature included in the message, and this is duly noted in the security considerations section. I see no problem with the document. Brian P.S. to authors: There's a typo at the end of Section 4.2: s/ INBOX.part-from-time/INBOX.part-from-tim/. -- Brian Weis Router/Switch Security Group, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Jan 25 07:52:39 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A79B3A6B5B; Sun, 25 Jan 2009 07:52:39 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AABE13A6B52; Sun, 25 Jan 2009 07:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.411 X-Spam-Level: X-Spam-Status: No, score=-4.411 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebPljui-0miV; Sun, 25 Jan 2009 07:52:37 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 760EF3A6829; Sun, 25 Jan 2009 07:52:37 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0PFpJ4g003410; Sun, 25 Jan 2009 08:51:19 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0PFqJQU203346; Sun, 25 Jan 2009 08:52:19 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0PFqJic016474; Sun, 25 Jan 2009 08:52:19 -0700 Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n0PFqIcA016460; Sun, 25 Jan 2009 08:52:19 -0700 Received: from 9.12.239.95:63566 ([9.12.239.95]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1232898740.792; Sun, 25 Jan 2009 10:52:20 -0400 Date: Sun, 25 Jan 2009 10:52:12 -0500 From: Barry Leiba To: iesg@ietf.org, secdir@ietf.org, apps-review@ietf.org Message-ID: <675489E3DF05B8FA18C3C849@Uranus.home> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline Cc: draft-kucherawy-sender-auth-header@tools.ietf.org, draft-otis-auth-header-sec-issues@tools.ietf.org Subject: [secdir] secdir review of draft-kucherawy-sender-auth-header-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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. Specifically, I've been asked to review draft-kucherawy-sender-auth-header-20, after having reviewed the -18 revision, and to consider draft-otis-auth-header-sec-issues-00 in the review. I'm also copying this review to the apps-review list, since it's relevant there. I've looked at the diffs between the -18 and -20 versions, to make sure I didn't miss any changes, and I've reviewed the -20 version as a whole. I've also looked at the comments and questions that have come up during IESG evaluation. My evaluation of the document stands from the -18 version -- the -19 and -20 revisions have made clarifications over -18, in response to other comments, and that's good. But the document was basically sound then, and reflected rough consensus of the participants from the email-developer community, and still does. Considering draft-otis-auth-header-sec-issues-00: Doug's main point appears to involve a disagreement with Murray's decision not to include the IP address, for SPF and Sender-ID cases (for simplicity, I'll just say "SPF" to refer to both in this review). Murray instead includes only the domain that has been verified (or not) *using* the IP address. His complaint is that the header field "fails to offer the authenticated entity being trusted in the exchange, the IP address of the SMTP client." In other words, Doug considers that it's the IP address, not the ADMD, that has been "authenticated". I disagree, but this is a tricky area, because we're not wading in a typical sort of authentication pool here -- SPF is actually blending identity, authentication, and authorization. As I see it, the SPF model is that the *identity* to be authenticated is taken from the SMTP MAIL FROM command (for Sender-ID it's derived through the PRA algorithm), the IP address supplies the authentication *credentials*, and the DNS lookup both verifies the credentials (completing the authentication) and returns the authorization information in one, combined response ("the entity with these credentials is authorized to send mail on behalf of the identity 'example.com'."). Of course, it's entirely reasonable to want the credentials to be preserved, since they're not secret. I see nothing wrong with including the IP address, and I wonder why Murray has chosen not to. That said, I agree with the approach that this field is meant to convey the *results* of application of an "authentication" algorithm, and not to give the MUA what it needs to re-run the authentication. I'll note that the same is true with the application of this to DKIM: the header field described here does not contain all the information provided to the DKIM validator. So, while I see no harm in including the IP address, I have no problem with the decision not to. I also note that it can be added as an extension, if there's demand for that from the MUA vendors. There doesn't seem to be, at this point. There's the issue of needing the IP address to properly assess reputation. DNS black/white lists (see draft-irtf-asrg-dnsbl) use the IP address as a reputation key because it's what they have. The whole *point* of SPF is to translate the IP address into a confirmed domain name, to have a more useful reputation key, and this header field supports that. That said, there are result values that do not allow the use of the ADMD as a key to a reputation check: "none" and "neutral", for example, explicitly refuse to tie the IP address to the domain name. In such cases it might be useful to have the IP address available for fall-back reputation checks. On the other hand, it's likely that the mail system will have done other checks at the domain boundary besides just SPF. Putting the responsibility for IP-address-based checks in the MUA is probably unwise anyway. Doug also worries about the use of the "local part" in SPF cases. I know that Doug is bothered by the local-part stuff in general, and I agree with some of his concerns. I think, though, that those concerns aren't relevant to this document -- the document, again, is reflecting the *results* of the SPF check, which may or may not involve the local part. This document is not *adding* anything in that regard. Finally, Doug appears to dislike the use of the word "authentication" here, and I agree with him. As I said above, SPF (for example) isn't *really* an authentication system, and it's unfortunate that we've fallen into using that term for it. But the fact is that we *have* fallen into it, and I think there'd be more damage done by trying to use a different term than there is by using the term that's come to be accepted, and to acknowledge that it's not strictly correct. So, here's the bottom line: 1. I think draft-kucherawy-sender-auth-header-20 is ready to go as it is. 2. I'd like it if we weren't calling all this "authentication", but I don't see any way around it and I recommend that it NOT be changed. 3. I wouldn't object to the inclusion of the IP address in the header field for SPF and Sender-ID cases, but I don't think it's necessary and support the decision not to include it. Barry -- Barry Leiba, Senior Technical Staff (leiba@watson.ibm.com) Internet Messaging Technology, IBM Research http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Jan 27 08:07:30 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6AB28C0D0; Tue, 27 Jan 2009 08:07:30 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307553A688D for ; Tue, 27 Jan 2009 07:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.676 X-Spam-Level: X-Spam-Status: No, score=-101.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzzkqD97yaBP for ; Tue, 27 Jan 2009 07:54:43 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id AFD2D3A6ABB for ; Tue, 27 Jan 2009 07:54:42 -0800 (PST) Received: from zps36.corp.google.com (zps36.corp.google.com [172.25.146.36]) by smtp-out.google.com with ESMTP id n0RFsO5C021346 for ; Tue, 27 Jan 2009 07:54:25 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1233071665; bh=h0nnfyLeyTNAT/+tJX+fkT+J328=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-GMailtapped-By: X-GMailtapped; b=MT4V2zB/cTSXiXv7lPUsroCHlMzsFU+B4oy+jSIUjeyYPos1J ZEiimcyD/MnugE1Bv5EA8wDlSCBpc+WJd5z7Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-gmailtapped-by:x-gmailtapped; b=NYhi+AsrC1A7Oy0CA1/ODpppOz36vwNLPX+QqMfJPIzUAtIdfe1k5GtJLlFS01zFB CrQV95c6QnevEMiL1V4zg== Received: from gxk14 (gxk14.prod.google.com [10.202.11.14]) by zps36.corp.google.com with ESMTP id n0RFrGmD008266 for ; Tue, 27 Jan 2009 07:54:21 -0800 Received: by gxk14 with SMTP id 14so5624429gxk.13 for ; Tue, 27 Jan 2009 07:54:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.201.2 with SMTP id y2mr681094ybf.185.1233071661124; Tue, 27 Jan 2009 07:54:21 -0800 (PST) In-Reply-To: References: Date: Tue, 27 Jan 2009 15:54:21 +0000 Message-ID: <6e608abf0901270754s5b16274fgeb6092f840baf82d@mail.gmail.com> From: Dave Burke To: Stephen Kent X-GMailtapped-By: 172.25.146.36 X-GMailtapped: daveburke X-Mailman-Approved-At: Tue, 27 Jan 2009 08:07:29 -0800 Cc: secdir@core3.amsl.com, Mark.Scott@genesyslab.com, jon.peterson@neustar.biz Subject: Re: [secdir] secdir review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0861883473==" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org --===============0861883473== Content-Type: multipart/alternative; boundary=00151748dcc6580d51046178dec9 --00151748dcc6580d51046178dec9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks for the feedback Stephen. Comments below. If you agree, I'll prepare an updated draft. Dave On Mon, Jan 19, 2009 at 10:18 PM, Stephen Kent 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 describes a SIP interface to VoiceXML media services and is an > adjunct to the (full) MEDIACTRL protocol. The interface leverages a > mechanism defined in RFC 4240, updating and extending it to match current > VoiceXML specs from the W3C. > The security considerations section of this document is very brief, i.e., > about half a page. The security-relevant requirements cited in this section > appear to be defined only here, not in the body of the spec. This seems a > bit unusual, i.e., this section often is used to summarize > security-relevant requirements that have been explicitly discussed > previously in a document. More importantly, since the security requirements > cited here appear nowhere else in this document, it is critical that the > description provided here be sufficient for implementers to develop > complaint products. We will include additional discussion of security considerations in the main text where appropriate for completeness. >Of the five security requirements (MUST or RECOMMENDED) > cited here, only three meet this criteria. > > The first paragraph notes that offering network services via well-known > ports may enable exploitation (of something) by adversaries, a pretty > generic and vague statement. It then notes that an application server > implementing this protocol MUST support digest authentication "of requesting > endpoints." At a minimum there ought to be a cite to the relevant RFC (2617) > here. Will do >Since the requesting endpoint in this context appears to be another > server (vs. a person) it is not clear that a password-based authentication > mechanism is the preferred choice here. Support for :https is mandated > later, in a different context, so it is not clear why support for that form > of authentication (preferably bi-directionally) is not required here as > well. The requesting endpoint could be as person for very simple networks though it will be a server in the more usual case. We will generalize the method of authentication to any SIP standard approach rather than mandate one particular flavor. > > The second paragraph of this section notes that the transfer mechanism > defined for this protocol could enable various types of attacks, by causing > an application server to make outbound calls. Such calls consume resources > (a DoS attack vector), may cost money (fraud), and might interfere with the > ability of the calls to be traced (unintentional anonymity?). The document > RECCOMMENDs that VoiceXML servers provide "local policies" to authorize and > limit such calls, and audit trails to help resolve billing issues and > provide traceability. This is not an appropriate recommendation for two > reasons. First, this RFC is specifying what vendors of application servers > are supposed to implement. Vendors can provide "mechanisms" that enforce > local policies, but they are not creators of policies per se. So, the > requirement is for mechanisms not policies. Second, this is a very vague > recommendation; if is not clear how one would determine whether a set of > mechanisms offered by a vendor satisfied the recommendation. Agree with the language issue (that we're talking about mechanisms to enforce policies). This paragraph is really attempting to address security within the VoiceXML language which, in retrospect, makes it clearly out of place in this document (it is actually a W3C consideration). For this reason, we'll drop the paragraph. > > To address confidentiality of data transferred to/from these servers, > support for :sips and https: is mandated, which seems appropriate. SRTP also > MUST be supported to provide various security services for media streams, > another appropriate and well-specified requirement. > > The sections ends with another RECOMMENDATION described in terms of the need > to support "local policies" that would help minimize DoS attacks launched > from an application server. Here too the document should be stating the > need for "mechanisms" that can be used to enforce local policies, as noted > above. And, as above, the description is vague, giving just one example, to > be used in evaluating whether a given product satisfies the recommendation. Will fix the language issue and will also change the recommendation to only include well-specified behaviour (i.e. SIP authentication). --00151748dcc6580d51046178dec9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the feedback Stephen. Comments below. If you agree, I'll pre= pare an updated draft.

Dave

On Mon, Jan 19, 2009 at 10:18 PM,= Stephen Kent <kent@bb= n.com> wrote:
> I have reviewed this document as part of the security directorate'= s ongoing
> effort to review all IETF documents being processed by th= e IESG.=A0 These
> comments were written primarily for the benefit of the security area> directors.=A0 Document editors and WG chairs should treat these comm= ents just
> like any other last call comments.
>
> This d= ocument describes a SIP interface to VoiceXML media services and is an
> adjunct to the (full) MEDIACTRL protocol. The interface leverages a> mechanism defined in RFC 4240, updating and extending it to match cur= rent
> VoiceXML specs from the W3C.
> The security consideratio= ns section of this document is very brief, i.e.,
> about half a page. The security-relevant requirements cited in this se= ction
> appear to be defined only here, not in the body of the spec. = This seems a
> bit unusual,=A0 i.e., this section often is used to su= mmarize
> security-relevant requirements that have been explicitly discussed
= > previously in a document. More importantly, since the security require= ments
> cited here appear nowhere else in this document, it is critic= al that the
> description provided here be sufficient for implementers to develop> complaint products.=A0

We will include additional discussion = of security considerations in the main text where appropriate for completen= ess.

>Of the five security requirements (MUST or RECOMMENDED)
> cit= ed here, only three meet this criteria.
>
> The first paragraph= notes that offering network services via well-known
> ports may enab= le exploitation (of something) by adversaries, a pretty
> generic and vague statement. It then notes that an application server<= br>> implementing this protocol MUST support digest authentication "= ;of requesting
> endpoints." At a minimum there ought to be a ci= te to the relevant RFC (2617)
> here.

Will do

>Since the requesting endpoint in this= context appears to be another
> server (vs. a person) it is not clea= r that a password-based authentication
> mechanism is the preferred c= hoice here. Support for :https is mandated
> later, in a different context, so it is not clear why support for that= form
> of authentication (preferably bi-directionally) is not requir= ed here as
> well.

The requesting endpoint could be as person = for very simple networks though it will be a server in the more usual case.= We will generalize the method of authentication to any SIP standard approa= ch rather than mandate one particular flavor.

>
> The second paragraph of this section notes that the transf= er mechanism
> defined for this protocol could enable various types o= f attacks, by causing
> an application server to make outbound calls.= Such calls consume resources
> (a DoS attack vector), may cost money (fraud), and might interfere wit= h the
> ability of the calls to be traced (unintentional anonymity?).= The document
> RECCOMMENDs that VoiceXML servers provide "local= policies" to authorize and
> limit such calls, and audit trails to help resolve billing issues and<= br>> provide traceability. This is not an appropriate recommendation for= two
> reasons. First, this RFC is specifying what vendors of applica= tion servers
> are supposed to implement. Vendors can provide "mechanisms" = that enforce
> local policies, but they are not creators of policies = per se. So, the
> requirement is for mechanisms not policies. Second,= this is a very vague
> recommendation; if is not clear how one would determine whether a set = of
> mechanisms offered by a vendor satisfied the recommendation.
=
Agree with the language issue (that we're talking about mechanisms = to enforce policies). This paragraph is really attempting to address securi= ty within the VoiceXML language which, in retrospect, makes it clearly out = of place in this document (it is actually a W3C consideration). For this re= ason, we'll drop the paragraph.

>
> To address confidentiality of data transferred to/from the= se servers,
> support for :sips and https: is mandated, which seems a= ppropriate. SRTP also
> MUST be supported to provide various security= services for media streams,
> another appropriate and well-specified requirement.
>
> Th= e sections ends with another RECOMMENDATION described in terms of the need<= br>> to support "local policies" that would help minimize DoS = attacks launched
> from an application server.=A0 Here too the document should be stating= the
> need for "mechanisms" that can be used to enforce lo= cal policies, as noted
> above. And, as above, the description is vag= ue, giving just one example, to
> be used in evaluating whether a given product satisfies the recommenda= tion.

Will fix the language issue and will also change the recommend= ation to only include well-specified behaviour (i.e. SIP authentication).

--00151748dcc6580d51046178dec9-- --===============0861883473== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir --===============0861883473==-- From secdir-bounces@ietf.org Thu Jan 29 04:42:20 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C7853A6852; Thu, 29 Jan 2009 04:42:20 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4CBA3A6852 for ; Thu, 29 Jan 2009 04:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ew-iGPilVEhn for ; Thu, 29 Jan 2009 04:42:18 -0800 (PST) Received: from smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by core3.amsl.com (Postfix) with SMTP id CCC7F3A6835 for ; Thu, 29 Jan 2009 04:42:17 -0800 (PST) Received: (qmail 52546 invoked from network); 29 Jan 2009 12:41:59 -0000 Received: from unknown (HELO ?192.168.1.2?) (turners@96.241.10.178 with plain) by smtp109.biz.mail.re2.yahoo.com with SMTP; 29 Jan 2009 12:41:58 -0000 X-YMail-OSG: Tlpe6_IVM1mGH0j_rS8pSp3_em2n1DpYiK_yPOxWQwRPidHADOnI11CEtWFNdopOWXdWgfcnBniQJae.dd2ZQfIBZEefe52siDKkiQD9nXk465UCBfDA0qgz4KsXxYtZAt9h8XZDfMkjvJqe637xQv4FxDhXvHdXuoJnOQ_jCQiB2HX1Vq5KSXbu82JPBQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4981A438.7040808@ieca.com> Date: Thu, 29 Jan 2009 07:42:32 -0500 From: Sean Turner User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Tero Kivinen References: <18800.23494.272977.262435@fireball.kivinen.iki.fi> In-Reply-To: <18800.23494.272977.262435@fireball.kivinen.iki.fi> Cc: pkix-chairs@tools.ietf.org, draft-ietf-pkix-rfc4055-update@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-pkix-rfc4055-update-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Tero Kivinen 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 updates RFC4055 "Additional Algorithms and Identifiers > for RSA Cryptography for use in the Internet X.509 Public Key > Infrastructure Certificate and Certificate Revocation List (CRL) > Profile" by changing one SHOULD to MUST NOT for algorithm parameters > in an X.509 certificate's subjectPublicKeyInfo field. > > I am not completely sure if the Security Considerations section is > enough. Now it says: > > The security considerations from [RFC4055] apply. No new security > considerations are introduced. > > but considering that this moves some bits away from the certificate > and says that they should be negotiated in protocols that need to > employ certificates, this might create new security issues, i.e. it > might put some more emphasis on the security of the protocol used to > negotiate those parameters. > > I do not really know enough, about what kind of parameters there are > to be negotiated in the protocols employing certificates, to know if > this is really the case. Perhaps someone who is understands better > what is moved here, should look this issue. I'm thinking about the S/MIME context where recipients advertise their capabilities with the SMIME Capability attribute and the originator either supports them or it doesn't. So maybe "negotiate" isn't the best word but - how about we add the following to the Security Considerations section: "If the RSAES-OAEP-params are negotiated, then the negotiation mechanism needs to provide integrity for these parameters. For example, an S/MIME Agent can advertise their capabilities in the SMIMECapabilities attribute, which is either signed attribute [RFC3851bis] or a certificate extension [RFC4262]." I'd need to add informative references for RFC3851bis and RFC4262. spt _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Jan 29 08:38:20 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 087543A6B5E; Thu, 29 Jan 2009 08:38:20 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 858933A6C09 for ; Wed, 28 Jan 2009 11:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkVRiMqKkimn for ; Wed, 28 Jan 2009 11:20:24 -0800 (PST) Received: from outbound-mail-03.bluehost.com (outbound-mail-03.bluehost.com [69.89.21.13]) by core3.amsl.com (Postfix) with SMTP id 568F03A6C06 for ; Wed, 28 Jan 2009 11:20:24 -0800 (PST) Received: (qmail 13357 invoked by uid 0); 28 Jan 2009 19:19:23 -0000 Received: from unknown (HELO box474.bluehost.com) (74.220.219.74) by outboundproxy1.bluehost.com with SMTP; 28 Jan 2009 19:19:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type:X-Identified-User; b=qf+5FwE7n8H8fSYgA/PBLvie2miMPTOJFeOjBkzroGy7OePySlZzOEuuWeN+nmHhVuNcQTVmgH6Eo5LNjO/DgVeNuU/xCTpcm7+vB0HPlYlBwgZuSyyBFzRug3my5LGC; Received: from box474.bluehost.com ([74.220.219.74] helo=LC2.labn.net) by box474.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1LSFwz-0001b2-Vs; Wed, 28 Jan 2009 12:19:55 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 28 Jan 2009 14:19:38 -0500 To: Julien Laganier From: Lou Berger In-Reply-To: <200812161700.31641.julien.laganier.IETF@googlemail.com> References: <200812161700.31641.julien.laganier.IETF@googlemail.com> Mime-Version: 1.0 X-Identified-User: {2629:box474.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 74.220.219.74 authed with lberger@labn.net} Message-Id: <20090128192024.568F03A6C06@core3.amsl.com> X-Mailman-Approved-At: Thu, 29 Jan 2009 08:38:19 -0800 Cc: iesg@ietf.org, Tim Polk , draft-ietf-softwire-encaps-ipsec@tools.ietf.org, softwire-chairs@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-softwire-encaps-ipsec-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Julien, Much thanks for your review & comments. Sorry about the delayed response. At 11:00 AM 12/16/2008, Julien Laganier 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. > >I'm no BGP expert thus I'm simply copy/pasting the draft's Abstract >below to give people some background: > > The BGP Encapsulation Subsequence Address Family Identifiers (SAFI) > provides a method for the dynamic exchange of encapsulation > information, and the indication of encapsulation protocol types to be > used for different next hops. Currently support for GRE and L2TPv3 > tunnel types are defined. This document defines support for IPsec > tunnel types. > >The document is short and thus I have few comments: > >In section 2. "IPsec Tunnel Encapsulation Types" >------------------------------------------------ > >" > Per [ENCAPS-SAFI], tunnel type is indicated in the Tunnel > Encapsulation attribute. This document defines the following tunnel > type values: > > - AH in Tunnel-mode: Tunnel Type = 3 [RFC4302] > > - ESP in Tunnel-mode: Tunnel Type = 4 [RFC4303] > > - IP-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 5 > [RFC4023] >" > >I made the same comment for the softwire framework draft but I'm >repeating it here for completeness: The use of IPsec transport mode to >protect tunnels is diminished significantly compared to the protection >afforded by IPsec tunnel mode and thus it would be good to point that >out in the Security Considerations section of this document. For >example RFC 4301 includes the following paragraph: > >" > [...] The access > control functions that are an important part of IPsec are > significantly limited in this context, as they cannot be applied to > the end-to-end headers of the packets that traverse a transport mode > SA used in this fashion. Thus, this way of using transport mode > should be evaluated carefully before being employed in a specific > context. >" Point taken, will add the following to the first paragraph of security considerations section: The security considerations from those documents as well as [RFC4301] apply to the data plane aspects of this document. Notably, this includes the comment on Page 14 of [RFC4301] in reference to the use of transport mode. >In section 3 "Use of IPsec" >--------------------------- > >" > If a R1 is a BGP speaker that receives an Encapsulation SAFI update > from another BGP speaker, R2, then if R1 has any data packets for > which R2 is the BGP next hop, R1 MUST initiate an IPsec SA of the > specified "tunnel type", and all such data packets MUST be sent > through that SA. > > Let R1 and R2 be two BGP speakers that may send data packets through > R3, such that the data packets from R1 and from R2 may be received by > R3 over the same interface. Then if R3 has sent an update containing > an Encapsulation SAFI, and if this update specifies an IPsec tunnel > type, and if this update is received by R2, and an Encapsulation-SAFI > with an IPsec tunnel type, SHOULD also be received by R1. [..] >" > >Maybe this is just me but I have read the last sentence above 5 or 6 >times and I have trouble to parse it. It seems to be some comas should >disappear. Would this rewording be appropriate: > >"If R3 has sent an update containing an Encapsulation SAFI that >specifies an IPsec tunnel type to R2, then an update containing an >Encapsulation SAFI that specifies an IPsec tunnel SHOULD also be >received by R1" ? How about: In this case, when R3 sends an Encapsulation SAFI which indicates an IPsec tunnel type to R2, then R3 SHOULD also send an update specifying an Encapsulation SAFI with an IPsec tunnel type to R1. >Nits: >----- > >In couple of places you're using a reference to a document as a >grammatical object while I understand a reference has a parenthetical >nature and thus can't play that role. > >E.g. "This document does not specify the use of the sub-TLV types >defined in [ENCAPS-SAFI] with these tunnel types." > >Should be reworded into something like "This document does not specify >the use of the sub-TLV types defined in the BGP Information SAFI and >BGP Tunnel Encapsulation Attribute specification [ENCAPS-SAFI] with >these tunnel types." This is pretty common in IETF documents... >This is all for this document. Hope this is useful. It is, thank you. Lou >--julien _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Jan 29 08:38:20 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EDE73A6B71; Thu, 29 Jan 2009 08:38:20 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F0463A67EC; Thu, 29 Jan 2009 08:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoH-ZgKmJbLE; Thu, 29 Jan 2009 08:25:28 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C654F3A68AB; Thu, 29 Jan 2009 08:25:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,345,1231113600"; d="scan'208";a="35277515" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 Jan 2009 16:25:09 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0TGP9ML010073; Thu, 29 Jan 2009 11:25:09 -0500 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0TGP9w7005400; Thu, 29 Jan 2009 16:25:09 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id n0TGP57o021964; Thu, 29 Jan 2009 11:25:05 -0500 To: Julien Laganier In-reply-to: Your message of Tue, 16 Dec 2008 16:35:44 +0100. <200812161635.45024.julien.laganier.IETF@googlemail.com> Date: Thu, 29 Jan 2009 11:25:05 -0500 Message-ID: <21963.1233246305@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4199; t=1233246309; x=1234110309; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20[secdir]=20SECDIR=20review=20of=20draft -ietf-softwire-mesh-framework-05=20 |Sender:=20 |To:=20Julien=20Laganier=20; bh=C/hPfWpVcEu+fMEuSz0xViGhXOfYMbVn044I/HNbsEY=; b=0tFw+x0PDP6g1s1PzXXWy9RGAyL75mByc+9vlqx5wR8HTRN5kiVdy3CnMK nr7Th2o/jV7RPufds5Q3x7th25TjBqENLwBL+BtBfkUGsfOje8KdNh0rJKFM AQGcqaqx6R; Authentication-Results: rtp-dkim-2; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Mailman-Approved-At: Thu, 29 Jan 2009 08:38:19 -0800 Cc: iesg@ietf.org, Tim Polk , secdir@ietf.org, softwire-chairs@tools.ietf.org, draft-ietf-softwire-mesh-framework@tools.ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-softwire-mesh-framework-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Sorry, somehow I didn't notice this review when it was posted. Julien> In section 14.1 "Problem Analysis": draft> Since the encapsulation headers determine the routing of packets draft> traveling through softwires, they must appear "in the clear", i.e., draft> they do not have any confidentiality requirement. Julien> Suggest removing "i.e." and what follows. Agreed. draft> In the Softwires mesh framework, for each tunnel receiving endpoint, draft> there are one or more "valid" transmitting endpoints, where the valid draft> transmitting endpoints are those which are authorized to tunnel draft> packets to the receiving endpoint. If the encapsulation header has draft> no guarantee of authentication or integrity, then it is possible to draft> have spoofing attacks, in which unauthorized nodes send encapsulated draft> packets to the receiving endpoint, giving the receiving endpoint the draft> invalid impression the encapsulated packets have really traveled draft> through the softwire. Replay attacks are also possible. draft> The effect of such attacks is somewhat limited though. The receiving draft> endpoint of a softwire decapsulates the payload and does further draft> routing based on the IP destination address of the payload. Since draft> the payload packets are traveling through the Internet, they have draft> addresses from the globally unique address space (rather than, e.g., draft> from a private address space of some sort). Therefore these attacks draft> cannot cause payload packets to be delivered to an address other than draft> the one intended. Julien> I'm finding the use of the term "intended" in the last sentence Julien> misleading. I will replace "the one intended" by "the one appearing in the IP destination address field of the payload packet". Julien> I suggest that the paragraph that contains the text on the "intended" Julien> destination is simply completely removed since it does not seem to add Julien> to the rest of the text. The point is that the tunnel egress will still forward the payload packet based on the contents of the payload packet's IP destination address field. draft> Attacks of the sort we are considering can also be used in Denial of draft> Service attacks on the receiving tunnel endpoints. However, such draft> attacks cannot be prevented by use of cryptographic draft> authentication/integrity techniques, as the need to do cryptography draft> on spoofed packets only makes the Denial of Service problem worse. Julien> It would be good to understand the sort of flooding attacks you are Julien> considering here (e.g. flooding attacks on the link supporting the Julien> softwire) so that the statement that integrity protection is of no used Julien> can be assessed. The assumption is that the crypto mechanisms are likely to be more costly than the decapsulation/forwarding mechanisms. So if one tries to eliminate a flooding attack on the decapsulation/forwarding mechanisms by using cryptographic integrity, one ends up just trading one kind of attack for another. In section 14.3 "Cryptographic Techniques" ------------------------------------------ Julien> The use of IPsec transport mode to protect tunnels is diminished Julien> significantly compared to the protection afforded by IPsec tunnel mode Julien> and thus it would be good to point that out in the above paragraph as Julien> well as in the IPsec encapsulation document [ENCAPS-IPSEC]. For example Julien> RFC 4301 includes the following paragraph: RFC4301> [...] The access RFC4301> control functions that are an important part of IPsec are RFC4301> significantly limited in this context, as they cannot be applied to RFC4301> the end-to-end headers of the packets that traverse a transport mode RFC4301> SA used in this fashion. Thus, this way of using transport mode RFC4301> should be evaluated carefully before being employed in a specific RFC4301> context. I believe this is adequately addressed in section 14.1, "Problem Analysis". Or do you see something that would make tunnel mode useful in this context? _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Jan 29 14:15:34 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472913A6B7A; Thu, 29 Jan 2009 14:15:34 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCE563A6B70; Thu, 29 Jan 2009 14:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75TLcXVxwTrj; Thu, 29 Jan 2009 14:15:32 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 0639F3A6A64; Thu, 29 Jan 2009 14:15:32 -0800 (PST) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LSfA1-0006zN-9z; Thu, 29 Jan 2009 17:14:57 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20090128192024.568F03A6C06@core3.amsl.com> References: <200812161700.31641.julien.laganier.IETF@googlemail.com> <20090128192024.568F03A6C06@core3.amsl.com> Date: Thu, 29 Jan 2009 17:14:54 -0500 To: Lou Berger From: Stephen Kent Cc: draft-ietf-softwire-encaps-ipsec@tools.ietf.org, secdir@ietf.org, Tim Polk , softwire-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-softwire-encaps-ipsec-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Lou, As an IPsec guy with an interest in routing, I had a few questions about this document. The current version of IPsec (See RFC 4301) suggests use of ESP-NULL for the latter security services, rather that AH. However, this document lists ESP and AH as the two IPsec encapsulation options. It might be preferable to cite ESP-NULL in lieu of AH here, especially if integrity is likely to be a commonly-selected service. (It was not clear from the security consideration section whether the primary focus of this tunnel option was to provide confidentiality and integrity for traffic, or integrity.) I also think that the IPsec architecture document (RFC 4301) ought to be cited here as normative, along with the IPsec protocol specs. If an RFC defines a means of triggering use of IPsec, and defines parameters that indicate which then the IPsec architecture document and the relevant IPsec protocol documents strike me as normative references. For example, when the encapsulation type calls for an AH or ESP tunnel, the two routers in question need to have SPD entries that specify the parameters for the tunnel that will be created, e.g., indicating algorithms, modes, and optional services like anti-replay. Just saying that a router will create an AH or ESP tunnel is not specific enough to say what really will happen. The SPD entries at each end will be used to fill in the details needed to allow successful creation of the tunnel. So, it seems appropriate to note this in the document, and to cite the architecture spec as normative. Finally, there is no cite for IKE. White it is true that IPsec does not require use of IKE, I believe that the vast majority of IPsec implementation use IKE. So, why not call for IKE use here as well, to negotiate the SA parameters and manage keys. The IETF prefers automated key management for security protocols, and IKE is the designated key management protocol for IPsec. Since the document cites the newest versions of AH and ESP, both of which assume use of IKEv2, the right cite is to that version of IPsec. Thanks, Steve _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Jan 29 15:05:00 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EBCE3A69CF; Thu, 29 Jan 2009 15:05:00 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5D23A69CF for ; Thu, 29 Jan 2009 15:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8Bn6t6IhEMA for ; Thu, 29 Jan 2009 15:04:58 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 880653A68F1 for ; Thu, 29 Jan 2009 15:04:58 -0800 (PST) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LSfw4-0007p2-BK; Thu, 29 Jan 2009 18:04:36 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <6e608abf0901270754s5b16274fgeb6092f840baf82d@mail.gmail.com> References: <6e608abf0901270754s5b16274fgeb6092f840baf82d@mail.gmail.com> Date: Thu, 29 Jan 2009 18:04:34 -0500 To: Dave Burke From: Stephen Kent Cc: secdir@core3.amsl.com, Mark.Scott@genesyslab.com, jon.peterson@neustar.biz Subject: Re: [secdir] secdir review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Dave, I think the changes you propose are reasonable. Steve _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Jan 29 15:29:59 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49C983A6873; Thu, 29 Jan 2009 15:29:59 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FAF13A6873; Thu, 29 Jan 2009 15:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEGCeS+8jnfs; Thu, 29 Jan 2009 15:29:56 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 4998F3A6864; Thu, 29 Jan 2009 15:29:56 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n0TNTNp0008227; Thu, 29 Jan 2009 17:29:23 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n0TNTLjj015405; Thu, 29 Jan 2009 17:29:21 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.155]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Jan 2009 18:28:22 -0500 Date: Thu, 29 Jan 2009 18:28:21 -0500 (Eastern Standard Time) From: Sandra Murphy To: Stephen Kent In-Reply-To: Message-ID: References: <200812161700.31641.julien.laganier.IETF@googlemail.com> <20090128192024.568F03A6C06@core3.amsl.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jan 2009 23:28:22.0369 (UTC) FILETIME=[468E7D10:01C98269] Cc: draft-ietf-softwire-encaps-ipsec@tools.ietf.org, secdir@ietf.org, Tim Polk , iesg@ietf.org, Lou Berger , softwire-chairs@tools.ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-softwire-encaps-ipsec-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On Thu, 29 Jan 2009, Stephen Kent wrote: > Lou, > > As an IPsec guy with an interest in routing, I had a few questions about this > document. > > The current version of IPsec (See RFC 4301) suggests use of ESP-NULL for the > latter security services, rather that AH. However, this document lists ESP > and AH as the two IPsec encapsulation options. It might be preferable to cite > ESP-NULL in lieu of AH here, especially if integrity is likely to be a > commonly-selected service. (It was not clear from the security consideration > section whether the primary focus of this tunnel option was to provide > confidentiality and integrity for traffic, or integrity.) I found it somewhat ironic that signalling the use of public key cryptography in these IPsec tunnels is itself to be protected by TCP MD5: When the IPsec Tunnel Authenticator sub-TLV is used, it is highly RECOMMENDED that the integrity of the BGP session itself be protected. This is usually done by using the TCP MD5 option [RFC2385]. > > I also think that the IPsec architecture document (RFC 4301) ought to be > cited here as normative, along with the IPsec protocol specs. If an RFC > defines a means of triggering use of IPsec, and defines parameters that > indicate which then the IPsec architecture document and the relevant IPsec ^^ ?? > protocol documents strike me as normative references. For example, when the > encapsulation type calls for an AH or ESP tunnel, the two routers in question > need to have SPD entries that specify the parameters for the tunnel that will > be created, e.g., indicating algorithms, modes, and optional services like > anti-replay. Just saying that a router will create an AH or ESP tunnel is not > specific enough to say what really will happen. The SPD entries at each end > will be used to fill in the details needed to allow successful creation of > the tunnel. So, it seems appropriate to note this in the document, and to > cite the architecture spec as normative. > > Finally, there is no cite for IKE. White it is true that IPsec does not > require use of IKE, I believe that the vast majority of IPsec implementation > use IKE. So, why not call for IKE use here as well, to negotiate the SA > parameters and manage keys. There's no cite, true. But I see that a reference to using IKE (but not IKEv2) in section 3 (for negotiation of policy) and in section 4.1 (for obtaining a certificate for the router that sent a tunnel authenticator sub-TLV). > The IETF prefers automated key management for > security protocols, and IKE is the designated key management protocol for > IPsec. Since the document cites the newest versions of AH and ESP, both of > which assume use of IKEv2, the right cite is to that version of IPsec. > > Thanks, > --Sandy _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Jan 29 15:31:55 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E98C3A689F; Thu, 29 Jan 2009 15:31:55 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A5F3A6864; Thu, 29 Jan 2009 15:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN1wdRMtmls1; Thu, 29 Jan 2009 15:31:54 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 767DA3A689F; Thu, 29 Jan 2009 15:31:54 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n0TNVO4v008259; Thu, 29 Jan 2009 17:31:24 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n0TNVOqe015469; Thu, 29 Jan 2009 17:31:24 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.155]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Jan 2009 18:30:54 -0500 Date: Thu, 29 Jan 2009 18:30:53 -0500 (Eastern Standard Time) From: Sandra Murphy To: Stephen Kent In-Reply-To: Message-ID: References: <200812161700.31641.julien.laganier.IETF@googlemail.com> <20090128192024.568F03A6C06@core3.amsl.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jan 2009 23:30:54.0151 (UTC) FILETIME=[A1069570:01C98269] Cc: draft-ietf-softwire-encaps-ipsec@tools.ietf.org, secdir@ietf.org, Tim Polk , iesg@ietf.org, Lou Berger , softwire-chairs@tools.ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-softwire-encaps-ipsec-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On Thu, 29 Jan 2009, Sandra Murphy wrote: > > > On Thu, 29 Jan 2009, Stephen Kent wrote: > >> Lou, >> indicate which then the IPsec architecture document and the relevant IPsec > ^^ > ?? Sorry, I was intended to point to the "which then" part of the sentence. I don't know that the spacing was retained by my mailer. --Sandy _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Jan 30 02:43:33 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3847A28C137; Fri, 30 Jan 2009 02:43:33 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9C43A69D4; Fri, 30 Jan 2009 02:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCbvXBeMC6Di; Fri, 30 Jan 2009 02:43:31 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id EA96328C137; Fri, 30 Jan 2009 02:43:30 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n0UAh72D011626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 12:43:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0UAh40A000125; Fri, 30 Jan 2009 12:43:04 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18818.55736.869990.205671@fireball.kivinen.iki.fi> Date: Fri, 30 Jan 2009 12:43:04 +0200 From: Tero Kivinen To: Sandra Murphy In-Reply-To: References: <200812161700.31641.julien.laganier.IETF@googlemail.com> <20090128192024.568F03A6C06@core3.amsl.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: draft-ietf-softwire-encaps-ipsec@tools.ietf.org, secdir@ietf.org, Tim Polk , iesg@ietf.org, Lou Berger , softwire-chairs@tools.ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-softwire-encaps-ipsec-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Sandra Murphy writes: > > Finally, there is no cite for IKE. White it is true that IPsec does not > > require use of IKE, I believe that the vast majority of IPsec implementation > > use IKE. So, why not call for IKE use here as well, to negotiate the SA > > parameters and manage keys. > > There's no cite, true. But I see that a reference to using IKE (but not > IKEv2) in section 3 (for negotiation of policy) and in section 4.1 (for > obtaining a certificate for the router that sent a tunnel authenticator > sub-TLV). The draft-ietf-softwire-mesh-framework draft says that negotiation is done using IKEv2: ---------------------------------------------------------------------- 6. Softwire Signaling ... ... A softwire based on IPsec would use standard IKEv2 (Internet Key Exchange) [RFC4306] and IPsec [RFC4301] signaling, as that is necessary in order to guarantee the softwire's security properties. ... 14.3. Cryptographic techniques ... Since the softwires are set up dynamically as a byproduct of passing routing information, key distribution MUST be done automatically by means of IKEv2 [RFC4306], operating in main mode with preshared keys. If a PKI (Public Key Infrastructure) is not available, the IPsec Tunnel Authenticator sub-TLV described in [ENCAPS-IPSEC] MUST be used and validated before setting up an SA. ... ---------------------------------------------------------------------- (altought as I said in my earlier mail the "main mode with preshared keys" text should not be there, as that is using IKEv1 terms). So softwire do use IKEv2 ad new IPsec architecture, but I agree that draft-ietf-softwire-encaps-ipsec should also have references to those documents. -- kivinen@iki.fi _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Jan 30 02:50:53 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51CD628C23B; Fri, 30 Jan 2009 02:50:53 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C7753A6A13; Fri, 30 Jan 2009 02:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EIYQzkqetOn; Fri, 30 Jan 2009 02:50:51 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 340CE3A69D4; Fri, 30 Jan 2009 02:50:51 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n0UAoSKD012998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 12:50:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0UAoRik019565; Fri, 30 Jan 2009 12:50:27 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18818.56179.659029.30051@fireball.kivinen.iki.fi> Date: Fri, 30 Jan 2009 12:50:27 +0200 From: Tero Kivinen To: Sean Turner In-Reply-To: <4981A438.7040808@ieca.com> References: <18800.23494.272977.262435@fireball.kivinen.iki.fi> <4981A438.7040808@ieca.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: pkix-chairs@tools.ietf.org, draft-ietf-pkix-rfc4055-update@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-pkix-rfc4055-update-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Sean Turner writes: > I'm thinking about the S/MIME context where recipients advertise their > capabilities with the SMIME Capability attribute and the originator > either supports them or it doesn't. So maybe "negotiate" isn't the best > word but - how about we add the following to the Security Considerations > section: > > "If the RSAES-OAEP-params are negotiated, then the negotiation mechanism > needs to provide integrity for these parameters. For example, an S/MIME > Agent can advertise their capabilities in the SMIMECapabilities > attribute, which is either signed attribute [RFC3851bis] or a > certificate extension [RFC4262]." That would address my concern. -- kivinen@iki.fi _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Jan 30 07:25:28 2009 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A74D3A69F8; Fri, 30 Jan 2009 07:25:28 -0800 (PST) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2299F3A69ED; Fri, 30 Jan 2009 07:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.712 X-Spam-Level: X-Spam-Status: No, score=-2.712 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQhUDcW-uQX9; Fri, 30 Jan 2009 07:25:19 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 574C33A69BD; Fri, 30 Jan 2009 07:25:13 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.4]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LSvEM-0002bp-A1; Fri, 30 Jan 2009 10:24:30 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200812161700.31641.julien.laganier.IETF@googlemail.com> <20090128192024.568F03A6C06@core3.amsl.com> Date: Fri, 30 Jan 2009 10:24:28 -0500 To: Sandra Murphy From: Stephen Kent Cc: draft-ietf-softwire-encaps-ipsec@tools.ietf.org, secdir@ietf.org, Tim Polk , iesg@ietf.org, Lou Berger , softwire-chairs@tools.ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-softwire-encaps-ipsec-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0843929097==" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org --===============0843929097== Content-Type: multipart/alternative; boundary="============_-978793427==_ma============" --============_-978793427==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 6:28 PM -0500 1/29/09, Sandra Murphy wrote: >On Thu, 29 Jan 2009, Stephen Kent wrote: > >>Lou, >> >>As an IPsec guy with an interest in routing, I had a few questions >>about this document. >> >>The current version of IPsec (See RFC 4301) suggests use of >>ESP-NULL for the latter security services, rather that AH. However, >>this document lists ESP and AH as the two IPsec encapsulation >>options. It might be preferable to cite ESP-NULL in lieu of AH >>here, especially if integrity is likely to be a commonly-selected >>service. (It was not clear from the security consideration section >>whether the primary focus of this tunnel option was to provide >>confidentiality and integrity for traffic, or integrity.) > >I found it somewhat ironic that signalling the use of public key >cryptography in these IPsec tunnels is itself to be protected by TCP >MD5: > > When the IPsec Tunnel Authenticator sub-TLV is used, it is highly > RECOMMENDED that the integrity of the BGP session itself be > protected. This is usually done by using the TCP MD5 option > [RFC2385]. good point, I missed that. That's what happens when one expands the set of options being negotiated to include security protocols. >> >>I also think that the IPsec architecture document (RFC 4301) ought >>to be cited here as normative, along with the IPsec protocol specs. >>If an RFC defines a means of triggering use of IPsec, and defines >>parameters that indicate which then the IPsec architecture >>document and the relevant IPsec > ^^ > ?? whoops. My editing deleted more that I intended. I think the sentence shoud read: If an RFC defines a means of triggering use of IPsec, and defines parameters that indicate which IPsec protocols are to be used, then the IPsec architecture document and the relevant IPsec >>protocol documents strike me as normative references. For example, >>when the encapsulation type calls for an AH or ESP tunnel, the two >>routers in question need to have SPD entries that specify the >>parameters for the tunnel that will be created, e.g., indicating >>algorithms, modes, and optional services like anti-replay. Just >>saying that a router will create an AH or ESP tunnel is not >>specific enough to say what really will happen. The SPD entries at >>each end will be used to fill in the details needed to allow >>successful creation of the tunnel. So, it seems appropriate to >>note this in the document, and to cite the architecture spec as >>normative. >> >>Finally, there is no cite for IKE. White it is true that IPsec >>does not require use of IKE, I believe that the vast majority of >>IPsec implementation use IKE. So, why not call for IKE use here as >>well, to negotiate the SA parameters and manage keys. > >There's no cite, true. But I see that a reference to using IKE (but >not IKEv2) in section 3 (for negotiation of policy) and in section >4.1 (for obtaining a certificate for the router that sent a tunnel >authenticator sub-TLV). Whoops, again. I missed that too. But, if one calls for use of the latest AH and ESP specs, then IKEv2 is needed, since these versions of the IPsec protocols rely on IKEv2 negotiation capabilities. Steve --============_-978793427==_ma============ Content-Type: text/html; charset="us-ascii" Re: [secdir] SECDIR review of draft-ietf-softwire-encaps-
At 6:28 PM -0500 1/29/09, Sandra Murphy wrote:
On Thu, 29 Jan 2009, Stephen Kent wrote:
Lou,

As an IPsec guy with an interest in routing, I had a few questions about this document.

The current version of IPsec (See RFC 4301) suggests use of ESP-NULL for the latter security services, rather that AH. However, this document lists ESP and AH as the two IPsec encapsulation options. It might be preferable to cite ESP-NULL in lieu of AH here, especially if integrity is likely to be a commonly-selected service.  (It was not clear from the security consideration section whether the primary focus of this tunnel option was to provide confidentiality and integrity for traffic, or integrity.)

I found it somewhat ironic that signalling the use of public key cryptography in these IPsec tunnels is itself to be protected by TCP MD5:

   When the IPsec Tunnel Authenticator sub-TLV is used, it is highly
   RECOMMENDED that the integrity of the BGP session itself be
   protected.  This is usually done by using the TCP MD5 option
   [RFC2385].

good point,  I missed that. That's what happens when one expands the set of options being negotiated to include security protocols.


I also think that the IPsec architecture document (RFC 4301) ought to be cited here as normative, along with the IPsec protocol specs.  If an RFC defines a means of triggering use of IPsec, and defines parameters that indicate which  then the IPsec architecture document and the relevant IPsec
                ^^
                ??

whoops. My editing deleted more that I intended.  I think the sentence shoud read:

If an RFC defines a means of triggering use of IPsec, and defines parameters that indicate which IPsec protocols are to be used, then the IPsec architecture document and the relevant IPsec

protocol documents strike me as normative references. For example, when the encapsulation type calls for an AH or ESP tunnel, the two routers in question need to have SPD entries that specify the parameters for the tunnel that will be created, e.g., indicating algorithms, modes, and optional services like anti-replay. Just saying that a router will create an AH or ESP tunnel is not specific enough to say what really will happen. The SPD entries at each end will be used to fill in the details needed to allow successful creation of the tunnel.  So, it seems appropriate to note this in the document, and to cite the architecture spec as normative.

Finally, there is no cite for IKE.  White it is true that IPsec does not require use of IKE, I believe that the vast majority of IPsec implementation use IKE. So, why not call for IKE use here as well, to negotiate the SA parameters and manage keys.

There's no cite, true.  But I see that a reference to using IKE (but not IKEv2) in section 3 (for negotiation of policy) and in section 4.1 (for obtaining a certificate for the router that sent a tunnel authenticator sub-TLV).

Whoops, again. I missed that too. But, if one calls for use of the latest AH and ESP specs, then IKEv2 is needed, since these versions of the IPsec protocols rely on IKEv2 negotiation capabilities.

Steve
--============_-978793427==_ma============-- --===============0843929097== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir --===============0843929097==--