From kivinen@iki.fi Fri Aug 2 02:02:07 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2B521F83EF for ; Fri, 2 Aug 2013 02:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjtYot9h1IkD for ; Fri, 2 Aug 2013 02:02:05 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2888711E82C9 for ; Fri, 2 Aug 2013 01:56:08 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r728twV1011820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 2 Aug 2013 11:55:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r728twtB024464; Fri, 2 Aug 2013 11:55:58 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20987.29726.33608.39332@fireball.kivinen.iki.fi> Date: Fri, 2 Aug 2013 11:55:58 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 5 min X-Total-Time: 4 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 09:02:07 -0000 There is quite a lot of rechecks this weeks, mostly because those drafts did have real changes since the last review, and reviewers had marked them having issues, so it is better for reviewers to check whether they have been solved. If there is only some nits, and the diffs clearly show they have been addressed, I do not assign rechecks, but this week that wasn't true for most of those recheck drafts. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Carl Wallace is next in the rotation. For telechat 2013-08-15 Reviewer LC end Draft Steve Hanna TR2013-06-27 draft-ietf-manet-rfc6622-bis-04 Dan Harkins T 2013-07-03 draft-ietf-multimob-pmipv6-ropt-07 Simon Josefsson TR2013-07-23 draft-merkle-tls-brainpool-04 Charlie Kaufman TR2013-07-18 draft-ietf-trill-directory-framework-06 Stephen Kent TR2013-05-27 draft-ietf-mpls-ldp-dod-09 Ben Laurie T 2013-07-25 draft-ietf-emu-crypto-bind-04 Matt Lepinski T 2013-08-13 draft-bormann-cbor-04 Kathleen Moriarty T 2013-07-29 draft-ietf-weirds-rdap-sec-04 Sandy Murphy TR2013-07-17 draft-jabley-dnsext-eui48-eui64-rrtypes-05 Sandy Murphy T 2013-07-29 draft-ietf-weirds-using-http-07 Joe Salowey T 2013-08-12 draft-ietf-websec-x-frame-options-07 Klaas Wierenga TR2013-04-29 draft-ietf-karp-crypto-key-table-08 For telechat 2013-08-29 Warren Kumari T 2013-07-15 draft-ietf-lisp-deployment-09 Last calls and special requests: Rob Austein 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Dave Cridland - draft-ietf-httpbis-p5-range-23 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-03-30 draft-ietf-roll-terminology-12 Jeffrey Hutzelman 2013-07-16 draft-yusef-dispatch-ccmp-indication-04 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-04 Julien Laganier - draft-ietf-avtcore-rtp-security-options-04 Julien Laganier - draft-ietf-websec-key-pinning-08 Alexey Melnikov - draft-ietf-payload-rtp-howto-04 Alexey Melnikov 2013-07-31 draft-ietf-mpls-retire-ach-tlv-03 Magnus Nystrom 2013-08-16 draft-allen-dispatch-imei-urn-as-instanceid-10 Radia Perlman 2013-08-18 draft-ietf-karp-ops-model-07 Vincent Roca 2013-06-11 draft-ietf-avtcore-idms-12 Vincent Roca 2013-08-21 draft-ietf-mpls-tp-mip-mep-map-08 Yaron Sheffer 2013-08-16 draft-ietf-tls-oob-pubkey-09 Ondrej Sury 2013-08-16 draft-nandakumar-rtcweb-stun-uri-05 Tina TSOU 2013-08-16 draft-petithuguenin-behave-turn-uris-05 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-10 Glen Zorn 2012-11-27 draft-ietf-lisp-eid-block-04 -- kivinen@iki.fi From adrian@olddog.co.uk Fri Aug 2 03:49:57 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB1911E81B0; Fri, 2 Aug 2013 03:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9UsU-JqS5oP; Fri, 2 Aug 2013 03:49:49 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id A16C711E810B; Fri, 2 Aug 2013 03:49:49 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r72Anfno026675; Fri, 2 Aug 2013 11:49:41 +0100 Received: from 950129200 (dhcp-13f0.meeting.ietf.org [130.129.19.240]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r72AnePo026669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Aug 2013 11:49:40 +0100 From: "Adrian Farrel" To: "'Ulrich Herberg'" , References: <332E771E-87A4-4C9F-83B7-CB96AB41D5A3@checkpoint.com> In-Reply-To: Date: Fri, 2 Aug 2013 11:49:38 +0100 Message-ID: <005201ce8f6d$fcc8ac20$f65a0460$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ2oxa89x7ZD6lT1OtVSdmjBUu/BgGMWeS+mCUv+aA= Content-Language: en-gb Cc: secdir@ietf.org, 'IESG' , draft-ietf-manet-nhdp-olsrv2-sec.all@tools.ietf.org Subject: Re: [secdir] SecDir Review of draft-ietf-manet-nhdp-olsrv2-sec-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 10:49:57 -0000 Hello all, >> I am not convinced by the suitability of a POSIX timestamp (32-bits with 1- >> second resolution) to protect in general against replay. Within the same second, a >> packet can be replayed. I don't know enough about the NHDP and OLSRv2 >> protocols to say whether this is a problem. Its usefulness depends on >> synchronized clocks, but this is well explained in the document, both in the >> security considerations, and in the regular sections where timestamp is >> mentioned. > > UH> In the majority of MANET use cases that we are aware of, time > synchronization much below one second is not possible. Also, keep in > mind that the MANET routers are not the typical huge backbone router, > but rather very constrained devices with CPUs of only a few Megahertz > and memory of megabytes or even just kilobytes. The precision of the > clocks on such devices will consequently not be of the same > granularity as on the big Internet routers. Note that, as we explained > in the previous comment, only the *implementation* of this framework > is mandatory, not the *usage*. In use cases with higher requirements > (and with routers of appropriate capability), higher granularity > timestamps may be used (e.g., for military use cases). > UH> In addition, when looking at the default message intervals and > validity times (minimum 2 seconds) anyone repeating the message within > a second is (bandwidth occupation aside) doing you a favor, not a > harm. If going into details, the use of RFC5148 jitter can cause a > message to take that long or more to traverse the network. In fact > even in a perfectly synchronized network, with fine granularity times, > the TC maximum delay would probably be greater than 1 second. (Shorter > for HELLO messages.) Yes, this seems right. This is good text and helps explain a lot about the operation of the protocols in environments that need to be secured. It also can be used to highlight the small vulnerability of replay within the timestamp granularity. Could you polish it and add it to the draft? > > The biggest hole in this specification is that it is silent about key distribution >> ("This framework does not...Specify how to distribute cryptographic material >> (shared secret key(s))." This is the real hard problem, and the draft doesn't even >> reference some other specification that does have a suitable key distribution >> protocol. You can't do HMAC without key distribution being in place. > > UH> We have intensely discussed this with Stephen Farrel, who agreed > with this approach (and which actually triggered this particular > draft). The relevant text why we do not specify a key management > mechanism, can be found in the "Security Considerations" section in > OLSRv2. We can add a pointer to that text in the nhdp-olsrv2-sec > draft. That pointer would be a great idea. I suspect that we must take small steps towards the complete security picture. That the key distribution is still an open issue is at last exposed here. Is there enough text describing how deployed systems handle this issue? I suspect that, since many MANETs are military, there is an operational solution to this problem (probably involving men with guns and RSA tokens :-) > > On to the security considerations section: [snip] > UH> Very good catches. We will fix them. Ulrich and authors... Last call expires on 8/14 and the document is currently set for IESG review on 8/15 If the resolution of these comments can be agreed with Yoav, no more substantive comments come in, and a new version is ready to post on 8/14 we can go ahead on the current schedule. If you think you need more time, I will move the document out to a later IESG telechat. Adrian From ynir@checkpoint.com Fri Aug 2 03:57:23 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A103B11E828F; Fri, 2 Aug 2013 03:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.478 X-Spam-Level: X-Spam-Status: No, score=-10.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9KEDqEXjvT0; Fri, 2 Aug 2013 03:57:13 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3183911E8251; Fri, 2 Aug 2013 03:57:12 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r72Av8Q6023835; Fri, 2 Aug 2013 13:57:08 +0300 X-CheckPoint: {51FB9084-3-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Fri, 2 Aug 2013 13:57:07 +0300 From: Yoav Nir To: "" Thread-Topic: SecDir Review of draft-ietf-manet-nhdp-olsrv2-sec-03 Thread-Index: AQHOjkRzWPcMempN206ICOIpPpticZl/4aaAgAGrfgCAAAIWAA== Date: Fri, 2 Aug 2013 10:57:06 +0000 Message-ID: <2696224D-F001-490D-8D37-381CCD199920@checkpoint.com> References: <332E771E-87A4-4C9F-83B7-CB96AB41D5A3@checkpoint.com> <005201ce8f6d$fcc8ac20$f65a0460$@olddog.co.uk> In-Reply-To: <005201ce8f6d$fcc8ac20$f65a0460$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.96] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 114f3aae9f1ac07032ddcf217b6e2e1a042259464f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , IESG , Ulrich Herberg , "" Subject: Re: [secdir] SecDir Review of draft-ietf-manet-nhdp-olsrv2-sec-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 10:57:24 -0000 With the proposed changes, including a statement that someone is working on= key distribution, I'm fine. On Aug 2, 2013, at 12:49 PM, Adrian Farrel wrote: > Hello all, >=20 >>> I am not convinced by the suitability of a POSIX timestamp (32-bits wit= h 1- >>> second resolution) to protect in general against replay. Within the sam= e > second, a >>> packet can be replayed. I don't know enough about the NHDP and OLSRv2 >>> protocols to say whether this is a problem. Its usefulness depends on >>> synchronized clocks, but this is well explained in the document, both i= n the >>> security considerations, and in the regular sections where timestamp is >>> mentioned. >>=20 >> UH> In the majority of MANET use cases that we are aware of, time >> synchronization much below one second is not possible. Also, keep in >> mind that the MANET routers are not the typical huge backbone router, >> but rather very constrained devices with CPUs of only a few Megahertz >> and memory of megabytes or even just kilobytes. The precision of the >> clocks on such devices will consequently not be of the same >> granularity as on the big Internet routers. Note that, as we explained >> in the previous comment, only the *implementation* of this framework >> is mandatory, not the *usage*. In use cases with higher requirements >> (and with routers of appropriate capability), higher granularity >> timestamps may be used (e.g., for military use cases). >> UH> In addition, when looking at the default message intervals and >> validity times (minimum 2 seconds) anyone repeating the message within >> a second is (bandwidth occupation aside) doing you a favor, not a >> harm. If going into details, the use of RFC5148 jitter can cause a >> message to take that long or more to traverse the network. In fact >> even in a perfectly synchronized network, with fine granularity times, >> the TC maximum delay would probably be greater than 1 second. (Shorter >> for HELLO messages.) >=20 > Yes, this seems right. >=20 > This is good text and helps explain a lot about the operation of the prot= ocols > in environments that need to be secured. It also can be used to highlight= the > small vulnerability of replay within the timestamp granularity. >=20 > Could you polish it and add it to the draft? >=20 >>> The biggest hole in this specification is that it is silent about key > distribution >>> ("This framework does not...Specify how to distribute cryptographic mat= erial >>> (shared secret key(s))." This is the real hard problem, and the draft d= oesn't > even >>> reference some other specification that does have a suitable key distri= bution >>> protocol. You can't do HMAC without key distribution being in place. >>=20 >> UH> We have intensely discussed this with Stephen Farrel, who agreed >> with this approach (and which actually triggered this particular >> draft). The relevant text why we do not specify a key management >> mechanism, can be found in the "Security Considerations" section in >> OLSRv2. We can add a pointer to that text in the nhdp-olsrv2-sec >> draft. >=20 > That pointer would be a great idea. >=20 > I suspect that we must take small steps towards the complete security pic= ture. > That the key distribution is still an open issue is at last exposed here= . >=20 > Is there enough text describing how deployed systems handle this issue? I > suspect that, since many MANETs are military, there is an operational sol= ution > to this problem (probably involving men with guns and RSA tokens :-) >=20 >>> On to the security considerations section: > [snip] >> UH> Very good catches. We will fix them. >=20 > Ulrich and authors... > Last call expires on 8/14 and the document is currently set for IESG revi= ew on > 8/15 > If the resolution of these comments can be agreed with Yoav, no more subs= tantive > comments come in, and a new version is ready to post on 8/14 we can go ah= ead on > the current schedule. > If you think you need more time, I will move the document out to a later = IESG > telechat. >=20 > Adrian >=20 >=20 > Email secured by Check Point From vincent.roca@inria.fr Fri Aug 2 10:32:44 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B8D11E80EE; Fri, 2 Aug 2013 10:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.205 X-Spam-Level: X-Spam-Status: No, score=-110.205 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hh4syBkg8yZL; Fri, 2 Aug 2013 10:32:39 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id EE3CE11E80E8; Fri, 2 Aug 2013 10:32:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,802,1367964000"; d="scan'208";a="28326851" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.147]) ([82.236.155.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 02 Aug 2013 19:32:36 +0200 From: Vincent Roca Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Aug 2013 14:32:06 +0200 Message-Id: To: IESG , draft-ietf-avtcore-idms.all@tools.ietf.org, secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [secdir] Secdir review of draft-ietf-avtcore-idms-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 17:32:44 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. -- One minor comment first: It is said that "Differences in playout time exceeding configured limits (e.g. more = than ten seconds) could be an indication of such inconsistent = information." But it could as well be caused by a misbehaving receiver (e.g. with an intermittent connection) who should better be removed from the = destination set altogether. So I wouldn't speak of "inconsistent information", but = rather "out of bound information" since this situation is "consistent" with the = real situation. Then, using "configured limits" is necessary, sure, but not sufficient. = What if an attacker periodically reports values that are just below this = configured limit? They should be accepted whereas they will negatively impact the = session. And you cannot reduce indefinitely the configured limits. A third comment. The document only mentions devices (in the example) that report erroneous information. The problem is broader than that. The attacker may also be on the route between a legitimate destination to = the source, and be able to alter the report message. Or the attacker may be=20= able to forge a packet with erroneous information, masquerading as a legitimate receiver. So it would be great to broaden the problem = statement with that in mind. And then it quickly leads to the idea of message integrity verification = (to combat packet modification) and source authentication (to combat masquerading). You should say something on it. Of course, the same comments apply for the messages sent on the other direction, from source to destinations. A reference to SRTP is missing. Please add. Finally, since everything depends on precise time synchronization, it = should be highlighted that having a secure time synchronization service is = absolutely required. Otherwise this is another potential means to attack the = session. Cheers, Vincent From dharkins@lounge.org Mon Aug 5 11:27:23 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FB421F9A74; Mon, 5 Aug 2013 11:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kyQEJ96xq-Q; Mon, 5 Aug 2013 11:27:17 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id DF74721F9A71; Mon, 5 Aug 2013 11:27:17 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 433DC10224008; Mon, 5 Aug 2013 11:27:16 -0700 (PDT) Received: from 64.164.138.146 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 5 Aug 2013 11:27:16 -0700 (PDT) Message-ID: Date: Mon, 5 Aug 2013 11:27:16 -0700 (PDT) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-ietf-multimob-pmipv6-ropt.all@tools.ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [secdir] review of draft-ietf-multimob-pmipv6-ropt-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 18:27:23 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. My apologies for the tardiness of this review. This draft describes an experimental way to use existing protocols to address a tunnel convergence problem where multiple instance of the same multicast traffic converges to the same Mobile Access Gateway. It also defines a new option to support dynamic policy subscriptions for use with the Proxy Binding Acknowledge message. It is heavy on acronyms and could use some additional definitions in section 2 for things like "MAG" and "LMA" (note: I am not a proxy mobile IPv6 person). The draft is ready for publication but I do have a few comments: 1. It would be easier to read if you move the definition of the new option before the description of the two operational modes that define the experimental solution, that presumably use the new option. 2. the protocol field "maps the type codification used in the original MLD specification for the Report message" and gives two explicit values. Is there a registry for this mapping somewhere that might be better to point at? 3. are bits really set to zero and set to one? I thought they were set (1) and cleared (0). 4. the security considerations say that the draft just explains how to use existing protocols without modification and therefore does not introduce new security threats. That makes me think that the problem hasn't even been looked at. It is certainly possible to use existing protocols in a way that introduces security problems. Maybe expand on why there are none. Also, the draft introduces a new option for dynamic policy subscriptions. Are there no security issues associated with that addition? If so, it might be good to mention that. Again, sorry for the delay, I hope these comments are still useful. regards, Dan. From cjbc@it.uc3m.es Mon Aug 5 14:29:09 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B283D21F9D02; Mon, 5 Aug 2013 14:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyWMmH0j4cyi; Mon, 5 Aug 2013 14:29:02 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 69ED721F9C7B; Mon, 5 Aug 2013 14:29:01 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A403DCD6586; Mon, 5 Aug 2013 23:29:00 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [10.3.251.252] (interdigital.vlan431.asr1.yyz1.gblx.net [208.49.79.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id D68A8CD641A; Mon, 5 Aug 2013 23:28:59 +0200 (CEST) Message-ID: <1375738133.4571.19.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Dan Harkins Date: Mon, 05 Aug 2013 23:28:53 +0200 In-Reply-To: References: Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20060.002 X-Mailman-Approved-At: Mon, 05 Aug 2013 17:35:56 -0700 Cc: draft-ietf-multimob-pmipv6-ropt.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-multimob-pmipv6-ropt-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 21:29:09 -0000 Dear Dan, Thanks a lot for your review. Please see some comments inline below. On Mon, 2013-08-05 at 11:27 -0700, Dan Harkins wrote: > Hello, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. My apologies > for the tardiness of this review. > > This draft describes an experimental way to use existing protocols > to address a tunnel convergence problem where multiple instance of > the same multicast traffic converges to the same Mobile Access > Gateway. It also defines a new option to support dynamic policy > subscriptions for use with the Proxy Binding Acknowledge message. > It is heavy on acronyms and could use some additional definitions > in section 2 for things like "MAG" and "LMA" (note: I am not a proxy > mobile IPv6 person). We reference in Section 2 the different documents where the terms used in the document are originally defined. This is the case of MAG and LMA, which are proxy mobile IPv6 specific entities. We believe that it is better not to reproduce all those definitions in the document, but we could do it if it helps improving the readability. We will reduce the use of acronyms in -08, by expanding some of them. > > The draft is ready for publication but I do have a few comments: > > 1. It would be easier to read if you move the definition of the new > option before the description of the two operational modes that > define the experimental solution, that presumably use the new > option. The option is used to allow conveying dynamic policies to perform the operational mode selection, but it is not mandatory to use the option, as manual configuration is also possible. We describe this in section 3.3. Therefore, we believe that defining the option before would probably not help. An alternative approach could be to move Section 3.3 before current 3.1 and 3.2. Do you think that would address your comment? > > 2. the protocol field "maps the type codification used in the original > MLD specification for the Report message" and gives two explicit > values. Is there a registry for this mapping somewhere that might > be better to point at? The values are defined in MLDv2 (RFC 3810) and MLDv1 (RFC2170) specs. Would the following revised text be more clear? Protocol: Field used to identify the multicast membership protocol in use, and the corresponding format of the next Multicast Address Record. This field maps the type codification used in the original MLD specifications for the Report message, namely for MLDv2 [RFC3810] the Protocol value MUST be 143, whereas for MLDv1 [RFC2710] the Protocol value MUST be 131. By the way, thanks to your comment we have realized that there was a nit in the values included in -07. The values are decimal (143 and 131) and not hex (0x143 and 0x131) as in -07. This will be fixed in -08. > > 3. are bits really set to zero and set to one? I thought they were > set (1) and cleared (0). Fixed. > > 4. the security considerations say that the draft just explains how to > use existing protocols without modification and therefore does > not introduce new security threats. That makes me think that the > problem hasn't even been looked at. It is certainly possible to > use existing protocols in a way that introduces security problems. > Maybe expand on why there are none. Also, the draft introduces > a new option for dynamic policy subscriptions. Are there no > security issues associated with that addition? If so, it might be > good to mention that. The addition of the new option does not address any security issue as long as the signaling is properly secured reusing Proxy Mobile IPv6 mechanisms. We will add some text in -07 stating more clearly this point (i.e., mentioning that the new mobility option defined in the document is conveyed in the proxy binding acknowledge message, which is protected by the IPsec security mechanism mandated by Proxy Mobile IPv6). Thanks, Carlos > > Again, sorry for the delay, I hope these comments are still useful. > > regards, > > Dan. > > > > > From yaronf.ietf@gmail.com Tue Aug 6 10:53:45 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9A421E80BE; Tue, 6 Aug 2013 10:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It1O5ZCVHkMM; Tue, 6 Aug 2013 10:53:30 -0700 (PDT) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 760B021E8093; Tue, 6 Aug 2013 10:53:02 -0700 (PDT) Received: by mail-ea0-f169.google.com with SMTP id z7so371958eaf.0 for ; Tue, 06 Aug 2013 10:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=zWe6vF5RC5FxYgXbRhAzCLV2N3ilMcTSgoEc0sm7TJU=; b=SoXF74GP6RmbU3xJX5oFkJDBYB/7Wg51SyfQfSz/nIMQbgNuvh8k0bsXiT/U7jKtY9 GZAY0e531XoaUK0F03y6qbiz4eDppjXJfxI1wnKEVRDNl2wI1hN7EvynqeVIcygpRe1g ILVDbH/LrEj0l1Zf4uMgxeDjM0WREU1zi3sOcW+oeL2g6T9xb8VNY/vWKpwXzKkuXabV UmUwLu4f8YRONxf08I/rYvfLBHaC9RV0apJNktF3SaLcaW6s8gQzS8feqYQV/oZJL/xt 5q6s/vbPPLH36faIGlaiZ40YiU9sitF64CzssVaAmarngaeUjnEAMr1Ork8SAP1K0wWI 84lw== X-Received: by 10.15.81.129 with SMTP id x1mr2229153eey.82.1375811577322; Tue, 06 Aug 2013 10:52:57 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-182-192-146.red.bezeqint.net. [79.182.192.146]) by mx.google.com with ESMTPSA id k3sm3652505een.16.2013.08.06.10.52.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 Aug 2013 10:52:56 -0700 (PDT) Message-ID: <520137EC.2030607@gmail.com> Date: Tue, 06 Aug 2013 20:52:44 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: IETF Security Directorate , The IESG , draft-ietf-tls-oob-pubkey.all@tools.ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [secdir] SecDir review of draft-ietf-tls-oob-pubkey-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 17:53:45 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document adds into TLS support for bare public keys (as opposed to keys wrapped in certificates). The main use case cited is constrained devices that get their trust anchors in an out-of-band manner (e.g. - horror - embedded in their software) as a set of trusted public keys. Summary: this document is almost ready for publication, but needs several clarifications and text improvements. Since some of the missing pieces revolve around authentication, we may even need another last call if (as discussed in Berlin) the document is to be merged or coordinated with the Channel ID work. Details • 1: "an out-of-band mechanism is also used to bind the public key to the entity presenting the key" - this text is strange. Obtaining the public key can be OOB, but binding to the TLS identity is part of the protocol negotiation. This sentence sounds as if we're trying to avoid a "MUST authenticate". • More generally, if the peer has an OOB way to obtain the public key (it has to have one, otherwise it wouldn't be able to bind it to an identity), why are we sending the full public key in the handshake, rather than only a fingerprint? Reading further (in the Acknowledgements section) it would appear this question has already been discussed in the WG. Shouldn't this option, or the interaction with "cached info", be mentioned here? • 3, Fig. 1: why do we support a sequence of public keys? What is the semantics? If the semantics is that you can authenticate using *one* of the provided keys, then why not support mixing public keys and certificates, or RSA with ECDSA public keys? • 3: "These extension MUST be omitted if the client only supports X.509 certificates" (note the typo, should be "this") - this is IMO overspecified, especially since the client can send a list of length 1 containing only the X.509 identifier. • "The 'server_certificate_type' in the client hello indicates the type of certificates" - this is probably a typo, and should be "types", i.e. a list. • In the two paragraphs discussing the semantics of the extensions, the word "supported" is used very loosely, sometimes referring to what you can send and sometimes to what you can accept. I suggest to clarify this point, and I suspect that the last sentence ("if the server does not send...") which is currently unclear will have to be corrected. • 4.1: " MUST include the 'client_certificate_type' and 'server_certificate_type' extensions" - do you really have to include both extensions? What if only the server presents a public key? • 4.2, bullet #2: does the server need to have a cert type in common with the client, or just in common with the types that the client specified in the "server cert type" extension? • 5, Fig. 8: does the client really have to indicate support of the server sending an X.509 cert? What if the client omits the server_certificate_type extension? • 6: what exactly is meant by "to check the status of that binding"? • 7: at least in the HTML version of this draft, the value/description/reference lines appear *before* the introductory sentence. Thanks, Yaron From kwiereng@cisco.com Wed Aug 7 06:52:31 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6EF21E8127; Wed, 7 Aug 2013 06:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBrgLk7YwTzH; Wed, 7 Aug 2013 06:52:26 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E98B821E812A; Wed, 7 Aug 2013 06:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=779; q=dns/txt; s=iport; t=1375883546; x=1377093146; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=ZYXXiAfHSDJUT09WLTKRYOzYEVLwclWcY4NLCCMN28I=; b=mTBDSqEu/9pOn0JKPt3iXEz5/0NgYDfISJJMnvjNnqv/jGdpnjKt4hxQ 2YC+OaR0p0qLiDiFg7Yf8CTWFYdA0Gc23royehn2Z50qrcarnKNJBKi09 LZyvNiJeTT2PHSUGLecbU2U3Zsxxb4428betcCAS3/cp/hvU7BMvRA7OT c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAJhQAlKtJV2b/2dsb2JhbABbgwaBBb5HgRwWdIImAQQ6PxIBKhRCJwQODYgIuFSPaTGDIXQDqTCDF4Iq X-IronPort-AV: E=Sophos;i="4.89,833,1367971200"; d="scan'208";a="244529063" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 07 Aug 2013 13:52:25 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r77DqPjY009436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Aug 2013 13:52:25 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.38]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Wed, 7 Aug 2013 08:52:25 -0500 From: "Klaas Wierenga (kwiereng)" To: "draft-ietf-karp-crypto-key-table.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-karp-crypto-key-table-08.txt Thread-Index: AQHOk3VYEg4BbEukoUS8XGc9hcW1Og== Date: Wed, 7 Aug 2013 13:52:24 +0000 Message-ID: <7E1636E02F313F4BA69A428B314B77C708CA7638@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.98.115] Content-Type: text/plain; charset="us-ascii" Content-ID: <24DA3405CA1AA642B4A8C08C8E06E55F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: The IESG , "secdir@ietf.org" Subject: [secdir] Secdir review of draft-ietf-karp-crypto-key-table-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 13:52:31 -0000 Hi, After having reviewed version 07, I have only one (minor) nit for version 8= , you write: KDF: A key derivation function is a one-way function that provides cryptographic separation of key material. The KDF MAY use inputs from the row in the key table and the message being sent or received but MUST NOT depend on other configuration state. I wonder whether that definition is correct. I have always considered forwa= rding secrecy a desirable but not necessary property for KDF's. For example= the key may not have the necessary properties so a transformation may be n= eeded (could be as simple as padding until a certain length). But if you ca= n point me to a definition that includes one-way I stand corrected. Klaas= From housley@vigilsec.com Wed Aug 7 07:19:45 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B0321E812D; Wed, 7 Aug 2013 07:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.672 X-Spam-Level: X-Spam-Status: No, score=-102.672 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9sln5F8AMpL; Wed, 7 Aug 2013 07:19:40 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id E91BB21F99B8; Wed, 7 Aug 2013 07:19:37 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id C4CF8F2408D; Wed, 7 Aug 2013 10:19:44 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id m38pvsmPkXsc; Wed, 7 Aug 2013 10:19:25 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 00A03F24085; Wed, 7 Aug 2013 10:19:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <7E1636E02F313F4BA69A428B314B77C708CA7638@xmb-aln-x12.cisco.com> Date: Wed, 7 Aug 2013 10:19:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9D8F4DC5-30E2-4E21-B28C-C44DA6105A5F@vigilsec.com> References: <7E1636E02F313F4BA69A428B314B77C708CA7638@xmb-aln-x12.cisco.com> To: Klaas Wierenga (kwiereng) X-Mailer: Apple Mail (2.1085) Cc: "secdir@ietf.org" , The IESG , "draft-ietf-karp-crypto-key-table.all@tools.ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-karp-crypto-key-table-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 14:19:45 -0000 Klaas: The property you describe depends on the inputs to the KDF, not just the = definition of the function. Notice that an IANA registry is defined, and each entry should point to = a definition of the function. Russ On Aug 7, 2013, at 9:52 AM, Klaas Wierenga (kwiereng) wrote: > Hi, >=20 > After having reviewed version 07, I have only one (minor) nit for = version 8, you write: >=20 > KDF: A key > derivation function is a one-way function that provides > cryptographic separation of key material. The KDF MAY use > inputs from the row in the key table and the message being sent > or received but MUST NOT depend on other configuration state. >=20 > I wonder whether that definition is correct. I have always considered = forwarding secrecy a desirable but not necessary property for KDF's. For = example the key may not have the necessary properties so a = transformation may be needed (could be as simple as padding until a = certain length). But if you can point me to a definition that includes = one-way I stand corrected. >=20 > Klaas > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From hartmans@painless-security.com Wed Aug 7 08:58:43 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3099B21E8143; Wed, 7 Aug 2013 08:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfGSeW8aB+tt; Wed, 7 Aug 2013 08:58:37 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3597011E813F; Wed, 7 Aug 2013 08:58:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 3F68D2022C; Wed, 7 Aug 2013 11:57:39 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpToLqEgCaCg; Wed, 7 Aug 2013 11:57:37 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (gain1-180.nortex.net [63.160.158.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 7 Aug 2013 11:57:37 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8CAF080E01; Wed, 7 Aug 2013 11:58:28 -0400 (EDT) From: Sam Hartman To: Russ Housley References: <7E1636E02F313F4BA69A428B314B77C708CA7638@xmb-aln-x12.cisco.com> <9D8F4DC5-30E2-4E21-B28C-C44DA6105A5F@vigilsec.com> Date: Wed, 07 Aug 2013 11:58:28 -0400 In-Reply-To: <9D8F4DC5-30E2-4E21-B28C-C44DA6105A5F@vigilsec.com> (Russ Housley's message of "Wed, 7 Aug 2013 10:19:28 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "secdir@ietf.org" , The IESG , "draft-ietf-karp-crypto-key-table.all@tools.ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-karp-crypto-key-table-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 15:58:43 -0000 >>>>> "Russ" == Russ Housley writes: Russ> Klaas: The property you describe depends on the inputs to the Russ> KDF, not just the definition of the function. Russ> Notice that an IANA registry is defined, and each entry should Russ> point to a definition of the function. So, there are a couple of things. There are functions that take a random bit string and convert them into a key. For example if you have 56 random bits and want a 64-bit correct-parity DES key. I don't have a good name for such a function but it's not a KDF. There are functions that take the output of key agreement (DH, ECDH, etc) and convernt into a good symmetric key. I've heard those described as key expansion functions or KDFs. There are functions that take one symmetric key and turn it into another symmetric key so that you can construct a key hierarchy. I've also seen these described as KDFs. It's probable that any function that's really good at taking key agreement output as input and producing a strong key will also be good enough for establishing a key hierarchy. I'm not aware of definitive definitions in this space, and I'm fairly sure the text we added in 08 is what we mean for this document. From charliek@microsoft.com Wed Aug 7 10:05:39 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C72821E812F; Wed, 7 Aug 2013 10:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.534 X-Spam-Level: * X-Spam-Status: No, score=1.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUuuMv6vK0WC; Wed, 7 Aug 2013 10:05:32 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 21E2D21F9A96; Wed, 7 Aug 2013 10:05:26 -0700 (PDT) Received: from mail35-am1-R.bigfish.com (10.3.201.241) by AM1EHSOBE018.bigfish.com (10.3.207.140) with Microsoft SMTP Server id 14.1.225.22; Wed, 7 Aug 2013 17:05:25 +0000 Received: from mail35-am1 (localhost [127.0.0.1]) by mail35-am1-R.bigfish.com (Postfix) with ESMTP id CBFB0100288; Wed, 7 Aug 2013 17:05:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: 4 X-BigFish: VS4(zzc85fhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h17326ah18c673h1de096h8275bh8275dh1de097hz2fh2a8h683h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh17ej9a9j1155h) Received-SPF: pass (mail35-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=charliek@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail35-am1 (localhost.localdomain [127.0.0.1]) by mail35-am1 (MessageSwitch) id 1375895123277075_12807; Wed, 7 Aug 2013 17:05:23 +0000 (UTC) Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.241]) by mail35-am1.bigfish.com (Postfix) with ESMTP id 34EFB2A005E; Wed, 7 Aug 2013 17:05:23 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 7 Aug 2013 17:05:21 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.3.136.1; Wed, 7 Aug 2013 17:05:12 +0000 Received: from mail133-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.22; Wed, 7 Aug 2013 17:04:00 +0000 Received: from mail133-ch1 (localhost [127.0.0.1]) by mail133-ch1-R.bigfish.com (Postfix) with ESMTP id B24114017E; Wed, 7 Aug 2013 17:04:00 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(46102001)(74316001)(69226001)(47976001)(49866001)(74706001)(50986001)(47736001)(19580385001)(33646001)(4396001)(74662001)(79102001)(54356001)(76482001)(53806001)(83322001)(59766001)(19580395003)(51856001)(80976001)(47446002)(74502001)(54316002)(31966008)(77982001)(74366001)(56776001)(56816003)(16236675002)(63696002)(76786001)(77096001)(74876001)(83072001)(81542001)(76576001)(65816001)(76176001)(19300405004)(76796001)(80022001)(15202345003)(16406001)(81342001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB592; H:BL2PR03MB592.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::8b; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail133-ch1 (localhost.localdomain [127.0.0.1]) by mail133-ch1 (MessageSwitch) id 137589503776661_31118; Wed, 7 Aug 2013 17:03:57 +0000 (UTC) Received: from CH1EHSMHS010.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.225]) by mail133-ch1.bigfish.com (Postfix) with ESMTP id 048BA4E0051; Wed, 7 Aug 2013 17:03:57 +0000 (UTC) Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS010.bigfish.com (10.43.70.10) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 7 Aug 2013 17:03:55 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) by BL2PRD0310HT003.namprd03.prod.outlook.com (10.255.97.38) with Microsoft SMTP Server (TLS) id 14.16.341.1; Wed, 7 Aug 2013 17:03:53 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) by BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) with Microsoft SMTP Server (TLS) id 15.0.731.11; Wed, 7 Aug 2013 17:03:52 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com ([169.254.11.38]) by BL2PR03MB592.namprd03.prod.outlook.com ([169.254.11.38]) with mapi id 15.00.0731.000; Wed, 7 Aug 2013 17:03:52 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-trill-directory-framework.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-trill-directory-framework-06 Thread-Index: Ac6TjsVavOP/CXwQRN63OmzJzsd+hA== Date: Wed, 7 Aug 2013 17:03:52 +0000 Message-ID: <00fa8fdba33644e2970788cd2a0aee64@BL2PR03MB592.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::8b] x-forefront-prvs: 0931CB1479 Content-Type: multipart/alternative; boundary="_000_00fa8fdba33644e2970788cd2a0aee64BL2PR03MB592namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PR03MB592.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [secdir] secdir review of draft-ietf-trill-directory-framework-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 17:05:39 -0000 --_000_00fa8fdba33644e2970788cd2a0aee64BL2PR03MB592namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document describes a framework for adding a central control mechanism = to trill to replace or supplement its autoconfiguring mechanism of dynamica= lly learning the locations of all addresses on the LAN. The specific protoc= ols for supplying and consuming this configuration information will presuma= bly appear in future specs. This sort of configuration control is useful in= a datacenter where all connections are carefully configured rather than be= ing plug and play. It is particularly applicable in a "cloud" environment w= here virtual machines are moved between physical machines by some sort of V= irtual Machine Management System that will also assign addresses and place = them. This is a re-review. This latest draft incorporates all of my comments on -= 05, in particular an expanded description of the security advantages of thi= s approach over the standard autoconfiguration in trill. I have no issues w= ith it. I did find 2 typos: Page 4 last paragraph: "Both items 3 and 4 above..." There are only three i= tems above. I suspect it should say "Both items 2 and 3 above..." Page 15 section 7 paragraph 3: "Perhaps S want steal" -> "Perhaps S wants t= o steal" --_000_00fa8fdba33644e2970788cd2a0aee64BL2PR03MB592namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

This document describes a framework for adding a = central control mechanism to trill to replace or supplement its autoconfigu= ring mechanism of dynamically learning the locations of all addresses on th= e LAN. The specific protocols for supplying and consuming this configuration information will presumably app= ear in future specs. This sort of configuration control is useful in a data= center where all connections are carefully configured rather than being plu= g and play. It is particularly applicable in a "cloud" environment where virtual machines are moved betwee= n physical machines by some sort of Virtual Machine Management System that = will also assign addresses and place them.

 

This is a re-review. This latest draft incorporates = all of my comments on -05, in particular an expanded description of the sec= urity advantages of this approach over the standard autoconfiguration in tr= ill. I have no issues with it. I did find 2 typos:

 

Page 4 last paragraph: “Both items 3 and 4 abo= ve…” There are only three items above. I suspect it should say = “Both items 2 and 3 above…”

 

Page 15 section 7 paragraph 3: “Perhaps S want= steal” -> “Perhaps S wants to steal”

--_000_00fa8fdba33644e2970788cd2a0aee64BL2PR03MB592namprd03pro_-- From d3e3e3@gmail.com Wed Aug 7 19:01:42 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C965B11E80D5; Wed, 7 Aug 2013 19:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fy+iZs1bBk1v; Wed, 7 Aug 2013 19:01:42 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEFF11E80E0; Wed, 7 Aug 2013 19:01:42 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id eh20so4806723obb.29 for ; Wed, 07 Aug 2013 19:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=t45rkniN28FJOZeoQ5rsaZsCNPiqWYGLZPO6IEy4Vx8=; b=i6secMlq3gS9iOuyMouts40i3NwZaceigRWLB3OuEu8NByrUIbzlO3pCs5EKkRlZoM ZZQ/VAvb8eqHYGJh6Xoaw22XsAXOhvKZOySva0eJ+FK0c8iP641Bw9WIvMplFu4pGV5j ggNFYOKrPFI+QtOFgCnWG3Zpcxv+fzLJT2xyNcIk3WEu8OAP7J64clZcPBcsLFIa32Wu mzDqgM7f5TGSiNwpjZJ9xksv/XLVw886eKDfxb8PCpJPOqbpalPsYqnGHKdn2WuNlBkp c2WnI71NhGmogCqcD0K+vmO8ryqt9CuXnkcfb9/1ClVXoUPMz6FTS9WrfoB6NuyFDOBv RApA== X-Received: by 10.60.124.14 with SMTP id me14mr2753618oeb.4.1375927301745; Wed, 07 Aug 2013 19:01:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.131.7 with HTTP; Wed, 7 Aug 2013 19:01:21 -0700 (PDT) In-Reply-To: <00fa8fdba33644e2970788cd2a0aee64@BL2PR03MB592.namprd03.prod.outlook.com> References: <00fa8fdba33644e2970788cd2a0aee64@BL2PR03MB592.namprd03.prod.outlook.com> From: Donald Eastlake Date: Wed, 7 Aug 2013 22:01:21 -0400 Message-ID: To: Charlie Kaufman Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-trill-directory-framework.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-trill-directory-framework-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 02:01:42 -0000 Hi Charlie, On Wed, Aug 7, 2013 at 1:03 PM, Charlie Kaufman wr= ote: > I have reviewed this document as part of the security directorate's ongoi= ng > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments ju= st > like any other last call comments. > > This document describes a framework for adding a central control mechanis= m > to trill to replace or supplement its autoconfiguring mechanism of > dynamically learning the locations of all addresses on the LAN. The speci= fic > protocols for supplying and consuming this configuration information will > presumably appear in future specs. This sort of configuration control is > useful in a datacenter where all connections are carefully configured rat= her > than being plug and play. It is particularly applicable in a "cloud" > environment where virtual machines are moved between physical machines by > some sort of Virtual Machine Management System that will also assign > addresses and place them. > > This is a re-review. This latest draft incorporates all of my comments on > -05, in particular an expanded description of the security advantages of > this approach over the standard autoconfiguration in trill. I have no iss= ues > with it. I did find 2 typos: > > Page 4 last paragraph: =93Both items 3 and 4 above=85=94 There are only t= hree > items above. I suspect it should say =93Both items 2 and 3 above=85=94 Yes, should be as you suggest. > Page 15 section 7 paragraph 3: =93Perhaps S want steal=94 -> =93Perhaps S= wants to > steal=94 Yup, thanks for spotting the typo. I'd be happy to make those changes and re-post but these are sufficiently minor that I am not sure I should do that right now... Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From alexey.melnikov@isode.com Thu Aug 8 04:15:18 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1108E11E8115 for ; Thu, 8 Aug 2013 04:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.155 X-Spam-Level: X-Spam-Status: No, score=-102.155 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNCO2oW7Hxfn for ; Thu, 8 Aug 2013 04:15:17 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 54F6C11E8103 for ; Thu, 8 Aug 2013 04:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1375960516; d=isode.com; s=selector; i=@isode.com; bh=gyzuPW4YXIYUCc1CPuzsIFVKuQbcceSe2JMiga1eX5c=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Rskgezsgjt6RlOu7Qo3ZsSP2V67MbVNmMCb4BuHDsxpvPMqn/nHdMY8JEp2ffokoqTl+aQ HXize4r3BnL0FIhCEiqcM7Iu/pTxjBD6mhGrqgE5bZqI4EmU2smlzxoTq3hYIvSGuN6Lc2 sn4pmazp4dMoYvmTsNtK3+mv341uTI4=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginmedia.com [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 8 Aug 2013 12:15:16 +0100 Message-ID: <52037DB4.9040807@isode.com> Date: Thu, 08 Aug 2013 12:15:00 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: secdir , Adrian Farrel , Stewart Bryant MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Spencer Dawkins Subject: [secdir] SECDIR review of draft-ietf-mpls-retire-ach-tlv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 11:15:18 -0000 I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document updates RFC 5586 by retiring ACH TLVs (an MPLS extensibility mechanism) and removing the associated IANA registry. The Security Considerations section states that by removing an unused feature of MPLS security of implementations is improved. I tend to agree, simplicity is a good thing. It also states that the removed feature can be used to secure messages on the G-ACh in a generic way, but that no such mechanism was proposed so far. I think this is a fair comment. I think the Security Considerations section is quite reasonable for this document. I don't have any issues with this document. From kivinen@iki.fi Thu Aug 8 06:20:53 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048FB21E804E for ; Thu, 8 Aug 2013 06:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHnhkccYDNQZ for ; Thu, 8 Aug 2013 06:20:52 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id B64D021E8089 for ; Thu, 8 Aug 2013 06:20:49 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r78DKiE5024201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 8 Aug 2013 16:20:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r78DKevZ014598; Thu, 8 Aug 2013 16:20:40 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20995.39720.449832.457323@fireball.kivinen.iki.fi> Date: Thu, 8 Aug 2013 16:20:40 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 1 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 13:20:53 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Derek Atkins is next in the rotation. For telechat 2013-08-15 Reviewer LC end Draft Steve Hanna TR2013-06-27 draft-ietf-manet-rfc6622-bis-04 Simon Josefsson TR2013-07-23 draft-merkle-tls-brainpool-04 Ben Laurie T 2013-07-25 draft-ietf-emu-crypto-bind-04 Matt Lepinski T 2013-08-13 draft-bormann-cbor-04 Kathleen Moriarty T 2013-07-29 draft-ietf-weirds-rdap-sec-04 Sandy Murphy TR2013-07-17 draft-jabley-dnsext-eui48-eui64-rrtypes-05 Sandy Murphy T 2013-07-29 draft-ietf-weirds-using-http-07 Joe Salowey T 2013-08-12 draft-ietf-websec-x-frame-options-07 For telechat 2013-08-29 Dan Harkins TR2013-05-15 draft-ietf-6man-addr-select-opt-11 Warren Kumari T 2013-07-15 draft-ietf-lisp-deployment-09 For telechat 2013-09-12 Sam Weiler T 2013-08-17 draft-ietf-homenet-arch-10 Last calls and special requests: Rob Austein 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Dave Cridland - draft-ietf-httpbis-p5-range-23 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-03-30 draft-ietf-roll-terminology-12 Jeffrey Hutzelman 2013-07-16 draft-yusef-dispatch-ccmp-indication-04 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-04 Julien Laganier - draft-ietf-avtcore-rtp-security-options-04 Julien Laganier - draft-ietf-websec-key-pinning-08 Alexey Melnikov - draft-ietf-payload-rtp-howto-04 Magnus Nystrom 2013-08-16 draft-allen-dispatch-imei-urn-as-instanceid-10 Radia Perlman 2013-08-18 draft-ietf-karp-ops-model-07 Vincent Roca 2013-08-21 draft-ietf-mpls-tp-mip-mep-map-08 Ondrej Sury 2013-08-16 draft-nandakumar-rtcweb-stun-uri-05 Tina TSOU 2013-08-16 draft-petithuguenin-behave-turn-uris-05 Carl Wallace 2013-08-16 draft-ietf-dime-overload-reqs-10 David Waltermire - draft-ietf-repute-considerations-02 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-10 Brian Weis - draft-ietf-radext-dtls-06 Tom Yu 2013-08-19 draft-ietf-storm-ipsec-ips-update-03 Glen Zorn 2012-11-27 draft-ietf-lisp-eid-block-04 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 -- kivinen@iki.fi From kwiereng@cisco.com Fri Aug 9 01:48:42 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3ADF21F9F50; Fri, 9 Aug 2013 01:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+NjzwYwgBji; Fri, 9 Aug 2013 01:48:37 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D8DB321F9BC1; Fri, 9 Aug 2013 01:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2516; q=dns/txt; s=iport; t=1376038117; x=1377247717; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bT/TENNzURX9RzEoLfSc02D3kvIVfKo5MecDBmyaqIs=; b=LzEv/JGRTHi352thw9WOhA3Ele7EsvQQwCqy1DfDbXvA9KSImnwKrajd tABVQIj6vXCDpZACTJZVCj4NF8XJSkJuor9nWqeoyBxoqPyrtYZh740/A gIx3Rq6FeEJs+90DAiVVj08dLRpl6f4hcnJ/nDfmcWwz7bebfseHs87fD g=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAJ+rBFKtJV2d/2dsb2JhbABbgwaBBb5SgRgWdIIlAQEEeRACAQgiJDIlAgQOBQgGiAK5RY9qMQeDGnQDkBSBLZdvgxiCKg X-IronPort-AV: E=Sophos;i="4.89,844,1367971200"; d="asc'?scan'208";a="245379394" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 09 Aug 2013 08:48:34 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r798mYPi022119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 08:48:34 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.38]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 03:48:34 -0500 From: "Klaas Wierenga (kwiereng)" To: Sam Hartman Thread-Topic: [secdir] Secdir review of draft-ietf-karp-crypto-key-table-08.txt Thread-Index: AQHOk4b0Eg4BbEukoUS8XGc9hcW1OpmM5zUA Date: Fri, 9 Aug 2013 08:48:34 +0000 Message-ID: <7E1636E02F313F4BA69A428B314B77C708CAF367@xmb-aln-x12.cisco.com> References: <7E1636E02F313F4BA69A428B314B77C708CA7638@xmb-aln-x12.cisco.com> <9D8F4DC5-30E2-4E21-B28C-C44DA6105A5F@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.100.141] Content-Type: multipart/signed; boundary="Apple-Mail=_F7A63075-84D5-4C1C-8CCB-E3107EFEEC06"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "secdir@ietf.org" , The IESG , "draft-ietf-karp-crypto-key-table.all@tools.ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-karp-crypto-key-table-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 08:48:42 -0000 --Apple-Mail=_F7A63075-84D5-4C1C-8CCB-E3107EFEEC06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Russ, Sam, On Aug 7, 2013, at 5:58 PM, Sam Hartman = wrote: >>>>>> "Russ" =3D=3D Russ Housley writes: >=20 > Russ> Klaas: The property you describe depends on the inputs to the > Russ> KDF, not just the definition of the function. >=20 > Russ> Notice that an IANA registry is defined, and each entry = should > Russ> point to a definition of the function. >=20 > So, there are a couple of things. > There are functions that take a random bit string and convert them = into > a key. For example if you have 56 random bits and want a 64-bit > correct-parity DES key. >=20 > I don't have a good name for such a function but it's not a KDF. >=20 > There are functions that take the output of key agreement (DH, ECDH, > etc) and convernt into a good symmetric key. I've heard those = described > as key expansion functions or KDFs. >=20 > There are functions that take one symmetric key and turn it into = another > symmetric key so that you can construct a key hierarchy. I've also = seen > these described as KDFs. It's probable that any function that's = really > good at taking key agreement output as input and producing a strong = key > will also be good enough for establishing a key hierarchy. >=20 > I'm not aware of definitive definitions in this space, and I'm fairly > sure the text we added in 08 is what we mean for this document. OK, I don't argue that this is what you need at all, so no argument = there. The only question I raised is whether one-way is a necessary = condition for each and every KDF. I would argue that key stretching not = necessarily means one-way . If you add "in this document" somewhere in the definition I'd be happy, = if you don't, no big deal either. Klaas --Apple-Mail=_F7A63075-84D5-4C1C-8CCB-E3107EFEEC06 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlIErOIACgkQH2Wy/p4XeFI8oACeNB25THL63sSCCUQJ1LYg/eGc 6YEAoKQqDZW9b+ZoxR4QOmpX8QZ+TwO0 =jp2J -----END PGP SIGNATURE----- --Apple-Mail=_F7A63075-84D5-4C1C-8CCB-E3107EFEEC06-- From ray.vanbrandenburg@tno.nl Thu Aug 8 23:37:41 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8267621F9CAE; Thu, 8 Aug 2013 23:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.362 X-Spam-Level: X-Spam-Status: No, score=0.362 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4NZJlwkHqWV; Thu, 8 Aug 2013 23:37:36 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id A1F5D21F9E9D; Thu, 8 Aug 2013 23:37:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,844,1367964000"; d="scan'208";a="12307206" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 09 Aug 2013 08:37:34 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.163]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.03.0123.003; Fri, 9 Aug 2013 08:37:33 +0200 From: "Brandenburg, R. (Ray) van" To: Vincent Roca , IESG , "draft-ietf-avtcore-idms.all@tools.ietf.org" , "secdir@ietf.org" Thread-Topic: Secdir review of draft-ietf-avtcore-idms-12 Thread-Index: AQHOj6Zfew5dacJNyUKMrFyD2GwMxZmMc9vg Date: Fri, 9 Aug 2013 06:37:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 09 Aug 2013 04:39:00 -0700 Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-idms-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 06:37:41 -0000 Hi Vincent, Thanks for your very thorough review. You will find my comments inline. Best regards, Ray > -----Original Message----- > From: Vincent Roca [mailto:vincent.roca@inria.fr] > Sent: vrijdag 2 augustus 2013 14:32 > To: IESG; draft-ietf-avtcore-idms.all@tools.ietf.org; secdir@ietf.org > Cc: Vincent Roca > Subject: Secdir review of draft-ietf-avtcore-idms-12 > = > Hello, > = > I have reviewed this document as part of the security directorate's ongoi= ng > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > = > -- > = > One minor comment first: It is said that > "Differences in playout time exceeding configured limits (e.g. more th= an > ten seconds) could be an indication of such inconsistent information." > But it could as well be caused by a misbehaving receiver (e.g. with an > intermittent connection) who should better be removed from the > destination set altogether. So I wouldn't speak of "inconsistent informat= ion", > but rather "out of bound information" since this situation is "consistent= " with > the real situation. Good point. I will change it to 'out of bound'. > Then, using "configured limits" is necessary, sure, but not sufficient. W= hat if > an attacker periodically reports values that are just below this configur= ed > limit? They should be accepted whereas they will negatively impact the > session. > And you cannot reduce indefinitely the configured limits. As indicated in the text, it's not just the SCs which checks for 'out-of-bo= und' info. It's the MSAS as well. If the MSAS includes a configured limit o= f let's say 10 seconds, it can use this as a threshold. Once any receiver i= s more than 10 seconds delayed from the rest, the MSAS could ignore that re= ceivers reports when deriving the target playout time. = > = > A third comment. The document only mentions devices (in the example) that > report erroneous information. The problem is broader than that. The > attacker may also be on the route between a legitimate destination to the > source, and be able to alter the report message. Or the attacker may be a= ble > to forge a packet with erroneous information, masquerading as a legitimate > receiver. So it would be great to broaden the problem statement with that= in > mind. = While you're absolutely right, I'm not sure we need to try and solve that p= roblem here. Once there is a man-in-the-middle who is able to include falsi= fied RTCP packets in the stream, there are a lot worse things it could acco= mplish than messing up the IDMS. I think in such cases, one should just use= SRTP/SRTCP. = > And then it quickly leads to the idea of message integrity verification (= to > combat packet modification) and source authentication (to combat > masquerading). You should say something on it. See my earlier point. Although message integrity and source authentication = is potentially an issue, I don't think we need to solve it here. That said,= I think you're right that it would be good to mention these issues when me= ntioning SRTP. = > Of course, the same comments apply for the messages sent on the other > direction, from source to destinations. > = > A reference to SRTP is missing. Please add.> = Thanks. Will do. > Finally, since everything depends on precise time synchronization, it sho= uld > be highlighted that having a secure time synchronization service is absol= utely > required. Otherwise this is another potential means to attack the session. Good point, we didn't think of that. I will add a note to the security cons= iderations mentioning that the same security vulnerabilities apply to the c= lock sync part as well. = > = > = > Cheers, > = > = > Vincent This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From uri@mit.edu Fri Aug 9 05:28:56 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A1F21F9EFF; Fri, 9 Aug 2013 05:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYyvwBgjv9i7; Fri, 9 Aug 2013 05:28:51 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id C67BB21F9E9A; Fri, 9 Aug 2013 05:28:44 -0700 (PDT) X-AuditID: 1209190c-b7fac8e000006335-14-5204e07b093e Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 53.92.25397.B70E4025; Fri, 9 Aug 2013 08:28:43 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r79CSf19006603; Fri, 9 Aug 2013 08:28:42 -0400 Received: from [192.168.1.108] (chostler.hsd1.ma.comcast.net [24.62.227.134]) (authenticated bits=0) (User authenticated as uri@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r79CSb39012732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 9 Aug 2013 08:28:39 -0400 References: <7E1636E02F313F4BA69A428B314B77C708CA7638@xmb-aln-x12.cisco.com> <9D8F4DC5-30E2-4E21-B28C-C44DA6105A5F@vigilsec.com> <7E1636E02F313F4BA69A428B314B77C708CAF367@xmb-aln-x12.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <7E1636E02F313F4BA69A428B314B77C708CAF367@xmb-aln-x12.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <70181507-3E70-4DED-9E74-2F61CBF63F50@mit.edu> X-Mailer: iPad Mail (10B329) From: Uri Blumenthal Date: Fri, 9 Aug 2013 08:28:39 -0400 To: "Klaas Wierenga (kwiereng)" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOKsWRmVeSWpSXmKPExsUixCmqrFv9gCXIYP03Noudf6ewWMz0tJjx ZyKzxdlfTBYfFj5kcWD1mPJ7I6vHkiU/mTxmf2tl9Phy+TNbAEsUl01Kak5mWWqRvl0CV0b3 j1fsBXcFK1Zs2cvUwDiVr4uRk0NCwESi6V4HE4QtJnHh3nq2LkYuDiGBfYwSl6etZwdJCAls YJQ4/ykCwt7LJPHmPxdE0W1GiU8nrrB2MXJw8AqIS1w96ANSwyngK3HrWx87SJhZQEdi8kJG kDCzgLbEsoWvmUFsXgEriZYVH9hBxjALvGOU2LrzOiPEETISm7c/BtvLJqAk0dy8hRXEFhbw k/g3bT+YzSKgItG89i3Y0SJAD+xe9oltAqPgLIQrZiFsnoVk8wJG5lWMsim5Vbq5iZk5xanJ usXJiXl5qUW6hnq5mSV6qSmlmxjBYS7Js4PxzUGlQ4wCHIxKPLwntjAHCbEmlhVX5h5ilORg UhLllb/DEiTEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhHf7BKAcb0piZVVqUT5MSpqDRUmc9+nT s4FCAumJJanZqakFqUUwWRkODiUJ3tL7QI2CRanpqRVpmTklCGkmDk6Q4TxAw+1AaniLCxJz izPTIfKnGHU5Js2d/4lRiCUvPy9VSpy3HaRIAKQoozQPbg4sPb1iFAd6S5hXDKSKB5ja4Ca9 AlrCBLRk+mGwJSWJCCmpBkYNM/myKZy5njPjbz9V2qj2Zxfv9p2itx7N2Pyp6vnS2WyyeyZ7 ewTyTzNTYbVXKNmXLL/jQ8/jPQERBi9m/L0kZmg7gW9PktahRwtnC0/K+FvaneFVmvnHbIOk SUPl8tbTFtJzZq966tRv9PycyZ3z6h3Zpf7OoSefKn5fqDbbJ+Ot7eQ7pWFKLMUZiYZazEXF iQDXUiUwKgMAAA== Cc: Sam Hartman , "draft-ietf-karp-crypto-key-table.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-karp-crypto-key-table-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 12:28:56 -0000 IMHO, yes - a KDF must be one-way. Including "key-stretcher" functions. TNX! Sent from my iPad On Aug 9, 2013, at 4:48, "Klaas Wierenga (kwiereng)" wr= ote: > Russ, Sam, >=20 > On Aug 7, 2013, at 5:58 PM, Sam Hartman w= rote: >=20 >>>>>>> "Russ" =3D=3D Russ Housley writes: >>=20 >> Russ> Klaas: The property you describe depends on the inputs to the >> Russ> KDF, not just the definition of the function. >>=20 >> Russ> Notice that an IANA registry is defined, and each entry should >> Russ> point to a definition of the function. >>=20 >> So, there are a couple of things. >> There are functions that take a random bit string and convert them into >> a key. For example if you have 56 random bits and want a 64-bit >> correct-parity DES key. >>=20 >> I don't have a good name for such a function but it's not a KDF. >>=20 >> There are functions that take the output of key agreement (DH, ECDH, >> etc) and convernt into a good symmetric key. I've heard those described >> as key expansion functions or KDFs. >>=20 >> There are functions that take one symmetric key and turn it into another >> symmetric key so that you can construct a key hierarchy. I've also seen >> these described as KDFs. It's probable that any function that's really >> good at taking key agreement output as input and producing a strong key >> will also be good enough for establishing a key hierarchy. >>=20 >> I'm not aware of definitive definitions in this space, and I'm fairly >> sure the text we added in 08 is what we mean for this document. >=20 > OK, I don't argue that this is what you need at all, so no argument there.= The only question I raised is whether one-way is a necessary condition for e= ach and every KDF. I would argue that key stretching not necessarily means o= ne-way . >=20 > If you add "in this document" somewhere in the definition I'd be happy, if= you don't, no big deal either. >=20 > Klaas >=20 >=20 >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From uri@mit.edu Fri Aug 9 05:36:50 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859A221F9F74; Fri, 9 Aug 2013 05:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TpFnf+5r9Ip; Fri, 9 Aug 2013 05:36:43 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id EEA3021F9F31; Fri, 9 Aug 2013 05:36:42 -0700 (PDT) X-AuditID: 1209190e-b7f988e0000009a7-9f-5204e25a135c Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id D3.8A.02471.A52E4025; Fri, 9 Aug 2013 08:36:42 -0400 (EDT) To: undisclosed-recipients:; Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r79CaeDa014530; Fri, 9 Aug 2013 08:36:40 -0400 Received: from [192.168.1.108] (chostler.hsd1.ma.comcast.net [24.62.227.134]) (authenticated bits=0) (User authenticated as uri@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r79CabcC015343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 9 Aug 2013 08:36:39 -0400 References: <7E1636E02F313F4BA69A428B314B77C708CA7638@xmb-aln-x12.cisco.com> <9D8F4DC5-30E2-4E21-B28C-C44DA6105A5F@vigilsec.com> <7E1636E02F313F4BA69A428B314B77C708CAF367@xmb-aln-x12.cisco.com> <70181507-3E70-4DED-9E74-2F61CBF63F50@mit.edu> From: Uri Blumenthal Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (10B329) In-Reply-To: <70181507-3E70-4DED-9E74-2F61CBF63F50@mit.edu> Message-Id: Date: Fri, 9 Aug 2013 08:36:38 -0400 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUixG6nrhv1iCXI4PhPUYudf6ewWMz0tJjx ZyKzxdlfTBYfFj5kcWD1mPJ7I6vHkiU/mTxmf2tl9Phy+TNbAEsUl01Kak5mWWqRvl0CV8aW K0uZCt6JVsxd0svawHhZsIuRk0NCwERiw62lzBC2mMSFe+vZuhi5OIQE9jFK3O99CJYQEZCR mDv7MStEYgOjxOLGpSwQzl4miY23ZoBVCQv4Sfybth+qqotJYueLB6wgCTYBJYnm5i1ANgcH s4COxOSFjBDrZCQ2b3/MDmJzClhLTDp9hQWkhFfASuLUu1SQMIuAikTn2TawKcwCK5kkzi0o hrC1JZYtfM0MUS4ucfWgzwRGwVkI82chKZqFULSAkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqR rrFebmaJXmpK6SZGUJhzSvLtYPx6UOkQowAHoxIPr8J25iAh1sSy4srcQ4ySHExKorzyd1iC hPiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwbp8AlONNSaysSi3Kh0lJc7AoifM+e3o2UEggPbEk NTs1tSC1CCYrw8GhJMEr+xCoUbAoNT21Ii0zpwQhzcTBCTKcB2i4NEgNb3FBYm5xZjpE/hSj McekufM/MXJ8O7bwE6MQS15+XqqUOO+nB0ClAiClGaV5cNNgqeoVozjQc8K8u0CqeIBpDm7e K6BVTECrph8GW1WSiJCSamCsr58y+xTfxd+nP/suWbXh4F1phZieR46bWl/WONv/3mTn+/6l 3kz+ZSkPP9eyxLv/e5Sl0hQZ4VbB/i/o9J6ebsldivLJB58kWzr/i/1i/Eo29vHBlatjmTJz b2w5E3JV83mOSk8QLztj+74Vq/78/xCx6KDNfde2ac/nsy6dGyZ2941nY1iREktxRqKhFnNR cSIA0wIUeDADAAA= Cc: Sam Hartman , "secdir@ietf.org" , The IESG , "draft-ietf-karp-crypto-key-table.all@tools.ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-karp-crypto-key-table-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 12:36:50 -0000 I would add that a function that "merely" adds parity to a DES key is a sing= ularly bad example, which is long gone and does not need to be resurrected. TNX! Sent from my iPad On Aug 9, 2013, at 8:28, Uri Blumenthal wrote: > IMHO, yes - a KDF must be one-way. Including "key-stretcher" functions. >=20 > TNX! >=20 > Sent from my iPad >=20 > On Aug 9, 2013, at 4:48, "Klaas Wierenga (kwiereng)" w= rote: >=20 >> Russ, Sam, >>=20 >> On Aug 7, 2013, at 5:58 PM, Sam Hartman w= rote: >>=20 >>>>>>>> "Russ" =3D=3D Russ Housley writes: >>>=20 >>> Russ> Klaas: The property you describe depends on the inputs to the >>> Russ> KDF, not just the definition of the function. >>>=20 >>> Russ> Notice that an IANA registry is defined, and each entry should >>> Russ> point to a definition of the function. >>>=20 >>> So, there are a couple of things. >>> There are functions that take a random bit string and convert them into >>> a key. For example if you have 56 random bits and want a 64-bit >>> correct-parity DES key. >>>=20 >>> I don't have a good name for such a function but it's not a KDF. >>>=20 >>> There are functions that take the output of key agreement (DH, ECDH, >>> etc) and convernt into a good symmetric key. I've heard those described= >>> as key expansion functions or KDFs. >>>=20 >>> There are functions that take one symmetric key and turn it into another= >>> symmetric key so that you can construct a key hierarchy. I've also seen= >>> these described as KDFs. It's probable that any function that's really >>> good at taking key agreement output as input and producing a strong key >>> will also be good enough for establishing a key hierarchy. >>>=20 >>> I'm not aware of definitive definitions in this space, and I'm fairly >>> sure the text we added in 08 is what we mean for this document. >>=20 >> OK, I don't argue that this is what you need at all, so no argument there= . The only question I raised is whether one-way is a necessary condition for= each and every KDF. I would argue that key stretching not necessarily means= one-way . >>=20 >> If you add "in this document" somewhere in the definition I'd be happy, i= f you don't, no big deal either. >>=20 >> Klaas >>=20 >>=20 >>=20 >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From jsalowey@cisco.com Sun Aug 11 11:50:42 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DDA11E811F; Sun, 11 Aug 2013 11:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oG0v3PuRcYA0; Sun, 11 Aug 2013 11:50:37 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD5F21F9C7E; Sun, 11 Aug 2013 11:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2640; q=dns/txt; s=iport; t=1376246678; x=1377456278; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=TTAGvXpct+YuAribT7grolLHljbC8PL6kraKlXjw9l0=; b=D1Xgz9q76zlnevDYv8jwTkRJEpHDT2UnCSwAKsgVpOW2lBegbuGM18aS frYS5Rfqk8Iw2SfuTJmPMOPIQTLH1BbS6v5EfzU2xfmggEu+eXK5Roz55 zcpvqPPZqsHEWo5WNdp6skK68TQuwlcvB5wiutSDRcdVaEqzQQ6IIWgDJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAMzaB1KtJXHB/2dsb2JhbABagwY1UL5hgRkWdIImAQQ6UQEqFEInBAEaiAi1OJAKg1N2A6k1gxuCKg X-IronPort-AV: E=Sophos;i="4.89,857,1367971200"; d="scan'208";a="243017323" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 11 Aug 2013 18:44:37 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7BIibFp005501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 11 Aug 2013 18:44:37 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.235]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Sun, 11 Aug 2013 13:44:37 -0500 From: "Joseph Salowey (jsalowey)" To: "secdir@ietf.org" , The IESG , "draft-ietf-websec-x-frame-options.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-websec-x-frame-options-07 Thread-Index: AQHOlsLTCIsxukwZF0auP9vgLBoZDw== Date: Sun, 11 Aug 2013 18:44:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.54] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] secdir review of draft-ietf-websec-x-frame-options-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 18:50:42 -0000 Do not be alarmed. I have reviewed this document as part of the security di= rectorate's ongoing effort to review all IETF documents being processed by = the IESG. These comments were written primarily for the benefit of the sec= urity area directors. Document editors and WG chairs should treat these co= mments just like any other last call comments. This document is ready with issues. =20 The document is generally well written and covers an important topic. It de= scribes existing options that can be included in an HTTP header to to preve= nt the HTTP content from being embedded in the frame of another page. The= document describes the existing options and therefore meets its main goal.= The main issue I see with the document is in the lack of guidance on = when to use the options. =20 Issues: 1. Section 2.1: It seems that RFC6454 should be first referenced in the S= AMEORIGIN section. Also, shouldn't the note about port not considered as = a defining component of origin apply to SAMEORIGIN as well? 2. Section 2.3.1: I'm not sure what section 2.3.1 is trying to say. Is = it saying that the X-FRAME-OPTIONS should apply to all of these embedding m= echanisms? If this is the case then I think this section should explicitl= y say so. =20 3. Section 5: =20 - The security considerations states that the X-FRAME-OPTIONS "it is not se= lf-sufficient on its own, but must be used in conjunction with other securi= ty measures like secure coding and the Content Security Policy." This stat= ement leads me to believe that more guidance is necessary. For example, do= es the reference to "secure coding" a general statement, or are there speci= fic coding considerations that are specific to clickjacking protection? I= f its general then it doesn't really add anything so I think it would be be= tter to be more specific. The same comment applies to CSP. =20 - Should pages also employ framebusting since the header options are not un= iformly implemented? - Perhaps the second paragraph should explicitly say that because of this d= evelopers must be aware that embedding content from other sites may leave t= hem vulnerable to clickjacking if the SAMEORIGIN directive is used.=20 - What pages should include this header option? More guidance here would = be good. Right now its necessarily clear which pages should include this h= eader especially given the uncertainty with SAMEORIGIN described in the sec= ond paragraph. Should all pages on a site deny being framed unless their c= ontent needs to be embedded in another site?=20 From tobias.gondrom@gondrom.org Sun Aug 11 13:53:18 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAADE21E8083 for ; Sun, 11 Aug 2013 13:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.505 X-Spam-Level: X-Spam-Status: No, score=-96.505 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jjbEpjhOIsS for ; Sun, 11 Aug 2013 13:53:13 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id BA28F21F9EEE for ; Sun, 11 Aug 2013 13:47:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=OdTR/zSySr+xo77LGhVADyOSSAX230/h5KQP5cAYBxT8mB916Tqnyi5FWf+0oTma7GTBpOJfHBhwAgOG0mrHemGuUsWzYoDhFy2ctqm1KJe8hWlN99M2H/+EypYU2B7G; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 11733 invoked from network); 11 Aug 2013 22:47:16 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 11 Aug 2013 22:47:16 +0200 Message-ID: <5207F854.6070706@gondrom.org> Date: Sun, 11 Aug 2013 21:47:16 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: jsalowey@cisco.com References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-websec-x-frame-options.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-websec-x-frame-options-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 20:53:18 -0000 Dear Joseph, thank you very much for the review. I revised the document to version-08 (also including feedback from other reviews) accordingly including most of your feedback. Answers inline. Best regards, Tobias On 11/08/13 19:44, Joseph Salowey (jsalowey) wrote: > Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. > > This document is ready with issues. > > The document is generally well written and covers an important topic. It describes existing options that can be included in an HTTP header to to prevent the HTTP content from being embedded in the frame of another page. The document describes the existing options and therefore meets its main goal. The main issue I see with the document is in the lack of guidance on when to use the options. > > Issues: > > 1. Section 2.1: It seems that RFC6454 should be first referenced in the SAMEORIGIN section. Also, shouldn't the note about port not considered as a defining component of origin apply to SAMEORIGIN as well? Hm. I am afraid that would be counterproductive. Although the name of the directive ("SAMEORIGIN") may suggest that this refers directly to RFC6454, it does not. As you can see from the next paragraph after the list, most current implementations do not follow RFC6454 to the letter as they do not consider the port as a defining component of the origin. That is the reason why we felt that it would be better to have the reference in the section below together with this explanation. > 2. Section 2.3.1: I'm not sure what section 2.3.1 is trying to say. Is it saying that the X-FRAME-OPTIONS should apply to all of these embedding mechanisms? If this is the case then I think this section should explicitly say so. Ok. Done. Added a sentence that "browser implementations cover all of them". > 3. Section 5: > > - The security considerations states that the X-FRAME-OPTIONS "it is not self-sufficient on its own, but must be used in conjunction with other security measures like secure coding and the Content Security Policy." This statement leads me to believe that more guidance is necessary. For example, does the reference to "secure coding" a general statement, or are there specific coding considerations that are specific to clickjacking protection? If its general then it doesn't really add anything so I think it would be better to be more specific. The same comment applies to CSP. Thanks. I can see your point and adjusted the text a bit accordingly. I understand that the terms are generic, on the other hand we want to avoid that people feel unnecessarily safe and think everything is fine, just because they are using this one header. E.g. if a page is vulnerable to XSS, you may be able to escape your frame otherwise. > - Should pages also employ framebusting since the header options are not uniformly implemented? No. We intentionally did not refer to framebusting as in addition to XFO in the security section, because: 1. today all major browsers support a minimum of x-frame-options, although with variations. So even with their variations, framebusting would not add much more capabilities. (note: in special use cases framebusting could still make sense, but describing these would not be adding value to the ID about XFO.) 2. framebusting has unfortunately been proven as not reliable against sophisticated attackers. (see reference in the ID). > - Perhaps the second paragraph should explicitly say that because of this developers must be aware that embedding content from other sites may leave them vulnerable to clickjacking if the SAMEORIGIN directive is used. Yes. Added text. > - What pages should include this header option? More guidance here would be good. Right now its necessarily clear which pages should include this header especially given the uncertainty with SAMEORIGIN described in the second paragraph. Should all pages on a site deny being framed unless their content needs to be embedded in another site? > Hm. I felt uncomfortable speaking in too much detail about which web pages should use X-FRAME-OPTIONS and which may not need to, as there is a huge variety of web applications. In general, you should obviously use it for anything that is vulnerable against clickjacking as given by the abstract and introduction (i.e. anything with buttons or links that you can click on with anything happening as a result of that click). Overall I would prefer to not go deeper into this in the draft, as IMHO the driving factor where to deploy XFO should be driven by the context of the web application and its risks. It could be useful and simplify things to just deploy it everywhere, even though some pages may not be at risk by clickjacking. But I don't see a lot of benefit in adding more text about this. From mlepinski.ietf@gmail.com Sun Aug 11 18:53:03 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701CA21F9DA1; Sun, 11 Aug 2013 18:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 410tIaKU8kFv; Sun, 11 Aug 2013 18:53:02 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 292EE21F9EFF; Sun, 11 Aug 2013 18:45:27 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id c1so3125806qcz.33 for ; Sun, 11 Aug 2013 18:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=njq15XjIZ/ty7zTpZFOOBTIhoWvGZyw6l5rTA8PVkBA=; b=o0pxx1+HejVlnuGZ0CXofK2b+j3pA1ppaLPPOR7k4vCgTVSUsA3TB1IHzCLzjusprt 786SrxMpLU9n9mrw1ryitUx+cDAecKD/GS3i9QhdZ5CPhVd2Gmd6tmJ61doT5FCaADJm bXnrulsNc6kpGzl+YdXfwMZw1r4NTVVIg3E7YSNczay2EJlKGDPws1p+fEvnhHhLp9Z6 P62GCjaau3H/iJIVlliXww9eEFgOgJBZvsZXwpNxmu6f6HCfnb020QB/aV/jksP0cg1w QzGaMWH12GLn36n/u/3HlJyCCDy9PWk4rXx/NDpnDaItSes1v1BEyCqvpMQK1E2VTTLC 9B3g== MIME-Version: 1.0 X-Received: by 10.224.54.8 with SMTP id o8mr14828054qag.112.1376271926658; Sun, 11 Aug 2013 18:45:26 -0700 (PDT) Received: by 10.49.117.106 with HTTP; Sun, 11 Aug 2013 18:45:26 -0700 (PDT) Date: Sun, 11 Aug 2013 21:45:26 -0400 Message-ID: From: Matthew Lepinski To: "secdir@ietf.org" , "iesg@ietf.org" , draft-bormann-cbor.all@tools.ietf.org Content-Type: multipart/alternative; boundary=001a1133dd144d898904e3b6478a Subject: [secdir] SecDir Review of draft-bormann-cbor-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 01:53:03 -0000 --001a1133dd144d898904e3b6478a Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document appears ready for publication. This document specifies the CBOR (Compact Binary Object Representation) binary encoding format. The document is generally clearly written, and in particular, is to be commended for providing a clear explanation of why one would want to specify yet another binary encoding for arbitrary objects. One minor note: In the security considerations section, the authors explain potential vulnerabilities in network protocols due to parser errors. (This is good cautionary guidance to provide implementers.) However, at the very end of the section, they suggest that an encoder/decoder used in a security context should provide at least one "strict" mode of operation. I would suggest adding another sentence or two explaining what the phrase "strict mode of operation" means in this context. --001a1133dd144d898904e3b6478a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's o= ngoing effort to review all IETF documents being processed by the IESG. =A0= These comments were written primarily for the benefit of the security area = directors. =A0Document editors and WG chairs should treat these comments ju= st like any other last call comments.

Thi= s document appears ready for publication.=A0

This document specifies the CBOR (Compact Binary Object Representation) = binary encoding format. The document is generally clearly written, and in p= articular, is to be commended for providing a clear explanation of why one = would want to specify yet another binary encoding for arbitrary objects.

One= minor note:
In the secur= ity considerations section, the authors explain potential vulnerabilities i= n network protocols due to parser errors. (This is good cautionary=A0guidan= ce=A0to provide=A0implementers.) However, at the very end of the section, t= hey suggest that an encoder/decoder used in a security context should provi= de at least one "strict" mode of operation. I would suggest addin= g another sentence or two explaining what the phrase "strict mode of o= peration" means in this context.
--001a1133dd144d898904e3b6478a-- From jsalowey@cisco.com Sun Aug 11 21:19:54 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF24A21F9DFB; Sun, 11 Aug 2013 21:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.599 X-Spam-Level: X-Spam-Status: No, score=-111.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsryJkrcrFVp; Sun, 11 Aug 2013 21:19:48 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id EB1DF21E80DC; Sun, 11 Aug 2013 21:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5891; q=dns/txt; s=iport; t=1376280772; x=1377490372; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ohW23QCSgTwH3OQ8Ko2lMoLGlk1gDtfeWFxLXB36TPQ=; b=Xg57BdOtAD71Gli/X1HNBE1UR/HCS0/Z5bCXPZJ3QK2yhAgXFkhz/92n TNsbjacujMsqBgU21+6YiQRn1Q9R92vyaZSsrQYDEOXBvLm2Am7/D1VKd mSfQaETlnN/eHPlqIqlsNIATcl8Ap6gQerNikuVL5GLDczxrjPg1zWynt o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAO5fCFKtJV2b/2dsb2JhbABagwY1UL5VgRsWdIIkAQEBAwF5BQsCAQgYCiQyJQIEDgUIiAIGtWKQCAIxB4MbdgOIdaBAgxuCKg X-IronPort-AV: E=Sophos;i="4.89,859,1367971200"; d="scan'208";a="246107938" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 12 Aug 2013 04:12:51 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7C4CpTw011986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 04:12:51 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.235]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Sun, 11 Aug 2013 23:12:50 -0500 From: "Joseph Salowey (jsalowey)" To: Tobias Gondrom Thread-Topic: secdir review of draft-ietf-websec-x-frame-options-07 Thread-Index: AQHOlsLTCIsxukwZF0auP9vgLBoZD5mQzjkAgAB86oA= Date: Mon, 12 Aug 2013 04:12:49 +0000 Message-ID: References: <5207F854.6070706@gondrom.org> In-Reply-To: <5207F854.6070706@gondrom.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.54] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" Subject: Re: [secdir] secdir review of draft-ietf-websec-x-frame-options-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 04:19:54 -0000 Hi Tobias, Thanks for the quick response. Your responses and modifications look good.= I still lean towards wanting to say something about a policy on which pa= ges should use XFO, however I can see how this can go beyond the scope of t= he document. The appendix B does provide some useful examples which are p= robably sufficient. =20 Cheers, Joe On Aug 11, 2013, at 1:47 PM, Tobias Gondrom wrote: > Dear Joseph, >=20 > thank you very much for the review. > I revised the document to version-08 (also including feedback from other > reviews) accordingly including most of your feedback. > Answers inline. > Best regards, Tobias >=20 > On 11/08/13 19:44, Joseph Salowey (jsalowey) wrote: >> Do not be alarmed. I have reviewed this document as part of the security= directorate's ongoing effort to review all IETF documents being processed = by the IESG. These comments were written primarily for the benefit of the = security area directors. Document editors and WG chairs should treat these= comments just like any other last call comments. >>=20 >> This document is ready with issues. =20 >>=20 >> The document is generally well written and covers an important topic. It= describes existing options that can be included in an HTTP header to to pr= event the HTTP content from being embedded in the frame of another page. = The document describes the existing options and therefore meets its main go= al. The main issue I see with the document is in the lack of guidance o= n when to use the options. =20 >>=20 >> Issues: >>=20 >> 1. Section 2.1: It seems that RFC6454 should be first referenced in th= e SAMEORIGIN section. Also, shouldn't the note about port not considered = as a defining component of origin apply to SAMEORIGIN as well? >=20 > Hm. I am afraid that would be counterproductive. > Although the name of the directive ("SAMEORIGIN") may suggest that this > refers directly to RFC6454, it does not. As you can see from the next > paragraph after the list, most current implementations do not follow > RFC6454 to the letter as they do not consider the port as a defining > component of the origin. > That is the reason why we felt that it would be better to have the > reference in the section below together with this explanation. >=20 >> 2. Section 2.3.1: I'm not sure what section 2.3.1 is trying to say. = Is it saying that the X-FRAME-OPTIONS should apply to all of these embeddin= g mechanisms? If this is the case then I think this section should explic= itly say so. =20 > Ok. Done. Added a sentence that "browser implementations cover all of > them". >=20 >=20 >> 3. Section 5: =20 >>=20 >> - The security considerations states that the X-FRAME-OPTIONS "it is not= self-sufficient on its own, but must be used in conjunction with other sec= urity measures like secure coding and the Content Security Policy." This s= tatement leads me to believe that more guidance is necessary. For example,= does the reference to "secure coding" a general statement, or are there sp= ecific coding considerations that are specific to clickjacking protection? = If its general then it doesn't really add anything so I think it would be= better to be more specific. The same comment applies to CSP. =20 > Thanks. I can see your point and adjusted the text a bit accordingly. > I understand that the terms are generic, on the other hand we want to > avoid that people feel unnecessarily safe and think everything is fine, > just because they are using this one header. E.g. if a page is > vulnerable to XSS, you may be able to escape your frame otherwise. >=20 >> - Should pages also employ framebusting since the header options are not= uniformly implemented? > No. We intentionally did not refer to framebusting as in addition to XFO > in the security section, because: > 1. today all major browsers support a minimum of x-frame-options, > although with variations. So even with their variations, framebusting > would not add much more capabilities. (note: in special use cases > framebusting could still make sense, but describing these would not be > adding value to the ID about XFO.) > 2. framebusting has unfortunately been proven as not reliable against > sophisticated attackers. (see reference in the ID). >=20 >> - Perhaps the second paragraph should explicitly say that because of thi= s developers must be aware that embedding content from other sites may leav= e them vulnerable to clickjacking if the SAMEORIGIN directive is used.=20 >=20 > Yes. Added text. >=20 >> - What pages should include this header option? More guidance here wou= ld be good. Right now its necessarily clear which pages should include thi= s header especially given the uncertainty with SAMEORIGIN described in the = second paragraph. Should all pages on a site deny being framed unless thei= r content needs to be embedded in another site?=20 >>=20 >=20 > Hm. I felt uncomfortable speaking in too much detail about which web > pages should use X-FRAME-OPTIONS and which may not need to, as there is > a huge variety of web applications. >=20 > In general, you should obviously use it for anything that is vulnerable > against clickjacking as given by the abstract and introduction (i.e. > anything with buttons or links that you can click on with anything > happening as a result of that click). Overall I would prefer to not go > deeper into this in the draft, as IMHO the driving factor where to > deploy XFO should be driven by the context of the web application and > its risks. > It could be useful and simplify things to just deploy it everywhere, > even though some pages may not be at risk by clickjacking. But I don't > see a lot of benefit in adding more text about this. >=20 >=20 From magnus.westerlund@ericsson.com Tue Aug 13 05:02:36 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6197821E80D8; Tue, 13 Aug 2013 05:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y18DK5JIqkXv; Tue, 13 Aug 2013 05:02:30 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 023FB11E8160; Tue, 13 Aug 2013 05:02:29 -0700 (PDT) X-AuditID: c1b4fb2d-b7f1c8e000000f62-04-520a20533c7e Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B0.66.03938.3502A025; Tue, 13 Aug 2013 14:02:27 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.150) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.2.328.9; Tue, 13 Aug 2013 14:02:27 +0200 Message-ID: <520A208F.6050104@ericsson.com> Date: Tue, 13 Aug 2013 14:03:27 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Brandenburg, R. (Ray) van" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+JvrW6wAleQwZ7XVha3bv5is5jxZyKz xbfN1xktPix8yGLRs6qfxYHVY8mSn0wek14cYvE4uO4Cs8eXy5/ZAliiuGxSUnMyy1KL9O0S uDI+XFvPWHCXo+LM/hssDYzT2bsYOTgkBEwkdqyx7GLkBDLFJC7cW8/WxcjFISRwmFHi9LKF rCAJIYHljBKdz/lAbF4BbYlTtw+DxVkEVCV6t/1lB7HZBCwkbv5oZAOxRQWCJdq3f2WDqBeU ODnzCQuILSJgLXHlchczyAJmgSOMEt+PdoI1CwM1f5y/iAnkICGBaonOXmaQMKeAj8Tz06fZ II6TlNi26BhYObOAnsSUqy2MELa8RPPW2cwQd2pLNDR1sE5gFJqFZPUsJC2zkLQsYGRexcie m5iZk15uuIkRGNoHt/zW3cF46pzIIUZpDhYlcd5NemcChQTSE0tSs1NTC1KL4otKc1KLDzEy cXBKNTBal8fdkGRyOfD+0Pfkt/GZ3MHHSyTV1+uLV5+4vnhi7J+o5Iwp0QeeHgn9Pqu8Ir96 s5ljyrYL75blfPBbuzgxb+rvD0aPFP0OmovNZv++sPnSgoJtuzlatxRmnYuc8+dmrPB9VjuZ A6qaL0sPsq9fM+FBwdOvBYY5ka3Bwru8DtuvWHthMu8RJZbijERDLeai4kQAHZBX2TsCAAA= Cc: "secdir@ietf.org" , IESG , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-idms-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 12:02:36 -0000 Vincent and Ray, >> >> A reference to SRTP is missing. Please add.> > > Thanks. Will do. I think referencing SRTP here is to narrow. I think the appropriate thing to point out is the need for source authentication and message integrity and then point to the need for a security solution that provide this. SRTP is a transport security solution, without key-management. So pointing at this to resolve this issue is insufficient and also not deployable. I think a better reference now that it exist and is getting closer to publication might be: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-security-options/ Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From radiaperlman@gmail.com Tue Aug 13 22:02:40 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DB811E80F0; Tue, 13 Aug 2013 22:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIuFDwXZVj9G; Tue, 13 Aug 2013 22:02:39 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF1121F9C7B; Tue, 13 Aug 2013 22:02:39 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id 13so6509149lba.34 for ; Tue, 13 Aug 2013 22:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Phb9D1FyUf3vlPOCvs/OMkvjJY6SrRaS3QffkVtVGbo=; b=YwXl4DkU9VK2mtlzBcSJUm1fRcWLJk6l0k57VcxU/2Zs/pWg/x3dqGnCvf2ARyrz+P Pq4WG2OaUGqRdzkyiotna9hBEWoI/LN7GExVVPz4P/0kOU+Mliz6ZQOjwlMamy6xxB8R sqTldHiAKQTKatUxxl2QTs2DQpiCIF/eDileHzwxlDGemCCzGn0REdigYINfuLpovieH 5w4PCrf7OR4zacxLq3TNbuFdWWyZ8hIhuNHKupZ60C5Y3vgHa5Scu+bt0c5oqX6YcKhQ iBoRmGv3y3jbTA4aYQUicFNuEMb/mB4e6/+kJtM+kezq8NmR2/i+KJqi3G3nA2wtAtd7 edig== MIME-Version: 1.0 X-Received: by 10.112.149.197 with SMTP id uc5mr6406957lbb.19.1376456558125; Tue, 13 Aug 2013 22:02:38 -0700 (PDT) Received: by 10.112.22.201 with HTTP; Tue, 13 Aug 2013 22:02:38 -0700 (PDT) Date: Tue, 13 Aug 2013 22:02:38 -0700 Message-ID: From: Radia Perlman To: The IESG , secdir@ietf.org, draft-ietf-karp-ops-model.all@tools.ietf.org Content-Type: multipart/alternative; boundary=047d7b343cd232296c04e3e144cf Subject: [secdir] secdir review of draft-ietf-karp-ops-model-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 05:02:40 -0000 --047d7b343cd232296c04e3e144cf Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is a useful document as an informational RFC. The technical content is interesting and useful. I think the document would be much improved with an introduction about what is different for "routing protocol security" rather than, say, an endnode authenticating to an access point, or nodes forming a peer relationship in an overlay network. So, for instance, "normal security issues" (i.e., outside the scope of KARP) might assume the network is up, so that it's possible to get CRLs, or be available to be managed, whereas perhaps KARP is targetting cases which depend on less infrastructure. It would be nice if this document were to have an introduction that talks about things like that. As for typos...3rd line up from bottom of page 14 has a glitch involving a bunch of spaces and an extra comma after the word "peers". And I can't parse the last sentence of the 1st paragraph of section 7. "...complexity of and update and risk...." Speaking of PKI...the document talks about certificates expiring, but not being revoked (CRL, OCSP). Radia --047d7b343cd232296c04e3e144cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ong= oing effort to review all IETF documents being processed by the IESG. =A0Th= ese comments were written primarily for the benefit of the security area di= rectors. =A0Document editors and WG chairs should treat these comments just= like any other last call comments.

This is a useful document as an informational RFC. The techn= ical content is interesting and useful.

I think th= e document would be much improved with an introduction about what is differ= ent for "routing protocol security" rather than, say, an endnode = authenticating to an access point, or nodes forming a peer relationship in = an overlay network. =A0So, for instance, "normal security issues"= (i.e., outside the scope of KARP) might assume the network is up, so that = it's possible to get CRLs, or be available to be managed, whereas perha= ps KARP is targetting cases which depend on less infrastructure. =A0It woul= d be nice if this document were to have an introduction that talks about th= ings like that.

As for typos...3rd line up from bottom of page 14 has a= glitch involving a bunch of spaces and an extra comma after the word "= ;peers". =A0And I can't parse the last sentence of the 1st paragra= ph of section 7. "...complexity of and update and risk...."

Speaking of PKI...the document talks about certificates= expiring, but not being revoked (CRL, OCSP).

Radi= a
--047d7b343cd232296c04e3e144cf-- From ray.vanbrandenburg@tno.nl Wed Aug 14 01:59:38 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC6F21F937E; Wed, 14 Aug 2013 01:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXQqlxDYgbvY; Wed, 14 Aug 2013 01:59:34 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 925C321F9344; Wed, 14 Aug 2013 01:59:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,875,1367964000"; d="scan'208";a="12490454" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 14 Aug 2013 10:59:32 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.163]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.03.0123.003; Wed, 14 Aug 2013 10:59:32 +0200 From: "Brandenburg, R. (Ray) van" To: Magnus Westerlund Thread-Topic: Secdir review of draft-ietf-avtcore-idms-12 Thread-Index: AQHOj6Zfew5dacJNyUKMrFyD2GwMxZmMc9vggAaFjYCAAYB5uw== Date: Wed, 14 Aug 2013 08:59:32 +0000 Message-ID: References: , <520A208F.6050104@ericsson.com> In-Reply-To: <520A208F.6050104@ericsson.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "secdir@ietf.org" , IESG , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-idms-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 08:59:38 -0000 Hi Magnus, Thanks for the heads-up. I think the document you mentioned is exactly what= we're looking for. = I will include a reference in the next iteration, which I will post after t= he 2nd WGLC has concluded. = Ray On 13 aug. 2013, at 14:02, "Magnus Westerlund" wrote: > Vincent and Ray, > = > = >>> = >>> A reference to SRTP is missing. Please add.> >> = >> Thanks. Will do. > = > I think referencing SRTP here is to narrow. I think the appropriate > thing to point out is the need for source authentication and message > integrity and then point to the need for a security solution that > provide this. SRTP is a transport security solution, without > key-management. So pointing at this to resolve this issue is > insufficient and also not deployable. I think a better reference now > that it exist and is getting closer to publication might be: > = > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-security-options/ > = > Cheers > = > Magnus Westerlund > = > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > = This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From turners@ieca.com Wed Aug 14 16:51:37 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92A521E80B0 for ; Wed, 14 Aug 2013 16:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.26 X-Spam-Level: X-Spam-Status: No, score=-101.26 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkXIJ7mc7-ws for ; Wed, 14 Aug 2013 16:51:27 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.15.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC0D21E8082 for ; Wed, 14 Aug 2013 16:51:25 -0700 (PDT) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 7BC3F86CDDB4; Wed, 14 Aug 2013 18:51:06 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 70BDD86CDD94 for ; Wed, 14 Aug 2013 18:51:06 -0500 (CDT) Received: from [96.231.225.44] (port=53277 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1V9kqZ-0000MZ-9t; Wed, 14 Aug 2013 18:51:23 -0500 Message-ID: <520C17FA.6030705@ieca.com> Date: Wed, 14 Aug 2013 19:51:22 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.225.44]:53277 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 11 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: secdir@ietf.org Subject: Re: [secdir] weirds and certificate naming X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 23:51:37 -0000 Sam, It looks like their MTI mechanism is: To that end, RDAP clients and servers MUST implement the authentication framework specified in "HTTP Authentication: Basic and Digest Access Authentication" [RFC2617]. spt On 7/29/13 9:31 AM, Sam Hartman wrote: > > > Hi. > To the ADs and especially to the folks who have outstanding weirds > reviews. > > Please chase down how a query name entered by a user makes its way into > a URI and how weirds validates the certificate in that URI. > I suspect that there are problems here. > For example, I suspect insecure DNS queries may be used to find parts of > that URI. > Alternatively even if DNSsec is available, I suspect supporting DNSsec > may not be a MTI for weirds clients. > So, I'm dubious whether weirds will have an interoperable MTI security > mechanism. > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From hartmans@mit.edu Wed Aug 14 17:05:07 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C496E21F9ABB for ; Wed, 14 Aug 2013 17:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WqmYvmzMtIP for ; Wed, 14 Aug 2013 17:05:01 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id ED1C311E81BB for ; Wed, 14 Aug 2013 17:05:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 596D620280; Wed, 14 Aug 2013 20:03:49 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f87TmoOCyolt; Wed, 14 Aug 2013 20:03:48 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 14 Aug 2013 20:03:48 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 242828052F; Wed, 14 Aug 2013 20:04:58 -0400 (EDT) From: Sam Hartman To: Sean Turner References: <520C17FA.6030705@ieca.com> Date: Wed, 14 Aug 2013 20:04:58 -0400 In-Reply-To: <520C17FA.6030705@ieca.com> (Sean Turner's message of "Wed, 14 Aug 2013 19:51:22 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , secdir@ietf.org Subject: Re: [secdir] weirds and certificate naming X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 00:05:07 -0000 >>>>> "Sean" == Sean Turner writes: Sean> Sam, It looks like their MTI mechanism is: Sean> To that end, RDAP clients and servers MUST implement the Sean> authentication framework specified in "HTTP Authentication: Sean> Basic and Digest Access Authentication" [RFC2617]. I don't understand how that helps authenticate the server at all. This seems horribly broken. Strongly recommend convincing yourself that the query string typed by the user is securily mapped to the identity of the right server. From prvs=1939e9a69c=sandra.murphy@parsons.com Wed Aug 14 18:10:37 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACB521E810A; Wed, 14 Aug 2013 18:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMpv0TJ8fP99; Wed, 14 Aug 2013 18:10:29 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id CBE8121E80FC; Wed, 14 Aug 2013 18:10:21 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r7F1ALRZ003962; Wed, 14 Aug 2013 20:10:21 -0500 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1e8mm3r35h-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 14 Aug 2013 20:10:20 -0500 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r7F1AJbO012532; Wed, 14 Aug 2013 20:10:19 -0500 Received: from CVA-HUB001.centreville.ads.sparta.com ([10.62.108.11]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r7F1AJh7016500; Wed, 14 Aug 2013 20:10:19 -0500 Received: from CVA-MB002.centreville.ads.sparta.com ([fe80::6046:a82a:c500:c9ad]) by CVA-HUB001.centreville.ads.sparta.com ([fe80::8ca8:7aea:3db9:1972%11]) with mapi id 14.02.0342.003; Wed, 14 Aug 2013 21:10:18 -0400 From: "Murphy, Sandra" To: "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: secdir review of draft-ietf-weirds-using-http-07 Thread-Index: AQHOmVQ0ei5n2pBFWkCHQ1m26XX5tw== Date: Thu, 15 Aug 2013 01:10:17 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6749CC526@CVA-MB002.centreville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-14_09:2013-08-15, 2013-08-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=87.496 compositescore=0.0463217897360062 urlsuspect_oldscore=0.463217897360062 suspectscore=0 recipient_domain_to_sender_totalscore=935 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=7197 rbsscore=0.0463217897360062 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1308140212 Cc: "draft-ietf-weirds-using-http@tools.ietf.org" Subject: [secdir] secdir review of draft-ietf-weirds-using-http-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 01:10:37 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments.=0A= =0A= =0A= =0A= =0A= =0A= Overall concerns:=0A= =0A= This draft in the first sentence portrays itself as one of a collection of= =0A= documents that describe the RDAP protocol. But no other documents are=0A= referenced or cited. Reviewing all the other drafts in the weirds wg, I be= lieve=0A= that the weirds working group considers the following three drafts to be th= e=0A= definition of the RDAP protocol:=0A= =0A= draft-ietf-weirds-rdap-query=0A= draft-ietf-weirds-json-response=0A= draft-ietf-weirds-using-http=0A= =0A= I would add draft-ietf-weirds-rdap-sec to the list, as it is also standards= =0A= track and states requirements for behavior. But I do not know if the weird= s wg=0A= considers the recommendations in the rdap-sec draft to be mandatory for all= RDAP=0A= implementations to implement.=0A= =0A= The security considerations section provides little in the way of discussio= n of=0A= the security considerations for the RDAP protocol. It refers to discussion= s of=0A= protections against denial of service (rate limiting) and reuse of existing= http=0A= security mechanisms (cross-site resource sharing, I think). Other than tha= t, it=0A= says=0A= =0A= Additional security considerations to the RDAP protocol will be=0A= covered in future RFCs documenting specific security mechanisms and=0A= schemes.=0A= =0A= Since there are obvious possible security considerations (client and server= =0A= authentcation, authorization, integrity, confidentiality in the server resp= onses=0A= at least, etc.), this is weak. Luckily, draft-ietf-weirds-rdap-sec provide= s a=0A= discussion of many of those considerations and others as well, and mechanis= ms to=0A= provide those security services. I am puzzled why the authors did not cite= that=0A= draft - is there some doubt that the rdap-sec draft will progress? Without= such=0A= a reference, this section is inadequate.=0A= =0A= [The rdap-sec draft is very thorough, but I have a few questions I might as= k=0A= about some of the recommendations - if I were reviewing that draft. But I'= m=0A= not. So I won't pose them here.]=0A= =0A= section 5.6=0A= =0A= When responding to queries, it is RECOMMENDED that servers use the=0A= Access-Control-Allow-Origin header field, as specified by=0A= [W3C.CR-cors-20130129].=0A= =0A= I have about 10 minutes of knowledge of this header field, but I can not en= vision=0A= a case where cross origin resource sharing might be needed, or whether the= =0A= access-control-allow-origin header is sufficiently secure for those cases.= =0A= =0A= Someone who understands that area should confirm that this is reasonable an= d=0A= adequate.=0A= =0A= The draft contains language that might be interpreted to be normative, usua= lly=0A= in the form "client(server) ". Maybe that would always be= =0A= interpreted to be "MUST", but in some cases later text makes it appear that= MAY=0A= or SHOULD is intended. Particularly section 4.1, 5.2, and 5.5.=0A= =0A= =0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= =0A= =0A= =0A= Specific comments:=0A= =0A= ---------=0A= =0A= Collecting a few comments about the posiiton of this draft wrt RDAP:=0A= =0A= Section 1 says=0A= =0A= This document is one of a collection that together describe the=0A= Registration Data Access Protocol (RDAP). It describes how RDAP is=0A= transported using the Hypertext Transfer Protocol (HTTP).=0A= =0A= In section 2 it says =0A= =0A= RDAP query and response formats are described in other=0A= documents in the collection of RDAP specifications, while this=0A= document describes how RDAP clients and servers use HTTP to exchange=0A= queries and responses.=0A= =0A= The other parts of the "collection" are left to the reader to discover. Th= ere=0A= are no related drafts listed in the reference section. Besides having pity= on=0A= your poor reader, this leaves the position of this draft somewhat unclear. = The=0A= text about "how RDAP is transported using ...(HTTP)" makes it sound like HT= TP is=0A= a transport protocol, not a fundamental component of the RDAP protocol. (R= EST=0A= is not limited to HTTP, if you can believe the web.) If the queries and=0A= responses in the two other drafts were carried in a different transport pro= tocol,=0A= would that communication still be RDAP? It would be helpful if that was cl= ear.=0A= The rdap-query draft contains references to the behavior in this draft, so = I have=0A= decided to believe that this document is a fundamental part of the RDAP=0A= protocol.=0A= =0A= And in section 3 it says:=0A= =0A= In this document, only a JSON=0A= [RFC4627] response media type is noted, with the response contents to=0A= be described separately. This document only describes how RDAP is=0A= transported using HTTP with this format.=0A= =0A= This could be read to mean that other documents might describe how RDAP is= =0A= transported using something other than HTTP, but I'm presuming it means tha= t this=0A= document describes how RDAP is transported in HTTP only with the JSON media= =0A= type, no other media types are described.=0A= =0A= ---------=0A= =0A= Going through the sections:=0A= =0A= Section 1 says:=0A= =0A= The purpose of this=0A= document is to clarify the use of standard HTTP mechanisms for this=0A= application.=0A= =0A= The rdap-query document section 2 says:=0A= =0A= WHOIS services, in general, are read-only services. Therefore URL=0A= [RFC3986] patterns specified in this document are only applicable to=0A= the HTTP [RFC2616] GET and HEAD methods.=0A= =0A= If only HTTP GET and HEAD methods are allowed in the client, should that no= t be=0A= mentioned in this document? Aren't they part of the "standard HTTP mechani= sms=0A= for this application"? (It would ahve been really helpful to know that=0A= restriction the first read through this document.)=0A= =0A= Section 1, page 3=0A= A replacement=0A= protocol is expected to retain the simple transactional nature of=0A= WHOIS, while providing a specification for queries and responses,=0A= =0A= Not sure - isn't this document (a component of) the "replacement protocol"?= =0A= So do you mean "RDAP retains...."?=0A= =0A= section 2=0A= =0A= In accordance with [SAC-051], this=0A= document describes the base behavior for a Registration Data Access=0A= Protocol (RDAP).=0A= =0A= Another point of uncertainty about the position of this document wrt RDAP (= part=0A= of the RDAP spec or not). But at any rate, this document does not describe= the base=0A= behavior. Unless by "base behavior" you mean the "HTTP behavior".=0A= =0A= Section 3=0A= =0A= There are a few design criteria this document attempts to meet.=0A= =0A= Did it succeed? =0A= =0A= For example, I don't see anything in this document that=0A= mandates that there is a bound on the maximum number of results to a query= =0A= as mentioned below:=0A= =0A= First, each query is meant to return either zero or one result. With=0A= the maximum upper bound being set to one=0A= =0A= I'm not even sure this is answered in the json-response draft, as it seems = to be=0A= concentrating on the data format of the response, not the specification of = what=0A= responses or how many responses are included in a reply to what queries (no= =0A= sort of state machine sort of description).=0A= =0A= Section 4.1=0A= =0A= To indicate to servers that an RDAP response is desired, clients=0A= include an Accept: header field with an RDAP specific JSON media=0A= type, the generic JSON media type, or both.=0A= ...=0A= This specification does not define the responses a server returns to=0A= a request with any other media types in the Accept: header field, or=0A= with no Accept: header field.=0A= =0A= So it seems "clients include an Accept: header field ..." is not a MUST. M= AY?=0A= SHOULD?=0A= =0A= To indicate to servers that an RDAP response is desired, clients=0A= include an Accept: header field with an RDAP specific JSON media=0A= type, the generic JSON media type, or both. Servers receiving an=0A= RDAP request return an entity with a Content-Type: header containing=0A= the RDAP specific JSON media type.=0A= =0A= Is that a "MUST return"? If the servers always return a specific JSON medi= a=0A= type, why do the clients indicate acceptance of a generic media type?=0A= =0A= section 5=0A= =0A= This section describes the various types of responses a server may=0A= send to a client. =0A= =0A= I don't think you meant "MAY" in the 2119 sense.=0A= =0A= section 5.1=0A= =0A= it returns that answer in the body of a 200 response.=0A= =0A= I think this is a MUST.=0A= =0A= section 5.2=0A= =0A= query can be found elsewhere, it returns either a 301 response code=0A= ...=0A= indicate a non-permanent redirection, and it includes an HTTP(s) URL=0A= =0A= I think these are both MUST.=0A= =0A= in the Location: header field. The client is expected to issue a=0A= subsequent request to satisfy the original query using the given URL=0A= without any processing of the URL. In other words, the server is to=0A= hand back a complete URL and the client should not have to transform=0A= the URL to follow it.=0A= =0A= Is this a MUST issue or a MAY issue? Is that should not a SHOULD NOT? Or = did=0A= you want to say that the server MUST provide a URL that could be used direc= tly=0A= by the client in a subsequent request without requiring any transformation.= =0A= =0A= [I have no clue what tranformations you might be trying to avoid. For my= =0A= curiousity, can you provide an example?]=0A= =0A= For this application, such an example of a permanent move might be a=0A= Top Level Domain (TLD) operator informing a client the information=0A= being sought can be found with another TLD operator (i.e. a query for=0A= the domain bar in foo.example is found at http://foo.example/domain/=0A= bar).=0A= =0A= such an example of a --> an example of such a=0A= =0A= I don't know why you emphasized that this example is TLD operators, because= the=0A= foo.example domain names don't look like TLDs to me. If the example relies= on the=0A= fact that the operators are TLDs, then the domain names chosen should refle= ct=0A= that. Unless I'm just completely misreading this.=0A= =0A= section 5.3=0A= =0A= If a server wishes to respond that it has no information regarding=0A= the query, it returns a 404 response code. Optionally, it MAY=0A= include additional information regarding the negative answer in the=0A= HTTP entity body.=0A= =0A= I think you mean MUST return.=0A= =0A= If a server wishes to inform the client that information about the=0A= query is available, but cannot include the information in the=0A= response to the client for policy reasons, the server MUST respond=0A= with an appropriate response code out of HTTP's 4xx range.=0A= =0A= In the second paragraph, is the server allowed to choose a 404 response cod= e?=0A= In the second paragraph, is the server allowed to return additional informa= tion=0A= about the refusal to return the information. (e.g., "I dould tell you but I= 'd=0A= have to shoot you")=0A= =0A= sectin 5.4=0A= =0A= If a server receives a query which it cannot interpret as an RDAP=0A= query, it returns a 400 response code.=0A= =0A= I think you mean MUST return.=0A= =0A= Section 4 of rdap-query says=0A= =0A= Servers MUST=0A= return an appropriate failure status code for a request with an=0A= unrecognized path segment.=0A= =0A= Is that covered by "which it cannot interpret as an RDAP query" - that is, = does=0A= this section provide the status code that would be appropriate? I think th= e=0A= section title of "malformed queries" suits all situations better than "cann= ot=0A= interpret as an RDAP query". in the rdap-query section 4 case, the server = can=0A= interpret the query as an RDAP query, but the query parameter is malformed.= =0A= =0A= section 5.5=0A= =0A= abuses. When a server declines to answer a query due to rate limits,=0A= it returns a 429 response code as described in [RFC6585].=0A= =0A= I think you mean MUST return.=0A= =0A= A client=0A= that receives a 429 response SHOULD decrease its query rate, and=0A= honor the Retry-After header field if one is present.=0A= =0A= So is it SHOULD honor, since it is SHOULD decrease? Or is it MUST honor?= =0A= =0A= section 7=0A= =0A= This document made recommendations for server implementations against=0A= makes=0A= denial-of-service (Section 5.5) and interoperability with existing=0A= security mechanism in HTTP clients (Section 5.6).=0A= mechanisms=0A= =0A= Section 5.6 is Cross-Origin Resource Sharing. Is that what you meant by=0A= "interoperability with existing security mechanism in HTTP clients"? As th= e=0A= Access-Control-Allow-Origin header field was developed as part of enabling= =0A= secure cross-site data transfers, it seems appropriate to discuss the=0A= security considerations and usage scenarios.=0A= =0A= sectin 8=0A= =0A= In accordance with RFC5226, the IANA policy for assigning new values=0A= shall be Specification Required: values and their meanings must be=0A= documented in an RFC or in some other permanent and readily available=0A= reference, in sufficient detail that interoperability between=0A= independent implementations is possible.=0A= =0A= This draft and the others are Standard track - why would extensions not als= o be=0A= standards track? I understand that the extensions are prefixes for JSON na= mes=0A= and URL path segments, not extensions to the protocol. Are there other=0A= permanent sources outside the IETF that you envision developing a specifica= tion=0A= for an RDAP name/path segment extension?=0A= =0A= If you are proposing a new registry, there's a requirement of what must be= =0A= included in this document in section 4.2 of rfc5226:=0A= 1) registry name=0A= 2) information that must be included in a request (this section does that)= =0A= 3) review process: ordinarily Specification Required means there's a Design= ated=0A= Expert=0A= 4) "size, format, and syntax of registry entries"=0A= 5) "Initial assignments and reservations."=0A= =0A= The request format suggests that the request should include the "Registry= =0A= operator". There's a conflation of the term "registry" here with the fact = that=0A= the request is being made to an "IANA registry". "Registry operator" here = I=0A= think means the operator of the registration data service to which an RDAP = query=0A= could be made.=0A= =0A= 9.3=0A= =0A= Given the description of the use of language identifiers in=0A= Section 9.2, unless otherwise specified servers SHOULD ignore the=0A= HTTP [RFC2616] Accept-Language header field when formulating HTTP=0A= entity responses, so that clients do not conflate the Accept-Language=0A= header with the 'lang' values in the entity body.=0A= =0A= (section 9.2 suggests that language identifiers, to be specified later, sho= uld be=0A= used to annotate responses.)=0A= =0A= This passage is confusing - the accept-language header is in the client's= =0A= request, so the server ignoring it is not going to prevent the client from= =0A= confusing that header with the 'lang' values in the (request?) entity body.= =0A= =0A= (It is unfortunate that one query path segment type is called "entity" as i= n=0A= GET /entity/JoeDoe-Handle, but I'm pretty sure here it is talking about the= =0A= http entity.)=0A= =0A= Appendix B=0A= =0A= The suggestion that caches can be avoided by inventing a random parameter w= ith=0A= a random value to make the query look unique seems to be commonly used. To= =0A= someone who has been in security for a long while, this looks like a huge= =0A= (not-so-)covert channel. But I don't think that's a concern.=0A= =0A= =0A= =0A= ---------=0A= =0A= =0A= real wordsmithing comments=0A= =0A= section 1 =0A= =0A= The registration data expected to be presented by this service is=0A= Internet resource registration data - registration of domain names=0A= and Internet number resources.=0A= =0A= I think you mean "data associated with the registration of domain names=0A= and Internet number resources".=0A= I don't think you mean for RDAP to have anything to do with the registratio= n=0A= process itself.=0A= =0A= Where complexity may=0A= reside, it is the goal of this document to place it upon the server=0A= and to keep the client as simple as possible.=0A= =0A= I think you mean "Where complexity may arise" or "may occur".=0A= =0A= section 7=0A= =0A= protocol. However, it does not restrict against the use of security=0A= ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=0A= =0A= Strange choice of words. I think you mean it does not restrict the use.=0A= =0A= This document made recommendations for server implementations against=0A= denial-of-service (Section 5.5) and interoperability with existing=0A= security mechanism in HTTP clients (Section 5.6).=0A= =0A= "recommendations ... against denial of service" - an odd wording.=0A= I'd say "recommendations for use of rate limiting as a response to=0A= denial of service"=0A= =0A= =0A= =0A= --Sandy Murphy= From kivinen@iki.fi Fri Aug 16 06:24:06 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1327111E8279 for ; Fri, 16 Aug 2013 06:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yalvjsd7sRTq for ; Fri, 16 Aug 2013 06:24:05 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD6C11E8190 for ; Fri, 16 Aug 2013 06:24:04 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r7GDNxsS007561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 16 Aug 2013 16:23:59 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r7GDNwtT005573; Fri, 16 Aug 2013 16:23:58 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21006.10221.791765.68557@fireball.kivinen.iki.fi> Date: Fri, 16 Aug 2013 16:23:57 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 1 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 13:24:06 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Phillip Hallam-Baker is next in the rotation. For telechat 2013-08-29 Reviewer LC end Draft Dan Harkins TR2013-05-15 draft-ietf-6man-addr-select-opt-11 Warren Kumari T 2013-07-15 draft-ietf-lisp-deployment-10 For telechat 2013-09-12 Sam Weiler T 2013-08-17 draft-ietf-homenet-arch-10 Last calls and special requests: Derek Atkins 2013-08-27 draft-ietf-dime-realm-based-redirect-11 Rob Austein 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Rob Austein 2013-08-29 draft-ietf-netext-update-notifications-07 Dave Cridland - draft-ietf-httpbis-p5-range-23 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Dave Cridland 2013-08-29 draft-ietf-repute-email-identifiers-08 Alan DeKok 2013-03-30 draft-ietf-roll-terminology-12 Alan DeKok 2013-08-29 draft-ietf-repute-media-type-10 Donald Eastlake 2013-08-29 draft-ietf-repute-model-07 Shawn Emery 2013-08-29 draft-ietf-repute-query-http-09 Tobias Gondrom 2013-08-26 draft-ietf-tsvwg-sctp-sack-immediately-03 Jeffrey Hutzelman 2013-07-16 draft-yusef-dispatch-ccmp-indication-04 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-04 Julien Laganier - draft-ietf-avtcore-rtp-security-options-04 Julien Laganier - draft-ietf-websec-key-pinning-08 Alexey Melnikov - draft-ietf-payload-rtp-howto-04 Magnus Nystrom 2013-08-16 draft-allen-dispatch-imei-urn-as-instanceid-10 Vincent Roca 2013-08-21 draft-ietf-mpls-tp-mip-mep-map-08 Ondrej Sury 2013-08-16 draft-nandakumar-rtcweb-stun-uri-05 Tina TSOU 2013-08-16 draft-petithuguenin-behave-turn-uris-05 Carl Wallace 2013-08-16 draft-ietf-dime-overload-reqs-10 David Waltermire - draft-ietf-repute-considerations-02 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-11 Brian Weis - draft-ietf-radext-dtls-06 Tom Yu 2013-08-19 draft-ietf-storm-ipsec-ips-update-03 Glen Zorn 2012-11-27 draft-ietf-lisp-eid-block-04 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 -- kivinen@iki.fi From magnusn@gmail.com Fri Aug 16 16:50:32 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E3821F9BD0; Fri, 16 Aug 2013 16:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itBMWOxfWVOQ; Fri, 16 Aug 2013 16:50:19 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id F339321F9B8F; Fri, 16 Aug 2013 16:50:18 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id gd11so1837523vcb.19 for ; Fri, 16 Aug 2013 16:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Jr0Eo8ugcIVLwUFLMqMJA2qRpxPOpSVbP46L5Gg7KEE=; b=noTvNVxCivPxYtoVxL82VjEhu8v7yHwf23sTj8vbbiuWBlHmTrTy5RDrLYSB+CqptE MnOMiwiDQo2P8B1FBrb13RA0S8U9yGdKJq7DHUQUaI5IaPkgx8RsKJn4DKtikaOlnEuq EGSFQGji6Kv5k0QP1pGlq8bFnsWVVu40qMbOUkLFzG9EZuIVDZRluZfPMwmjyyfWp3pY bUjTWUhRXRas11IfQHsfDzU3kh8bKhczq4fIdlqqH4qH7iZWqAJjtVn2RRXUltmSsyHg yb8c67nojfJXxhYN4Esvo2wKRbUIfc58JdLNc/oskpXJNfilFqeUZsifa+XdcgMH1nCA wYdA== MIME-Version: 1.0 X-Received: by 10.58.73.202 with SMTP id n10mr209755vev.7.1376697017302; Fri, 16 Aug 2013 16:50:17 -0700 (PDT) Received: by 10.52.36.115 with HTTP; Fri, 16 Aug 2013 16:50:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Aug 2013 16:50:17 -0700 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: "secdir@ietf.org" , draft-allen-dispatch-imei-urn-as-instanceid@tools.ietf.org Content-Type: multipart/alternative; boundary=047d7bacbb5cae04e304e4194068 Cc: "iesg@ietf.org" Subject: [secdir] Fwd: Secdir review of draft-ietf-avtcore-6222bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 23:50:33 -0000 --047d7bacbb5cae04e304e4194068 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This memo describes how to use the GSM IMEI URN as an instance-id in SIP contexts. The Security Considerations section seems adequate to me although I think that an IMEI more than "loosely" associates a user with a device; most mobile devices have only one user and so the IMEI tracks a user pretty well. Thanks, -- Magnus --047d7bacbb5cae04e304e4194068 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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

This memo describes how to use the GSM IMEI URN as an instance-id in SIP co= ntexts.

The Security Considerations section seems adequate to me although I think t= hat an IMEI more than "loosely" associates a user with a device; = most mobile devices have only one user and so the IMEI tracks a user pretty= well.

Thanks,
-- Magnus
--047d7bacbb5cae04e304e4194068-- From magnusn@gmail.com Fri Aug 16 16:51:59 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA9F21F9CF1; Fri, 16 Aug 2013 16:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdwTInb-HsmO; Fri, 16 Aug 2013 16:51:58 -0700 (PDT) Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id B5C7921F9CF3; Fri, 16 Aug 2013 16:51:51 -0700 (PDT) Received: by mail-vb0-f41.google.com with SMTP id g17so2098108vbg.0 for ; Fri, 16 Aug 2013 16:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=+uIAc25z9l/CCJ82r1+x4VBF4Tb//ebpS0ycullNTNY=; b=BbrrWeJaEyuuE/D5vFjoTt6EkcgitFsf0gz+PV0eg1aUdnfi7Qw1KYPsu7xr9EB/2O 0op8OK2LMR6b3B58Wu63nIJq22YQvyA1FJG8gfylg1v6RwouXgjgw3o0jdVqUau4PLEZ ZSXI4LuF/he3OZ/4xvspueU6FYlpJacn2THUF44LC5sWZN6rVRdEBguaRqhpBsvnUNOo WhyxVs5TtCTqATQdpFs32OvXYEjyz7IG/TDgejabZ5nZfMF0RF6ax4WJvfMWGuQyqJYJ d3oRfT+YwW+XvMQwgdgUpp7d/AoGyXnW66s3lb2VIDHI0GOdqirLkf/Hcgp9qKG1+3TI OOuw== MIME-Version: 1.0 X-Received: by 10.220.199.5 with SMTP id eq5mr193242vcb.16.1376697111228; Fri, 16 Aug 2013 16:51:51 -0700 (PDT) Received: by 10.52.36.115 with HTTP; Fri, 16 Aug 2013 16:51:51 -0700 (PDT) Date: Fri, 16 Aug 2013 16:51:51 -0700 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: "secdir@ietf.org" , "" Content-Type: multipart/alternative; boundary=047d7b5db26a47381704e4194649 Cc: "iesg@ietf.org" Subject: [secdir] Subject correction: Security directorate review of draft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 23:51:59 -0000 --047d7b5db26a47381704e4194649 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry for using the wrong Subject: line. /M On Sun, Jun 9, 2013 at 11:37 PM, Magnus Nystr=F6m 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 ar= ea > directors. Document editors and WG chairs should treat these comments jus= t > like any other last call comments. > > This avtcore document describes a new method for generating unique RTCP > canonical names and obsoletes RFC 6222. > The Security Considerations section seems adequate to me. > > (A few side comments: > - RFC 6222 is mentioned in several places (e.g., Section 1, Section 8). > Should it not also be a reference? > - In Section 4.2, it is stated that, if the RTP endpoint is in a > virtualized environment, then the MAC address may not be unique. In such > cases, the host shall use the other presented option for short-term > persistent RTP CNAMEs. I wonder if it in general is possible for an RTCP > endpoint to deterministically determine if its MAC address is unique? It = is > not in general possible for a process to detect if it is running in a > virtualized OS.) > > Thanks, > -- Magnus > --047d7b5db26a47381704e4194649 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Sorry for using the wrong S= ubject: line.
/M

On Sun, Jun 9, 2013 at 11:37 P= M, Magnus Nystr=F6m <magnusn@gmail.com> wrote:
I have reviewed this docume= nt as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. =A0These 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 avtcore document describes a new method for generating unique RTCP can= onical names and obsoletes RFC 6222.

The Security Considerations section seems adequate to me.

(A few sid= e comments:
- RFC 6222 is mentioned in several places (e.g., Section 1,= Section 8). Should it not also be a reference?
- In Section 4.2, it is = stated that, if the RTP endpoint is in a virtualized environment, then the = MAC address may not be unique. In such cases, the host shall use the other = presented option for short-term persistent RTP CNAMEs. I wonder if it in ge= neral is possible for an RTCP endpoint to deterministically determine if it= s MAC address is unique? It is not in general possible for a process to det= ect if it is running in a virtualized OS.)

Thanks,
-- Magnus
--047d7b5db26a47381704e4194649-- From tobias.gondrom@gondrom.org Sat Aug 17 17:13:03 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AE211E813B for ; Sat, 17 Aug 2013 17:13:03 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E2 hex): To: ...vwg-sctp-sack-immediately\342\200\213.all@tools.ie[...] X-Spam-Flag: NO X-Spam-Score: -95.205 X-Spam-Level: X-Spam-Status: No, score=-95.205 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3eq0Mkn7qJl for ; Sat, 17 Aug 2013 17:12:58 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 10B0911E815C for ; Sat, 17 Aug 2013 17:12:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=fTLfrIy8kCogHviz/jAdIAtwM9xsiqxsAtuOnXO9xT+wp5KdEJIr2SW1P5NZdeJ4xlKqHTXD6VASxx80aAMATv2toz27zxffwivzzt1hatMX1GT/fScSiQaavaOmc1Ir; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type; Received: (qmail 25860 invoked from network); 18 Aug 2013 02:12:56 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Aug 2013 02:12:56 +0200 Message-ID: <52101187.2060409@gondrom.org> Date: Sun, 18 Aug 2013 01:12:55 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: draft-ietf-tsvwg-sctp-sack-immediately​.all@tools.ietf.org X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------050502050906000604050700" Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-tsvwg-sctp-sack-immediately-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 00:13:03 -0000 This is a multi-part message in MIME format. --------------050502050906000604050700 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document is an extension for SCTP and updates 4960. It aims for Standards Track. This document appears ready for publication. I found no problems or comments. And no nits or spelling issues. Well done. Best regards, Tobias --------------050502050906000604050700 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.


The document is an extension for SCTP and updates 4960.
It aims for Standards Track.


This document appears ready for publication.

I found no problems or comments.
And no nits or spelling issues.

Well done.

Best regards, Tobias



 --------------050502050906000604050700-- From Tina.Tsou.Zouting@huawei.com Mon Aug 19 10:41:30 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569A921F9974; Mon, 19 Aug 2013 10:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARbUquxLiror; Mon, 19 Aug 2013 10:41:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D263211E82AF; Mon, 19 Aug 2013 10:41:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUN30799; Mon, 19 Aug 2013 17:41:19 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 19 Aug 2013 18:40:30 +0100 Received: from SJCEML402-HUB.china.huawei.com (10.212.94.43) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 19 Aug 2013 18:41:16 +0100 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.77]) by sjceml402-hub.china.huawei.com ([10.212.94.43]) with mapi id 14.01.0323.007; Mon, 19 Aug 2013 10:41:12 -0700 From: Tina TSOU To: "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: Secdir review of draft-petithuguenin-behave-turn-uris-05 Thread-Index: Ac6dA0VAOItBp4XNQVOu2ZUd/rwVdg== Date: Mon, 19 Aug 2013 17:41:11 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.124] Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A8172DD663sjceml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-petithuguenin-behave-turn-uris.all@tools.ietf.org" Subject: [secdir] Secdir review of draft-petithuguenin-behave-turn-uris-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 17:41:30 -0000 --_000_C0E0A32284495243BDE0AC8A066631A8172DD663sjceml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area = directors. Document editors and WG chairs should treat these comments just= like any other last call comments. Summary: This document is almost ready for publication aiming for Standards= Track. This document defines two URI schemes to provision the TURN Resolution Mech= anism. This document defines TURN Server URI syntax. It considers UDP/TCP/TLS scen= arios, facilitating applications like WEBRTC to use TURN Server to accompli= sh NAT Traversal. Major issues: None Minor issues: 1. The authors define the syntax for the turn/turns URI in ad hoc fashion, = copying definitions from RFC 3986 rather than using RFC 3986 directly. The = justification is that there is no need for hierarchy in the turn/turns URI. In fact, hierarchy is introduced only within the path component described b= y RFC 3986. The turn/turns URI as defined in this document is achieved by u= se of the RFC 3986 form: scheme ":" hier-part [ "?" query ] [ "#" fragment ] with the following specific rules: hier-part consists of the authority part and an empty path userinfo and the succeeding '@' MUST be omitted from authority the fragment portion is not present. It is strongly recommended that this formulation be used, to bring the docu= ment into line with RFC 3986. Note that this implies adding double slash '/= /' after the scheme. 2. The Security Considerations section correctly makes reference to RFC 592= 8, but perhaps does not make it clear that RFC 5928 Section 5 is essential = reading. Could I suggest: "Security considerations for the resolution mechanism are discussed in Sect= ion 5 of [RFC5928]. Note that that section contains normative text defining= authentication procedures to be followed by turn clients when TLS is used.= " Thank you, Tina --_000_C0E0A32284495243BDE0AC8A066631A8172DD663sjceml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

I have reviewed this document as part of the securit= y directorate's ongoing effort to review all IETF documents being processed= by the IESG.

These comments were written primarily for the benefi= t of the security area directors.  Document editors and WG chairs shou= ld treat these comments just like any other last call comments.<= /p>

 

Summary: This document is almost ready for publicati= on aiming for Standards Track.

 

This document defines two URI schemes to provision t= he TURN Resolution Mechanism.

 

This document defines TURN Server URI syntax. It con= siders UDP/TCP/TLS scenarios, facilitating applications like WEBRTC to use = TURN Server to accomplish NAT Traversal.

 

Major issues: None

 

Minor issues:

 

1. The authors define the syntax for the turn/turns = URI in ad hoc fashion, copying definitions from RFC 3986 rather than using = RFC 3986 directly. The justification is that there is no need for hierarchy= in the turn/turns URI.

 

In fact, hierarchy is introduced only within the pat= h component described by RFC 3986. The turn/turns URI as defined in this do= cument is achieved by use of the RFC 3986 form:

 

scheme ":" hier-part [ "?" query= ] [ "#" fragment ]

 

with the following specific rules:

 

  hier-part consists of the authority part and = an empty path

 

  userinfo and the succeeding '@' MUST be omitt= ed from authority

 

  the fragment portion is not present.

 

It is strongly recommended that this formulation be = used, to bring the document into line with RFC 3986. Note that this implies= adding double slash '//' after the scheme.

 

2. The Security Considerations section correctly mak= es reference to RFC 5928, but perhaps does not make it clear that RFC 5928 = Section 5 is essential reading. Could I suggest:

 

"Security considerations for the resolution mec= hanism are discussed in Section 5 of [RFC5928]. Note that that section cont= ains normative text defining authentication procedures to be followed by tu= rn clients when TLS is used."

 

 

Thank you,

Tina

 

--_000_C0E0A32284495243BDE0AC8A066631A8172DD663sjceml501mbschi_-- From marc@petit-huguenin.org Mon Aug 19 13:59:06 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDDA21F8540; Mon, 19 Aug 2013 13:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDArADSl0Hbo; Mon, 19 Aug 2013 13:59:03 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id E87B521F9AE3; Mon, 19 Aug 2013 13:56:56 -0700 (PDT) Received: from [IPv6:2601:9:4bc0:25:c46:df4a:a6e:6768] (unknown [IPv6:2601:9:4bc0:25:c46:df4a:a6e:6768]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 8F21C20454; Mon, 19 Aug 2013 22:56:41 +0200 (CEST) Message-ID: <52128687.4080506@petit-huguenin.org> Date: Mon, 19 Aug 2013 13:56:39 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: Tina TSOU References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 19 Aug 2013 14:05:55 -0700 Cc: "draft-petithuguenin-behave-turn-uris.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-petithuguenin-behave-turn-uris-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 20:59:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Tina, Thanks for the review, see my comments inline. On 08/19/2013 10:41 AM, Tina TSOU wrote: > Dear all, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > > These comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > > > Summary: This document is almost ready for publication aiming for Standards > Track. > > > > This document defines two URI schemes to provision the TURN Resolution > Mechanism. > > > > This document defines TURN Server URI syntax. It considers UDP/TCP/TLS > scenarios, facilitating applications like WEBRTC to use TURN Server to > accomplish NAT Traversal. > > > > Major issues: None > > > > Minor issues: > > > > 1. The authors define the syntax for the turn/turns URI in ad hoc fashion, > copying definitions from RFC 3986 rather than using RFC 3986 directly. The > justification is that there is no need for hierarchy in the turn/turns > URI. > > > > In fact, hierarchy is introduced only within the path component described > by RFC 3986. The turn/turns URI as defined in this document is achieved by > use of the RFC 3986 form: > > > > scheme ":" hier-part [ "?" query ] [ "#" fragment ] > > > > with the following specific rules: > > > > hier-part consists of the authority part and an empty path > > > > userinfo and the succeeding '@' MUST be omitted from authority > > > > the fragment portion is not present. > > > > It is strongly recommended that this formulation be used, to bring the > document into line with RFC 3986. Note that this implies adding double > slash '//' after the scheme. The // means after the scheme means that this is a hierarchical URI, which does not make sense in this case as the concept of hierarchy is not applicable to a TURN server. I am in fact following the advice of RFC 4395 section 2.2: "URI schemes that do not contain a conformant hierarchical structure in their SHOULD NOT use double slashes following the ":" string." The TURN URI is not using the userinfo part, the hier-part, the query part or the fragment part, only the host and port parts and this is the reason why the ABNF productions from RFC 3986 are copied and not simply referenced: Using references proved confusing to reviewers and implementers, as this made them think that a TURN URI could be parsed with a hierarchical URI parser. > > > > 2. The Security Considerations section correctly makes reference to RFC > 5928, but perhaps does not make it clear that RFC 5928 Section 5 is > essential reading. Could I suggest: > > > > "Security considerations for the resolution mechanism are discussed in > Section 5 of [RFC5928]. Note that that section contains normative text > defining authentication procedures to be followed by turn clients when TLS > is used." > I will add this in -06. Thanks. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJSEoaEAAoJECnERZXWan7EXswQAK56Gc4ZjrypCVmn0kE7qRtD i/H9rKx1XvrPonmHCat2UpysiU25sZnnm8QgxhHqYHfqWqndj/oFeTMTUgwR+rPs T1x4Pmk7CgEYyQC4Eu+gUy63IQP3JaPT+2h4Vdi070Qy9k+ar3R47K+/VfeNCfa/ 8B1drTW5yNkrR4lIVUd0ubNraGCmTi8reKn3jLtgGLqYi/s4Mo5BAlP0vu+xTwlU 43YaVxFvYeVulwNRoQ5gcPqtnyKM+AwEJf0rw4fvW+MjaipUMW7vS2EKgWASKddm PnZnk7ai/nzQaTaFL6qJKz5RwzDyY/JU6gNPMhCry+0MShqreBtx58UknP1cTtJN 4Ng5wdot4BrfWiB/2OMTe8+RVqMVmU9L5Js9aLDuk7rDezyJLg93Vjv844sTSfr4 4vzgYA/uOcKRv+ysq65XsPufI8dSS4EMLkvbK86rghkf2gGRX+dX6j3Nf7YP4hwT Hd86irS5kQ9VZkZsQvSF3q2XWPWyNlql7KGPT/BT6om5z8JjJYj8Qxeu46j8QmoI W9YZ170qrXzPM8pF1JbOcM/sR2JVZyXQt4Qjfx8E9vOks1wvdubTVOCypWUnlDaj gZsWc9QQEoDXxl/LKpWKNkuRqS1L9NG0Y23B54pbhsp/xs7Jx+VRFaDPmFgbYoZ9 KlI8PCRk1IFvyzljb2x0 =45Zn -----END PGP SIGNATURE----- From new-work-bounces@ietf.org Wed Aug 21 10:52:13 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9519511E83D3; Wed, 21 Aug 2013 10:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1377107533; bh=l0XdVMKlkeAWToOVmxnO2hxJ9gAjW73xZMFHse0zU7I=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=glKXL1yhYdbGHyUil3E4o8xi/K2Nl00Eowx4bP4shHntwS2xIY+ubEu/zR9LnxxEo OBGeQ8ri6hr75boVkdxFnFS2eXnOVaNu18PLzolmSBVgcEGOTuZ29Ah3YFUMO/UxS/ QxW5UUDr0VauFhyTXds2+utTtQiXkQZvi+vwfdaQ= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B9611E8242; Wed, 21 Aug 2013 10:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwJMwhhbY6BB; Wed, 21 Aug 2013 10:51:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF82711E812D; Wed, 21 Aug 2013 10:51:58 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130821175158.24722.74055.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2013 10:51:58 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 21 Aug 2013 11:02:55 -0700 Subject: [secdir] [new-work] WG Review: Secure Telephone Identity Revisited (stir) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 17:52:13 -0000 A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-08-28. Secure Telephone Identity Revisited (stir) ------------------------------------------------ Current Status: Proposed WG Chairs: TBD Assigned Area Director: Richard Barnes Mailing list Address: stir@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stir Archive: http://www.ietf.org/mail-archive/web/stir/ Charter: The STIR working group will specify Internet-based mechanisms that allow verification of the calling party's authorization to use a particular telephone number for an incoming call. Since it has become fairly easy to present an incorrect source telephone number, a growing set of problems have emerged over the last decade. As with email, the claimed source identity of a SIP request is not verified, permitting unauthorized use of the source identity as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). In addition, use of an incorrect source telephone number facilitates wire fraud or can lead to a return call at premium rates. SIP is one of the main VoIP technologies used by parties that want to present an incorrect origin, in this context an origin telephone number. Several previous efforts have tried to secure the origins of SIP communications, including RFC 3325, RFC 4474, and the VIPR working group. To date, however, true validation of the source of SIP calls has not seen any appreciable deployment. Several factors contributed to this lack of success, including: failure of the problem to be seen as critical at the time; lack of any technical means of producing a proof of authorization to use telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with the complex deployment environment that has emerged for SIP; lack of end-to-end SIP session establishment; and inherent operational problems with a transitive trust model. To make deployment of this solution more likely, consideration must be given to latency, real-time performance, computational overhead, and administrative overhead for the legitimate call source and all verifiers. As its priority mechanism work item, the working group will specify a SIP header-based mechanism for verification that the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation. The working group will consider choices for protecting identity information and credentials used. This protection will likely be based on a digital signature mechanism that covers a set of information in the SIP header fields, and verification will employ a credential that contains the public key that is associated with the one or more telephone numbers. Credentials used with this mechanism will be derived from existing telephone number assignment and delegation models. That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or modified) to reflect such delegation. The mechanism must allow a telephone number holder to further delegate and revoke use of a telephone number without compromising the global delegation scheme. In addition to its priority mechanism work item, the working group will consider a mechanism for verification of the originator during session establishment in an environment with one or more non-SIP hops, most likely requiring an out-of-band authorization mechanism. However, the in-band and the out-of-band mechanisms should share as much in common as possible, especially the credentials. The in-band mechanism must be sent to the IESG for approval and publication prior to the out-of-band mechanism. Expansion of the authorization mechanism to identities using the user@domain form is out of scope. The work of this group is limited to developing a solution for telephone numbers. The working group will coordinate with the Security Area on credential management. The working group will coordinate with other working groups in the RAI Area regarding signaling through existing deployments. The working group welcomes input from potential implementors or operators of technologies developed by this working group. For example, national numbering authorities might consider acting as credential authorities for telephone numbers within their purview. It is important to note that while the main focus of this working group is telephone numbers, the STIR working group will not develop any mechanisms that require changes to circuit-switched technologies. Authentication and authorization of identity is closely linked to privacy, and these security features sometimes come at the cost of privacy. Anonymous calls are already defined in SIP standards, and this working group will not propose changes to these standards. In order to support anonymity, the working group will provide a solution in which the called party receives an indication that the source telephone number is unavailable. This working group, to the extent feasible, will specify privacy-friendly mechanisms that do not reveal any more information to user agents or third parties than a call that does not make use of secure telephone identification mechanisms. Input to working group discussions shall include: - Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks [RFC 3325] - Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) [RFC 4474] - Secure Call Origin Identification [draft-cooper-iab-secure-origin-00] - Secure Origin Identification: Problem Statement, Requirements, and Roadmap [draft-peterson-secure-origin-ps-00] - Authenticated Identity Management in the Session Initiation Protocol (SIP) [draft-jennings-dispatch-rfc4474bis-00] The working group will deliver the following: - A problem statement detailing the deployment environment and situations that motivate work on secure telephone identity - A threat model for the secure telephone identity mechanisms - A privacy analysis of the secure telephone identity mechanisms - A document describing the SIP in-band mechanism for telephone number-based identities during call setup - A document describing the credentials required to support telephone number identity authentication - A document describing the out-of-band mechanism for telephone number-based identities during call setup Milestones Sep 2013 Submit problem statement for Informational Nov 2013 Submit threat model for Informational Nov 2013 Submit in-band mechanism for Proposed Standard Feb 2014 Submit credential specification for Proposed Standard Apr 2014 Submit Privacy analysis for Informational Jun 2014 Submit out-of-band mechanism for Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From tlyu@mit.edu Wed Aug 21 11:56:57 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B430B21F9E48; Wed, 21 Aug 2013 11:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POFlHk8EY7la; Wed, 21 Aug 2013 11:56:51 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id F33DB21F9CD9; Wed, 21 Aug 2013 11:56:50 -0700 (PDT) X-AuditID: 1209190f-b7fa58e000000953-cd-52150d72bf6c Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 66.D2.02387.27D05125; Wed, 21 Aug 2013 14:56:50 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r7LIunkR009694; Wed, 21 Aug 2013 14:56:49 -0400 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.8/8.12.4) with ESMTP id r7LIuk51011261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Aug 2013 14:56:48 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r7LIukaK029452; Wed, 21 Aug 2013 14:56:46 -0400 (EDT) To: iesg@ietf.org, secdir@ietf.org, draft-ietf-storm-ipsec-ips-update.all@tools.ietf.org From: Tom Yu Date: Wed, 21 Aug 2013 14:56:46 -0400 Message-ID: Lines: 44 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixCmqrFvEKxpk0DFV0OLRu9NMFjP+TGS2 +LDwIYsDs8eSJT+ZPL5c/swWwBTFZZOSmpNZllqkb5fAlfHodAdzwTTBirmXnzE1MP7j7WLk 5JAQMJE4eeI/C4QtJnHh3nq2LkYuDiGBfYwS/RcWgiWEBDYySvy4zg9hn2OSuPrJB6Koi1Fi 1okGZpCEiECixPquG0wgtrCAncT3rZMYuxg5ONgEpCWOLi4DCbMIqEo0HWsEK+EVsJDY/Xgv I4jNI8ApMffObWaIuKDEyZlPwPYyC2hJ3Pj3kmkCI98sJKlZSFILGJlWMcqm5Fbp5iZm5hSn JusWJyfm5aUW6Zro5WaW6KWmlG5iBAeaJP8Oxm8HlQ4xCnAwKvHwXtgpEiTEmlhWXJl7iFGS g0lJlHcRt2iQEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHexWxAOd6UxMqq1KJ8mJQ0B4uSOO+z p2cDhQTSE0tSs1NTC1KLYLIyHBxKErxZPECNgkWp6akVaZk5JQhpJg5OkOE8QMM7QGp4iwsS c4sz0yHypxgVpcR5E0ASAiCJjNI8uF5YInjFKA70ijBvN0gVDzCJwHW/AhrMBDR4toYQyOCS RISUVAOjePb35Lfp/Z3xrQwLq3490Wjc9ffLQ871F9SXb5//uPGhvrjFtc+tcwo/PGuL/rNn 7vfmp/XH5n95dr37+6GrKXf33UxMOOqd53ns838Bubnu8y521Jrz7p/+6tK5tZYaxj52Ahb6 ATViu0RkmbpZd9ivvZuVOqGb7eMdAWaHX2wTFqyzvHp3jxJLcUaioRZzUXEiAPTz9IPfAgAA Subject: [secdir] secdir review of draft-ietf-storm-ipsec-ips-update-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 18:56:57 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I believe this document is ready with minor issues. The Security Considerations section in its entirety is "This entire document is about security." Although the above statement is true, I think it would also be beneficial to provide additional information in the Security Considerations to help implementers and administrators make informed risk assessments. This could include describing the consequences of failing to adopt the recommendations of this document. I have outlined below some possible risk tradeoffs to consider describing in the document. AES in GCM mode is vulnerable to catastrophic forgery attacks if a nonce is ever repeated with a given key. Hopefully this won't be a practical issue, but implementation bugs involving random number generators are not uncommon. Forgery in a content protection context is probably also less of a concern than forgery in an authentication context. What concerns with AES-CTR motivate its demotion? I do seem to recall that (contrary to best practice) confidentiality can be done separately from integrity in IPsec. Is this composition done in a way that has vulnerabilities? I'm not very familiar with IPsec and am not remembering the details at the moment. If there is sufficiently low traffic, is it likely that a site constrained by legacy or resource issues could use 3DES (with its 64-bit block size) at an acceptable risk level? (possibly with frequent rekeying) Ciphertext collision isn't as catastrophic with CBC mode ciphers as nonce collision is for AES-GCM. McGrew's paper about collision attacks includes equations that estimate data leakage. It could be useful to include advice about matching symmetric key lengths with public key strengths. See NIST SP 800-57 Part 1. What are the consequences of sequence number cycling in ESP? From david.black@emc.com Wed Aug 21 13:17:12 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B248811E8146; Wed, 21 Aug 2013 13:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2MtBTgykvNN; Wed, 21 Aug 2013 13:17:06 -0700 (PDT) Received: from mexforwardwc.lss.emc.com (mexforwardwc.lss.emc.com [137.69.117.200]) by ietfa.amsl.com (Postfix) with ESMTP id C25AA11E8152; Wed, 21 Aug 2013 13:17:06 -0700 (PDT) Received: from scl02-01d02-si01.isus.emc.com (scl02-01d02-si01.isus.emc.com [137.69.225.84]) by mexforwardwc.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r7LKH1Im001776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Aug 2013 13:17:02 -0700 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by scl02-01d02-si01.isus.emc.com (RSA Interceptor); Wed, 21 Aug 2013 13:16:50 -0700 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r7LKGlC4026171; Wed, 21 Aug 2013 16:16:47 -0400 Received: from mx15a.corp.emc.com ([169.254.1.99]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Wed, 21 Aug 2013 16:16:47 -0400 From: "Black, David" To: "tlyu@mit.edu" , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-storm-ipsec-ips-update.all@tools.ietf.org" Date: Wed, 21 Aug 2013 16:16:39 -0400 Thread-Topic: secdir review of draft-ietf-storm-ipsec-ips-update-03 Thread-Index: Ac6eq1U6aUgpzNAsQz+niqUAY1KY+Q== Message-ID: <8D3D17ACE214DC429325B2B98F3AE7129C489A53@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "Black, David" Subject: Re: [secdir] secdir review of draft-ietf-storm-ipsec-ips-update-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 20:17:12 -0000 Tom, Thank you for this review. I would prefer not to repeat general advice applicable to all uses of IPsec in this draft. That applies to the exposure of AES GCM to nonce reus= e and means of preventing that reuse (e.g., use of IKE) which are covered in = the Security Considerations section of RFC 4106; if that advice is inadequate, I'd suggest a revision of RFC 4106 rather than adding advice to this draft. * OTOH, it would make sense to add a sentence to point out that all of the referenced security RFCs and the security considerations in all of the other referenced RFCs are applicable if that seems useful. As explained in Section 2.2, the hardware implementation considerations originally used to select AES-CTR as a "SHOULD implement" transform now favor AES-GCM. Based on those considerations, AES-GCM is a significantly better choice due to its hardware-friendly hash, so retaining the "SHOULD" for AES-CTR doesn't make sense. The comments on 3DES seems off the mark to me. The IETF approach to security, as I've understood it, is to require implementation of sufficient security mechanisms so that they will be available if needed. =20 Since the protocols to which this draft's requirements apply will operate at high data rates in some environments (e.g., see discussion in Section 2.= 2), 3DES is no longer appropriate as the single "MUST implement" confidentialit= y transform. Further, the comparison to AES-GCM seems misplaced, as AES-CBC is the new "MUST implement" transform, not AES-GCM. * I'll add some advice about matching strengths of symmetric and asymmetric keys with a pointer to NIST SP 800-57, as there are key length requirements in this draft. * ESP sequence number cycling is prohibited (MUST rekey before that happens= ) by RFC 2404 and RFC 4303, so I don't see any point in discussing its=20 consequences. OTOH, I think it would be good to call attention to this requirement to rekey before the ESP sequence number rolls over and point ou= t that extended sequence numbers greatly reduce the frequency at which that m= ay be necessary (probably in Section 2 of this draft). The three paragraphs noted by '*' above indicate the three changes that I'd propose to make in response to this review - is that reasonable? With this draft in IESG Evaluation for next week's telechat (August 29), I would plan to defer these changes until after the telechat. Thanks, --David > -----Original Message----- > From: Tom Yu [mailto:tlyu@MIT.EDU] > Sent: Wednesday, August 21, 2013 2:57 PM > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-storm-ipsec-ips- > update.all@tools.ietf.org > Subject: secdir review of draft-ietf-storm-ipsec-ips-update-03 >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > I believe this document is ready with minor issues. >=20 > The Security Considerations section in its entirety is >=20 > "This entire document is about security." >=20 > Although the above statement is true, I think it would also be > beneficial to provide additional information in the Security > Considerations to help implementers and administrators make informed > risk assessments. This could include describing the consequences of > failing to adopt the recommendations of this document. I have > outlined below some possible risk tradeoffs to consider describing in > the document. >=20 > AES in GCM mode is vulnerable to catastrophic forgery attacks if a > nonce is ever repeated with a given key. Hopefully this won't be a > practical issue, but implementation bugs involving random number > generators are not uncommon. Forgery in a content protection context > is probably also less of a concern than forgery in an authentication > context. >=20 > What concerns with AES-CTR motivate its demotion? I do seem to recall > that (contrary to best practice) confidentiality can be done > separately from integrity in IPsec. Is this composition done in a way > that has vulnerabilities? I'm not very familiar with IPsec and am not > remembering the details at the moment. >=20 > If there is sufficiently low traffic, is it likely that a site > constrained by legacy or resource issues could use 3DES (with its > 64-bit block size) at an acceptable risk level? (possibly with > frequent rekeying) Ciphertext collision isn't as catastrophic with > CBC mode ciphers as nonce collision is for AES-GCM. McGrew's paper > about collision attacks includes equations that estimate data leakage. >=20 > It could be useful to include advice about matching symmetric key > lengths with public key strengths. See NIST SP 800-57 Part 1. >=20 > What are the consequences of sequence number cycling in ESP? From shawn.emery@oracle.com Wed Aug 21 21:00:02 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4D711E81CE for ; Wed, 21 Aug 2013 21:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bPAFUt0vtvV for ; Wed, 21 Aug 2013 20:59:54 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id AB3C311E811D for ; Wed, 21 Aug 2013 20:59:54 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7M3xoSa032285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Aug 2013 03:59:51 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7M3xo28021304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Aug 2013 03:59:50 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7M3xoGC021292; Thu, 22 Aug 2013 03:59:50 GMT Received: from [10.159.82.82] (/10.159.82.82) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Aug 2013 20:59:49 -0700 Message-ID: <52158CF5.4050001@oracle.com> Date: Wed, 21 Aug 2013 22:00:53 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20130718 Thunderbird/17.0.6 MIME-Version: 1.0 To: secdir@ietf.org References: <51CAA254.6040303@oracle.com> In-Reply-To: <51CAA254.6040303@oracle.com> X-Forwarded-Message-Id: <51CAA254.6040303@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: draft-ietf-repute-query-http.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-repute-query-http-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 04:00:02 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This internet-draft describes a protocol for querying reputation data via HTTP. The first part of the protocol retrieves a template that will subsequently be used as the basis for a URI, which in turn is used to retrieve the reputation information. The security considerations section does exist and acknowledges that the base protocol for retrieving URIs is insecure as well as the retrieval of reputation data. The section refers to the URI template and well-known URI RFCs for further discussions of template exchange security issues and makes an informative reference to the repute considerations draft for the reputation retrieval. However, none of the referenced RFCs and draft directly talk about the various attacks and how to mitigate against said attacks. I would suggest a direct reference if such a document exists. General comments: None. Editorial comments: s/comprise the/comprise of the/ s/explicitly support support/explicitly support/ s/until finds one/until the client finds one/ Shawn. -- From kivinen@iki.fi Thu Aug 22 05:36:48 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30AF11E81BD for ; Thu, 22 Aug 2013 05:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vL-pbTSdA4PB for ; Thu, 22 Aug 2013 05:36:43 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id C31DF21F8265 for ; Thu, 22 Aug 2013 05:36:42 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r7MCaZXR000492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 22 Aug 2013 15:36:35 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r7MCaYL2017196; Thu, 22 Aug 2013 15:36:34 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21014.1490.482917.486895@fireball.kivinen.iki.fi> Date: Thu, 22 Aug 2013 15:36:34 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 12:36:48 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Tero Kivinen is next in the rotation. For telechat 2013-08-29 Reviewer LC end Draft Dan Harkins TR2013-05-15 draft-ietf-6man-addr-select-opt-11 Warren Kumari T 2013-07-15 draft-ietf-lisp-deployment-10 For telechat 2013-09-12 Dave Cridland T 2013-08-29 draft-ietf-repute-email-identifiers-08 Alan DeKok T 2013-08-29 draft-ietf-repute-media-type-10 Donald Eastlake T 2013-08-29 draft-ietf-repute-model-07 Phillip Hallam-Baker TR2013-09-02 draft-ietf-spfbis-4408bis-19 Simon Josefsson T 2013-09-02 draft-ietf-v6ops-mobile-device-profile-04 Charlie Kaufman T 2013-09-02 draft-ietf-v6ops-rfc3316bis-03 Sam Weiler T 2013-08-17 draft-ietf-homenet-arch-10 Last calls and special requests: Derek Atkins 2013-08-27 draft-ietf-dime-realm-based-redirect-11 Rob Austein 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Rob Austein 2013-08-29 draft-ietf-netext-update-notifications-07 Dave Cridland - draft-ietf-httpbis-p5-range-23 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-03-30 draft-ietf-roll-terminology-12 Phillip Hallam-Baker 2013-09-18 draft-boucadair-rfc6153-update-01 Steve Hanna 2013-09-02 draft-ietf-ccamp-gmpls-g709-framework-14 Dan Harkins 2013-09-02 draft-ietf-ccamp-gmpls-signaling-g709v3-11 David Harrington 2013-09-03 draft-ietf-dhc-dhcpv6-solmaxrt-update-03 Sam Hartman 2013-09-03 draft-ietf-mediactrl-call-flows-13 Paul Hoffman 2013-09-04 draft-ietf-mpls-return-path-specified-lsp-ping-12 Jeffrey Hutzelman 2013-07-16 draft-yusef-dispatch-ccmp-indication-04 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-04 Jeffrey Hutzelman 2013-09-03 draft-ietf-mpls-targeted-mldp-03 Leif Johansson 2013-09-03 draft-ietf-pim-rfc4601-update-survey-report-02 Scott Kelly 2013-09-16 draft-kelsey-intarea-mesh-link-establishment-05 Stephen Kent 2013-09-13 draft-worley-service-example-13 Julien Laganier - draft-ietf-avtcore-rtp-security-options-04 Julien Laganier - draft-ietf-websec-key-pinning-08 Alexey Melnikov - draft-ietf-payload-rtp-howto-05 Vincent Roca 2013-08-21 draft-ietf-mpls-tp-mip-mep-map-08 Ondrej Sury 2013-08-16 draft-nandakumar-rtcweb-stun-uri-05 Carl Wallace 2013-08-16 draft-ietf-dime-overload-reqs-10 David Waltermire - draft-ietf-repute-considerations-02 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-12 Brian Weis - draft-ietf-radext-dtls-06 Glen Zorn 2012-11-27 draft-ietf-lisp-eid-block-04 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 -- kivinen@iki.fi From stephen.farrell@cs.tcd.ie Thu Aug 22 05:54:06 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7C111E81B2 for ; Thu, 22 Aug 2013 05:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XP+aDqF1eWCG for ; Thu, 22 Aug 2013 05:54:02 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id CD68F21F89EB for ; Thu, 22 Aug 2013 05:54:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A8E74BE80; Thu, 22 Aug 2013 13:53:56 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyxHT-QIDCAz; Thu, 22 Aug 2013 13:53:51 +0100 (IST) Received: from [10.37.123.216] (unknown [95.83.248.183]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5C95ABE76; Thu, 22 Aug 2013 13:53:51 +0100 (IST) References: <21014.1490.482917.486895@fireball.kivinen.iki.fi> Mime-Version: 1.0 (1.0) In-Reply-To: <21014.1490.482917.486895@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8240F2AA-93CC-4403-B2A3-4642F974A83B@cs.tcd.ie> X-Mailer: iPhone Mail (10B329) From: Stephen Farrell Date: Thu, 22 Aug 2013 13:49:33 +0100 To: "secdir-secretary@mit.edu" Cc: "secdir@ietf.org" Subject: Re: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 12:54:06 -0000 And btw for next week's telechat I could really do with the help as I'll be= offline for most of the week but I understand that so are some of you=20 TIA, S On 22 Aug 2013, at 13:36, Tero Kivinen wrote: > Review instructions and related resources are at: > http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >=20 > Tero Kivinen is next in the rotation. >=20 > For telechat 2013-08-29 >=20 > Reviewer LC end Draft > Dan Harkins TR2013-05-15 draft-ietf-6man-addr-select-opt-11 > Warren Kumari T 2013-07-15 draft-ietf-lisp-deployment-10 >=20 >=20 > For telechat 2013-09-12 >=20 > Dave Cridland T 2013-08-29 draft-ietf-repute-email-identifiers-08= > Alan DeKok T 2013-08-29 draft-ietf-repute-media-type-10 > Donald Eastlake T 2013-08-29 draft-ietf-repute-model-07 > Phillip Hallam-Baker TR2013-09-02 draft-ietf-spfbis-4408bis-19 > Simon Josefsson T 2013-09-02 draft-ietf-v6ops-mobile-device-profile= -04 > Charlie Kaufman T 2013-09-02 draft-ietf-v6ops-rfc3316bis-03 > Sam Weiler T 2013-08-17 draft-ietf-homenet-arch-10 >=20 > Last calls and special requests: >=20 > Derek Atkins 2013-08-27 draft-ietf-dime-realm-based-redirect-1= 1 > Rob Austein 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 > Rob Austein 2013-08-29 draft-ietf-netext-update-notifications= -07 > Dave Cridland - draft-ietf-httpbis-p5-range-23 > Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practic= es-07 > Alan DeKok 2013-03-30 draft-ietf-roll-terminology-12 > Phillip Hallam-Baker 2013-09-18 draft-boucadair-rfc6153-update-01 > Steve Hanna 2013-09-02 draft-ietf-ccamp-gmpls-g709-framework-= 14 > Dan Harkins 2013-09-02 draft-ietf-ccamp-gmpls-signaling-g709v= 3-11 > David Harrington 2013-09-03 draft-ietf-dhc-dhcpv6-solmaxrt-update-= 03 > Sam Hartman 2013-09-03 draft-ietf-mediactrl-call-flows-13 > Paul Hoffman 2013-09-04 draft-ietf-mpls-return-path-specified-= lsp-ping-12 > Jeffrey Hutzelman 2013-07-16 draft-yusef-dispatch-ccmp-indication-0= 4 > Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap= -04 > Jeffrey Hutzelman 2013-09-03 draft-ietf-mpls-targeted-mldp-03 > Leif Johansson 2013-09-03 draft-ietf-pim-rfc4601-update-survey-r= eport-02 > Scott Kelly 2013-09-16 draft-kelsey-intarea-mesh-link-establi= shment-05 > Stephen Kent 2013-09-13 draft-worley-service-example-13 > Julien Laganier - draft-ietf-avtcore-rtp-security-options-= 04 > Julien Laganier - draft-ietf-websec-key-pinning-08 > Alexey Melnikov - draft-ietf-payload-rtp-howto-05 > Vincent Roca 2013-08-21 draft-ietf-mpls-tp-mip-mep-map-08 > Ondrej Sury 2013-08-16 draft-nandakumar-rtcweb-stun-uri-05 > Carl Wallace 2013-08-16 draft-ietf-dime-overload-reqs-10 > David Waltermire - draft-ietf-repute-considerations-02 > Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-address= es-12 > Brian Weis - draft-ietf-radext-dtls-06 > Glen Zorn 2012-11-27 draft-ietf-lisp-eid-block-04 > Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 > --=20 > kivinen@iki.fi > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From kent@bbn.com Thu Aug 22 08:51:49 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D2011E8211 for ; Thu, 22 Aug 2013 08:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28iDI69PJpXn for ; Thu, 22 Aug 2013 08:51:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A463121F99F4 for ; Thu, 22 Aug 2013 08:51:32 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:53446) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VCXAW-000DTr-Up; Thu, 22 Aug 2013 11:51:29 -0400 Message-ID: <52163380.5070005@bbn.com> Date: Thu, 22 Aug 2013 11:51:28 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: secdir , worley@ariadne.com, Mary Barnes , fluffy@iii.ca, gonzalo.camarillo@ericsson.com Content-Type: multipart/alternative; boundary="------------000107060007080509050304" Subject: [secdir] SECDIR review of draft-worley-service-example-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 15:51:50 -0000 This is a multi-part message in MIME format. --------------000107060007080509050304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit SECDIR review of draft-worley-service-example-13 I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors and WG chairs should treat these comments just like any other last call comments. This document describes how to provide music on old (MOH) in a VoIp environment, an obviously critical capability needed to preserve feature compatibility with the PSTN. Callers who are not subjected to MOH might otherwise not be exposed to classical music, in many contexts, a tragic outcome. This document is intended to be Informational. The author notes that this status is appropriate because there are other methods for providing MOH, and they interoperate. He believes that the proposed method is superior, but not so much as to warrant BCP status. The document seems to be well-written, clear, and it contains numerous examples (and diagrams) to help illustrate the mechanism details. I was surprised to see that all the references to RFCs (normative and informative) use labels other than RFC numbers. This an unusual convention that I hope the RFC editor will fix. It is hard to overstate the importance of appropriate security mechanisms for this critical aspect of VoIP. Consistent with this observation, the Security Considerations section of this document consists of just one paragraph. The paragraph addresses one security concern, i.e., the ability of the UA of a caller to filter incoming media based on the address of the source of the media. The design in this document provides the source address of the MOH server, via SDP (in a re-INVITE), to the caller who is on hold, and thus satisfies this concern. In a more serious vein, I'd like to see the Security Considerations section mention whether UAs are expected to use SDP and SIP security mechanisms for MOH, IF these mechanisms were employed for the original call. Another paragraph could be added to discuss the desirability of maintaining an equivalent level of security when a caller is switched over to MOH, and to cite the relevant RFCs, or to explain why this is not appropriate. --------------000107060007080509050304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

SECDIR review of draft-worley-service-example-13

 

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

 

This document describes how to provide music on old (MOH) in a VoIp environment, an obviously critical capability needed to preserve feature compatibility with the PSTN. Callers who are not subjected to MOH might otherwise not be exposed to classical music, in many contexts, a tragic outcome.

 

This document is intended to be Informational. The author notes that this status is appropriate because there are other methods for providing MOH, and they interoperate. He believes that the proposed method is superior, but not so much as to warrant BCP status.

 

The document seems to be well-written, clear, and it contains numerous examples (and diagrams) to help illustrate the mechanism details. I was surprised to see that all the references to RFCs (normative and informative) use labels other than RFC numbers. This an unusual convention that I hope the RFC editor will fix.

 

It is hard to overstate the importance of appropriate security mechanisms for this critical aspect of VoIP. Consistent with this observation, the Security Considerations section of this document consists of just one paragraph. The paragraph addresses one security concern, i.e., the ability of the UA of a caller to filter incoming media based on the address of the source of the media. The design in this document provides the source address of the MOH server, via SDP (in a re-INVITE), to the caller who is on hold, and thus satisfies this concern.

 

In a more serious vein, I’d like to see the Security Considerations section mention whether UAs are expected to use SDP and SIP security mechanisms for MOH, IF these mechanisms were employed for the original call. Another paragraph could be added to discuss the desirability of maintaining an equivalent level of security when a caller is switched over to MOH, and to cite the relevant RFCs, or to explain why this is not appropriate.

--------------000107060007080509050304-- From tlyu@mit.edu Thu Aug 22 16:45:49 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AC911E823B; Thu, 22 Aug 2013 16:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjhfGaAMK2EW; Thu, 22 Aug 2013 16:45:40 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id 003A211E8239; Thu, 22 Aug 2013 16:45:38 -0700 (PDT) X-AuditID: 1209190f-b7fa58e000000953-da-5216a2a1b544 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 3F.43.02387.1A2A6125; Thu, 22 Aug 2013 19:45:37 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r7MNjQwr013391; Thu, 22 Aug 2013 19:45:26 -0400 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.8/8.12.4) with ESMTP id r7MNjNWx030597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Aug 2013 19:45:24 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r7MNjMYC003649; Thu, 22 Aug 2013 19:45:22 -0400 (EDT) To: "Black, David" References: <8D3D17ACE214DC429325B2B98F3AE7129C489A53@MX15A.corp.emc.com> From: Tom Yu Date: Thu, 22 Aug 2013 19:45:22 -0400 In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7129C489A53@MX15A.corp.emc.com> (David Black's message of "Wed, 21 Aug 2013 16:16:39 -0400") Message-ID: Lines: 100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleLIzCtJLcpLzFFi42IRYrdT1124SCzIYP1jQYuth9eyWzx6d5rJ YsaficwWHxY+ZHFg8ThyZDaLx5IlP5k8vlz+zBbAHMVlk5Kak1mWWqRvl8CVcWT/K8aCL5oV j3b+ZGtgnKzUxcjJISFgIrHv6HFGCFtM4sK99WxdjFwcQgL7GCUO3dkA5WxklHhxZRMjhHOO SWJTVzsThNPFKNG3+wgTSL+IgIbE9o/7wKqYBQ4wSnx9sQ4sISzgJLHz3kp2EFtIwFNixeSD zF2MHBxsAtISRxeXgYRZBFQlbi9rBVvHKdDOKNFyej1YPa+AhcTUnw/ZQep5BLgkXs8sgQgL Spyc+YQFxGYW0JK48e8l0wRGwVlIUrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdHL zSzRS00p3cQICmVOSf4djN8OKh1iFOBgVOLhtXAUCxJiTSwrrsw9xCjJwaQkyntsLlCILyk/ pTIjsTgjvqg0J7X4EKMEB7OSCO+uiUA53pTEyqrUonyYlDQHi5I477OnZwOFBNITS1KzU1ML UotgsjIcHEoSvBcWAjUKFqWmp1akZeaUIKSZODhBhvMADd8OUsNbXJCYW5yZDpE/xajL8Wfl 3E+MQix5+XmpUuK8t0CKBECKMkrz4ObAUtArRnGgt4R594BU8QDTF9ykV0BLmICWzHwsCrKk JBEhJdXAmD3lSIqw/c+yayve1O1bH5L0JYy50fQgV0b+u57zjc8ZOeLYhCTLniu61/xfddi+ u9WotFRPeZfY8VPlyjsyHjKk3472sl2/+sVyi6OSAh7qElmXS18ETSyc1rx97d0/WpdfGs/I MH74e3eZ3N2b9+J/SihovS53X5lusjmgottL4+snHRFeJZbijERDLeai4kQAVsWgbxwDAAA= Cc: "draft-ietf-storm-ipsec-ips-update.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-storm-ipsec-ips-update-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 23:45:50 -0000 "Black, David" writes: > I would prefer not to repeat general advice applicable to all uses of > IPsec in this draft. That applies to the exposure of AES GCM to nonce reuse > and means of preventing that reuse (e.g., use of IKE) which are covered in the > Security Considerations section of RFC 4106; if that advice is inadequate, > I'd suggest a revision of RFC 4106 rather than adding advice to this draft. I would tend to agree about not repeating general advice applicable to all uses of IPsec. This document does replace AES-CTR with AES-GCM, and the consequences of nonce reuse with these modes are qualitatively different and possibly bear mentioning. I think the text in RFC 4106 about the risks of nonce reuse should be more specific about the consequences. (RFC 4106 says "destroys the security guarantees of AES-GCM mode" instead of "reveals the authentication subkey".) Compared to most other cipher modes, nonce reuse in GCM has surprisingly catastrophic consequences. Perhaps RFC 4106 could use revision, but that would not benefit readers of this document until that revision was published. > * OTOH, it would make sense to add a sentence to point out that all of the > referenced security RFCs and the security considerations in all of the > other referenced RFCs are applicable if that seems useful. That would be useful, as would additional text calling out the security considerations sections for RFCs related to algorithms whose requirement levels this document changes, e.g., AES-CTR (RFC 3686), AES-GCM (RFC 4106), and AES-GMAC (RFC 4543). Because this document replaces one "SHOULD" requirement level AES counter mode with another, I think it would also be useful to contrast the considerably different consequences of nonce reuse in AES-CTR (confidentiality loss limited to the blocks with colliding counter values) compared to AES-GCM (additionally reveals the authentication subkey). The relative severity of these vulnerabilities might be debatable in the context of a block storage protocol. If you believe the security impacts to block storage protocols caused by these nonce reuse issues are negligibly different, the document might not need to make that comparison. (Although I would be interested in hearing the reasoning behind such a belief.) > As explained in Section 2.2, the hardware implementation considerations > originally used to select AES-CTR as a "SHOULD implement" transform now > favor AES-GCM. Based on those considerations, AES-GCM is a significantly > better choice due to its hardware-friendly hash, so retaining the "SHOULD" > for AES-CTR doesn't make sense. Am I correct in concluding from the above that there were no security issues leading to the changes of requirement levels for AES-CTR ("SHOULD" to "MAY"), and that you base the advice on hardware implementation considerations? If so, this text in Section 2.2 seems potentially misleading: "This document changes both [3DES-CBC and AES-CTR] of these requirements based on cryptographic developments since the publication of RFC 3723." unless "cryptographic developments" refers to both the block size vulnerability of 3DES and the standardization of AES-GCM. In that case, I would suggest adding text to the "AES Counter mode" paragraph of Section 2.2 indicating that the new preference of AES-GCM above AES-CTR is because of hardware implementation considerations and not cryptographic weakness. > The comments on 3DES seems off the mark to me. The IETF approach to > security, as I've understood it, is to require implementation of > sufficient security mechanisms so that they will be available if needed. > Since the protocols to which this draft's requirements apply will operate > at high data rates in some environments (e.g., see discussion in Section 2.2), > 3DES is no longer appropriate as the single "MUST implement" confidentiality > transform. Further, the comparison to AES-GCM seems misplaced, as AES-CBC > is the new "MUST implement" transform, not AES-GCM. I agree that 3DES is no longer appropriate as the "MUST implement" confidentiality transform. I think that because 3DES remains available as an optional algorithm, it could be valuable to provide advice about when its use might be an acceptable risk (low data rate sessions?). > * I'll add some advice about matching strengths of symmetric and asymmetric > keys with a pointer to NIST SP 800-57, as there are key length requirements > in this draft. > > * ESP sequence number cycling is prohibited (MUST rekey before that happens) > by RFC 2404 and RFC 4303, so I don't see any point in discussing its > consequences. OTOH, I think it would be good to call attention to this > requirement to rekey before the ESP sequence number rolls over and point out > that extended sequence numbers greatly reduce the frequency at which that may > be necessary (probably in Section 2 of this draft). > > The three paragraphs noted by '*' above indicate the three changes that I'd > propose to make in response to this review - is that reasonable? > > With this draft in IESG Evaluation for next week's telechat (August 29), > I would plan to defer these changes until after the telechat. Your proposed changes seem reasonable. From david.black@emc.com Thu Aug 22 17:46:59 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3135C11E815B; Thu, 22 Aug 2013 17:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.111 X-Spam-Level: X-Spam-Status: No, score=-103.111 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-dEmebLCnNe; Thu, 22 Aug 2013 17:46:53 -0700 (PDT) Received: from mexforward.lss.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0331711E812E; Thu, 22 Aug 2013 17:46:52 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r7N0kor5007798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Aug 2013 20:46:50 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 22 Aug 2013 20:46:41 -0400 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r7N0iEPr026549; Thu, 22 Aug 2013 20:46:38 -0400 Received: from mx15a.corp.emc.com ([169.254.1.99]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Thu, 22 Aug 2013 20:46:08 -0400 From: "Black, David" To: "tlyu@mit.edu" Date: Thu, 22 Aug 2013 20:46:07 -0400 Thread-Topic: secdir review of draft-ietf-storm-ipsec-ips-update-03 Thread-Index: Ac6fkacfvZUo8x/tTaeWwP8FNlpmJAABcKWw Message-ID: <8D3D17ACE214DC429325B2B98F3AE7129C489CB1@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE7129C489A53@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "Black, David" , "draft-ietf-storm-ipsec-ips-update.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-storm-ipsec-ips-update-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 00:46:59 -0000 Tom, I think we should agree to disagree on one point, and I'm prepared to make text changes to address the others (in particular, you are clearly right that the hardware implementation rationale for AES GCM instead of AES CTR should be made clearer). As previously noted, I plan to hold off on submitting a revised draft until after the IESG telechat on August 29. Again, thank you for the review and your comments. -- Point of disagreement I firmly believe that filing technical errata against RFC 4106 (AES GCM) is the appropriate vehicle for the concerns about AES GCM nonce reuse, including the comparison of security properties to AES CTR. Such errata wi= ll get the requisite level of review from security experts and cryptographers who may not look at this draft, and will result in them being seen by anyone who implements GCM, in contrast to this draft which may not even be consulted by all IPsec implementers. I propose leaving this to the Security ADs to determine at this juncture, a= s I believe I understand your security concerns, (with which I do not disagre= e). Rather, I am asserting that this draft is the wrong vehicle for them, becau= se (IMHO) they should be directly associated with the AES GCM RFC, and filing technical errata against that RFC is the appropriate means to accomplish th= at. -- Points of agreement (1) Applicability of security considerations text in other RFCs > > * OTOH, it would make sense to add a sentence to point out that all of = the > > referenced security RFCs and the security considerations in all of the > > other referenced RFCs are applicable if that seems useful. >=20 > That would be useful, as would additional text calling out the > security considerations sections for RFCs related to algorithms whose > requirement levels this document changes, e.g., AES-CTR (RFC 3686), > AES-GCM (RFC 4106), and AES-GMAC (RFC 4543). Ok, I can do that. (2) Rationale for replacement of AES CTR with AES GCM > Am I correct in concluding from the above that there were no security > issues leading to the changes of requirement levels for AES-CTR > ("SHOULD" to "MAY"), and that you base the advice on hardware > implementation considerations? If so, this text in Section 2.2 seems > potentially misleading: >=20 > "This document changes both [3DES-CBC and AES-CTR] of these > requirements based on cryptographic developments since the > publication of RFC 3723." >=20 > unless "cryptographic developments" refers to both the block size > vulnerability of 3DES and the standardization of AES-GCM. That is the situation. > In that > case, I would suggest adding text to the "AES Counter mode" paragraph > of Section 2.2 indicating that the new preference of AES-GCM above > AES-CTR is because of hardware implementation considerations and not > cryptographic weakness. Good suggestion - I'll plan on doing that. (3) Use of 3DES > I agree that 3DES is no longer appropriate as the "MUST implement" > confidentiality transform. I think that because 3DES remains > available as an optional algorithm, it could be valuable to provide > advice about when its use might be an acceptable risk (low data rate > sessions?). Ok, I can write a sentence to the effect that when the data rate is low enough that 3DES's rekeying frequency is not a concern, 3DES is a reasonable algorithm to use. (4) Key strength matching As previously noted, I'll do the following: > > * I'll add some advice about matching strengths of symmetric and asymme= tric > > keys with a pointer to NIST SP 800-57, as there are key length requirem= ents > > in this draft. (5) ESP sequence numbers and rekeying As previously noted, I'll do the following: > > * ESP sequence number cycling is prohibited (MUST rekey before that hap= pens) > > by RFC 2404 and RFC 4303, so I don't see any point in discussing its > > consequences. OTOH, I think it would be good to call attention to this > > requirement to rekey before the ESP sequence number rolls over and poin= t out > > that extended sequence numbers greatly reduce the frequency at which th= at > > may be necessary (probably in Section 2 of this draft). Thanks, --David > -----Original Message----- > From: Tom Yu [mailto:tlyu@MIT.EDU] > Sent: Thursday, August 22, 2013 7:45 PM > To: Black, David > Cc: iesg@ietf.org; secdir@ietf.org; draft-ietf-storm-ipsec-ips- > update.all@tools.ietf.org > Subject: Re: secdir review of draft-ietf-storm-ipsec-ips-update-03 >=20 > "Black, David" writes: >=20 > > I would prefer not to repeat general advice applicable to all uses of > > IPsec in this draft. That applies to the exposure of AES GCM to nonce = reuse > > and means of preventing that reuse (e.g., use of IKE) which are covered= in the > > Security Considerations section of RFC 4106; if that advice is inadequa= te, > > I'd suggest a revision of RFC 4106 rather than adding advice to this dr= aft. >=20 > I would tend to agree about not repeating general advice applicable to > all uses of IPsec. This document does replace AES-CTR with AES-GCM, > and the consequences of nonce reuse with these modes are qualitatively > different and possibly bear mentioning. >=20 > I think the text in RFC 4106 about the risks of nonce reuse should be > more specific about the consequences. (RFC 4106 says "destroys the > security guarantees of AES-GCM mode" instead of "reveals the > authentication subkey".) Compared to most other cipher modes, nonce > reuse in GCM has surprisingly catastrophic consequences. Perhaps RFC > 4106 could use revision, but that would not benefit readers of this > document until that revision was published. >=20 > > * OTOH, it would make sense to add a sentence to point out that all of = the > > referenced security RFCs and the security considerations in all of the > > other referenced RFCs are applicable if that seems useful. >=20 > That would be useful, as would additional text calling out the > security considerations sections for RFCs related to algorithms whose > requirement levels this document changes, e.g., AES-CTR (RFC 3686), > AES-GCM (RFC 4106), and AES-GMAC (RFC 4543). >=20 > Because this document replaces one "SHOULD" requirement level AES > counter mode with another, I think it would also be useful to contrast > the considerably different consequences of nonce reuse in AES-CTR > (confidentiality loss limited to the blocks with colliding counter > values) compared to AES-GCM (additionally reveals the authentication > subkey). >=20 > The relative severity of these vulnerabilities might be debatable in > the context of a block storage protocol. If you believe the security > impacts to block storage protocols caused by these nonce reuse issues > are negligibly different, the document might not need to make that > comparison. (Although I would be interested in hearing the reasoning > behind such a belief.) >=20 > > As explained in Section 2.2, the hardware implementation considerations > > originally used to select AES-CTR as a "SHOULD implement" transform now > > favor AES-GCM. Based on those considerations, AES-GCM is a significant= ly > > better choice due to its hardware-friendly hash, so retaining the "SHOU= LD" > > for AES-CTR doesn't make sense. >=20 > Am I correct in concluding from the above that there were no security > issues leading to the changes of requirement levels for AES-CTR > ("SHOULD" to "MAY"), and that you base the advice on hardware > implementation considerations? If so, this text in Section 2.2 seems > potentially misleading: >=20 > "This document changes both [3DES-CBC and AES-CTR] of these > requirements based on cryptographic developments since the > publication of RFC 3723." >=20 > unless "cryptographic developments" refers to both the block size > vulnerability of 3DES and the standardization of AES-GCM. In that > case, I would suggest adding text to the "AES Counter mode" paragraph > of Section 2.2 indicating that the new preference of AES-GCM above > AES-CTR is because of hardware implementation considerations and not > cryptographic weakness. >=20 > > The comments on 3DES seems off the mark to me. The IETF approach to > > security, as I've understood it, is to require implementation of > > sufficient security mechanisms so that they will be available if needed= . > > Since the protocols to which this draft's requirements apply will opera= te > > at high data rates in some environments (e.g., see discussion in Sectio= n > 2.2), > > 3DES is no longer appropriate as the single "MUST implement" confidenti= ality > > transform. Further, the comparison to AES-GCM seems misplaced, as AES-= CBC > > is the new "MUST implement" transform, not AES-GCM. >=20 > I agree that 3DES is no longer appropriate as the "MUST implement" > confidentiality transform. I think that because 3DES remains > available as an optional algorithm, it could be valuable to provide > advice about when its use might be an acceptable risk (low data rate > sessions?). >=20 > > * I'll add some advice about matching strengths of symmetric and asymme= tric > > keys with a pointer to NIST SP 800-57, as there are key length requirem= ents > > in this draft. > > > > * ESP sequence number cycling is prohibited (MUST rekey before that hap= pens) > > by RFC 2404 and RFC 4303, so I don't see any point in discussing its > > consequences. OTOH, I think it would be good to call attention to this > > requirement to rekey before the ESP sequence number rolls over and poin= t out > > that extended sequence numbers greatly reduce the frequency at which th= at > may > > be necessary (probably in Section 2 of this draft). > > > > The three paragraphs noted by '*' above indicate the three changes that= I'd > > propose to make in response to this review - is that reasonable? > > > > With this draft in IESG Evaluation for next week's telechat (August 29)= , > > I would plan to defer these changes until after the telechat. >=20 > Your proposed changes seem reasonable. From stpeter@stpeter.im Thu Aug 22 18:55:45 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF1B11E810B for ; Thu, 22 Aug 2013 18:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vws5392dkYAC for ; Thu, 22 Aug 2013 18:55:39 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9815611E80A2 for ; Thu, 22 Aug 2013 18:55:32 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3D4C741520; Thu, 22 Aug 2013 19:58:57 -0600 (MDT) Message-ID: <5216C111.9070703@stpeter.im> Date: Thu, 22 Aug 2013 19:55:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Paul Hoffman References: <845C917C-4115-4F3E-9E91-E6A3DB903F0C@vpnc.org> <1670FE635C32C34AAD005D960F1C501115CA4D2B@xmb-aln-x11.cisco.com> In-Reply-To: <1670FE635C32C34AAD005D960F1C501115CA4D2B@xmb-aln-x11.cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "draft-ivov-xmpp-cusax.all@tools.ietf.org" , "Peter Saint-Andre \(psaintan\)" , secdir Subject: Re: [secdir] Secdir review of draft-ivov-xmpp-cusax X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 01:55:45 -0000 On 7/17/13 1:56 PM, Peter Saint-Andre (psaintan) wrote: > Hi Paul, thank you for the review. Thanks again and apologies for the delayed processing. Proposed text changes inline. > On Jul 17, 2013, at 9:13 AM, Paul Hoffman > wrote: > >> Greetings. I have reviewed this document for security issues, and >> have mixed feelings. I apologize for the lateness of this review. >> >> The draft specifies a non-normative way to make clients (and to a >> small extent, servers) mostly-transparently combine the use of SIP >> for voice and video with XMPP for instant messaging. It is >> informational, and talks about the various things that applications >> developers of software that makes this combination should think >> about. >> >> Security is barely discussed, likely because a client that is >> presenting two different protocols that each have their own >> security frameworks is not going to make the security of either >> protocol worse. However, user perception of security will be >> significantly affected by the combination. There is one paragraph >> that alludes to this in the Security Considerations, but there >> should be more. >> >> The first sentence of that one paragraph describes mis-matched >> crypto between the SIP part and the XMPP part, which is fine but >> mostly invisible to users. >> >> The second sentence is much more worrying: it describes the case >> where one of the protocols is cryptographically protected and the >> other has none. This is an all-too-common case with IETF protocols: >> the user doesn't have to turn on crypto, and once it is not turned >> on, that fact is forgotten. The document blithely says that the >> application developer should ensure that such mis-matches are >> avoided to prevent downgrade attacks, but says nothing about how >> that could be avoided. A stronger statement would be "if both >> protocols are not protected by similar levels of cryptographic >> protection, the user MUST be informed of that and given the >> opportunity to bring both up to the same level". > > Agreed. Thanks for the text suggestion. > >> There should also be at least a paragraph describing the difference >> in commonly-used authentication mechanisms for SIP and XMPP. A user >> may have authenticated one of the two channels with an >> easily-attacked password, but the other channel with a strong >> cryptographic mechanism such as TLS client certificates. When you >> combine two similar functions into one application without making >> that clear, a user might assume that their IM and voice >> communications are similarly protected when in fact they are not. > > The two examples in the Security Considerations are (1) > authentication and (2) channel encryption. Do you think we need a > full new paragraph about authentication mechanism mismatches, or > would it be acceptable to expand upon the text that's there now? OLD 7. Security Considerations Use of the same user agent with two different accounts providing complementary features introduces the possibility of mismatches between the security profiles of those accounts or features. For example, the SIP aspect and XMPP aspect of the CUSAX service might offer different authentication options (e.g., digest authentication for SIP as specified in [RFC3261] and SCRAM authentication [RFC5802] for XMPP as specified in [RFC6120]). Similarly, a CUSAX client might successfully negotiate Transport Layer Security (TLS) [RFC5246] when connecting to the XMPP aspect of the service but not when connecting to the SIP aspect. Such mismatches could introduce the possibility of downgrade attacks. User agent developers and service providers ought to ensure that such mismatches are avoided as much as possible. Refer to the specifications for the relevant SIP and XMPP features for detailed security considerations applying to each "stack" in a CUSAX client. NEW 7. Security Considerations Use of the same user agent with two different accounts providing complementary features introduces the possibility of mismatches between the security profiles of those accounts or features. Two security mismatches of particular concern are: o The SIP aspect and XMPP aspect of a CUSAX service might offer different authentication options (e.g., digest authentication for SIP as specified in [RFC3261] and SCRAM authentication [RFC5802] for XMPP as specified in [RFC6120]). Because SIP uses a password- based method (digest) and XMPP uses a pluggable framework for authentication via the Simple Authentication and Security Layer (SASL) technology [RFC4422], it is also possible that the XMPP connection could be authenticated using a password-free method such as client certificates with SASL EXTERNAL even though a username and password is used for the SIP connection. o The Transport Layer Security (TLS) [RFC5246] ciphersuites offered or negotiated on the XMPP side might be different from those on the SIP side because of implementation or configuration differences between the SIP server and the XMPP server. Even more seriously, a CUSAX client might successfully negotiate TLS when connecting to the XMPP aspect of the service but not when connecting to the SIP aspect, or vice-versa. In this situation an end user might think that the combined CUSAX session with the service is protected by TLS, even though only one aspect is protected. Security mismatches such as these (as well as others related to end- to-end encryption of messages or media) introduce the possibility of downgrade attacks, eavesdropping, information leakage, and other security vulnerabilities. User agent developers and service providers MUST ensure that such mismatches are avoided as much as possible (e.g., by enforcing common and strong security configurations and policies across protocols). Specifically, if both protocols are not safeguarded by similar levels of cryptographic protection, the user MUST be informed of that fact and given the opportunity to bring both up to the same level. Section 5 discusses potential issues that may arise due to a mismatch between client capabilities, such as calls being initiated with costs contrary to the expectation of the end user. Such issues could be triggered maliciously, as well as by accident. Implementers therefore need to provide necessary cues to raise user awareness as suggested in Section 5. Refer to the specifications for the relevant SIP and XMPP features for detailed security considerations applying to each "stack" in a CUSAX client. >> It would also be valuable if the document mentioned the possibility >> of security mis-match in the introduction, given the high chance >> for user confusion on the issue. > > > Yes, that would be helpful. > > The authors will put their heads together and come back with proposed > text changes. OLD This document explains how such hybrid offerings can be achieved with a minimum of modifications to existing software while providing an optimal user experience. It covers server discovery, determining a SIP Address of Record (AOR) while using XMPP, and determining an XMPP Jabber Identifier ("JID") from incoming SIP requests. Most of the text here pertains to client behavior but it also recommends certain server-side configurations. NEW This document explains how such hybrid offerings can be achieved with a minimum of modifications to existing software while providing an optimal user experience. It covers server discovery, determining a SIP Address of Record (AOR) while using XMPP, and determining an XMPP Jabber Identifier ("JID") from incoming SIP requests. Most of the text here pertains to client behavior but it also recommends certain server-side configurations and operational practices. The document also discusses significant security considerations that can arise when offering a dual-protocol solution, and provides advice for avoiding security mismatches that would result in degraded communications security for end users. Let us know what you think of the proposed modifications. Peter -- Peter Saint-Andre https://stpeter.im/ From paul.hoffman@vpnc.org Thu Aug 22 19:18:03 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1875321F9D33 for ; Thu, 22 Aug 2013 19:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.11 X-Spam-Level: X-Spam-Status: No, score=-104.11 tagged_above=-999 required=5 tests=[AWL=1.936, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFsvlPVlm4GF for ; Thu, 22 Aug 2013 19:17:57 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by ietfa.amsl.com (Postfix) with ESMTP id D6D6B21F9D0A for ; Thu, 22 Aug 2013 19:17:56 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r7N2Hs7M014171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Aug 2013 19:17:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <5216C111.9070703@stpeter.im> Date: Thu, 22 Aug 2013 19:17:54 -0700 Content-Transfer-Encoding: 7bit Message-Id: <20490774-373E-498B-B304-B1CC81917C92@vpnc.org> References: <845C917C-4115-4F3E-9E91-E6A3DB903F0C@vpnc.org> <1670FE635C32C34AAD005D960F1C501115CA4D2B@xmb-aln-x11.cisco.com> <5216C111.9070703@stpeter.im> To: secdir X-Mailer: Apple Mail (2.1508) Cc: draft-ivov-xmpp-cusax.all@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ivov-xmpp-cusax X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 02:18:03 -0000 On Aug 22, 2013, at 6:55 PM, Peter Saint-Andre wrote: > Thanks again and apologies for the delayed processing. Proposed text > changes inline. Those worked fine for me. Thanks! --Paul Hoffman From tlyu@mit.edu Thu Aug 22 20:39:26 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD2C11E80FC; Thu, 22 Aug 2013 20:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hyx2P94K9DJu; Thu, 22 Aug 2013 20:39:20 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id D0EB911E813B; Thu, 22 Aug 2013 20:39:19 -0700 (PDT) X-AuditID: 12074425-b7f0c8e000000953-64-5216d9668aa0 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 41.09.02387.669D6125; Thu, 22 Aug 2013 23:39:18 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r7N3dGkg030256; Thu, 22 Aug 2013 23:39:17 -0400 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.8/8.12.4) with ESMTP id r7N3dDbu001801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Aug 2013 23:39:15 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r7N3dDjo004274; Thu, 22 Aug 2013 23:39:13 -0400 (EDT) To: "Black, David" References: <8D3D17ACE214DC429325B2B98F3AE7129C489A53@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE7129C489CB1@MX15A.corp.emc.com> From: Tom Yu Date: Thu, 22 Aug 2013 23:39:13 -0400 In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7129C489CB1@MX15A.corp.emc.com> (David Black's message of "Thu, 22 Aug 2013 20:46:07 -0400") Message-ID: Lines: 111 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IR4hRV1k27KRZkcKXbxGLr4bXsFo/enWay mPFnIrPFh4UPWRxYPI4cmc3isWTJTyaPL5c/swUwR3HZpKTmZJalFunbJXBlLHx6iLVguWrF 93Nn2BsYb8h2MXJySAiYSOzrXcMMYYtJXLi3nq2LkYtDSGAfo8SWY2dZIJyNjBIvL21khXDO MUnc3ruJGcLpYpRY8q+DFaRfREBDYvvHfYwgCWaBA4wSX1+sYwJJCAs4Sey8t5IdomMHo0TX 2yNAHRwcbALSEkcXl4HUsAioSuy7sZcJpIZToJ1R4s+EDmaQGl4BC4nFV5JAangEuCTmXrzC BmLzCghKnJz5hAXEZhbQkrjx7yXTBEbBWUhSs5CkFjAyrWKUTcmt0s1NzMwpTk3WLU5OzMtL LdK10MvNLNFLTSndxAgKZnYX1R2MEw4pHWIU4GBU4uGd4CwWJMSaWFZcmXuIUZKDSUmUV+YC UIgvKT+lMiOxOCO+qDQntfgQowQHs5IIr80qoBxvSmJlVWpRPkxKmoNFSZz3+dOzgUIC6Ykl qdmpqQWpRTBZGQ4OJQne5BtAjYJFqempFWmZOSUIaSYOTpDhPEDDC0FqeIsLEnOLM9Mh8qcY dTn+rJz7iVGIJS8/L1VKnDcLpEgApCijNA9uDiwJvWIUB3pLmNcNpIoHmMDgJr0CWsIEtGTm Y1GQJSWJCCmpBsbAn2/lL75bu2czp+TPmlt18dZ3JU53y8y9zWai53/yve6dludzX3fuYju9 +SHruRb2rcH1k85WffzBtjpS376v5n5c5KtmpoVMJ0V5Vk1Yn5W+/NS8XIdWrdvcvvN9l6xK /NvqeII9+0V4SOrqSy/WPS+5fnvixZdLA+Zl9mSsfJLnZnI1YVOZEktxRqKhFnNRcSIAKYWz bB0DAAA= Cc: "draft-ietf-storm-ipsec-ips-update.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-storm-ipsec-ips-update-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 03:39:27 -0000 "Black, David" writes: > Tom, > > I think we should agree to disagree on one point, and I'm prepared to make > text changes to address the others (in particular, you are clearly right > that the hardware implementation rationale for AES GCM instead of AES CTR > should be made clearer). As previously noted, I plan to hold off on > submitting a revised draft until after the IESG telechat on August 29. > > Again, thank you for the review and your comments. > > -- Point of disagreement > > I firmly believe that filing technical errata against RFC 4106 (AES GCM) > is the appropriate vehicle for the concerns about AES GCM nonce reuse, > including the comparison of security properties to AES CTR. Such errata will > get the requisite level of review from security experts and cryptographers > who may not look at this draft, and will result in them being seen by > anyone who implements GCM, in contrast to this draft which may not even > be consulted by all IPsec implementers. > > I propose leaving this to the Security ADs to determine at this juncture, as > I believe I understand your security concerns, (with which I do not disagree). > > Rather, I am asserting that this draft is the wrong vehicle for them, because > (IMHO) they should be directly associated with the AES GCM RFC, and filing > technical errata against that RFC is the appropriate means to accomplish that. Hi David, I think that is a reasonable approach (although I do have some slight disagreement with it), and I'm willing to defer to the Security ADs about which approach is the most appropriate in this situation. > -- Points of agreement > > (1) Applicability of security considerations text in other RFCs > >> > * OTOH, it would make sense to add a sentence to point out that all of the >> > referenced security RFCs and the security considerations in all of the >> > other referenced RFCs are applicable if that seems useful. >> >> That would be useful, as would additional text calling out the >> security considerations sections for RFCs related to algorithms whose >> requirement levels this document changes, e.g., AES-CTR (RFC 3686), >> AES-GCM (RFC 4106), and AES-GMAC (RFC 4543). > > Ok, I can do that. > > (2) Rationale for replacement of AES CTR with AES GCM > >> Am I correct in concluding from the above that there were no security >> issues leading to the changes of requirement levels for AES-CTR >> ("SHOULD" to "MAY"), and that you base the advice on hardware >> implementation considerations? If so, this text in Section 2.2 seems >> potentially misleading: >> >> "This document changes both [3DES-CBC and AES-CTR] of these >> requirements based on cryptographic developments since the >> publication of RFC 3723." >> >> unless "cryptographic developments" refers to both the block size >> vulnerability of 3DES and the standardization of AES-GCM. > > That is the situation. > >> In that >> case, I would suggest adding text to the "AES Counter mode" paragraph >> of Section 2.2 indicating that the new preference of AES-GCM above >> AES-CTR is because of hardware implementation considerations and not >> cryptographic weakness. > > Good suggestion - I'll plan on doing that. > > (3) Use of 3DES > >> I agree that 3DES is no longer appropriate as the "MUST implement" >> confidentiality transform. I think that because 3DES remains >> available as an optional algorithm, it could be valuable to provide >> advice about when its use might be an acceptable risk (low data rate >> sessions?). > > Ok, I can write a sentence to the effect that when the data rate is low > enough that 3DES's rekeying frequency is not a concern, 3DES is a > reasonable algorithm to use. > > (4) Key strength matching > > As previously noted, I'll do the following: > >> > * I'll add some advice about matching strengths of symmetric and asymmetric >> > keys with a pointer to NIST SP 800-57, as there are key length requirements >> > in this draft. > > (5) ESP sequence numbers and rekeying > > As previously noted, I'll do the following: > >> > * ESP sequence number cycling is prohibited (MUST rekey before that happens) >> > by RFC 2404 and RFC 4303, so I don't see any point in discussing its >> > consequences. OTOH, I think it would be good to call attention to this >> > requirement to rekey before the ESP sequence number rolls over and point out >> > that extended sequence numbers greatly reduce the frequency at which that >> > may be necessary (probably in Section 2 of this draft). > > Thanks, > --David Yes, I believe we are in agreement on the other points you describe above. Thank you for your prompt and thoughtful reply. From warren@kumari.net Fri Aug 23 16:19:45 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FA221F9EA8 for ; Fri, 23 Aug 2013 16:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBdp7z+FGHEM for ; Fri, 23 Aug 2013 16:19:40 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C1021F9ECA for ; Fri, 23 Aug 2013 16:19:39 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.89]) by vimes.kumari.net (Postfix) with ESMTPSA id 6ED741B412DE; Fri, 23 Aug 2013 19:19:37 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Aug 2013 19:19:36 -0400 Message-Id: <01D946E4-348D-4A3D-ABF8-B7DBD6F74F6E@kumari.net> To: "secdir@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: draft-ietf-lisp-deployment.all@tools.ietf.org Subject: [secdir] SecDir Review of draft-ietf-lisp-deployment X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 23:19:45 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. This draft describes LISP deployment scenarios. It represents current = thinking and is expected to change (I guess be obsoleted / replaced?) as = more experience is gained with deployment. Summary: I'm not sure what to do here. The document is very well written, and the authors seem to have taken = care to consider the implications of various deployment scenarios.=20 In spite of knowing very little about LISP I found the document to be = accessible and easily understood. It clearly lays out the considerations = for different deployments, and provides some guidance as to how to = select. However, the security considerations section simply says: "Security implications of LISP deployments are to be discussed in separate documents. [I-D.ietf-lisp-threats ] gives an overview of LISP threat models, while securing mapping lookups is discussed in [I-D.ietf-lisp-sec]." This is a deployment document, and so this may be perfectly acceptable; = the "separate documents" may completely cover everything. Or not. I am unclear if the authors mean that I-D.ietf-lisp-threats and = I-D.ietf-lisp-sec cover all security considerations, or if the = implication is that there will be other documents that cover the = security implications.=20 http://i.imgur.com/5rTHfRs.jpg Section 2.4. "Inter-Service Provider Traffic Engineering" says: "Failure to follow these recommendations may lead to operational and = security issues when deploying this scenario." I think that a (short) explanation of what the security issues are if = you don't follow the recommendations would be nice. Nits: Section 4.2: "For more details on P-ETRs see the [RFC6832] draft." -- I think that = this could be better worded as "For more details on P-ETRs see = [RFC6832]" (think this was written while RFC6832 was still a draft). ID NITs complains about use of RFC2119 language ("It is NOT RECOMMENDED = for deployment"), but no RFC2119 reference / boilerplate. I'm scraping the bottom of the barrel here, 'tis well written.. -- It is impossible to sharpen a pencil with a blunt axe. It is equally = vain to try to do it with ten blunt axes instead. -- E.W Dijkstra, 1930-2002 From shawn.emery@oracle.com Sat Aug 24 21:56:28 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF5411E8203 for ; Sat, 24 Aug 2013 21:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EFZCShF-wkx for ; Sat, 24 Aug 2013 21:56:21 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0304A11E81FF for ; Sat, 24 Aug 2013 21:56:20 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7P4u9B7012081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 25 Aug 2013 04:56:10 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7P4u83c002585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Aug 2013 04:56:09 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7P4u721002580; Sun, 25 Aug 2013 04:56:08 GMT Received: from shawn-emerys-computer.local (/174.29.22.102) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 24 Aug 2013 21:56:07 -0700 Message-ID: <52198E83.7050406@oracle.com> Date: Sat, 24 Aug 2013 22:56:35 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <51CAA254.6040303@oracle.com> <52158CF5.4050001@oracle.com> <521591FA.20601@dcrocker.net> In-Reply-To: <521591FA.20601@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: draft-ietf-repute-query-http.all@tools.ietf.org, Dave Crocker , secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-repute-query-http-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 04:56:28 -0000 On 08/21/13 10:22 PM, Dave Crocker wrote: > On 8/21/2013 9:00 PM, Shawn M Emery wrote: >> However, none of the >> referenced RFCs and draft directly talk about the various attacks and >> how to mitigate against said attacks. > > > Shawn, some clarification please: > > This is a simple query protocol, ableit yes one where the data is > making trust assertions. > > A possible implication of your above comment is that all IETF > protocols should carry a threat analysis. Have I misunderstood? Hi Dave, Sorry for not being specific. I will try to clarify my concerns: This draft references the reputation considerations draft when providing or using reputation services, I assume in a security context given that it is referenced in the security considerations section. When I looked at the referenced draft's security considerations section it stated that there are threats discussed in the operation text above. I think that these types of discussions deserve a separate section. If the topic is mostly security it would be helpful to have a summary of the various threats and how to mitigate. In any case, when looking through the entire draft I do see some suggestions for clients and their RSPs. Shawn. -- From uri@mit.edu Sun Aug 25 03:38:32 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B83621F9A4C for ; Sun, 25 Aug 2013 03:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNJ0YE0gVCHJ for ; Sun, 25 Aug 2013 03:38:25 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9646921F93D4 for ; Sun, 25 Aug 2013 03:38:24 -0700 (PDT) X-AuditID: 12074423-b7f168e00000095a-94-5219dea07d6e Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 61.76.02394.0AED9125; Sun, 25 Aug 2013 06:38:24 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id r7PAcLUa010473; Sun, 25 Aug 2013 06:38:21 -0400 Received: from [192.168.1.106] (chostler.hsd1.ma.comcast.net [24.62.227.134]) (authenticated bits=0) (User authenticated as uri@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r7PAcInB027896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 25 Aug 2013 06:38:19 -0400 References: <51CAA254.6040303@oracle.com> <52158CF5.4050001@oracle.com> <521591FA.20601@dcrocker.net> <52198E83.7050406@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: <52198E83.7050406@oracle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <48C75C3D-6DCB-448F-AA82-FAC7DCAF1710@mit.edu> X-Mailer: iPad Mail (10B329) From: Uri Blumenthal Date: Sun, 25 Aug 2013 06:38:20 -0400 To: Shawn M Emery X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUixCmqrbvgnmSQwfWbHBa/P31gszi17jyz xYtz0RYfFj5kseh7fYjdgdXj0s6TbB7/Z79m91iy5CeTx8ent1g8vlz+zBbAGsVlk5Kak1mW WqRvl8CVcfqlQ8EB3oo9J+8zNjD+4Opi5OSQEDCRuDDxHDOELSZx4d56ti5GLg4hgX2MEg/e PGWEcDYySrxf/Z0FKsMk8WTZDSinmVFi0p4jQGUcHLwC4hJXD/qAmJwCWhKzXxmDmMwCOhKT FzKCLGAW0JZYtvA12DJeASuJDYe+M4NMYRZ4wSgxeeYVqCtkJDZvf8wOYrMJKEk0N29hBbGF Bewlem9tYAOZySKgKtE1wxokLAK06UZDB9MERsFZCDfMQlg8C8niBYzMqxhlU3KrdHMTM3OK U5N1i5MT8/JSi3TN9HIzS/RSU0o3MYJCnt1FeQfjn4NKhxgFOBiVeHglhCWDhFgTy4orcw8x SnIwKYnyxt8CCvEl5adUZiQWZ8QXleakFh9ilOBgVhLhdXUAyvGmJFZWpRblw6SkOViUxHmf PT0bKCSQnliSmp2aWpBaBJOV4eBQkuANuAvUKFiUmp5akZaZU4KQZuLgBBnOAzS8CaSGt7gg Mbc4Mx0if4pRl2PS3PmfGIVY8vLzUqXEedNBigRAijJK8+DmwFLVK0ZxoLeEee/cAariAaY5 uEmvgJYwAS05uBxsSUkiQkqqgfEcI98X7qcuS9clCdvmLXd9xeDB5VvUyl0wlcv1U/f392IF yudaFSpOFfBmueUfKG/LeXV0bqgLc7zT4gkhPDNW5yewGSU6ny0U1jrHz3YiIvXi32rZ42u2 a++smtiyan386uk7TYQmSJxQqAzrn+dwKo8tNuW53vSY6klrP9/cZJb9tz9RWomlOCPRUIu5 qDgRAOoQ8AUwAwAA Cc: Dave Crocker , "draft-ietf-repute-query-http.all@tools.ietf.org" , "dcrocker@bbiw.net" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-repute-query-http-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 10:38:32 -0000 And if every protocol description did carry a threat analysis, IMHO it would= be a GOOD thing.=20 Sent from my iPad On Aug 25, 2013, at 0:56, Shawn M Emery wrote: > On 08/21/13 10:22 PM, Dave Crocker wrote: >> On 8/21/2013 9:00 PM, Shawn M Emery wrote: >>> However, none of the >>> referenced RFCs and draft directly talk about the various attacks and >>> how to mitigate against said attacks. >>=20 >>=20 >> Shawn, some clarification please: >>=20 >> This is a simple query protocol, ableit yes one where the data is >> making trust assertions. >>=20 >> A possible implication of your above comment is that all IETF >> protocols should carry a threat analysis. Have I misunderstood? >=20 > Hi Dave, >=20 > Sorry for not being specific. I will try to clarify my concerns: >=20 > This draft references the reputation considerations draft when providing o= r using reputation services, I assume in a security context given that it is= referenced in the security considerations section. When I looked at the re= ferenced draft's security considerations section it stated that there are th= reats discussed in the operation text above. I think that these types of di= scussions deserve a separate section. If the topic is mostly security it wo= uld be helpful to have a summary of the various threats and how to mitigate.= In any case, when looking through the entire draft I do see some suggestio= ns for clients and their RSPs. >=20 > Shawn. > -- > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From derek@ihtfp.com Mon Aug 26 12:39:22 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C4021F9D28; Mon, 26 Aug 2013 12:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jT76NW+rpy73; Mon, 26 Aug 2013 12:39:22 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id 8B68321F9048; Mon, 26 Aug 2013 12:39:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id BB2FE260268; Mon, 26 Aug 2013 15:39:16 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 30995-08; Mon, 26 Aug 2013 15:39:15 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 7D3EC2600BB; Mon, 26 Aug 2013 15:39:15 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.5/Submit) id r7QJd8lN017365; Mon, 26 Aug 2013 15:39:08 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Mon, 26 Aug 2013 15:39:08 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: Ruibing_Hao@cable.comcast.com, tom.taylor.stds@gmail.com, dime-chairs@tools.ietf.org Subject: [secdir] sec-dir review of draft-ietf-dime-realm-based-redirect-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 19:39:23 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Message redirection is a basic capability provided by the Diameter base protocol. In its conventional form, message redirection is performed by an application-independent "redirect agent", which returns one or more individual hosts to the message sender as possible destinations of the redirected message. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which that can be achieved. New applications may incorporate this capability by reference to the present document. The Security Considerations section offloads to RFC6733. Other than a bunch of English editorial issues (which I'm sure the RFC Editor will handle) I see no significant issues with this document. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From paul.hoffman@vpnc.org Tue Aug 27 10:08:09 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE3C21E8088 for ; Tue, 27 Aug 2013 10:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.657 X-Spam-Level: X-Spam-Status: No, score=-102.657 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESZj76xXOkLb for ; Tue, 27 Aug 2013 10:08:08 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2065A21E8085 for ; Tue, 27 Aug 2013 10:08:08 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r7RH85gT097288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 27 Aug 2013 10:08:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <13D927ED-EE3B-44AD-9BA9-42AE56C94236@vpnc.org> Date: Tue, 27 Aug 2013 10:08:05 -0700 To: secdir Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [secdir] Secdir review of draft-ietf-mpls-return-path-specified-lsp-ping X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 17:08:09 -0000 This document defines a set of extensions to MPLS to allow the failure = detection mode (basically, a ping) to know which path to use in the = reply. Given that MPLS is a protocol that is only run between gateways = that fully trust each other, there are not many security considerations = for such an extensions. The entire Security Considerations section = reads: Security considerations discussed in [RFC4379] apply to this document. In addition to that, in order to prevent using the extension defined in this document for "proxying" any possible attacks, the return path LSP MUST have destination to the same node where the forward path is from. That actually seems sufficient, given that the underlying protocol is = not meant to have any non-administrative security features. --Paul Hoffman= From dhc@dcrocker.net Wed Aug 21 21:22:52 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF6B11E811D for ; Wed, 21 Aug 2013 21:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjoIE7im7Yg2 for ; Wed, 21 Aug 2013 21:22:47 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC5211E81FF for ; Wed, 21 Aug 2013 21:22:47 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7M4MhUe002466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Aug 2013 21:22:46 -0700 Message-ID: <521591FA.20601@dcrocker.net> Date: Wed, 21 Aug 2013 21:22:18 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Shawn M Emery References: <51CAA254.6040303@oracle.com> <52158CF5.4050001@oracle.com> In-Reply-To: <52158CF5.4050001@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 21 Aug 2013 21:22:47 -0700 (PDT) X-Mailman-Approved-At: Tue, 27 Aug 2013 10:22:17 -0700 Cc: draft-ietf-repute-query-http.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-repute-query-http-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 04:22:52 -0000 On 8/21/2013 9:00 PM, Shawn M Emery wrote: > However, none of the > referenced RFCs and draft directly talk about the various attacks and > how to mitigate against said attacks. Shawn, some clarification please: This is a simple query protocol, ableit yes one where the data is making trust assertions. A possible implication of your above comment is that all IETF protocols should carry a threat analysis. Have I misunderstood? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From superuser@gmail.com Mon Aug 26 22:10:41 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173B021F9A1E for ; Mon, 26 Aug 2013 22:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKFVsMoq8haM for ; Mon, 26 Aug 2013 22:10:40 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 16FF521F99FA for ; Mon, 26 Aug 2013 22:10:39 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t61so3530484wes.14 for ; Mon, 26 Aug 2013 22:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dyg4ul1cqq36MePz8ePR+3DA30aqRhVxWEr43vS4dI4=; b=JxYl20kc6BAwOpDCangTHwExCcRztdMavBI/xM0GHUxkLfHMwmpSIC0fiGHEQ2JOVh 6XgTtEaaILnf/B8KKUmCub5wo7tKie+zOeymcxeLou4BZzQyFGThbSZYCIAoAvQH3MR8 wous4vurVnfghaTM/Ma/E42lXUv/9FavwdGbL+Y9nkSs5JV09/9t7rJ5w00H0NsrmJp0 fspZJV+mJR2Q3UYv5+ZZKM4VasBDrFYLl+qMxGjzkvxQtovJ9Ru+hbdqRQvvg0emMJSL cCW1mYeNsqxzsdjICLz5+CfnjeqvX3R5+0nePM8SsX7JWGJltADBVFgHLbmiuRYUIza6 wg7Q== MIME-Version: 1.0 X-Received: by 10.194.240.197 with SMTP id wc5mr12968747wjc.23.1377580238059; Mon, 26 Aug 2013 22:10:38 -0700 (PDT) Received: by 10.180.75.144 with HTTP; Mon, 26 Aug 2013 22:10:37 -0700 (PDT) In-Reply-To: <52198E83.7050406@oracle.com> References: <51CAA254.6040303@oracle.com> <52158CF5.4050001@oracle.com> <521591FA.20601@dcrocker.net> <52198E83.7050406@oracle.com> Date: Mon, 26 Aug 2013 22:10:37 -0700 Message-ID: From: "Murray S. Kucherawy" To: Shawn M Emery Content-Type: multipart/alternative; boundary=089e013d19ccbd410c04e4e6e416 X-Mailman-Approved-At: Tue, 27 Aug 2013 10:22:17 -0700 Cc: draft-ietf-repute-query-http.all@tools.ietf.org, Dave Crocker , Dave Crocker , secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-repute-query-http-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 05:10:41 -0000 --089e013d19ccbd410c04e4e6e416 Content-Type: text/plain; charset=ISO-8859-1 Hi Shawn, thanks for the review. On Sat, Aug 24, 2013 at 9:56 PM, Shawn M Emery wrote: > On 08/21/13 10:22 PM, Dave Crocker wrote: > >> On 8/21/2013 9:00 PM, Shawn M Emery wrote: >> >>> However, none of the >>> referenced RFCs and draft directly talk about the various attacks and >>> how to mitigate against said attacks. >>> >> >> >> Shawn, some clarification please: >> >> This is a simple query protocol, ableit yes one where the data is >> making trust assertions. >> >> A possible implication of your above comment is that all IETF >> protocols should carry a threat analysis. Have I misunderstood? >> > > Hi Dave, > > Sorry for not being specific. I will try to clarify my concerns: > > This draft references the reputation considerations draft when providing > or using reputation services, I assume in a security context given that it > is referenced in the security considerations section. When I looked at the > referenced draft's security considerations section it stated that there are > threats discussed in the operation text above. I think that these types of > discussions deserve a separate section. If the topic is mostly security it > would be helpful to have a summary of the various threats and how to > mitigate. In any case, when looking through the entire draft I do see some > suggestions for clients and their RSPs. > > > I'm still a little unclear about what the suggestion is here. Since this review is specific to query-http, I take your feedback to mean that query-http itself is fine, but it's desirable that the considerations document go into more detail about what it's discussing. I think that's fine and probably true, and I'll do so for that document, but I don't think there's anything outstanding for this one. Do you agree? -MSK --089e013d19ccbd410c04e4e6e416 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Shawn, thanks for the review.

On Sat, Aug 24, 2013 at 9:56 PM, S= hawn M Emery <shawn.emery@oracle.com> wrote:
On 08/21/13 10:22 PM, Dave= Crocker wrote:
On 8/21/2013 9:00 PM, Shawn M Emery wrote:
However, none of the
referenced RFCs and draft directly talk about the various attacks and
how to mitigate against said attacks.


Shawn, some clarification please:

=A0 =A0This is a simple query protocol, ableit yes one where the data is making trust assertions.

=A0 =A0A possible implication of your above comment is that all IETF
protocols should carry a threat analysis. =A0Have I misunderstood?

Hi Dave,

Sorry for not being specific. =A0I will try to clarify my concerns:

This draft references the reputation considerations draft when providing or= using reputation services, I assume in a security context given that it is= referenced in the security considerations section. =A0When I looked at the= referenced draft's security considerations section it stated that ther= e are threats discussed in the operation text above. =A0I think that these = types of discussions deserve a separate section. =A0If the topic is mostly = security it would be helpful to have a summary of the various threats and h= ow to mitigate. =A0In any case, when looking through the entire draft I do = see some suggestions for clients and their RSPs.



I'm still a little unclear about wh= at the suggestion is here.=A0 Since this review is specific to query-http, = I take your feedback to mean that query-http itself is fine, but it's d= esirable that the considerations document go into more detail about what it= 's discussing.=A0 I think that's fine and probably true, and I'= ll do so for that document, but I don't think there's anything outs= tanding for this one.=A0 Do you agree?

-MSK
--089e013d19ccbd410c04e4e6e416-- From shawn.emery@oracle.com Tue Aug 27 22:20:56 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9091211E8140 for ; Tue, 27 Aug 2013 22:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMFL2qaXUgXB for ; Tue, 27 Aug 2013 22:20:50 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 139DD11E8128 for ; Tue, 27 Aug 2013 22:20:50 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7S5Kc3R028640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Aug 2013 05:20:39 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7S5Kbxv029613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Aug 2013 05:20:38 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7S5KbS5028004; Wed, 28 Aug 2013 05:20:37 GMT Received: from [10.159.72.16] (/10.159.72.16) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Aug 2013 22:20:36 -0700 Message-ID: <521D88D8.7020603@oracle.com> Date: Tue, 27 Aug 2013 23:21:28 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20130718 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <51CAA254.6040303@oracle.com> <52158CF5.4050001@oracle.com> <521591FA.20601@dcrocker.net> <52198E83.7050406@oracle.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050709070309020805090707" X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: draft-ietf-repute-query-http.all@tools.ietf.org, Dave Crocker , Dave Crocker , secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-repute-query-http-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 05:20:56 -0000 This is a multi-part message in MIME format. --------------050709070309020805090707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/26/13 11:10 PM, Murray S. Kucherawy wrote: > Hi Shawn, thanks for the review. > > On Sat, Aug 24, 2013 at 9:56 PM, Shawn M Emery > wrote: > > On 08/21/13 10:22 PM, Dave Crocker wrote: > > On 8/21/2013 9:00 PM, Shawn M Emery wrote: > > However, none of the > referenced RFCs and draft directly talk about the various > attacks and > how to mitigate against said attacks. > > > > Shawn, some clarification please: > > This is a simple query protocol, ableit yes one where the > data is > making trust assertions. > > A possible implication of your above comment is that all IETF > protocols should carry a threat analysis. Have I misunderstood? > > > Hi Dave, > > Sorry for not being specific. I will try to clarify my concerns: > > This draft references the reputation considerations draft when > providing or using reputation services, I assume in a security > context given that it is referenced in the security considerations > section. When I looked at the referenced draft's security > considerations section it stated that there are threats discussed > in the operation text above. I think that these types of > discussions deserve a separate section. If the topic is mostly > security it would be helpful to have a summary of the various > threats and how to mitigate. In any case, when looking through > the entire draft I do see some suggestions for clients and their RSPs. > > > > I'm still a little unclear about what the suggestion is here. Since > this review is specific to query-http, I take your feedback to mean > that query-http itself is fine, but it's desirable that the > considerations document go into more detail about what it's > discussing. I think that's fine and probably true, and I'll do so for > that document, but I don't think there's anything outstanding for this > one. Do you agree? Yes, that's pretty much it; that this draft or the referenced draft should have a consolidated list of the various security issues and guidance to counter them. Thanks, Shawn. -- --------------050709070309020805090707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 08/26/13 11:10 PM, Murray S. Kucherawy wrote:
Hi Shawn, thanks for the review.

On Sat, Aug 24, 2013 at 9:56 PM, Shawn M Emery <shawn.emery@oracle.com> wrote:
On 08/21/13 10:22 PM, Dave Crocker wrote:
On 8/21/2013 9:00 PM, Shawn M Emery wrote:
However, none of the
referenced RFCs and draft directly talk about the various attacks and
how to mitigate against said attacks.


Shawn, some clarification please:

   This is a simple query protocol, ableit yes one where the data is
making trust assertions.

   A possible implication of your above comment is that all IETF
protocols should carry a threat analysis.  Have I misunderstood?

Hi Dave,

Sorry for not being specific.  I will try to clarify my concerns:

This draft references the reputation considerations draft when providing or using reputation services, I assume in a security context given that it is referenced in the security considerations section.  When I looked at the referenced draft's security considerations section it stated that there are threats discussed in the operation text above.  I think that these types of discussions deserve a separate section.  If the topic is mostly security it would be helpful to have a summary of the various threats and how to mitigate.  In any case, when looking through the entire draft I do see some suggestions for clients and their RSPs.



I'm still a little unclear about what the suggestion is here.  Since this review is specific to query-http, I take your feedback to mean that query-http itself is fine, but it's desirable that the considerations document go into more detail about what it's discussing.  I think that's fine and probably true, and I'll do so for that document, but I don't think there's anything outstanding for this one.  Do you agree?

Yes, that's pretty much it; that this draft or the referenced draft should have a consolidated list of the various security issues and guidance to counter them.

Thanks,

Shawn.
--
--------------050709070309020805090707-- From kivinen@iki.fi Thu Aug 29 00:55:48 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382AB21F9FDA for ; Thu, 29 Aug 2013 00:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojO6klZGDUId for ; Thu, 29 Aug 2013 00:55:47 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id C40D221F9F12 for ; Thu, 29 Aug 2013 00:55:46 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r7T7tbns027522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 29 Aug 2013 10:55:37 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r7T7tZ9e022947; Thu, 29 Aug 2013 10:55:35 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21022.65143.608221.92128@fireball.kivinen.iki.fi> Date: Thu, 29 Aug 2013 10:55:35 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 07:55:48 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Warren Kumari is next in the rotation. For telechat 2013-08-29 Reviewer LC end Draft Dan Harkins TR2013-05-15 draft-ietf-6man-addr-select-opt-11 For telechat 2013-09-12 Dave Cridland T 2013-08-29 draft-ietf-repute-email-identifiers-08 Alan DeKok T 2013-08-29 draft-ietf-repute-media-type-10 Donald Eastlake T 2013-09-10 draft-ietf-repute-model-08 Phillip Hallam-Baker TR2013-09-02 draft-ietf-spfbis-4408bis-19 Simon Josefsson T 2013-09-02 draft-ietf-v6ops-mobile-device-profile-04 Charlie Kaufman T 2013-09-02 draft-ietf-v6ops-rfc3316bis-03 Sam Weiler T 2013-08-17 draft-ietf-homenet-arch-10 Last calls and special requests: Rob Austein 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Rob Austein 2013-08-29 draft-ietf-netext-update-notifications-07 Dave Cridland - draft-ietf-httpbis-p5-range-23 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-03-30 draft-ietf-roll-terminology-12 Phillip Hallam-Baker 2013-09-18 draft-boucadair-rfc6153-update-01 Steve Hanna 2013-09-02 draft-ietf-ccamp-gmpls-g709-framework-14 Dan Harkins 2013-09-02 draft-ietf-ccamp-gmpls-signaling-g709v3-11 David Harrington 2013-09-03 draft-ietf-dhc-dhcpv6-solmaxrt-update-03 Sam Hartman 2013-09-03 draft-ietf-mediactrl-call-flows-13 Jeffrey Hutzelman 2013-07-16 draft-yusef-dispatch-ccmp-indication-04 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-04 Jeffrey Hutzelman 2013-09-03 draft-ietf-mpls-targeted-mldp-03 Leif Johansson 2013-09-03 draft-ietf-pim-rfc4601-update-survey-report-02 Scott Kelly 2013-09-16 draft-kelsey-intarea-mesh-link-establishment-05 Tero Kivinen 2013-09-24 draft-cotton-rfc4020bis-01 Julien Laganier - draft-ietf-avtcore-rtp-security-options-04 Julien Laganier - draft-ietf-websec-key-pinning-08 Alexey Melnikov - draft-ietf-payload-rtp-howto-05 Vincent Roca 2013-08-21 draft-ietf-mpls-tp-mip-mep-map-08 Ondrej Sury 2013-08-16 draft-nandakumar-rtcweb-stun-uri-06 Carl Wallace 2013-08-16 draft-ietf-dime-overload-reqs-11 David Waltermire - draft-ietf-repute-considerations-02 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-12 Brian Weis - draft-ietf-radext-dtls-06 Glen Zorn 2012-11-27 draft-ietf-lisp-eid-block-04 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 -- kivinen@iki.fi From hallam@gmail.com Thu Aug 29 16:49:28 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB49F21F9FB7; Thu, 29 Aug 2013 16:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6M0KQ8PLb2hR; Thu, 29 Aug 2013 16:49:28 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id F1EC621F9F12; Thu, 29 Aug 2013 16:49:27 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ep20so954742lab.2 for ; Thu, 29 Aug 2013 16:49:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GcfpnGLjzuExgqJvWsRWQJJUNMZqgVgH+Ms3VqkVk8o=; b=Jtj/rxiONVQcY07GZJMzV2cuK7vmAGneVcNKryQ97zsBiMI69PTWbAxMp3Pf16VJUk YmO/Cw/rijebTT2X2p3WEGmcVDlrjv3J3Kx+jhWBruwcDym3FCvrbA3VcrRnAWBVmaX9 25GkqAtR42Z/As02JU6Id5lTq13P/g7Tr0sWvo6cfEQf6rjTYru/FPh2SAd8NGJcqbTY eeMRq+hMYVSywFCcSKgfUYrnnR/QSwjTujyOHaSVktylri4+J8HuqZPfUW44Gh+jtMN1 amElD0xxUb3ZM8/xcaYUgYLcyfoC2msSUBe+2TaMIoRdDjrlnR9+J7Wn9yvGVEBBMKHg pCSQ== MIME-Version: 1.0 X-Received: by 10.152.21.225 with SMTP id y1mr5167848lae.18.1377820166829; Thu, 29 Aug 2013 16:49:26 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Thu, 29 Aug 2013 16:49:26 -0700 (PDT) Date: Thu, 29 Aug 2013 19:49:26 -0400 Message-ID: From: Phillip Hallam-Baker To: "secdir@ietf.org" , "iesg@ietf.org" , draft-boucadair-rfc6153-update@tools.ietf.org Content-Type: multipart/alternative; boundary=089e0158b6bc9bbc9804e51ec15c Subject: [secdir] Secdir review of draft-boucadair-rfc6153-update-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 23:49:29 -0000 --089e0158b6bc9bbc9804e51ec15c Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document describes a fix to the allocation of DHCPv4 and DHCPv6 Options for Access Network Discovery which appears to be entirely determined by the needs of backwards compatibility. I found no security issues problems or comments. -- Website: http://hallambaker.com/ --089e0158b6bc9bbc9804e51ec15c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate= 9;s ongoing effort to review all IETF documents being processed by the IESG= .=A0 These comments were written primarily for the benefit of the security = area directors.=A0 Document editors and WG chairs should treat these commen= ts just like any other last call comments.

The documen= t describes a fix to the allocation of=A0DHCPv4 and DHCPv6 Options for Acce= ss Network Discovery which appears to be entirely determined by the needs o= f backwards compatibility.

I foun= d no security issues problems or comments.
--089e0158b6bc9bbc9804e51ec15c-- From charliek@microsoft.com Fri Aug 30 10:10:52 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E7E21F9E22; Fri, 30 Aug 2013 10:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q53R+HnOpgeB; Fri, 30 Aug 2013 10:10:14 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id BFF2F21F9FBA; Fri, 30 Aug 2013 10:09:59 -0700 (PDT) Received: from BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) by BL2PR03MB594.namprd03.prod.outlook.com (10.255.109.37) with Microsoft SMTP Server (TLS) id 15.0.745.25; Fri, 30 Aug 2013 17:09:57 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com ([169.254.11.169]) by BL2PR03MB592.namprd03.prod.outlook.com ([169.254.11.169]) with mapi id 15.00.0745.000; Fri, 30 Aug 2013 17:09:56 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-v6ofs-rfc3316bis@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-v6ops-rfc3316bis-03 Thread-Index: Ac6loXJjgnlzJzVlTyaEQMgolbnTmA== Date: Fri, 30 Aug 2013 17:09:56 +0000 Message-ID: <4776e66c43414501a1d0a1fe6eec7fca@BL2PR03MB592.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::4] x-forefront-prvs: 0954EE4910 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(46102001)(81542001)(83322001)(74662001)(19580395003)(47976001)(50986001)(74316001)(74502001)(81342001)(47446002)(81686001)(80976001)(31966008)(77096001)(56816003)(76576001)(74706001)(74366001)(51856001)(15202345003)(54356001)(15975445006)(53806001)(49866001)(4396001)(47736001)(33646001)(16236675002)(19300405004)(81816001)(69226001)(63696002)(80022001)(65816001)(56776001)(76482001)(54316002)(76176001)(83072001)(77982001)(59766001)(74876001)(79102001)(76786001)(76796001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB594; H:BL2PR03MB592.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::4; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_4776e66c43414501a1d0a1fe6eec7fcaBL2PR03MB592namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: [secdir] secdir review of draft-ietf-v6ops-rfc3316bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 17:10:52 -0000 --_000_4776e66c43414501a1d0a1fe6eec7fcaBL2PR03MB592namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This Informational (if approved) RFC is a cleanup update and refresh of RFC= 3316, which discusses how to implement IPv6 on 3GPP Cellular hosts. It inc= orporates several RFCs that have come out since RFC 3316 along with other c= larifications. There is a substantial Security Considerations section deali= ng with security considerations for dealing with a cellular environment, bu= t this document mostly references other RFCs and does not introduce any sec= urity issues of its own. Minor (non-security) issues: This document does not use the MUST and SHOULD conventions of most RFCs. I'= ve long believed these were inappropriate for Informational RFCs, but this = is the first time I've seen anyone agree with me and remove them. There are many places where referenced RFCs are not placed in brackets (e.g= . "RFC 5095" instead of [RFC5095]. I found 2 typos: Page 5: "build-in" -> "built-in" Page 17: "causes no hard" -> "causes no harm" --Charlie --_000_4776e66c43414501a1d0a1fe6eec7fcaBL2PR03MB592namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

This Informational (if approved) RFC is a cleanup up= date and refresh of RFC 3316, which discusses how to implement IPv6 on 3GPP= Cellular hosts. It incorporates several RFCs that have come out since RFC = 3316 along with other clarifications. There is a substantial Security Considerations section dealing with securi= ty considerations for dealing with a cellular environment, but this documen= t mostly references other RFCs and does not introduce any security issues o= f its own.

 

Minor (non-security) issues:

 

This document does not use the MUST and SHOULD conve= ntions of most RFCs. I’ve long believed these were inappropriate for = Informational RFCs, but this is the first time I’ve seen anyone agree= with me and remove them.

 

There are many places where referenced RFCs are not = placed in brackets (e.g. “RFC 5095” instead of [RFC5095].<= /o:p>

 

I found 2 typos:

Page 5: “build-in” -> “built-in= ”

Page 17: “causes no hard” -> “c= auses no harm”

 

        &nbs= p;       --Charlie

 

--_000_4776e66c43414501a1d0a1fe6eec7fcaBL2PR03MB592namprd03pro_-- From charliek@microsoft.com Fri Aug 30 14:06:52 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7ACB11E8111; Fri, 30 Aug 2013 14:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqdpCueaebkl; Fri, 30 Aug 2013 14:06:44 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0155.outbound.protection.outlook.com [207.46.163.155]) by ietfa.amsl.com (Postfix) with ESMTP id 98D4E21F9D18; Fri, 30 Aug 2013 14:06:43 -0700 (PDT) Received: from BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) by BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) with Microsoft SMTP Server (TLS) id 15.0.745.25; Fri, 30 Aug 2013 21:06:40 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com ([169.254.11.169]) by BL2PR03MB592.namprd03.prod.outlook.com ([169.254.11.169]) with mapi id 15.00.0745.000; Fri, 30 Aug 2013 21:06:39 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-v6ops-rfc3316bis@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-v6ops-rfc3316bis-03 Thread-Index: Ac6loXJjgnlzJzVlTyaEQMgolbnTmAAIyoPg Date: Fri, 30 Aug 2013 21:06:39 +0000 Message-ID: <628e03ee393949d388167e3fd31d5540@BL2PR03MB592.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::4] x-forefront-prvs: 0954EE4910 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(377454003)(54316002)(56776001)(16236675002)(47446002)(74662001)(74502001)(77982001)(74366001)(59766001)(19580405001)(76482001)(83322001)(74316001)(51856001)(31966008)(46102001)(33646001)(63696002)(83072001)(74876001)(15202345003)(74706001)(53806001)(19580395003)(54356001)(56816003)(77096001)(19300405004)(80022001)(65816001)(81816001)(69226001)(81686001)(79102001)(80976001)(47736001)(81542001)(50986001)(49866001)(76176001)(47976001)(76786001)(15975445006)(76796001)(81342001)(4396001)(76576001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB592; H:BL2PR03MB592.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::4; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_628e03ee393949d388167e3fd31d5540BL2PR03MB592namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: [secdir] secdir review of draft-ietf-v6ops-rfc3316bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 21:06:53 -0000 --_000_628e03ee393949d388167e3fd31d5540BL2PR03MB592namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resending with corrected mailing list name (if replying, please reply to th= is copy). From: Charlie Kaufman Sent: Friday, August 30, 2013 10:10 AM To: secdir@ietf.org; iesg@ietf.org; 'draft-ietf-v6ofs-rfc3316bis@tools.ietf= .org' Subject: secdir review of draft-ietf-v6ops-rfc3316bis-03 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This Informational (if approved) RFC is a cleanup update and refresh of RFC= 3316, which discusses how to implement IPv6 on 3GPP Cellular hosts. It inc= orporates several RFCs that have come out since RFC 3316 along with other c= larifications. There is a substantial Security Considerations section deali= ng with security considerations for dealing with a cellular environment, bu= t this document mostly references other RFCs and does not introduce any sec= urity issues of its own. Minor (non-security) issues: This document does not use the MUST and SHOULD conventions of most RFCs. I'= ve long believed these were inappropriate for Informational RFCs, but this = is the first time I've seen anyone agree with me and remove them. There are many places where referenced RFCs are not placed in brackets (e.g= . "RFC 5095" instead of [RFC5095]. I found 2 typos: Page 5: "build-in" -> "built-in" Page 17: "causes no hard" -> "causes no harm" --Charlie --_000_628e03ee393949d388167e3fd31d5540BL2PR03MB592namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Resending with correct= ed mailing list name (if replying, please reply to this copy).

 

From: Charlie = Kaufman
Sent: Friday, August 30, 2013 10:10 AM
To: secdir@ietf.org; iesg@ietf.org; 'draft-ietf-v6ofs-rfc3316bis@too= ls.ietf.org'
Subject: secdir review of draft-ietf-v6ops-rfc3316bis-03<= /span>

 

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

 

This Informational (if approved) RFC is a cleanup up= date and refresh of RFC 3316, which discusses how to implement IPv6 on 3GPP= Cellular hosts. It incorporates several RFCs that have come out since RFC = 3316 along with other clarifications. There is a substantial Security Considerations section dealing with securi= ty considerations for dealing with a cellular environment, but this documen= t mostly references other RFCs and does not introduce any security issues o= f its own.

 

Minor (non-security) issues:

 

This document does not use the MUST and SHOULD conve= ntions of most RFCs. I’ve long believed these were inappropriate for = Informational RFCs, but this is the first time I’ve seen anyone agree= with me and remove them.

 

There are many places where referenced RFCs are not = placed in brackets (e.g. “RFC 5095” instead of [RFC5095].<= /o:p>

 

I found 2 typos:

Page 5: “build-in” -> “built-in= ”

Page 17: “causes no hard” -> “c= auses no harm”

 

        &nbs= p;       --Charlie

 

--_000_628e03ee393949d388167e3fd31d5540BL2PR03MB592namprd03pro_-- From ietfdbh@comcast.net Sat Aug 31 08:46:07 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8861D21F9B18 for ; Sat, 31 Aug 2013 08:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8fW5gI2+Qhh for ; Sat, 31 Aug 2013 08:46:01 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC0A21F99DD for ; Sat, 31 Aug 2013 08:46:01 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta06.westchester.pa.mail.comcast.net with comcast id KSEp1m0011YDfWL56Tm1SQ; Sat, 31 Aug 2013 15:46:01 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta20.westchester.pa.mail.comcast.net with comcast id KTm01m00b2yZEBF3gTm0G1; Sat, 31 Aug 2013 15:46:01 +0000 From: "ietfdbh" To: , , Date: Sat, 31 Aug 2013 11:46:00 -0400 Message-ID: <017901cea661$313309b0$93991d10$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6mXFvpdp2QCrMlQbuC7It9OmMcYg== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377963961; bh=7ULXZdzbiBbRwEWcv+1q/CWMKDONH/QZluwdnIhUQjo=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=mSgyrSG3wA/ASH4ivs2rwPbPpFF1K+Do2tOMCoW5Z64ZgJWrMtcsmd76Cb+h7gPSL pmCZmX9odX4aD1A6RoVG0+Ccl9kq0UBT9FHiEJ9wJw75arPGSg/wHtPNc71XSU60C9 fzhv96IhcPs3qlEXZicPdwLPIs0SZNwOJkffFTBpOfl4uuhxPQScmvL2CedImzmq1f IvoWmRRjHDP+MBVqzEeC3pnGME0zW0p9pe8W2DS3U2Ufyk/yfeKURK9XeHD3FsNztB kJi1J95eKWIa8oPCh1yeDLjxlELU2kwdJ7/Xs6lvNwIfYoVVkl0defDl2RXR+xB8SH GK3ke6lDr7cTA== Subject: [secdir] secdir review of draft-ietf-dhc-dhcpv6-solmaxrt-update-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 15:46:07 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document describes a change to the values of DHCPv6 Options for Solicit and Information timeout values (SOL_MAX_RT and INF_MAX_RT). I am not very knowledgeable about DHCPv6 options, but I have a few questions. 1) section 6 says " the client MUST process an included SOL_MAX_RT option and/or an included INF_MAX_RT option"; this could be interpreted as OR even if both are present. Hopefully no implementer would make that choice, but they could claim compliance if they did. It would be tighter to say they MUST process SOL-MAX-RT and MUST process INF_MAX_RT ... 2) section 7 says " A DHCPv6 client MUST include the SOL_MAX_RT option code in an Option Request option [RFC3315] in any message it sends." Is this really required for every message? 3) if #2 is true, then section 8 seems to have some unnecessary conditionals. "the server will send option SOL_MAX_RT and INF_MAX_RT only if .... the client requested those options ...". Doesn't section 7 say the client is REQUIRED to request these options? 4) similar to question #3, in section 8 paragraph 2, the server responds to " a client that has included the SOL_MAX_RT option code in an Option Request option"; doesn't section 7 REQUIRE that the client include this? Ditto for paragraph 3 and INF_MAX_RT? 5) In security considerations, the potential security **impact** of a malicious server setting a high value isn't discussed. 6) On a related note to #5, are there operational considerations if a DHCPv6 server choose to set an arbitrarily high value? Could there be economic benefit for a server to do this, leading some requesters to use a different server either for load-balancing or servicing only priority customers? What impact could such behavior create in a network that an operator should consider? 7) In IANA considerations, you define OPTION_SOL_MAX_RT and OPTION_INF_MAX_RT, but discussion of sending these options in sections 7 and 8 don't mention these codes; they refer only to SOL_MAX_RT and SOL_MAX_RT. I don't know much about registering DHCP options; is this correct? David Harrington ietfdbh@comcast.net +1-603-828-1401 From new-work-bounces@ietf.org Fri Aug 30 09:53:16 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5891221E80F0; Fri, 30 Aug 2013 09:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1377881596; bh=EitSczePfnLdPTeZG5pbeiHBaOaRZBjDs3UiAI96O+o=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=KU50VyybrFO1u/pvMpXI5vrcvi2tDYsvPtS9ITFp4SQfGcYZZvkDOD3ewNok5coTg j9zFRVTUHR6rV7iLqfJZ1XJDK/HDX6WNR9YsSCHtF12w6hL9Su3ENkI7QixbbdqgCX XJhoQXqhO8b7xoMqyuXwbdWI4/wG/QV4bbC5f7J4= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377F221E80AA; Fri, 30 Aug 2013 09:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELz1HTMjimM3; Fri, 30 Aug 2013 09:53:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC19321E805F; Fri, 30 Aug 2013 09:53:13 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130830165313.5104.89450.idtracker@ietfa.amsl.com> Date: Fri, 30 Aug 2013 09:53:13 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Sat, 31 Aug 2013 08:49:53 -0700 Subject: [secdir] [new-work] WG Review: Dynamic Host Configuration (dhc) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 16:53:16 -0000 The Dynamic Host Configuration (dhc) working group in the Internet Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-09-09. Dynamic Host Configuration (dhc) ------------------------------------------------ Current Status: Active WG Chairs: Bernie Volz Tomek Mrugalski Assigned Area Director: Ted Lemon Mailing list Address: dhcwg@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dhcwg Archive: http://www.ietf.org/mail-archive/web/dhcwg/ Charter: Proposed Updated DHC WG Charter (August 26, 2013) ------------------------------------------------- The Dynamic Host Configuration working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a Draft Standard and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a Proposed Standard and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. The DHC WG is responsible for defining DHCP protocol extensions. Definitions of new DHCP options that are delivered using standard mechanisms with documented semantics are not considered a protocol extension and thus are outside of scope for the DHC WG. Such options should be defined within their respective WGs and reviewed by the DHCP Directorate. However, if such options require protocol extensions or new semantics, the protocol extension work must be done in the DHC WG. The DHC WG has the following main objectives: 1. Develop extensions to the DHCPv6 infrastructure as required to meet new applications and deployments of DHCP. The topics currently in development are: - DHCPv6 Failover, High Availability and Load Balancing - Extend DHCPv6 to work with multiple provisioning domains - DHCP provisioning of IPv4 clients over IPv6 networks - SOLMAXRT counter update - Container option - Access Network Identifier - DNS registration for SLAAC Additional topics may only be added with approval from the responsible Area Director or by re-chartering. 2. Develop a replacement for OPTION_NTP_SERVER (RFC 5908). The DHC working group will develop this option, taking input from the NTP working group during the development process. Last call on this option will be done in the DHC working group. 3. Specify guidelines for creating new DHCPv6 options. 4. Develop documents that help explain operational considerations for the wider community. 5. Issue updated versions of the DHCP base specifications-- RFC 3315 (DHCPv6), RFC 3633 (DHCPv6 Prefix Delegation) and RFC 3736 (Stateless DHCPv6) so as to fix errata and bring the documents to the point where they can advance along the IETF Standards Track. 6. In the process of updating the DHCP base specifications, in cases where time is of the essence, issue corrections and clarifications of the specifications in order to quickly address interoperability problems. 7. Write analyses and interoperability reports on existing DHC documents, including base specs. 8. When serious interoperability problems are found in other DHCP specifications, issue updated versions of those problems to address the interoperability problems. Milestones: Done - WG Last Call on DHCP Options for Internet Storage Name Service (draft-ietf-dhc-isnsoption-03.txt) Done - WG Last Call on Load Balancing for DHCPv6 (draft-ietf-dhc-dhcpv6-loadb-02.txt) Done - WG Last Call on Time Configuration Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt) Done - WG Last Call on IPv6 Prefix Options for DHCPv6 (draft-troan-dhcpv6-opt-prefix-delegation-02.txt) Done - WG Last Call on DNS Configuration options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt) Done - WG Last Call on NIS Configuration Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt) Done - Resubmit draft-ietf-dhc-dhcpv6-28.txt to IESG Done - Identify DHCPv4 authentication design team Done - Identify DHCPv4 specification review design team Done - Identify DHCPv4 relay agent message authentication design team Done - Submit DHCP Options for Internet Storage Name Service to IESG (draft-ietf-dhc-isnsoption) Done - Submit DNS Configuration options for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-opt-dnsconfig) Done - Submit NIS Configuratio Options for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-opt-nisconfig) Done - Submit IPv6 Prefix Options for DHCPv6 to IESG (draft-troan-dhcpv6-opt-prefix-delegation) Done - Submit 'Detection of Network Attachment (DNA) in IPv4' to IESG (draft-ietf-dhc-dna-ipv4) Done - Resolve IPR issues around 'Rapid Commit Option for DHCPv4' Done - Publish report on dual-stack issues in DHCP (draft-ietf-dhc-dual-stack) Done - Publish report on requirements for renumbering using stateless DHCPv6 (draft-ietf-dhc-stateless-dhcpv6-renumbering) Done - Submit 'Lifetime Option for DHCPv6' to IESG (draft-ietf-dhc-lifetime) Done - Submit 'Rapid Commit Option for DHCPv4' to IESG (draft-ietf-dhc-rapid-commit-opt) Done - Submit DDNS/DHCP documents to IESG Done - Submit 'Node-Specific Client Identifiers for DHCPv4' to IESG (draft-ietf-dhc-3315id-for-v4) Done - WG last call for 'Subnet Allocation Option' Done - WG last call on 'Virtual Subnet Selection Option' Oct 2007 - Submit 'Subnet Allocation Option' (draft-ietf-dhc-subnet-alloc-04) to IESG for Proposed Standard Nov 2007 - WG last call on 'Guidelines for Creating New DHCP Options' (draft-ietf-dhc-option-guidelines) Nov 2007 - Submit 'Virtual Subnet Selection Option', (draft-ietf-dhc-vpn-option) and (draft-ietf-dhc-agent-vpn-id) to IESG for Proposed Standard Dec 2007 - WG last call for 'Domain Suffix Option for DHCPv6' (draft-ietf-dhc-dhcpv6-opt-dnsdomain) Jan 2008 - Submit 'Domain Suffix Option for DHCPv6' (draft-ietf-dhc-dhcpv6-opt-dnsdomain) to IESG for Proposed Standard Jan 2008 - Submit 'Guidelines for Creating New DHCP Options' (draft-ietf-dhc-option-guidelines) to IESG for Best Current Practice Jan 2008 - Develop plan for advancing DHCPv4 and DHCPv6 plan to include completion of DHCPv4 specification review report, 'Implementation Issues with RFC 2131' (draft-ietf-dhc-implementation) for Informational Feb 2008 - WG last call for 'Status of Reclassifying DHCPv4 Options' (draft-ietf-dhc-status-3942) Feb 2008 - WG last call for 'Dual-stack clients and merging of data from DHCPv4 and DHCPv6' (draft-ietf-dhc-dual-stack-merge); waiting for more experience with IPv6 deployment Feb 2008 - WG last call for 'Rebind Capability in DHCPv6 Reconfigure Messages' (draft-ietf-dhc-dhcpv6-reconfigure-rebind) Mar 2008 - Submit 'Status of Reclassifying DHCPv4 Options' (draft-ietf-dhc-status-3942) to IESG for Informational Apr 2008 - 2nd WG last call for 'DHCP Relay Agent Assignment Notification Option (draft-ietf-dhc-dhcpv6-agentopt-delegate) and 'DHCPv6 Server Reply Sequence Number Option' (draft-ietf-dhc-dhcpv6-srsn-option) May 2008 - Submit 'Rebind Capability in DHCPv6 Reconfigure Messages' (draft-ietf-dhc-dhcpv6-reconfigure-rebind) to IESG for Proposed Standard Jun 2008 - WG last call on 'Layer 2 Relay Agent Behaviour' (draft-ietf-dhc-layer2-relay-agent) Jul 2008 - Submit 'Layer 2 Relay Agent Behaviour' to IESG (draft-ietf-dhc-layer2-relay-agent) for Informational Jul 2008 - Submit 'DHCP Relay Agent Assignment Notification Option' (draft-ietf-dhc-dhcpv6-agentopt-delegate) and 'DHCPv6 Server Reply Sequence Number Option' (draft-ietf-dhc-dhcpv6-srsn-option) to IESG for Proposed Standard Jul 2008 - Recharter, if needed _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From jouni.nospam@gmail.com Sat Aug 31 12:46:21 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D4321F9B92; Sat, 31 Aug 2013 12:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwb5F1PF1mqE; Sat, 31 Aug 2013 12:46:20 -0700 (PDT) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 093FC21F8495; Sat, 31 Aug 2013 12:46:19 -0700 (PDT) Received: by mail-ea0-f179.google.com with SMTP id b10so1543256eae.38 for ; Sat, 31 Aug 2013 12:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1pucwzl3rqlJhWA4hyx/+Ch8ZvDxojyp+TTywSbk31E=; b=EBWpkaPRgvYSWTHlqvVWGXCu/YiWjo+7bbXF1jGBfnUffWdkqmH8VqK5fmMne1z/d5 ZdN9lrAafMKqE2WiDWHeSUGw85+tYyO6/qdrYBT152qDw0wV46IvAKWfrpHBXahfVpOg opygb/0UTJ7/5CruZYe69IpwVZFHZ6yTs8nJ7fhBb8lnKbh1hxbJ/nFaxZRqsFJzziHf n7WdXY+67r+4PsA4E77fodNgtQR9D+NT0EI5zk6U4DfzXf74MnXkaWY4qYrRmMU8pj4z 9PIWu3X+3URhC2vdOQzhNTj/xXiXFfL/tsuAXljOiORIxiBvafEJwU/Cj0Rw33ESX/HB 1Zbw== X-Received: by 10.14.174.195 with SMTP id x43mr5640064eel.47.1377978378038; Sat, 31 Aug 2013 12:46:18 -0700 (PDT) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id j7sm7521887eeo.15.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 Aug 2013 12:46:17 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: <628e03ee393949d388167e3fd31d5540@BL2PR03MB592.namprd03.prod.outlook.com> Date: Sat, 31 Aug 2013 22:46:19 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <628e03ee393949d388167e3fd31d5540@BL2PR03MB592.namprd03.prod.outlook.com> To: Charlie Kaufman X-Mailer: Apple Mail (2.1508) Cc: "draft-ietf-v6ops-rfc3316bis@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-v6ops-rfc3316bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 19:46:21 -0000 Thanks Charlie for the review. I have corrected the references and the = typos. They are actually already visible in the github in-progress = version: = https://github.com/jounikor/draft-ietf-v6ops-rfc3316bis/blob/master/draft-= ietf-v6ops-rfc3316bis-04.txt - JOuni On Aug 31, 2013, at 12:06 AM, Charlie Kaufman = wrote: > Resending with corrected mailing list name (if replying, please reply = to this copy). > =20 > From: Charlie Kaufman=20 > Sent: Friday, August 30, 2013 10:10 AM > To: secdir@ietf.org; iesg@ietf.org; = 'draft-ietf-v6ofs-rfc3316bis@tools.ietf.org' > Subject: secdir review of draft-ietf-v6ops-rfc3316bis-03 > =20 > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. > =20 > This Informational (if approved) RFC is a cleanup update and refresh = of RFC 3316, which discusses how to implement IPv6 on 3GPP Cellular = hosts. It incorporates several RFCs that have come out since RFC 3316 = along with other clarifications. There is a substantial Security = Considerations section dealing with security considerations for dealing = with a cellular environment, but this document mostly references other = RFCs and does not introduce any security issues of its own. > =20 > Minor (non-security) issues: > =20 > This document does not use the MUST and SHOULD conventions of most = RFCs. I=92ve long believed these were inappropriate for Informational = RFCs, but this is the first time I=92ve seen anyone agree with me and = remove them. > =20 > There are many places where referenced RFCs are not placed in brackets = (e.g. =93RFC 5095=94 instead of [RFC5095]. > =20 > I found 2 typos: > Page 5: =93build-in=94 -> =93built-in=94 > Page 17: =93causes no hard=94 -> =93causes no harm=94 > =20 > --Charlie > =20 From simon@josefsson.org Sat Aug 31 14:21:31 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BA611E8191; Sat, 31 Aug 2013 14:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jw28yTo0qEaL; Sat, 31 Aug 2013 14:21:31 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id D93F811E8190; Sat, 31 Aug 2013 14:21:30 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r7VLLQQ1026585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 31 Aug 2013 23:21:28 +0200 Date: Sat, 31 Aug 2013 23:21:25 +0200 From: Simon Josefsson To: secdir@ietf.org, iesg@ietf.org, draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org Message-ID: <20130831232125.19f0ceb6@latte.josefsson.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Subject: [secdir] secdir review of draft-ietf-v6ops-mobile-device-profile-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 21:21:31 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This (informational) document list a set of features a 3GPP device is supposed to be compliant with. The document contain pointers to other protocols/specifications which contains the real security considerations for those protocols. As such, I don't think there could be any significant security issue with this document. Hence my take is that the document is Ready with nits (see below). A notable point is that there is no discussion or references to IPSec in the document, nor any of the IPv6 "bugs" (e.g., RFC 5722 and RFC 6946). There may be other document that could be referenced that would lead to improved security, but it is hard to list them all. This document seems related to draft-ietf-v6ops-rfc3316bis which describe another IPv6 profile for 3GPP hosts. The utility of having two different IPv6 profiles for 3GPP hosts could be discussed, but it is only a security issue in the marginal sense that complexity often leads to poor security. The security considerations of this document is only pointers to the security considerations of RFC3316bis, RFC6459, and RFC6092 which feels underwhelming to me -- especially since the RFC3316bis security consideration is for the particular profile that RFC3316bis defines. The security considerations of RFC3316bis wouldn't automatically apply to the profile defined by draft-ietf-v6ops-mobile-device-profile since the profiles are different. Other notes: * The document uses RFC 2119 language "for precision", although I don't understand what it means for an Informational document to contain MUST languages. * The document really really should reference RFC 2460. * The security consideration contains normative text (REQ#34) that typically go into the core part of a document. * I found REQ#32 a bit too generalized. I believe it is common for applications to be aware of whether connections are over IPv4 or IPv6 and behave differently. >REQ#32: Applications MUST be independent of the underlying IP > address family. This means applications must be IP version > agnostic. /Simon