From simon.perreault@viagenie.ca Wed Jun 30 14:33:33 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EAE13A696B; Wed, 30 Jun 2010 14:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNCBXMhXIgz5; Wed, 30 Jun 2010 14:33:31 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by core3.amsl.com (Postfix) with ESMTP id 281433A6873; Wed, 30 Jun 2010 14:33:31 -0700 (PDT) Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D428920D1B; Wed, 30 Jun 2010 17:33:41 -0400 (EDT) Message-ID: <4C2BB835.5070601@viagenie.ca> Date: Wed, 30 Jun 2010 17:33:41 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Richard L. Barnes" References: <188D3671-05E9-40A2-9498-24BAE91B269E@bbn.com> <4BBBD185.7090606@viagenie.ca> <47C35048-FF47-4E92-821B-6EB21343B9B1@bbn.com> In-Reply-To: <47C35048-FF47-4E92-821B-6EB21343B9B1@bbn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 01 Jul 2010 06:04:23 -0700 Cc: draft-ietf-behave-turn-ipv6@tools.ietf.org, "behave@ietf.org" , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-behave-turn-ipv6-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 21:33:33 -0000 On 06/25/2010 02:49 PM, Richard L. Barnes wrote: > I think it makes sense to describe the attack here, because it's not the > same as the Usenix attack. Here's how it works. Consider the following > setup: > > +--------------------------------+ > | | > | 2001:DB8::1 2001:DB8::2 | > +-----------------+ +------------+ > | Tunnel Endpoint | | TURN Relay | > +-----------------+ +------------+ > | 192.0.2.1 192.0.2.2 | > | | > +--------------------------------+ > > Suppose an attacker knows that a tunnel endpoint will forward > encapsulated packets from a given IPv6 address (this doesn't necessarily > need to be the tunnel endpoint's address). Suppose he then spoofs two > packets from this address: > 1. An allocate request asking for a v4 address, and > 2. A ChannelBind request establishing a channel to the IPv4 address of > the tunnel endpoint > > Then he has set up an amplification attack: > -- The TURN relay will re-encapsulate IPv6 UDP data in v4 and send it to > the tunnel endpoint > -- The tunnel endpoint will decapsulate packets from the v4 interface > and send them to v6 > So if the attacker sends a packet of the following form... > > IPv6: src=2001:DB9::1 dst=2001:DB8::2 > UDP: > TURN: > IPv6: src=2001:DB9::1 dst=2001:DB8::2 > UDP: > TURN: > IPv6: src=2001:DB9::1 dst=2001:DB8::2 > UDP: > TURN: > ... > > Then the TURN relay and the tunnel endpoint will send it back and forth > until the last TURN header is consumed, at which point the TURN relay > will send an empty packet, which the tunnel endpoint will drop. > > The amplification potential here is limited by the MTU, so it's not > huge: IPv6+UDP+TURN takes 334 bytes, so you could get a four-to-one > amplification out of a 1500-byte packet. But the attacker could still > increase traffic volume by sending multiple packets or by establishing > multiple channels spoofed from different addresses behind the same > tunnel endpoint. > > This attack is kind of like the TURN loop attack in RFC 5766 (which > definitely still applies here!), but nicer for the attacker, since the > attacker never needs to see the response to a spoofed packet, since he > doesn't care about the relayed-transport address. Thanks, I understand now. I'll include a summary of the attack in the text. > I think the moral here is that TURN relays shouldn't be involved in > tunnels -- no need for two v4/v6 compatibility measures at once. So I > would suggest the document say something like: > " > It is RECOMMENDED that TURN relays not accept allocation or channel > binding requests from addresses known to be tunneled, and that they not > forward data to such addresses. In particular, a TURN relay MUST NOT > accept Teredo or 6to4 addresses in these requests. > " Agreed. Thanks, Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From jan.melen@ericsson.com Thu Jul 1 06:02:13 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6DEA3A67EA; Thu, 1 Jul 2010 06:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.87 X-Spam-Level: X-Spam-Status: No, score=-3.87 tagged_above=-999 required=5 tests=[AWL=-1.271, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Or7X1xNl9S4O; Thu, 1 Jul 2010 06:02:12 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 60DE63A67D0; Thu, 1 Jul 2010 06:02:10 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-33-4c2c91dd28c5 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0F.89.19600.DD19C2C4; Thu, 1 Jul 2010 15:02:21 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jul 2010 15:02:21 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jul 2010 15:02:20 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7CD3A2372; Thu, 1 Jul 2010 16:02:20 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 438D14F268; Thu, 1 Jul 2010 16:02:20 +0300 (EEST) Received: from esealmw967.eemea.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9ECB04E74E; Thu, 1 Jul 2010 16:02:19 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-55--965571591; protocol="application/pkcs7-signature"; micalg=sha1 From: Jan Melen In-Reply-To: Date: Thu, 1 Jul 2010 16:02:18 +0300 Message-Id: References: To: David McGrew X-Mailer: Apple Mail (2.1081) X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 01 Jul 2010 13:02:20.0887 (UTC) FILETIME=[A425AE70:01CB191D] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Thu, 01 Jul 2010 06:04:23 -0700 Cc: "draft-ietf-hip-hiccups.all@tools.ietf.org" , IESG , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-hip-hiccups-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 13:02:14 -0000 --Apple-Mail-55--965571591 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for review. I will submit a new version as soon as I have gone = through all the other review comments from other reviewers. On Jun 15, 2010, at 12:38 AM, David McGrew wrote: > I have reviewed this document as part of the security directorate's =20= > ongoing effort to review all IETF documents being processed by the =20 > IESG. These comments were written primarily for the benefit of the =20= > security area directors. Document editors and WG chairs should treat =20= > these comments just like any other last call comments. >=20 > There are several points where the draft could be made more clear, =20 > some of which might impact security. I've listed those below, =20 > intermingled with some nits. >=20 > Abstract and Section 1. "secure" is used where "authenticated" would =20= > be better, since this protocol does not provide any confidentiality =20= > services or encryption. >=20 Changed as proposed > RFC 4949 lists "message integrity code (MIC)" as a deprecated term, =20= > but this term is defined and used. In this case what is meant is =20 > "collision-resistant hash"; that phrase should be used in Sections 2 =20= > and 7. "Checksum" is an inappropriate term for a collision-resistant =20= > hash and it should be replaced in Section 4. For the security =20 > considerations section: does the hash need strong collision-=20 > resistance, or just second preimage resistance (also called weak =20 > collision-resistance)? Replaced with collision-resistance and added preimage requirements to = security considerations. > Section 4 nits: "with help of MIC." -> "with the help of the MIC." > "HIP DATA packet"-> "The HIP DATA packet" > "Hash algorithm used to generate MIC is same " -> "The hash algorithm =20= > used to generate the MIC is the same " Done >=20 > Section 4.1. I suggest emphasizing the requirement for the "Sequence =20= > Number" fields in distinct SEQ_DATA parameters to be distinct. >=20 Done > Section 4.3. says "Payload Data 8 last bytes of the payload data over =20= > which the MIC is calculated. This field is used to uniquely bind =20 > PAYLOAD_MIC parameter to next header, in case there are multiple =20 > copies of same type." It seems to me that this uniqueness is not =20 > guaranteed, but that if the last-8-bytes is not unique, the MIC =20 > verification process would fail, but that there is no way that an =20 > attacker could exploit this fact. I suggest noting this property in =20= > the security considerations. >=20 Added to Security considerations > Section 4.3: The PAYLOAD_MIC parameter has a field called "Payload =20 > MIC". It would be less confusing if the latter was called "MIC Value" = =20 > or some other named that is distinct from the parameter name. Done > Section 4.3 nit: "Identifies the data that protected by this MIC." add = =20 > "is". Done. > Section 5.1 nit: "A HIP DATA packet MUST contain SEQ_DATA or ACK_DATA =20= > parameter if both parameters are missing then packet MUST be dropped =20= > as invalid." -> "A HIP DATA packet MUST contain either a SEQ_DATA or =20= > ACK_DATA parameter; if both parameters are missing, then the packet =20= > MUST be dropped as invalid." Done. > Section 5.2 says "The receiver MUST validate these MICs." It should =20= > also describe how to validate them, and S 5.3 would be a more =20 > appropriate place to detail that process. That is already defined in 5.3.1 so I added reference to that. > Section 5.2 says " ... no SEQ_DATA sequence number is reused before =20= > the receiver has closed the processing window for the previous packet =20= > using the same SEQ_DATA sequence number." Important question: what =20= > enables the receiver to tell the difference? I assume that there are = =20 > some other fields (e.g. nonces) associated with the connection that =20= > might serve this purpose; if that is right, I suggest documenting that = =20 > fact. It can be easily checked by comparing the MIC value and I added also a = statement on that to section 5.3.1. Regards, Jan --Apple-Mail-55--965571591 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEJzCCBCMw ggMLoAMCAQICEBcym0rvC4ysd7OuULv1nZMwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0wOTA4MTMwNzAx MjZaFw0xMjA4MTMwNzAxMjRaMGAxETAPBgNVBAoMCEVyaWNzc29uMRIwEAYDVQQDDAlKYW4gTWVs ZW4xEDAOBgNVBAUTB2xtZmptZ20xJTAjBgkqhkiG9w0BCQEWFmphbi5tZWxlbkBlcmljc3Nvbi5j b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJMm59CngqBfJmkbsn3BqfjoMPGBvrNecqG5 fwqLxxyxt4Gs9lNM4rt/bDx1mkXe/IvVdEwYa07vha4OMCKVEMS2n3M07vMvHODqEgKNBYYxXx1D VkdAxHFLoEHIjG8twhbQA80vO/A8spxbabBVDbV/SQbQCTGYB00pZ7QFe8qDAgMBAAGjggGCMIIB fjCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9Fcmlj c3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVzdC50ZWxpYS5jb20vY249 RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nzb24/Y2VydGlmaWNhdGVy ZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAhBgNVHREEGjAYgRZqYW4ubWVsZW5AZXJpY3Nzb24u Y29tMEYGA1UdIAQ/MD0wOwYGKoVwawEBMDEwLwYIKwYBBQUHAgEWI2h0dHA6Ly93d3cuZXJpY3Nz b24uY29tL2xlZ2FsLnNodG1sMB0GA1UdDgQWBBSyqywTA2aW8THpjWat4NxGgZDw7zAfBgNVHSME GDAWgBSWJ8O43qVfXUQ+OVLlRbF2X2MwmzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQAD ggEBAC1qz1fyRs2hKzFsvp8FZBxHbsBZn2mDlyt/hSWaZxNfuVoD5YfRkhep5FJrTksF0aM7kxN8 0NdqydRgtn0UWuwwfwguHqlv7gDnMlkVa2zy/6xyl8TahFskC8/3KHbeTBTvzvZ6FS6K1bHZqzWc d92JvBoq4aMloDnqjVoPbs3Cw5MMiLlQyBZVGe2qixv8pziwvyWnj1/UBgL9tBnqihMbJyDPA1Sq 2jC27m6uq3W1IVLmFGIO7DKD1vxVcwGZK9Zh73jkwBzV/B4KoyJOBYKaTUd1nqauRHR26kITQwK3 MBHKTuaEXPSwrmHs098GqPHj7SRPl2ZwIWB9LupJW8AxggISMIICDgIBATBNMDkxETAPBgNVBAoM CEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEBcym0rvC4ys d7OuULv1nZMwCQYFKw4DAhoFAKCCARswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTAwNzAxMTMwMjE5WjAjBgkqhkiG9w0BCQQxFgQUY0T/sF1w69yBz7lakJfTG/4B 1wEwXAYJKwYBBAGCNxAEMU8wTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQTAxAhAXMptK7wuMrHezrlC79Z2TMF4GCyqGSIb3DQEJEAILMU+g TTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QTAxAhAXMptK7wuMrHezrlC79Z2TMA0GCSqGSIb3DQEBAQUABIGAB1Q1KFRo/OAs5GlDkaw0cEAx klixJ5sBXsUD3l06/Am6S6DMlckoL9FmRQDDp4x1TT9z2UR8rxxA83NhnRn5vCFR1S009r271u5v 6Qc1i44sFN3mICw0m+r64+jHfTqObqt4NVgPxKMYwXwlrxQDoFloycVBJQ7kcNNgF5Svr1gAAAAA AAA= --Apple-Mail-55--965571591-- From weiler+secdir@watson.org Thu Jul 1 08:46:55 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7273A698F for ; Thu, 1 Jul 2010 08:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnoDOfiPaJU9 for ; Thu, 1 Jul 2010 08:46:54 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id B343E3A6895 for ; Thu, 1 Jul 2010 08:46:54 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o61Fl5X2066618 for ; Thu, 1 Jul 2010 11:47:05 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o61Fl5GG066615 for ; Thu, 1 Jul 2010 11:47:05 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 1 Jul 2010 11:47:05 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 01 Jul 2010 11:47:05 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 15:46:56 -0000 Stephen Farrell is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2010-07-15 (please complete by Friday, 9 July) Sandy Murphy T 2010-07-13 draft-ietf-csi-proxy-send-04 Yaron Sheffer TR2010-07-13 draft-ietf-nsis-tunnel-11 Larry Zhu T 2010-07-13 draft-ietf-opsawg-mpls-tp-oam-def-06 Last calls and special requests: Derek Atkins 2010-07-09 draft-ietf-avt-forward-shifted-red-05 Rob Austein 2010-07-12 draft-ietf-forces-applicability-09 Richard Barnes 2010-07-12 draft-ietf-ipsecme-roadmap-07 Pat Cain 2010-07-12 draft-ietf-pkix-certimage-08 Dave Cridland 2010-07-09 draft-ietf-v6ops-v6inixp-08 Alan DeKok 2010-07-12 draft-ietf-forces-implementation-report-02 Donald Eastlake 2010-07-12 draft-ietf-isis-ipv6-te-07 Shawn Emery 2010-07-14 draft-ietf-ippm-twamp-reflect-octets-07 Love Hornquist-Astrand 2010-04-07 draft-ietf-eai-mailinglist-07 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Stefan Santesson 2010-07-07 draft-ietf-proto-wgdocument-states-07 Tina TSOU 2010-07-09 draft-mcgrew-fundamental-ecc-03 Sam Weiler 2010-07-12 draft-ietf-v6ops-rogue-ra-01 Brian Weis 2010-07-16 draft-daboo-srv-caldav-05 Nico Williams 2010-07-16 draft-turner-suiteb-cmc-03 Tom Yu 2010-07-08 draft-ietf-netmod-yang-usage-07 Kurt Zeilenga 2010-07-23 draft-hammer-hostmeta-13 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-07 Glen Zorn 2010-07-26 draft-cakulev-mikey-ibake-01 From Sandra.Murphy@cobham.com Thu Jul 1 17:30:47 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E59523A659C; Thu, 1 Jul 2010 17:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.523 X-Spam-Level: X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[AWL=1.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NieFJ1FUSJx; Thu, 1 Jul 2010 17:30:45 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id DEE013A6837; Thu, 1 Jul 2010 17:30:44 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o620Um8Z031423; Thu, 1 Jul 2010 19:30:49 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o620Um1I008913; Thu, 1 Jul 2010 19:30:48 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 20:30:47 -0400 Date: Thu, 1 Jul 2010 20:30:45 -0400 (Eastern Daylight Time) From: Sandra Murphy To: iesg@ietf.org, secdir@ietf.org, draft-ietf-csi-proxy-send.all@tools.ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1382430996-12988-1278029505=:9620" X-OriginalArrivalTime: 02 Jul 2010 00:30:47.0855 (UTC) FILETIME=[D104CBF0:01CB197D] Subject: [secdir] secdir review of draft-ietf-csi-proxy-send-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 00:30:48 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1382430996-12988-1278029505=:9620 Content-Type: TEXT/PLAIN; CHARSET=X-UNKNOWN; FORMAT=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE This is a review of draft draft-ietf-csi-proxy-send-04.txt. I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the IESG.=20 These comments were written primarily for the benefit of the security area= =20 directors. Document editors and WG chairs should treat these comments just= =20 like any other last call comments. This document provides new Neighbor Discovery options that will secure=20 proxied Neighbor Discovery messages. It is an update to: RFC4861: Neighbor Discovery in IPv6 RFC4389: Neighbor Discovery Proxies (ND Proxy) RFC3971: Send Neighbor Discovery (SEND) This draft relies on draft draft-ietf-csi-send-cert-04.txt. The need for new mechanisms for security for proxied messages is explained= =20 in draft-ietf-csi-sndp-prob-04.txt. I've read all of these, but it is pretty new to me, so I could have missed= =20 something. The Neighbor Discovery protocol communicates link-level addresses in the=20 protocol messages. The ND Proxy extension would make changes to those=20 fields. SEND, which secures the base ND protocol, relies on the sender of= =20 a message computing a signature associated with the source IP address of=20 the message. Any ND Proxy changes to messages would invalidate the=20 signature and the ND Proxy itself could not generate a new signature=20 (since it would not have the private key associated with the source IP=20 address). This draft introduces a Proxy Signature (PS) option to secure=20 the proxied messages. RFC3971, the base SEND spec, defines a new Router Authorization=20 Certificate profile, dependent on RFC3779, which authorizes the router to= =20 act as a router and act for certain prefixes. Message authorization in=20 SEND of some ND messages checks the prefixes listed in the certificate=20 against the prefixes mentioned in those messages. There is no explicit=20 representation in the certificate of the authority to act as a router.=20 Possession of the certificate in SEND serves as implicit authorization to= =20 act as a router, as that was the only authorization defined. With the introduction of proxies, there was a need to distinguish the=20 various roles that a node might have in the network. No longer is=20 possession of a certificate adequate authorization. The draft=20 draft-ietf-csi-send-cert-04.txt uses the KeyPurposeId field to distinguish= =20 three different roles: router, proxy and owner. That draft notes that=20 multiple key purposes are possible. I believe that it is also possible to= =20 have single roles =96 so a node could be a proxy but not a router. With the extensions of the csi-send-cert draft, possession of a=20 certificate is no longer proof of any particular authorization. It seem=20 clear to me that the authorization validation described in RFC3971 is no=20 longer sufficient. I believe that a discussion is needed of what messages= =20 require or allow each particular key purpose authorization. Issuing an=20 RA, for example, seems likely to require the "router" value of the key=20 purpose field, if the new certificate format was used for authorization.=20 Issuing an NA may require the "owner" value of the key purpose field, if=20 the new certificate format was used for authorization rather than a CGA.=20 I do not know if that discussion would be more appropriate here or in the= =20 csi-send-cert draft, or another draft entirely that updates RFC3971=20 directly. If a SPND proxy was using SEND to communicate with other nodes that=20 understood SPND, would it be OK to use a new format cert (with the=20 "router" KeyPurposeId) as a router certificate for the SEND RSA Signature= =20 Options? This draft validates the use of its new PS option against a proxy=20 KeyPurposeId in the certificate. However, I could not find that it=20 validates the prefixes in the proxied messages against the prefixes=20 mentioned in the certificate. Surely it should. RFC3971 requires that=20 the prefixes in a PI option match the router cert prefixes, but I=92m not= =20 sure that carries through to the proxied messages or those (like NA) that= =20 refer to an address and have no PI option. I was curious as to the topological scenarios possible with proxies.=20 RFC4861 notes that multiple proxies might respond on a single link,=20 draft-csi-sndp-prob-04.txt discusses proxies that are nested, RFC4389 says= =20 that a proxy never receives RAs from other proxies (which restricts=20 topologies), and this draft mentions proxying messages that already=20 contain a PS option. In Sec 5.2.2 of this draft, steps 6 and 7 of the=20 rules for receivers of the Proxy Signature option imply that there might=20 be multiple proxies on a link as well as proxy responses colliding with=20 direct responses. While there is a discussion of scenarios for proxying=20 ND messages, they are not discussions of topologies of the proxies=20 themselves. I believe that I would have benefited from an explanation of= =20 the topology envisioned here. Each SPND proxy must be able to distinguish secure nodes (RFC3971 or SPND= =20 nodes) from insecure nodes (non-SEND) on the link for which it serves as=20 proxy. It decides whether to securely proxy ND messages received from=20 those nodes based on that info. Is there any thought as to how the SPND=20 proxy would know this? If this is manual configuration, that could be a=20 lot of work or impossible depending on the scenario. And if there are=20 multiple proxies on the link in some topologies, they must be consistent. I was curious as to whether unsigned ND messages could be proxied securely= =20 by a SPND node. Section 5.2.1 p 10 says the PS option MUST be added,=20 which satisfied me, but then Section 7.2 p 20 says there are cases where=20 the PS option MUST NOT be added. If that=92s a contradiction, it needs to= =20 be addressed. The text seems to make a distinction between "locally generated"/"issued"= =20 messages for a proxied address and "forwarding" or "translating" a message= =20 from a proxied address. I was never certain what cases might cause the=20 local generation of an address. RFC4389 seem to me to refer only to the=20 forwarding of messages. Perhaps the "local generate" term refers to the=20 scenario discussion in section 6.2 of Proxy Mobile IP, perhaps the term=20 refers to some of the exchanges in RFC4389 proxying. I=92m not sure. After reading this, I was not sure that I had an adequate idea of the=20 error processing when different information has the potential to conflict.= =20 I was particularly interested in the RA message. RFC4389 introduces a "P"= =20 bit for the RA messages to indicate a proxied message. This draft=20 introduces a PS option to secure proxied messages. The new cert format=20 has a "proxy" value for the KeyPurposeId. I tried to work out the=20 combinations: P bit PS opt cert:"proxy" action 0 no no no proxy needed (can use 3791) 0 no yes no proxy needed (can use 3971) 0 yes no silent discard of message 0 yes yes weird but OK? 1 no no "unsecured", even if 3971 signed? cert says not a proxy, so drop? 1 no yes "unsecured", even if 3971 signed? If 3971 signed, check 3971 cert prefixes or new cert prefixes? 1 yes no silent discard of message 1 yes yes secure proxy =96 all OK As acknowledged in the Section 7.1, a RFC3971 message from a RFC3971 node= =20 to another RFC3971 node proxied through a SPND proxy appears unsecured to= =20 the receiver. That=92s no worse than proxying the message through a RFC397= 1=20 proxy, so no harm done, for most messages. For Router Solicitation=20 messages, which according to RFC3489 don=92t get altered and can retain=20 their signatures, the outcome is worse. I think. Detailed comments: Sec 4, p 6: Proxy ND's certificate. When a ND message contains a PS option, it MUST NOT contain CGA and RSA Signature options. This option can be appended to any ND message: NA, NS, RS, RA and Redirect. Is that a "MAY" be appended? Page 10 says "MUST" be added, but section=20 7.2 p 20 talks of cases where it MUST NOT be added. o A modification of the SEND processing rules for all ND messages: NA, NS, RS, RA, and Redirect. This draft and RFC4389 do not mention =96 if the proxied message is a NA,= =20 and the proxy is a router, does the router bit get set? Sec 5.2.1 p 10 5.2.1. Processing rules for senders A ICMPv6 message sent by a Secure ND Proxy for a proxied address MUST contain a PS option and MUST NOT contain either CGA or RSA Signature options. Note contradiction in section 7.2 p 20. Sec 5.2.1 p 11 C. If the Secure ND Proxy is forwarding a SEND message already containing a PS option, first the authenticity of the intercepted message is verified as specified in Section 5.2.2 of this specification. If the SEND message is valid, the original PS option MUST be removed from the message. The intercepted message is finally modified as described in Section 4 of the ND Proxy specification [RFC4389]. Does this disagree with the RFC4389 statement that RA messages can not be= =20 received from other proxies? That is, if an RA message P bit is set (and= =20 if it contains a PS option, one hopes the P bit is set), RFC4389 sec=20 4.1.3.3 says the interface must not be used as a proxy interface. 2. Timestamp and Nonce options MUST be included according to the rules specified in SEND [RFC3971]. The value in the Timestamp option MUST be generated by the proxy. If the proxy is forwarding a message, the Nonce value in the proxied message MUST be the same as in the forwarded message, otherwise it is generated by the proxy. What is the "otherwise" here? If the proxy is *not* forwarding, which=20 might be if it is "locally generating" a message? If the Nonce is not=20 present in the forwarded messages? Sec 6.2 p 16 This scenario seems to be using the SPND feature because the MAG is using= =20 a source address that does not really belong to it. It is not forwarding= =20 any ND messages. So perhaps this is the case where the "locally=20 generated" terminology applies. To provide SEND protection, each MAG is configured to act as a proxy by means of a certificate associated to the PMIPv6 domain, authorizing each MAG to proxy securely ND messages. In addition, the certificate must also authorize the MAG to advertise prefixes. Note that the inclusion of multiple KeyPurposeId values is supported by [I-D.ietf-csi-send-cert]. I believe that means that the new cert format must show both the router=20 and the proxy KeyPurposeID values because it is generating a RA. But no=20 such check is mentioned anywhere. Sec 6.2 p 16 A node receiving a message from the MAG containing the PS option MUST apply the rules defined in Section 5.2.2. Note that unsolicited messages sent by MAG are validated by the host according to timestamp values specific to the MAG serving the link, not to any other MAG to which the host has been connected before in other links. The host does not see any difference in the MAG, since the MAG is using=20 the same source IP address as all other MAGs to which the host has been=20 connected. According to my reading of RFC3971, that means that there=92s a= =20 chance that unsolicited messages from the MAG would appear stale =96 as lon= g=20 as the unsolicited message was received before a solicited advertisement.= =20 Receipt of a solicited advertisement should update the timestamp at the=20 host, based on the nonce matching, by RFC3971 rules Sec 6.3 p 17/18 A Secure ND Proxy shall parse any IPv6 packet it receives on a proxy interface to check whether it contains one of the following secured ICMPv6 messages: NS, NA, RA, or Redirect. This seems to disagree with Section 5.2.1, p 10, which says the PS option= =20 is added to *all* messages. However, it does agree with the discussion in= =20 section 7.2 p 19/20, which says that the PS option is only generated on=20 behalf of RFC3917 nodes and SPND nodes. Section 7.1 p 19 In the scenarios in which the proxy translates ND messages, the messages to translate can either be originated in a RFC3971 node or in an SPND node, without interoperability issues. The discussion immediately above this text says that RFC3971 nodes drop a= =20 PS option in a proxied message and treat the message as unsecured, so I am= =20 not sure what this is talking about. A secure proxied NA reply, for=20 example, would appear unsecured to the RFC3971 host and secure to the SPND= =20 proxied host. Is "translates" an ND message different from=20 "forwards"/"proxies" an ND message =96 i.e., the PS option is not applied? sec 7.2 p 20 Therefore, the Secure ND Proxy MUST generate messages containing the PS option for SPND and RFC3971 hosts, and MUST NOT generate messages containing the PS option for non-SEND nodes. This (and other places in the subsequent paragraphs) seems to contradict=20 sec 5.2.1 p 10 which says the PS option is a MUST, period. What does the "for SPND and RFC3971 hosts" and the "for non-SEND hosts"=20 mean? I believe that it means that the proxy is forwarding messages on=20 their behalf. The use of the term "generate" here doesn=92t seem to mean= =20 the same as "locally generated" elsewhere. I am not sure how the SPND would know which of the nodes on the proxy=20 interface were non-SEND, RFC3917, or SPND nodes. But if it can be=20 configured with that information, could it also be configured to know the= =20 status of nodes on the outgoing interface? It might then detect that=20 doing the computation to add the PS option was a waste of effort because=20 there were no SPND nodes on that side. If the RFC3971 node produces a solicitation that needs to be forwarded=20 through the SPND proxy, and the SPND proxy forwards the advertisement it=20 received in reply along with the PS option, the RFC3971 will drop the PS=20 option. True? Should the SPND still produce the (wasted) signature? Sec 7.2 page 20 o For translating ND messages for nodes that can arrive to the link in which the proxy operates, =85 o For synthesizing ND messages on behalf of remote nodes, I think "translating" here means forwarding through the proxy and doing=20 the RFC4389 changes, while "synthesizing ND messages" means the mobile=20 node scenarios where no message is received for forwarding but one is=20 created (PMIPv6 and MIPv6?). An explanation of this difference and a consistent set of terms would have= =20 helped a lot. o For translating ND messages for nodes that can arrive to the link in which the proxy operates, the rule can be easily applied: only messages validated in the Secure ND Proxy according to the SEND specification [RFC3971] MUST be proxied securely by the inclusion of a PS option. Unsecured ND messages could be proxied if unsecured operation is enabled in the proxy, but the message generated by the Secure ND Proxy for the received message MUST NOT include a PS option. Is it possible for a proxy to receive a message with a PS option?=20 Previous text (sec 5.2.1 part C) seems to indicate so. If the "MUST be=20 proxied securely" applies to SPND protected messages as well as RFC3971=20 protected messages, then this case is the same as the previous paragraph=20 "MUST generate messages containing the PS option for SPND and RFC3971=20 hosts . . .". Unless this is a difference between translating messages=20 and generating messages, of course. Sec 8 p 22 However, when two on-link hosts communicate using their respective link-local addresses, the threats involved with a compromised router and a compromised proxy ND differs because the router is not able to siphon off traffic exchanged between the hosts or mount a man-in-the-middle attack, while the proxy ND can, even if the hosts use SEND. This should be explained in more detail. I believe that the reason is=20 that a SEND router would not be able to produce a NA reply to an NS that=20 would be believed, but the SPND could pretend to be proxying a NA reply=20 believably =96 as long as the recipient used SPND and could accept the PS= =20 option. Proper configuration of when the PS option must or must not be included, depending on the proxied nodes being SEND or non-SEND may result in security considerations which are discussed in Section 7. This is pretty contorted. I believe that this is trying to say that=20 Section 7 discusses some of the security considerations resulting from the= =20 decision to append or omit PS protections depending on the SEND awareness= =20 of the proxied nodes. But I=92m not sure. Attacks to the timestamp of the secured ND message can be performed as described in section 7.3 of [I-D.ietf-csi-sndp-prob]. I found that section of that draft to be particularly unclear. And it is= =20 not normatively cited here. I=92m not saying that it should be, but if tha= t=20 draft does not progress (giving opportunity to improve the discussion),=20 the reader of this draft would be lost. Is there any way to summarize the= =20 vulnerabilities so that the reader of this draft have some hint of what=20 can go wrong and why? NITS Sec 5.2.2 p 12 the IP of node for which the message is proxied. In this way, a ^^^^^^^^^^^^^^ the IP address of a node cached link-layer address created securily by means of RSA ^^^^^^^^ securely Sec 6.1 p 13-14 Sometimes the Home Address is abbreviated HoA and sometimes as HA Sec 6.2 p 16 link to which the MN is attached to, to be generated by the LMA when ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ to which the MN is attached, the MN first attach to a PMIPv6 domain, ^^^^^^ attaches sec 7.2 p 20 options on behalf of nodes with SEND capabilities (i.e. that they could use SEND to defend their messages if being in the same link ^^^^^^^^ present on than the proxy, either RFC3971 nodes or SPND nodes). ^^^^ with sec 7.2 p 20 Not using the PS option for a RFC3971 or SPND MN would make more vulnerable the address in the home link when the MN is away than when it is in the home link This is a bit awkward. I suggest moving the "more vulnerable" part" so=20 that it reads: Not using the PS option for a RFC3971 or SPND MN would make the address in= =20 the home link more vulnerable when the MN is away than when it is in the=20 home link Sec 8 p 22 The security of proxied ND messages not including a PS option is the same of an unsecured ND message. The security of a proxied ND ^^ as message received by a non-SEND host or RFC3971 host is the same of an ^^ as unsecured ND message. Sec 8 p 22 Attacks to the timestamp of the secured ND message can be performed ^^ on. --1382430996-12988-1278029505=:9620-- From christer.holmberg@ericsson.com Fri Jul 2 01:04:40 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE7A63A68C0; Fri, 2 Jul 2010 01:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.861 X-Spam-Level: X-Spam-Status: No, score=-2.861 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i11r-yHHD87b; Fri, 2 Jul 2010 01:04:38 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 7048B3A6863; Fri, 2 Jul 2010 01:04:37 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-aa-4c2d9da02ecb Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A0.B8.19600.0AD9D2C4; Fri, 2 Jul 2010 10:04:48 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.94]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 2 Jul 2010 10:04:48 +0200 From: Christer Holmberg To: Ted Hardie Date: Fri, 2 Jul 2010 10:04:46 +0200 Thread-Topic: secdir review of draft-ietf-simple-msrp-sessmatch Thread-Index: AcsXsdZJ8x4hdxgeTiaH2eToWPAxJgBjlGdg Message-ID: References: <5A638DC0-41CF-4C0C-B00D-6793C43FB708@bbn.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , The IETF , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 08:04:40 -0000 Hi, We have some ideas on how to address the issues and move forward, but due t= o summer vacations we will unfortunately most likely not be able reply to T= ed's and Richard's e-mails before august. Just to let you know. Regards, Christer =20 > -----Original Message----- > From: Ted Hardie [mailto:ted.ietf@gmail.com]=20 > Sent: 29. kes=E4kuuta 2010 20:37 > To: Christer Holmberg > Cc: Richard L. Barnes; secdir@ietf.org; iesg@ietf.org; The=20 > IETF; draft-ietf-simple-msrp-sessmatch@tools.ietf.org > Subject: Re: secdir review of draft-ietf-simple-msrp-sessmatch >=20 > In-line. >=20 > On Tue, Jun 29, 2010 at 8:41 AM, Christer Holmberg=20 > wrote: > > > > Hi Ted, > > > >>I join Richard in believing that this document makes changes beyond=20 > >>that which could be understood as "updating" the MSRP URI scheme=20 > >>processing. > >> > >>To highlight one particular aspect, RFC 4975 does not require=20 > >>session-ids to be present, a fact noted both in the ABNF=20 > and in this=20 > >>text: > >> > >>4. The session-id part is compared as case sensitive. =A0A URI without > >> =A0 a session-id part is never equivalent to one that includes one. > >> > >>A matching scheme which relies on a URI section which is not=20 > >>guaranteed to be present has some interesting problems=20 > ahead of it. If=20 > >>this effectively makes their use mandatory, that requires a=20 > change to=20 > >>the fundamental ABNF and text. > > > > An MSRP URI in an SDP offer or answer for an MSRP session=20 > MUST include a session-id part, so I believe the comment is=20 > >based on incorrect assumptions. >=20 > This is not indicated in the URI matching sectio >=20 >=20 > > > > Section 6 of RFC 4975 says: > > > > =A0 "The session-id part identifies a particular session of the=20 > > participant. The absence of the session-id > > =A0 part indicates a reference to an MSRP host device, but=20 > does not refer to a particular session at that device." > > >=20 > The full section from which that quote is taken is: >=20 > The MSRP URI authority field identifies a participant in a=20 > particular > MSRP session. If the authority field contains a numeric=20 > IP address, > it MUST also contain a port. The session-id part identifies a > particular session of the participant. The absence of the=20 > session-id > part indicates a reference to an MSRP host device, but=20 > does not refer > to a particular session at that device. A particular value of > session-id is only meaningful in the context of the associated > authority; thus, the authority component can be thought of as > identifying the "authority" governing a namespace for the=20 > session-id. >=20 > This proposal changes the concept of a namespace authority=20 > present in the URI matching section of RFC 4975. I am sorry=20 > if my wry reference to this in my previous message was hard=20 > to follow; I should have known better. > To be more plain, this proposal fundamentally changes the=20 > matching semantics of the URI set out in RFC 4975, by=20 > requiring a match on only a portion of the URI. At a bare=20 > minimum, this would require noting a normative update to=20 > section 6 and 6.1 of RFC 4975, which this draft does not do. =20 > In reality, this is unlikely to be sufficient, as URI=20 > matching semantics do not generally have the concept of=20 > ignoring the authority in providing a match (at least in my=20 > reading of the RFC > 3986 "ladder of comparison" text). That means you'd have to=20 > special case the MSRP matching semantics, rather than have=20 > the URI be parsed and compared using a standard library. >=20 > Creating a new URI scheme without re-using authority may be a=20 > better approach; this would require more work, but it is=20 > cleaner than this appears to be. >=20 > > > >>I also note that the security considerations, in addition to having=20 > >>some fairly disingenuous language about the impact of this change,=20 > >>seems to fail to mention MSRPS URIs and what, if any, impact this=20 > >>would have on them. > > > > There are no impacts to MSRPS URIs. I assumed it would be=20 > implicitly understood since MSRPS URIs are not mentioned in the draft. > > > > However, we could explicitly make it clear by modifying the=20 > first sentences of section 5: > > > > =A0 =A0 =A0"The change of session matching procedure does not impact th= e=20 > > format of MSRP URIs, > > =A0 =A0 =A0 =A0disregarding if the "msrp" scheme or the "msrps"=20 > scheme is used. > > =A0 =A0 =A0 =A0However, MSRP endpoints can only check that the=20 > session-id part of the MSRP URI..." > > >=20 > This doesn't seem to me to actually work, based on Richard's=20 > comments, unless what you mean to say is "if MSRPS is in use,=20 > nothing in this draft can be used". That gives you different=20 > matching semantics for MSRPS (authority must be present and=20 > must be matched using TLS semantics) vs MSRP (only session-id=20 > is checked) which is at the very least a violation of the=20 > principle of least surprise (no other foo over TLS protocol=20 > works that way that I know of ). >=20 > regards, >=20 > Ted > > > > Regards, > > > > Christer > > > > > > > >> On Mon, Jun 14, 2010 at 10:21 AM, Richard L. Barnes=20 > =20 > >> wrote: > >> > I have reviewed this document as part of the security=20 > directorate's=20 > >> > ongoing effort to review all IETF documents being=20 > processed by the=20 > >> > IESG. =A0These comments were written primarily for the=20 > benefit of the=20 > >> > security area directors. =A0Document editors and WG chairs > >> should treat > >> > these comments just like any other last call comments. > >> > > >> > This document changes the URI matching algorithm used in > >> MSRP. =A0MSRP > >> > sessions are typically initiated using SDP bodies in SIP. > >> These SDP > >> > bodies contain MSRP URIs that the peers use to contact=20 > each other. > >> > When one peer receives a request to initiate a session,=20 > he verifies=20 > >> > that the URI being requested is one that he initiated in > >> SDP, thereby > >> > using the URI as a shared secret to authenticate that the > >> originator > >> > of the session actually received the SDP body in question. > >> > > >> > According to the current SDP specification, this comparison is=20 > >> > performed over the whole URI; this document restricts the > >> comparison > >> > to the "session-id" component, omitting the host, port, and > >> transport components. > >> > =A0The goal of the document is to facilitate a certain class of=20 > >> > man-in-the-middle attack, namely to allow a signaling > >> intermediary to > >> > insert a media intermediary. =A0The restriction on the URI > >> comparison is > >> > needed in order for the media intermediary not to have to > >> modify URIs > >> > in MSRP packets to reflect the modifications to URIs in=20 > SDP bodies=20 > >> > performed to redirect traffic through the media intermediary. > >> > > >> > I have a few significant reservations about this document: > >> > > >> > This extension makes it more difficult for MSRP entities=20 > to secure=20 > >> > their communications against attackers in the signaling=20 > path. =A0The=20 > >> > current model provides a basic integrity protection, in > >> that signaling > >> > intermediaries cannot redirect traffic to an arbitrary=20 > third party;=20 > >> > they must at least advise the third party about how to=20 > modify MSRP=20 > >> > packets. =A0The proposed modification would remove even this cost. > >> > Moreover, it raises the cost of providing integrity=20 > protection to=20 > >> > messages, since Alice must now employ both integrity and=20 > >> > confidentiality protections on an end-to-end basis; if=20 > her messages=20 > >> > are only integrity-protected, then a proxy can remove the > >> integrity protection and redirect traffic without it being=20 > observable=20 > >> to Alice. > >> > > >> > The document needs to clarify what the impacts are for > >> authentication > >> > in secure modes of MSRP. =A0In particular: > >> > -- The distinction between "self-signed" and "public" > >> certificates is > >> > inappropriate. =A0The proper distinction is between the name-based=20 > >> > authentication in Section 14.2 of RFC 4975 and the > >> fingerprint-based > >> > authentication in Section 14.4. -- In either case, changing > >> the host > >> > name need not result in an authentication failure, since=20 > the media=20 > >> > intermediary can simply authenticate as itself to both=20 > endpoints,=20 > >> > having changed the respective MSRP URIs appropriately. > >> > -- There is currently no requirement that a endpoint > >> identity in the > >> > To-Path URI matches the endpoint identity authenticated=20 > at the TLS=20 > >> > layer, because these two are required to be the same. =A0This > >> document > >> > changes that assumption, and should note that these two > >> identities can differ. > >> > The document also precludes any name-based multiplexing, where a=20 > >> > single MSRP process (single IP address and port) directs > >> requests to > >> > different virtual recipients based on the domain name in > >> the To-Path > >> > header. =A0(In analogy to Host-based multiplexing in HTTP, > >> which is very > >> > widely deployed.) =A0Since with this extension, the domain in the=20 > >> > To-Path is completely unpredictable from the recipient's > >> perspective, it is useless to the recipient. > >> > > >> > The document has no backward-compatibility. =A0MSRP > >> implementations that > >> > do not support this extension will not be able to receive MSRP=20 > >> > sessions from implementations that do. =A0 In that regard, =A0this=20 > >> > document seems more like an new version of MSRP rather than > >> an update. > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Ietf mailing list > >> > Ietf@ietf.org > >> > https://www.ietf.org/mailman/listinfo/ietf > >> > > >> > = From secdir-bounces@mit.edu Sat Jul 3 06:03:57 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 276513A6844 for ; Sat, 3 Jul 2010 06:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.204 X-Spam-Level: X-Spam-Status: No, score=-4.204 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SLB3xn0DtiA for ; Sat, 3 Jul 2010 06:03:56 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 121373A67FC for ; Sat, 3 Jul 2010 06:03:55 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o63D46od014430 for ; Sat, 3 Jul 2010 09:04:06 -0400 Received: from mailhub-dmz-2.mit.edu (MAILHUB-DMZ-2.MIT.EDU [18.7.62.37]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o63D44TU014427 for ; Sat, 3 Jul 2010 09:04:04 -0400 Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by mailhub-dmz-2.mit.edu (8.13.8/8.9.2) with ESMTP id o63D43SA001633 for ; Sat, 3 Jul 2010 09:04:04 -0400 X-AuditID: 12074424-b7b63ae000000a0b-78-4c2f35439c2d Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id 58.F7.02571.3453F2C4; Sat, 3 Jul 2010 09:04:03 -0400 (EDT) X-IronPort-AV: E=Sophos;i="4.53,530,1272837600"; d="scan'208";a="62666158" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO macbook-pro-de-roca.local) ([82.236.155.50]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 03 Jul 2010 15:04:01 +0200 Message-ID: <4C2F3541.7000206@inrialpes.fr> Date: Sat, 03 Jul 2010 15:04:01 +0200 From: Vincent Roca Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jaehoon Jeong References: <4C248D9A.5080508@inrialpes.fr> <5A6980BCAE9E6D438D4D8A05540F6FB70113043B9B@BRM-EXCH-3.corp.brocade.com> <4C25CA06.1080809@piuha.net> <5A6980BCAE9E6D438D4D8A05540F6FB70113658855@BRM-EXCH-3.corp.brocade.com> In-Reply-To: <5A6980BCAE9E6D438D4D8A05540F6FB70113658855@BRM-EXCH-3.corp.brocade.com> X-Enigmail-Version: 1.0.1 X-Brightmail-Tracker: AAAAAhTzSz4U9B3E X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Cc: 6man Chairs <6man-chairs@tools.ietf.org>, "secdir@mit.edu" , Jari Arkko , IESG , "draft-ietf-6man-dns-options-bis.all@tools.ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 13:03:57 -0000 Dear authors, Thanks for your prompt reply. A few additional comments (it's my role ;-)) ** new "Security Considerations" section says: > This attack > is similar to Neighbor Discovery attacks that use Redirect or > Neighbor Advertisement messages to redirect traffic to individual > addresses to malicious parties. In general, the attacks related to > RDNSS and DNSSL are similar to both Neighbor Discovery attacks and > attacks against unauthenticated DHCP, as both can be used for both > "wholesale" traffic redirection and more specific attacks. > You're right, other attacks are possible that lead to the same result. ND and unauthenticated DHCP are such possibilities. However, IMHO this is not a sufficient reason not to RECOMMEND a security solution for RA. Indeed, if ND / DHCP are made robust but nothing is done for RA, then the threat remains. So the updated text does not fully satisfies me, even if the new paragraph is more clear than the old one. >> ** Section 7: >> Another point... the authors explain than network devices like >> switches can be configured in such a way to disable ND/DHCP from >> some ports. That's great and I agree it helps preventing attacks. >> However this is limited to wired networks. Nothing is said concerning >> ND configurations in wireless networks. The situation is rather >> different since any host can issue ND/DHCP traffic as if it were a >> legitimate server if I understand correctly. The document MUST >> include this kind of discussion. >> >> > But this is generic issue with spoofing RAs and I am not sure it is the > task of this document to specify the solutions. One solution exists in > SEND (RFC 3791). > Once again I agree. You don't have to specify technical solutions. However you need to provide a good security analysis, perhaps inherited from that of the base RA document for the generic RA threats, with some text describing the additional threats added by the proposed extensions. And since security solutions exist elsewhere (SEND), you should recommend their use. That's your responsibility. >> ** Section 7: >> Yet another remark: SEND is listed as one potential solution to >> add signatures in ND packets issued from servers. >> I don't know SEND at all, so may be my remarks are flawed (but in >> that case the text should be at least clarified). >> - Shouldn't the use of SEND be RECOMMENDED as a solution to >> mitigate attacks? Current document is not clear. >> - Does SEND enable an authentication of the sender (the document >> only mentions integrity protection)? If there's no sender >> authentication, then I agree that the added value of SEND would be >> limited. I'd like the authors to clarify this as well. >> >> > The details are in RFC 3791 and its companion documents. SEND does > enable a host to verify that the sender of an RA is actually a router > authorized to act as a router. > The text in your proposed I-D update does not reflect this. Can you add it? Being able to authenticate the sender is as important as being able to check the packet integrity. ** I'm coming back to a comment I made earlier and that has not been answered. In the updated I-D, section 5.3.1, I read: "In the case where the DNS options of RDNSS and DNSSL can be obtained from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep some DNS options from all sources. " I don't see (but I read very quickly so I may have missed something) that secured RA/RDNSS/DNSSL messages be prefered in the choice. If some RA use SEND, they must be preferred over others. I hope my comments are useful. Cheers, Vincent _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From yaronf.ietf@gmail.com Sun Jul 4 06:13:16 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4F143A680D for ; Sun, 4 Jul 2010 06:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxkKK3p1mmeE for ; Sun, 4 Jul 2010 06:13:15 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 4B5CA3A67FA for ; Sun, 4 Jul 2010 06:13:14 -0700 (PDT) Received: by wwb24 with SMTP id 24so1092098wwb.13 for ; Sun, 04 Jul 2010 06:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=R4y+XG6/M9yhQDtYPSl72XXdXDECfRgfsgKTSAA1mkE=; b=Ju0fIjCccAeTSVTjqYTnT0vzKY+7GUgAOFn24MukkoFOiGhXc9jq7EDIvYR7P89n7s Oa8SLyx5s2ltqhdu/iI5xXZHy0gC9dWaFK1lHJ+csXYI2yy0LG+lpDT0uLnDIABY4vrW D59pJCycoJwxK82WZTiia6lQE1DfgXxIsoRzo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=IsQSCFETFKThdTPpA7le9hXMqAEqhTeP2veC0MP+pgBXALMrSoqoVgj76KFdySzG2+ uf1cGn5nPjnzw4t8KfErR7ndGOICYCmpK6uVtKOXBOwnWO7i5ASKFJ7DuZjQdZeOhxgC wLFcDy+KGjmdYfkOFjH/+mXFDAGv0TVjX+Rhs= Received: by 10.227.138.67 with SMTP id z3mr1764617wbt.179.1278249189226; Sun, 04 Jul 2010 06:13:09 -0700 (PDT) Received: from [10.0.0.1] ([109.67.47.233]) by mx.google.com with ESMTPS id i25sm23066522wbi.16.2010.07.04.06.13.07 (version=SSLv3 cipher=RC4-MD5); Sun, 04 Jul 2010 06:13:08 -0700 (PDT) Message-ID: <4C3088E1.6000100@gmail.com> Date: Sun, 04 Jul 2010 16:13:05 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Charles Shen References: <4C148FB1.8060709@gmail.com> <4C1DFF97.1020103@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Henning Schulzrinne , draft-ietf-nsis-tunnel.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-nsis-tunnel-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2010 13:13:16 -0000 Hi Charles, I have been assigned your draft for a secdir re-review. The draft has not been revised since my last review, so I will just reiterate: I recommend that the Security Considerations be improved before the document goes into IESG telechat. Thanks, Yaron On 06/21/2010 06:15 PM, Charles Shen wrote: > Thanks Yaron, please see inline. > > On Sun, Jun 20, 2010 at 7:46 AM, Yaron Sheffer wrote: >> [Removed the IESG.] >> >> Hi Charles, >> >> please see my comments inline. >> >> Thanks, >> Yaron >> >> On 06/20/2010 06:52 AM, Charles Shen wrote: >>> >>> Hi Yaron, thank you for your careful review. Please see comments inline. >>> >>> On Sun, Jun 13, 2010 at 3:58 AM, Yaron Sheffer >>> wrote: >>>> I have reviewed this document as part of the security directorate's >>>> ongoing effort to review all IETF documents being processed by the IESG. >>>> These comments were written primarily for the benefit of the security >>>> area directors. Document editors and WG chairs should treat these >>>> comments just like any other last call comments. >>>> >>>> This draft discusses the problem of NSIS messages (particularly, QoS >>>> reservation flows) being encapsulated into various IP tunneling >>>> protocols, >>>> which prevent the correct QoS setup from being performed. The draft >>>> proposes >>>> a solution for NSIS tunnel-aware tunnel endpoints, which basically adds >>>> an >>>> NSIS signaling flow between the tunnel endpoints, but outside of the >>>> tunnel. >>>> >>>> General >>>> >>>> The draft presents the problem, and the solution, reasonably well. >>>> >>>> The draft goes for the "no new security issues" approach. I think this >>>> is >>>> incorrect, and in fact a number of security issues should be analyzed >>>> and >>>> possibly resolved. In addition, as a complete outsider to NSIS, I have >>>> identified one major unspecified piece, leading me to believe that the >>>> draft >>>> has not had enough review. >>>> >>>> Security >>>> >>>> The main security issue is that the draft fails to consider >>>> security-oriented tunnels. IPsec tunnels (and the commonly used >>>> GRE-over-IPsec) provide security services: normally encryption and >>>> integrity >>>> protection with ESP, less commonly integrity-protection only with AH, >>>> ESP >>>> with null encryption, or the new WESP (RFC 5840). The proposed solution >>>> raises at least three major security issues related to these tunnels: >>>> >>>> 1. A so-called covert channel that results from NSIS flows in the >>>> protected >>>> networks directly triggering NSIS protocol exchanges in an unprotected >>>> network (i.e. between the tunnel endpoints). Please see Appendix B.1 of >>>> draft-ietf-tsvwg-ecn-tunnel-08 for treatment of a similar issue. >>>> >>> >>> With regard to this specific draft, I see the problem as a more >>> generic issue which exists also for other protocols (e.g., RSVP) >>> requiring per-hop processing to interact with IPSec. E.g., RFC4302 >>> mentions that "NOTE: Use of the Router Alert option is potentially >>> incompatible with use of IPsec. Although the option is immutable, its >>> use implies that each router along a packet's path will "process" the >>> packet and consequently might change the packet.". I think that >>> mentioning of this potential incompatibility will be beneficial. But I >>> don't quite see how "limiting the bandwidth of the covert channel" as >>> discussed in Appendix B.1 of draft-ietf-tsvwg-ecn-tunnel-08 can be >>> applied here. Please correct me if I were wrong. >>> >> You can say this solution is incompatible with IPsec and be done with it. >> Otherwise, there is a "covert channel >> " - someone can create spurious >> NSIS signaling flows within the protected network, just to create signaling >> in the outside network, which then someone else is monitoring. For highly >> secure networks, this would be seen as a way to smuggle information out of >> the network, and you would want to rate-limit this channel. >>> > > That makes sense. My understanding is that the rate-limit does not > complete solve the problem, but does reduce the potential harm. > > >>>> 2. A more serious interaction in the other direction: unprotected NSIS >>>> flows >>>> outside the tunnel interact with NSIS flows in the protected networks >>>> and >>>> inside the tunnel, and so, an attacker in the unprotected network can >>>> possibly influence QoS behavior in protected networks. >>>> >>>> 3. A practical result of (2) is that the NSIS protocol stack on the >>>> tunnel >>>> endpoint is now exposed to unprotected networks and therefore suddenly >>>> becomes security-critical. >>>> >>> >>> IMHO, if we have a segment of the path which is compromised, the QoS >>> of the rest of the path segments (and the end-to-end QoS) can be >>> easily affected anyway, whether you have a tunnel segment in the path >>> or not. Therefore, it doesn't seem to me as a new threat introduced by >>> this document per se. But it will certainly also be helpful to mention >>> this scenario in the security considerations section. >> >> What I'm saying in #3 is that any security vulnerability (e.g. buffer >> overflow) in the NSIS stack is suddenly exposed to the big bad Internet, >> even when the customer may have expected all their traffic to be protected >> by a VPN gateway, where the VPN software is normally the only software that >> needs to be hardened. > > I agree. What I had been thinking is that compromise of other nodes > (non-tunnel end-points) may similarly affect end-to-end QoS signaling, > even if the end-to-end path includes a secure tunnel. > >>> >>>> Non-Security >>>> >>>> The draft defines extra UDP encapsulation in some cases ("the tunnel >>>> entry-point inserts an additional UDP header"), but the format >>>> (specifically, the port number) is not specified. This omission is >>>> strange, >>>> because the protocol cannot be implemented in the absence of this >>>> information! >>>> >>> >>> To me this is an intended feature. The mechanism does not require a >>> pre-allocated fixed UDP port, but allows the port to be dynamically >>> chosen and conveyed during the tunnel flow/session binding operations. >>> >> Sure, I missed this point. Can you please mention it explicitly. >> > > Sure! > > Thanks > > Charles From stefan@aaa-sec.com Mon Jul 5 00:36:56 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36A5F3A6823 for ; Mon, 5 Jul 2010 00:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.049 X-Spam-Level: * X-Spam-Status: No, score=1.049 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_50=0.001, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3wT6PUbxjTj for ; Mon, 5 Jul 2010 00:36:54 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.112]) by core3.amsl.com (Postfix) with ESMTP id C67E03A685C for ; Mon, 5 Jul 2010 00:36:53 -0700 (PDT) Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id DD2A22F5349 for ; Mon, 5 Jul 2010 09:36:55 +0200 (CEST) Received: (qmail 63965 invoked from network); 5 Jul 2010 07:36:53 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.9]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 Jul 2010 07:36:53 -0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Mon, 05 Jul 2010 09:36:51 +0200 From: Stefan Santesson To: , "iesg@ietf.org" , "secdir@ietf.org" Message-ID: Thread-Topic: Secdir review of draft-ietf-proto-wgdocument-states-07 Thread-Index: AcscFNUUT4X1N6sDuk2IQZbZPDrEWg== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3361167413_15768803" Subject: [secdir] Secdir review of draft-ietf-proto-wgdocument-states-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 07:36:56 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3361167413_15768803 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I=B9m the assigned Secdir reviewer of draft-ietf-proto-wgdocument-states-07. However, this draft does not define any protocol. It=B9s purpose seems limite= d to define document states in the standardization process. As such I don=B9t think there is anything in this document that needs a security review. /Stefan --B_3361167413_15768803 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Secdir review of draft-ietf-proto-wgdocument-states-07 I’m the assigned Secdir reviewer of draft-ietf-proto-wgdocument-stat= es-07.

However, this draft does not define any protocol. It’s purpose seems = limited to define document states in the standardization process. As such I = don’t think there is anything in this document that needs a security r= eview.

/Stefan
  --B_3361167413_15768803-- From tena@huawei.com Mon Jul 5 19:29:08 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B95E3A6991 for ; Mon, 5 Jul 2010 19:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.827 X-Spam-Level: X-Spam-Status: No, score=-93.827 tagged_above=-999 required=5 tests=[AWL=-4.933, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_BACKHAIR_11=1, J_BACKHAIR_13=1, J_BACKHAIR_23=1, J_BACKHAIR_31=1, J_BACKHAIR_34=1, J_BACKHAIR_46=1, J_BACKHAIR_51=1, J_BACKHAIR_52=1, J_BACKHAIR_56=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlXmh96h4fMu for ; Mon, 5 Jul 2010 19:29:06 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B6C7E3A6993 for ; Mon, 5 Jul 2010 19:29:05 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5400L9Y6W6S2@szxga03-in.huawei.com> for secdir@ietf.org; Tue, 06 Jul 2010 10:28:54 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L54009BY6W6JQ@szxga03-in.huawei.com> for secdir@ietf.org; Tue, 06 Jul 2010 10:28:54 +0800 (CST) Received: from z00147053k ([10.70.39.90]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5400I5J6W6WS@szxml04-in.huawei.com> for secdir@ietf.org; Tue, 06 Jul 2010 10:28:54 +0800 (CST) Date: Tue, 06 Jul 2010 10:28:54 +0800 From: Tina TSOU To: secdir@ietf.org Message-id: <4F1C2535C6A94BD4A5F5E313FB245851@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: multipart/alternative; boundary="Boundary_(ID_hK2qFfuSrhbVIyTP5dax7Q)" X-Priority: 3 X-MSMail-priority: Normal Subject: [secdir] secdir review for draft-mcgrew-fundamental-ecc-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 02:29:08 -0000 This is a multi-part message in MIME format. --Boundary_(ID_hK2qFfuSrhbVIyTP5dax7Q) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable 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 comments. Abstract 1. First sentence: Should >are< rather be >were< ? Introduction 2. Introduction (p.2): I would insert the word >finite< before >fields<. 3. Introduction (p.4): >ECDH< should be replaced by >Elliptic Curve = Diffie-Hellman (ECDH) <. Mathematical Background 4. Mathematical Background (p.1): Should >is< rather be >are< ? The same = holds in Sec.~2.2 (p.1). 5. Sec.~2.2 (p.3): The term >g< is undefined. Hence, >g^N< should be = replaced by >a^N<. The same holds for >Note that a^M is equal to g^ (M = mod R)< in (p.9). 6. Sec.~2.3 (p.2): From this description, it appears to me that all = elements in Z_p can perform division operation. However, only non-zero = elements, namely elements in the set=20 Z_p^* =3D Z_p-{0} can perform the division operation. Moreover, all the mathematical = operations over Z_p are in the sense of mod p. In addition, a prime = number p is called the characteristic of a field, if 1+=A1=AD+1=3D0 (add = p times); in this case F_q contains the prime field F_p, where q=3Dp^n, = n>=3D1. So I think the definition of the F_p lacks precision. Elliptic Curve Groups 7. Elliptic Curve Groups (p.1): I think the last sentence is too = abstract to understand. More precisely, the elliptic curve satisfies the = equations, y^2+cy=3Dx^3+ax+b, y^2=3Dx^3+ax^2+bx+c, when the characteristic of the field is 2 and 3, respectively. 8. Elliptic Curve Groups (p.3): The first sentence says that = >when both points are the point at Infinity<. Maybe such statement is = not accurate enough due to the fundamental fact that each elliptic curve = abelian group has only one infinity, i.e., the identity element. 9. Sec.~3.1 (p.2): It seems to me that the projection space = representation >x=3DX/Z mod p , y=3DY/Z mod p< is a special case of = x=3DX/Z^{c_1} mod p and y=3DY/Z^{c_2} mod p when both c_1 and c_2 are = equal to 1. If so, should it be clearly explained ? 10. Sec.~3.3.1: I would simply state the reason for the non-zero = discriminant, namely, to ensure that the elliptic curve is chosen to be = a non-singular one, i.e., it has no self intersections or cusps. Elliptic Curve Diffie-Hellman (ECDH) 11. Elliptic Curve Groups (p.1): >an arbitrary cyclic group< = instead of >an arbitrary mathematical group< ? Elliptic Curve ElGamal Signatures 12. Sec.~5.1 (p.1): Insert >Galois< before >field GF(2^w)<. 13. Sec.~5.3 (p.2): Why not denote the generator >alpha< as >g< = for consistency in this draft ? 14. Sec.~5.3.2 (4): As the symbol >*< denotes the scalar = multiplication, why use such a symbol in Sec.~2.2 to represent the = addition operation in a group ? Needs to be modified ? 15. Sec.~5.3.3 (p.1): Insert >the generator g, the group order q< = before >the public key Y< in that these two parameters must know in = advance before the signature verification procedure. 16. Sec.~5.3.2 (1): Should >0s_1 in Z_q< = for consistency ? The same holds for >0*< in the = equation=20 >R'=3Dalpha^{u_1} * Y^{u_2}< represents the addition operation of two = points on the elliptic curve; while in >u_2=3Ds_1 * s_2 mod q<, it means = the scalar multiplication operation. 18. Sec.~5.6 (p.2): In the equations >A=3Dm< and >m=3D-r*z+s*k = (mod q)<, does the symbol m represent a message digest ? If so, I think = m should be replaced by h(m), although the hash function is not = necessary here. If not, it should be transformed to an integer since it = has been defined to be a bit string in Sec.~5.2. The same holds for the = equation >m*s=3D-r*s*z+k (mod q)<. Converting between integers and octet strings 19. the title >Converting between integers and octet strings<, why not = >Converting between Integers and Octet Strings< for consistency ? The = same goes for other titles and subtitles. Security Considerations=20 20. Sec.~10.1 (p.3): I think it is necessary to explain the = physical meaning of the cofactor and the reason that a number of attacks = are possible against ECDH when the cofactor is not equal to 1. =20 B. R. Tina http://tinatsou.weebly.com/contact.html= --Boundary_(ID_hK2qFfuSrhbVIyTP5dax7Q) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi,

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

 

Abstract

1. First sentence: Should >are< rather be >were<=20 ?

Introduction

2. Introduction (p.2): I would insert the word >finite< = before=20 >fields<.

3. Introduction (p.4): >ECDH< should be replaced by = >Elliptic=20 Curve Diffie-Hellman (ECDH) <.

Mathematical=20 Background

4. Mathematical Background (p.1): Should >is< rather be = >are<=20 ? The same holds in Sec.~2.2 (p.1).

5. Sec.~2.2 (p.3): The term >g< is undefined. Hence, = >g^N<=20 should be replaced by >a^N<. The same holds for >Note that a^M = is equal=20 to g^ (M mod R)< in (p.9).

6. Sec.~2.3 (p.2):  = From this=20 description, it appears to me that all elements in Z_p can perform = division=20 operation. However, only non-zero elements, namely elements in the set=20

Z_p^* =3D=20 Z_p-{0}

can perform the division operation. Moreover, all the = mathematical=20 operations over Z_p are in the sense of mod p. In addition, a prime = number p is=20 called the characteristic of a field, = if=20 1+=A1=AD+1=3D0 (add p times); in this case F_q contains the prime field = F_p, where=20 q=3Dp^n, n>=3D1. So I think the definition of the F_p lacks=20 precision.

Elliptic Curve=20 Groups

7. Elliptic Curve Groups (p.1): I think the last sentence is = too abstract=20 to understand. More precisely, the elliptic curve satisfies the=20 equations,

y^2+cy=3Dx^3+ax+b,

y^2=3Dx^3+ax^2+bx+c,

when the=20 characteristic of the field is 2 and 3,=20 respectively.

       = 8. Elliptic=20 Curve Groups (p.3): The first sentence says that >when both points = are the=20 point at Infinity<. Maybe such statement is not accurate enough due = to the=20 fundamental fact that each elliptic curve abelian group has only one infinity, i.e., the = identity=20 element.

       = 9. Sec.~3.1=20 (p.2): It seems to me that the projection space representation = >x=3DX/Z mod p ,=20 y=3DY/Z mod p< is a special case of x=3DX/Z^{c_1} mod p and y=3DY/Z^{c_2} mod p when both c_1 and c_2 are equal = to 1. If=20 so, should it be clearly explained ?

       = 10.=20 Sec.~3.3.1: I would simply state the reason for = the=20 non-zero discriminant, namely, to ensure that the elliptic curve is = chosen to be=20 a non-singular one, i.e., it has no self intersections or=20 cusps.

Elliptic Curve = Diffie-Hellman=20 (ECDH)

       = 11.=20 Elliptic Curve Groups (p.1): >an arbitrary cyclic group<  instead of >an arbitrary = mathematical=20 group< ?

Elliptic Curve ElGamal=20 Signatures

       = 12.=20 Sec.~5.1 (p.1): Insert >Galois< before >field=20 GF(2^w)<.

       = 13.=20 Sec.~5.3 (p.2): Why not denote the generator >alpha< as >g< = for=20 consistency in this draft ?

       = 14.=20 Sec.~5.3.2 (4): As the symbol = >*< denotes=20 the scalar multiplication, why use such a symbol in Sec.~2.2 to = represent the=20 addition operation in a group ? Needs to be modified=20 ?

       = 15.=20 Sec.~5.3.3 (p.1): Insert >the = generator g,=20 the group order q< before >the public key Y< in that these two=20 parameters must know in advance before the signature verification=20 procedure.

       = 16.=20 Sec.~5.3.2 (1): Should = >0<s_1<q< be=20 replaced by >s_1 = in Z_q< for consistency ? The same holds for=20 >0<s_2<q< and the sentence in Sec.~5.4.3=20 (1).

       = 17.=20 Sec.~5.3.2 (3): As mentioned above, = the symbol=20 >*< in the equation

>R'=3Dalpha^{u_1} * = Y^{u_2}< represents the = addition=20 operation of two points on the elliptic curve; while in >u_2=3Ds_1 * = s_2 mod=20 q<, it means the scalar multiplication=20 operation.

       = 18.=20 Sec.~5.6 (p.2): In the equations >A=3Dm< and >m=3D-r*z+s*k (mod = q)<,=20 does the symbol m represent a message digest ? If so, I think m should = be=20 replaced by h(m), although the hash function is not necessary here. If = not, it=20 should be transformed to an integer since it has been defined to be a = bit string=20 in Sec.~5.2. The same holds for the equation >m*s=3D-r*s*z+k (mod=20 q)<.

Converting between = integers and=20 octet strings

19. the title >Converting between integers and octet = strings<, why=20 not >Converting between Integers and Octet Strings< for = consistency ? The=20 same goes for other titles and subtitles.

Security=20 Considerations
       20. = Sec.~10.1 (p.3): I=20 think it is necessary to explain the physical meaning of the cofactor and the reason = that a=20 number of attacks are possible against ECDH when the cofactor is not = equal to=20 1.

 

 

B. R.
Tina
http://tinatsou.weebly.c= om/contact.html
--Boundary_(ID_hK2qFfuSrhbVIyTP5dax7Q)-- From yaronf.ietf@gmail.com Tue Jul 6 05:57:38 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F9BA3A6863 for ; Tue, 6 Jul 2010 05:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuDR8K8XTJAg for ; Tue, 6 Jul 2010 05:57:36 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 404D53A6876 for ; Tue, 6 Jul 2010 05:57:36 -0700 (PDT) Received: by ywa8 with SMTP id 8so6190ywa.31 for ; Tue, 06 Jul 2010 05:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=iTUfKNIAWJMVtCyakAjWiLBcamXtpuxPjd0JqAgF2lo=; b=e6OgHFK2p5Ed0paCgBy3d+AxlFtRAb++nf18yAaUFJbdmVQj1+aVKFlBh+egVeIEzo PQdy9uua+lMwp/Osbn1+OGux590ROe41ii5aSkuB+kzHIfyYVRVfXz5FejDTruJNeZuz bGki6dtUYvmBpsFmS3dl8A5dh07zrEqMGVui8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=pA5rFTE9jrrbB90TBsmZd9rd0CxnvW+HeqdgTrktpaV/1pS47DAiEyKmZcwp4LxIZD kNUR7IaLrocBTqJNhDDt6e56Ez7eTckS/ke4hOuWGG4WRXAv0lkizPkqpRWnNwW5gqkI ZcukH97nZtitjrPS4aalksCMa5+U1zi24FkxI= Received: by 10.213.32.197 with SMTP id e5mr4126960ebd.92.1278421054839; Tue, 06 Jul 2010 05:57:34 -0700 (PDT) Received: from [10.0.0.1] ([109.67.45.226]) by mx.google.com with ESMTPS id a48sm50129446eei.12.2010.07.06.05.57.31 (version=SSLv3 cipher=RC4-MD5); Tue, 06 Jul 2010 05:57:33 -0700 (PDT) Message-ID: <4C332838.4070607@gmail.com> Date: Tue, 06 Jul 2010 15:57:28 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Charles Shen References: <4C148FB1.8060709@gmail.com> <4C1DFF97.1020103@gmail.com> <4C3088E1.6000100@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Henning Schulzrinne , draft-ietf-nsis-tunnel.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-nsis-tunnel-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 12:57:38 -0000 Looks good to me. Thanks, Yaron On 07/06/2010 03:59 AM, Charles Shen wrote: > Hi Yaron, I have just submitted a revised version. please take a look > and let me know if you have any further comments. > > Thanks again. > > Charles > > > > > On Sun, Jul 4, 2010 at 9:13 AM, Yaron Sheffer wrote: >> Hi Charles, >> >> I have been assigned your draft for a secdir re-review. The draft has not >> been revised since my last review, so I will just reiterate: I recommend >> that the Security Considerations be improved before the document goes into >> IESG telechat. >> >> Thanks, >> Yaron >> >> On 06/21/2010 06:15 PM, Charles Shen wrote: >>> >>> Thanks Yaron, please see inline. >>> >>> On Sun, Jun 20, 2010 at 7:46 AM, Yaron Sheffer >>> wrote: >>>> >>>> [Removed the IESG.] >>>> >>>> Hi Charles, >>>> >>>> please see my comments inline. >>>> >>>> Thanks, >>>> Yaron >>>> >>>> On 06/20/2010 06:52 AM, Charles Shen wrote: >>>>> >>>>> Hi Yaron, thank you for your careful review. Please see comments inline. >>>>> >>>>> On Sun, Jun 13, 2010 at 3:58 AM, Yaron Sheffer >>>>> wrote: >>>>>> >>>>>> I have reviewed this document as part of the security directorate's >>>>>> ongoing effort to review all IETF documents being processed by the >>>>>> IESG. >>>>>> These comments were written primarily for the benefit of the security >>>>>> area directors. Document editors and WG chairs should treat these >>>>>> comments just like any other last call comments. >>>>>> >>>>>> This draft discusses the problem of NSIS messages (particularly, QoS >>>>>> reservation flows) being encapsulated into various IP tunneling >>>>>> protocols, >>>>>> which prevent the correct QoS setup from being performed. The draft >>>>>> proposes >>>>>> a solution for NSIS tunnel-aware tunnel endpoints, which basically adds >>>>>> an >>>>>> NSIS signaling flow between the tunnel endpoints, but outside of the >>>>>> tunnel. >>>>>> >>>>>> General >>>>>> >>>>>> The draft presents the problem, and the solution, reasonably well. >>>>>> >>>>>> The draft goes for the "no new security issues" approach. I think this >>>>>> is >>>>>> incorrect, and in fact a number of security issues should be analyzed >>>>>> and >>>>>> possibly resolved. In addition, as a complete outsider to NSIS, I have >>>>>> identified one major unspecified piece, leading me to believe that the >>>>>> draft >>>>>> has not had enough review. >>>>>> >>>>>> Security >>>>>> >>>>>> The main security issue is that the draft fails to consider >>>>>> security-oriented tunnels. IPsec tunnels (and the commonly used >>>>>> GRE-over-IPsec) provide security services: normally encryption and >>>>>> integrity >>>>>> protection with ESP, less commonly integrity-protection only with AH, >>>>>> ESP >>>>>> with null encryption, or the new WESP (RFC 5840). The proposed solution >>>>>> raises at least three major security issues related to these tunnels: >>>>>> >>>>>> 1. A so-called covert channel that results from NSIS flows in the >>>>>> protected >>>>>> networks directly triggering NSIS protocol exchanges in an unprotected >>>>>> network (i.e. between the tunnel endpoints). Please see Appendix B.1 of >>>>>> draft-ietf-tsvwg-ecn-tunnel-08 for treatment of a similar issue. >>>>>> >>>>> >>>>> With regard to this specific draft, I see the problem as a more >>>>> generic issue which exists also for other protocols (e.g., RSVP) >>>>> requiring per-hop processing to interact with IPSec. E.g., RFC4302 >>>>> mentions that "NOTE: Use of the Router Alert option is potentially >>>>> incompatible with use of IPsec. Although the option is immutable, its >>>>> use implies that each router along a packet's path will "process" the >>>>> packet and consequently might change the packet.". I think that >>>>> mentioning of this potential incompatibility will be beneficial. But I >>>>> don't quite see how "limiting the bandwidth of the covert channel" as >>>>> discussed in Appendix B.1 of draft-ietf-tsvwg-ecn-tunnel-08 can be >>>>> applied here. Please correct me if I were wrong. >>>>> >>>> You can say this solution is incompatible with IPsec and be done with it. >>>> Otherwise, there is a "covert channel >>>> " - someone can create >>>> spurious >>>> NSIS signaling flows within the protected network, just to create >>>> signaling >>>> in the outside network, which then someone else is monitoring. For highly >>>> secure networks, this would be seen as a way to smuggle information out >>>> of >>>> the network, and you would want to rate-limit this channel. >>>>> >>> >>> That makes sense. My understanding is that the rate-limit does not >>> complete solve the problem, but does reduce the potential harm. >>> >>> >>>>>> 2. A more serious interaction in the other direction: unprotected NSIS >>>>>> flows >>>>>> outside the tunnel interact with NSIS flows in the protected networks >>>>>> and >>>>>> inside the tunnel, and so, an attacker in the unprotected network can >>>>>> possibly influence QoS behavior in protected networks. >>>>>> >>>>>> 3. A practical result of (2) is that the NSIS protocol stack on the >>>>>> tunnel >>>>>> endpoint is now exposed to unprotected networks and therefore suddenly >>>>>> becomes security-critical. >>>>>> >>>>> >>>>> IMHO, if we have a segment of the path which is compromised, the QoS >>>>> of the rest of the path segments (and the end-to-end QoS) can be >>>>> easily affected anyway, whether you have a tunnel segment in the path >>>>> or not. Therefore, it doesn't seem to me as a new threat introduced by >>>>> this document per se. But it will certainly also be helpful to mention >>>>> this scenario in the security considerations section. >>>> >>>> What I'm saying in #3 is that any security vulnerability (e.g. buffer >>>> overflow) in the NSIS stack is suddenly exposed to the big bad Internet, >>>> even when the customer may have expected all their traffic to be >>>> protected >>>> by a VPN gateway, where the VPN software is normally the only software >>>> that >>>> needs to be hardened. >>> >>> I agree. What I had been thinking is that compromise of other nodes >>> (non-tunnel end-points) may similarly affect end-to-end QoS signaling, >>> even if the end-to-end path includes a secure tunnel. >>> >>>>> >>>>>> Non-Security >>>>>> >>>>>> The draft defines extra UDP encapsulation in some cases ("the tunnel >>>>>> entry-point inserts an additional UDP header"), but the format >>>>>> (specifically, the port number) is not specified. This omission is >>>>>> strange, >>>>>> because the protocol cannot be implemented in the absence of this >>>>>> information! >>>>>> >>>>> >>>>> To me this is an intended feature. The mechanism does not require a >>>>> pre-allocated fixed UDP port, but allows the port to be dynamically >>>>> chosen and conveyed during the tunnel flow/session binding operations. >>>>> >>>> Sure, I missed this point. Can you please mention it explicitly. >>>> >>> >>> Sure! >>> >>> Thanks >>> >>> Charles >> From secdir-bounces@mit.edu Sat Jul 3 10:32:52 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D4D13A67F4 for ; Sat, 3 Jul 2010 10:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIiN5puq+7pe for ; Sat, 3 Jul 2010 10:32:47 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id D11C43A6811 for ; Sat, 3 Jul 2010 10:32:46 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o63HWvP6009955 for ; Sat, 3 Jul 2010 13:32:57 -0400 Received: from mailhub-dmz-2.mit.edu (MAILHUB-DMZ-2.MIT.EDU [18.7.62.37]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o63HWtpM009951 for ; Sat, 3 Jul 2010 13:32:55 -0400 Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by mailhub-dmz-2.mit.edu (8.13.8/8.9.2) with ESMTP id o63HWsma021524 for ; Sat, 3 Jul 2010 13:32:54 -0400 X-AuditID: 12074424-b7b63ae000000a0b-4a-4c2f74456a77 Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id E1.4E.02571.6447F2C4; Sat, 3 Jul 2010 13:32:54 -0400 (EDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o63HWmRX030453; Sat, 3 Jul 2010 10:32:48 -0700 Received: from brm-exedge.brocade.com (brm-exedge.brocade.com [144.49.197.7]) by mx0a-000f0801.pphosted.com with ESMTP id pt42h03b4-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 03 Jul 2010 10:32:47 -0700 Received: from brm-excashub-1.corp.brocade.com (172.16.72.131) by BRM-EXEDGE-1.corp.brocade.com (172.16.72.149) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 3 Jul 2010 11:32:14 -0600 Received: from brm-exch-3.corp.brocade.com ([169.254.3.246]) by brm-excashub-1.corp.brocade.com ([172.16.72.131]) with mapi; Sat, 3 Jul 2010 11:32:46 -0600 From: Jaehoon Jeong To: Vincent Roca Date: Sat, 3 Jul 2010 11:32:40 -0600 Thread-Topic: SecDir review of draft-ietf-6man-dns-options-bis-03 Thread-Index: AcsasDpvniSK/grqQTaQyM5iV1HDqgAHM7kg Message-ID: <5A6980BCAE9E6D438D4D8A05540F6FB70115513677@BRM-EXCH-3.corp.brocade.com> References: <4C248D9A.5080508@inrialpes.fr> <5A6980BCAE9E6D438D4D8A05540F6FB70113043B9B@BRM-EXCH-3.corp.brocade.com> <4C25CA06.1080809@piuha.net> <5A6980BCAE9E6D438D4D8A05540F6FB70113658855@BRM-EXCH-3.corp.brocade.com> <4C2F3541.7000206@inrialpes.fr> In-Reply-To: <4C2F3541.7000206@inrialpes.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-02_03:2010-02-06, 2010-07-02, 2010-07-03 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1007030069 X-Brightmail-Tracker: AAAAAhTzSz4U9B3E X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id o63HWtpM009951 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Tue, 06 Jul 2010 08:40:02 -0700 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, "secdir@mit.edu" , "draft-ietf-6man-dns-options-bis.all@tools.ietf.org" , Jari Arkko , IESG Subject: Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 17:32:52 -0000 Hi Vincent, I would like to address your comments as below. The updated I-D is located in the following link: http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-ietf-6man-dns-options-bis-06.txt On Sat, Jul 3, 2010 at 11:31 AM, Jaehoon Jeong wrote: > > > -----Original Message----- > From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] > Sent: Saturday, July 03, 2010 8:04 AM > To: Jaehoon Jeong > Cc: Jari Arkko; draft-ietf-6man-dns-options-bis.all@tools.ietf.org; secdir@mit.edu; IESG; 6man Chairs; vincent.roca@inrialpes.fr > Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03 > > Dear authors, > > Thanks for your prompt reply. A few additional comments (it's my role ;-)) > > ** new "Security Considerations" section says: >> This attack >> is similar to Neighbor Discovery attacks that use Redirect or >> Neighbor Advertisement messages to redirect traffic to individual >> addresses to malicious parties. In general, the attacks related to >> RDNSS and DNSSL are similar to both Neighbor Discovery attacks and >> attacks against unauthenticated DHCP, as both can be used for both >> "wholesale" traffic redirection and more specific attacks. >> > You're right, other attacks are possible that lead to the same result. ND and unauthenticated DHCP are such possibilities. However, IMHO this is not a sufficient reason not to RECOMMEND a security solution for RA. > Indeed, if ND / DHCP are made robust but nothing is done for RA, then the threat remains. > > So the updated text does not fully satisfies me, even if the new paragraph is more clear than the old one. I reorganize the text such that the description for SEND (as a security solution for RA) follows the above paragraph: ... In general, the attacks related to RDNSS and DNSSL are similar to both Neighbor Discovery attacks and attacks against unauthenticated DHCP, as both can be used for both "wholesale" traffic redirection and more specific attacks. If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as a security mechanism for ND, all the ND options including the RDNSS and DNSSL options are automatically included in the signatures, so the transport for the RA options is integrity-protected; that is, SEND can prevent the spoofing of these DNS options with signatures. Also, SEND enables an IPv6 host to verify that the sender of an RA is actually a router authorized to act as a router. However, since any valid SEND router can still insert RDNSS and DNSSL options, SEND cannot verify which one is or is not authorized to send the options. > >>> ** Section 7: >>> Another point... the authors explain than network devices like >>> switches can be configured in such a way to disable ND/DHCP from some >>> ports. That's great and I agree it helps preventing attacks. >>> However this is limited to wired networks. Nothing is said concerning >>> ND configurations in wireless networks. The situation is rather >>> different since any host can issue ND/DHCP traffic as if it were a >>> legitimate server if I understand correctly. The document MUST >>> include this kind of discussion. >>> >>> >> But this is generic issue with spoofing RAs and I am not sure it is >> the task of this document to specify the solutions. One solution >> exists in SEND (RFC 3791). >> > Once again I agree. You don't have to specify technical solutions. However you need to provide a good security analysis, perhaps inherited from that of the base RA document for the generic RA threats, with some text describing the additional threats added by the proposed extensions. And since security solutions exist elsewhere (SEND), you should recommend their use. That's your responsibility. In the following paragraph, we address that SEND can prevent such RA DNS option spoofing: If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as a security mechanism for ND, all the ND options including the RDNSS and DNSSL options are automatically included in the signatures, so the transport for the RA options is integrity-protected; that is, SEND can prevent the spoofing of these DNS options with signatures. Also, SEND enables an IPv6 host to verify that the sender of an RA is actually a router authorized to act as a router. However, since any valid SEND router can still insert RDNSS and DNSSL options, SEND cannot verify which one is or is not authorized to send the options. > >>> ** Section 7: >>> Yet another remark: SEND is listed as one potential solution to add >>> signatures in ND packets issued from servers. >>> I don't know SEND at all, so may be my remarks are flawed (but in >>> that case the text should be at least clarified). >>> - Shouldn't the use of SEND be RECOMMENDED as a solution to mitigate >>> attacks? Current document is not clear. >>> - Does SEND enable an authentication of the sender (the document only >>> mentions integrity protection)? If there's no sender authentication, >>> then I agree that the added value of SEND would be limited. I'd like >>> the authors to clarify this as well. >>> >>> >> The details are in RFC 3791 and its companion documents. SEND does >> enable a host to verify that the sender of an RA is actually a router >> authorized to act as a router. >> > > The text in your proposed I-D update does not reflect this. Can you add it? Being able to authenticate the sender is as important as being able to check the packet integrity. According to the comments, the checking for valid router is mentioned in the middle: If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as a security mechanism for ND, all the ND options including the RDNSS and DNSSL options are automatically included in the signatures, so the transport for the RA options is integrity-protected; that is, SEND can prevent the spoofing of these DNS options with signatures. Also, SEND enables an IPv6 host to verify that the sender of an RA is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ actually a router authorized to act as a router. However, since any ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ valid SEND router can still insert RDNSS and DNSSL options, SEND cannot verify which one is or is not authorized to send the options. > > ** I'm coming back to a comment I made earlier and that has not been answered. > > In the updated I-D, section 5.3.1, I read: > > "In the case where the DNS options of RDNSS and DNSSL can be obtained > from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep > some DNS options from all sources. " > > I don't see (but I read very quickly so I may have missed > something) that secured RA/RDNSS/DNSSL messages be preferred in the choice. If some RA use SEND, they must be preferred over others. > In Section 5.3.1, the considerations on SEND is mentioned as follows: In the case where the DNS options of RDNSS and DNSSL can be obtained from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep some DNS options from all sources. Unless explicitly specified for the discovery mechanism, the exact number of addresses and domain names to keep is a matter of local policy and implementation choice. However, it is RECOMMENDED that at least three RDNSS addresses (or DNSSL domain names) can be stored from at least two different sources. The DNS options from Router Advertisements and DHCP SHOULD be stored into DNS Repository and Resolver Repository so that information from DHCP appears there first and therefore takes precedence. Thus, the DNS information from DHCP takes precedence over that from RA for DNS queries. On the other hand, for DNS ^^^^^^^^^^^^^^^^^^^^^^^^^ options announced by RA, if some RAs use the Secure Neighbor ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Discovery (SEND) protocol [RFC3971] for RA security, they MUST be ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ preferred over those which do not use SEND. Refer to Section 7 for ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the detailed discussion on SEND for RA DNS options. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I hope my comments are useful. > Cheers, > > Vincent > Thanks for your efforts on the improvement for this document. Best Regards, Paul _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From charles.newyork@gmail.com Mon Jul 5 17:59:37 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D54A3A63CB for ; Mon, 5 Jul 2010 17:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0-ydv6-Yo3W for ; Mon, 5 Jul 2010 17:59:36 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 1333A3A67F3 for ; Mon, 5 Jul 2010 17:59:36 -0700 (PDT) Received: by iwn38 with SMTP id 38so399532iwn.31 for ; Mon, 05 Jul 2010 17:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=X6YwSDEnUQaY9mLecVjZ1AUYMjhPgaOU0LDq8oQDWc8=; b=BRB2nvwaI8qUkPwC9XwqWPqmpJvgyMeqEXPpogd+tMDQhp8HssvB7NouqpqJD+ZN3w 1gwxz1k4JCi8S0UzLzFcrkV/FRkqOtPmVcAk4+wuAThP7MsZ1SySIZvHxGQciImmE7lK CQIZA41yjkb/FXXHQV6L1eSCYbRC9i6Y6DLxg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=t8jHVqPuX3rMfEH62v1yiTqv2QrgPSQd/NYwMWyNVi9NTmHA4AdmMmZenSzCCmtBJ5 s1UuDbt6pQ/yFsERdAlhg9vXZjElDrCy/4or085WSglROvwGgMXdsKGpsnrEZ1lFfHcW jEr95bvGu0J2Zh/LX1vj8xeWbvHnyxni9/DpQ= MIME-Version: 1.0 Received: by 10.231.174.201 with SMTP id u9mr3773357ibz.17.1278377977592; Mon, 05 Jul 2010 17:59:37 -0700 (PDT) Sender: charles.newyork@gmail.com Received: by 10.231.14.136 with HTTP; Mon, 5 Jul 2010 17:59:37 -0700 (PDT) In-Reply-To: <4C3088E1.6000100@gmail.com> References: <4C148FB1.8060709@gmail.com> <4C1DFF97.1020103@gmail.com> <4C3088E1.6000100@gmail.com> Date: Mon, 5 Jul 2010 20:59:37 -0400 X-Google-Sender-Auth: ibE5BLhzPOmHqvzu8899Eo2D090 Message-ID: From: Charles Shen To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 06 Jul 2010 08:40:02 -0700 Cc: Henning Schulzrinne , draft-ietf-nsis-tunnel.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-nsis-tunnel-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 00:59:37 -0000 Hi Yaron, I have just submitted a revised version. please take a look and let me know if you have any further comments. Thanks again. Charles On Sun, Jul 4, 2010 at 9:13 AM, Yaron Sheffer wrote= : > Hi Charles, > > I have been assigned your draft for a secdir re-review. The draft has not > been revised since my last review, so I will just reiterate: I recommend > that the Security Considerations be improved before the document goes int= o > IESG telechat. > > Thanks, > =C2=A0 =C2=A0 =C2=A0 =C2=A0Yaron > > On 06/21/2010 06:15 PM, Charles Shen wrote: >> >> Thanks Yaron, please see inline. >> >> On Sun, Jun 20, 2010 at 7:46 AM, Yaron Sheffer >> =C2=A0wrote: >>> >>> [Removed the IESG.] >>> >>> Hi Charles, >>> >>> please see my comments inline. >>> >>> Thanks, >>> =C2=A0 =C2=A0Yaron >>> >>> On 06/20/2010 06:52 AM, Charles Shen wrote: >>>> >>>> Hi Yaron, thank you for your careful review. Please see comments inlin= e. >>>> >>>> On Sun, Jun 13, 2010 at 3:58 AM, Yaron Sheffer >>>> =C2=A0wrote: >>>>> >>>>> 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. =C2=A0Document editors and WG chairs should treat the= se >>>>> comments just like any other last call comments. >>>>> >>>>> This draft discusses the problem of NSIS messages (particularly, QoS >>>>> reservation flows) being encapsulated into various IP tunneling >>>>> protocols, >>>>> which prevent the correct QoS setup from being performed. The draft >>>>> proposes >>>>> a solution for NSIS tunnel-aware tunnel endpoints, which basically ad= ds >>>>> an >>>>> NSIS signaling flow between the tunnel endpoints, but outside of the >>>>> tunnel. >>>>> >>>>> General >>>>> >>>>> The draft presents the problem, and the solution, reasonably well. >>>>> >>>>> The draft goes for the "no new security issues" approach. I think thi= s >>>>> is >>>>> incorrect, and in fact a number of security issues should be analyzed >>>>> and >>>>> possibly resolved. In addition, as a complete outsider to NSIS, I hav= e >>>>> identified one major unspecified piece, leading me to believe that th= e >>>>> draft >>>>> has not had enough review. >>>>> >>>>> Security >>>>> >>>>> The main security issue is that the draft fails to consider >>>>> security-oriented tunnels. IPsec tunnels (and the commonly used >>>>> GRE-over-IPsec) provide security services: normally encryption and >>>>> integrity >>>>> protection with ESP, less commonly integrity-protection only with AH, >>>>> ESP >>>>> with null encryption, or the new WESP (RFC 5840). The proposed soluti= on >>>>> raises at least three major security issues related to these tunnels: >>>>> >>>>> 1. A so-called covert channel that results from NSIS flows in the >>>>> protected >>>>> networks directly triggering NSIS protocol exchanges in an unprotecte= d >>>>> network (i.e. between the tunnel endpoints). Please see Appendix B.1 = of >>>>> draft-ietf-tsvwg-ecn-tunnel-08 for treatment of a similar issue. >>>>> >>>> >>>> With regard to this specific draft, I see the problem as a more >>>> generic issue which exists also for other protocols (e.g., RSVP) >>>> requiring per-hop processing to interact with IPSec. E.g., RFC4302 >>>> mentions that "NOTE: Use of the Router Alert option is potentially >>>> incompatible with use of IPsec. Although the option is immutable, its >>>> use implies that each router along a packet's path will "process" the >>>> packet and consequently might change the packet.". I think that >>>> mentioning of this potential incompatibility will be beneficial. But I >>>> don't quite see how "limiting the bandwidth of the covert channel" as >>>> discussed in Appendix B.1 of draft-ietf-tsvwg-ecn-tunnel-08 can be >>>> applied here. Please correct me if I were wrong. >>>> >>> You can say this solution is incompatible with IPsec and be done with i= t. >>> Otherwise, there is a "covert channel >>> " - someone can create >>> spurious >>> NSIS signaling flows within the protected network, just to create >>> signaling >>> in the outside network, which then someone else is monitoring. For high= ly >>> secure networks, this would be seen as a way to smuggle information out >>> of >>> the network, and you would want to rate-limit this channel. >>>> >> >> That makes sense. My understanding is that the rate-limit does not >> complete solve the problem, but does reduce the potential harm. >> >> >>>>> 2. A more serious interaction in the other direction: unprotected NSI= S >>>>> flows >>>>> outside the tunnel interact with NSIS flows in the protected networks >>>>> and >>>>> inside the tunnel, and so, an attacker in the unprotected network can >>>>> possibly influence QoS behavior in protected networks. >>>>> >>>>> 3. A practical result of (2) is that the NSIS protocol stack on the >>>>> tunnel >>>>> endpoint is now exposed to unprotected networks and therefore suddenl= y >>>>> becomes security-critical. >>>>> >>>> >>>> IMHO, if we have a segment of the path which is compromised, the QoS >>>> of the rest of the path segments (and the end-to-end QoS) can be >>>> easily affected anyway, whether you have a tunnel segment in the path >>>> or not. Therefore, it doesn't seem to me as a new threat introduced by >>>> this document per se. But it will certainly also be helpful to mention >>>> this scenario in the security considerations section. >>> >>> What I'm saying in #3 is that any security vulnerability (e.g. buffer >>> overflow) in the NSIS stack is suddenly exposed to the big bad Internet= , >>> even when the customer may have expected all their traffic to be >>> protected >>> by a VPN gateway, where the VPN software is normally the only software >>> that >>> needs to be hardened. >> >> I agree. What I had been thinking is that compromise of other nodes >> (non-tunnel end-points) may similarly affect end-to-end QoS signaling, >> even if the end-to-end path includes a secure tunnel. >> >>>> >>>>> Non-Security >>>>> >>>>> The draft defines extra UDP encapsulation in some cases ("the tunnel >>>>> entry-point inserts an additional UDP header"), but the format >>>>> (specifically, the port number) is not specified. This omission is >>>>> strange, >>>>> because the protocol cannot be implemented in the absence of this >>>>> information! >>>>> >>>> >>>> To me this is an intended feature. The mechanism does not require a >>>> pre-allocated fixed UDP port, but allows the port to be dynamically >>>> chosen and conveyed during the tunnel flow/session binding operations. >>>> >>> Sure, I missed this point. Can you please mention it explicitly. >>> >> >> Sure! >> >> Thanks >> >> Charles > From secdir-bounces@mit.edu Tue Jul 6 07:37:20 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D7E03A6809 for ; Tue, 6 Jul 2010 07:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=2.167, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWHM2ir8tnLa for ; Tue, 6 Jul 2010 07:37:19 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id CD1443A67FA for ; Tue, 6 Jul 2010 07:37:18 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o66EbKmt031031 for ; Tue, 6 Jul 2010 10:37:20 -0400 Received: from mailhub-dmz-3.mit.edu (MAILHUB-DMZ-3.MIT.EDU [18.9.21.42]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o66EbH6s031012 for ; Tue, 6 Jul 2010 10:37:18 -0400 Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by mailhub-dmz-3.mit.edu (8.13.8/8.9.2) with ESMTP id o66EaFad014698 for ; Tue, 6 Jul 2010 10:37:17 -0400 X-AuditID: 1209190d-b7c19ae0000009ea-ad-4c333f9cf0a3 Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by dmz-mailsec-scanner-2.mit.edu (Symantec Brightmail Gateway) with SMTP id 5B.9D.02538.C9F333C4; Tue, 6 Jul 2010 10:37:17 -0400 (EDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o66EZG4O006882; Tue, 6 Jul 2010 07:37:10 -0700 Received: from brm-exedge.brocade.com (brm-exedge.brocade.com [144.49.197.8]) by mx0a-000f0801.pphosted.com with ESMTP id puy0185xm-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 06 Jul 2010 07:37:10 -0700 Received: from brm-excashub-2.corp.brocade.com (172.16.72.231) by BRM-EXEDGE-2.corp.brocade.com (172.16.72.249) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 6 Jul 2010 08:37:04 -0600 Received: from brm-exch-3.corp.brocade.com ([169.254.3.246]) by brm-excashub-2.corp.brocade.com ([172.16.72.231]) with mapi; Tue, 6 Jul 2010 08:37:08 -0600 From: Jaehoon Jeong To: Jari Arkko Date: Tue, 6 Jul 2010 08:37:06 -0600 Thread-Topic: SecDir review of draft-ietf-6man-dns-options-bis-03 Thread-Index: AcsasDpvniSK/grqQTaQyM5iV1HDqgAHM7kgAJLLXnA= Message-ID: <5A6980BCAE9E6D438D4D8A05540F6FB70115649BE6@BRM-EXCH-3.corp.brocade.com> References: <4C248D9A.5080508@inrialpes.fr> <5A6980BCAE9E6D438D4D8A05540F6FB70113043B9B@BRM-EXCH-3.corp.brocade.com> <4C25CA06.1080809@piuha.net> <5A6980BCAE9E6D438D4D8A05540F6FB70113658855@BRM-EXCH-3.corp.brocade.com> <4C2F3541.7000206@inrialpes.fr> <5A6980BCAE9E6D438D4D8A05540F6FB70115513677@BRM-EXCH-3.corp.brocade.com> In-Reply-To: <5A6980BCAE9E6D438D4D8A05540F6FB70115513677@BRM-EXCH-3.corp.brocade.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-06_01:2010-02-06, 2010-07-06, 2010-07-06 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1007060060 X-Brightmail-Tracker: AAAAAhTzSz4U9B3E X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id o66EbH6s031012 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Tue, 06 Jul 2010 08:40:03 -0700 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, "secdir@mit.edu" , "draft-ietf-6man-dns-options-bis.all@tools.ietf.org" , IESG Subject: Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 14:37:20 -0000 Hi Jari, Is this update fine to you along with Section 5.3.2 (Warnings for DNS Options Configuration)? The difference between 05-version and 06-version is located at: http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/wdiff%20draft-ietf-6man-dns-options-bis-05_txt%20draft-ietf-6man-dns-options-bis-06_txt.htm If so, I will submit the version 06-ID today. Thanks. Best Regards, Paul -----Original Message----- From: Jaehoon Jeong [mailto:pjeong@Brocade.com] Sent: Saturday, July 03, 2010 12:33 PM To: Vincent Roca Cc: Jari Arkko; draft-ietf-6man-dns-options-bis.all@tools.ietf.org; secdir@mit.edu; IESG; 6man Chairs Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03 Hi Vincent, I would like to address your comments as below. The updated I-D is located in the following link: http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-ietf-6man-dns-options-bis-06.txt On Sat, Jul 3, 2010 at 11:31 AM, Jaehoon Jeong wrote: > > > -----Original Message----- > From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] > Sent: Saturday, July 03, 2010 8:04 AM > To: Jaehoon Jeong > Cc: Jari Arkko; draft-ietf-6man-dns-options-bis.all@tools.ietf.org; > secdir@mit.edu; IESG; 6man Chairs; vincent.roca@inrialpes.fr > Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03 > > Dear authors, > > Thanks for your prompt reply. A few additional comments (it's my role > ;-)) > > ** new "Security Considerations" section says: >> This attack >> is similar to Neighbor Discovery attacks that use Redirect or >> Neighbor Advertisement messages to redirect traffic to individual >> addresses to malicious parties. In general, the attacks related to >> RDNSS and DNSSL are similar to both Neighbor Discovery attacks and >> attacks against unauthenticated DHCP, as both can be used for both >> "wholesale" traffic redirection and more specific attacks. >> > You're right, other attacks are possible that lead to the same result. ND and unauthenticated DHCP are such possibilities. However, IMHO this is not a sufficient reason not to RECOMMEND a security solution for RA. > Indeed, if ND / DHCP are made robust but nothing is done for RA, then the threat remains. > > So the updated text does not fully satisfies me, even if the new paragraph is more clear than the old one. I reorganize the text such that the description for SEND (as a security solution for RA) follows the above paragraph: ... In general, the attacks related to RDNSS and DNSSL are similar to both Neighbor Discovery attacks and attacks against unauthenticated DHCP, as both can be used for both "wholesale" traffic redirection and more specific attacks. If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as a security mechanism for ND, all the ND options including the RDNSS and DNSSL options are automatically included in the signatures, so the transport for the RA options is integrity-protected; that is, SEND can prevent the spoofing of these DNS options with signatures. Also, SEND enables an IPv6 host to verify that the sender of an RA is actually a router authorized to act as a router. However, since any valid SEND router can still insert RDNSS and DNSSL options, SEND cannot verify which one is or is not authorized to send the options. > >>> ** Section 7: >>> Another point... the authors explain than network devices like >>> switches can be configured in such a way to disable ND/DHCP from >>> some ports. That's great and I agree it helps preventing attacks. >>> However this is limited to wired networks. Nothing is said >>> concerning ND configurations in wireless networks. The situation is >>> rather different since any host can issue ND/DHCP traffic as if it >>> were a legitimate server if I understand correctly. The document >>> MUST include this kind of discussion. >>> >>> >> But this is generic issue with spoofing RAs and I am not sure it is >> the task of this document to specify the solutions. One solution >> exists in SEND (RFC 3791). >> > Once again I agree. You don't have to specify technical solutions. However you need to provide a good security analysis, perhaps inherited from that of the base RA document for the generic RA threats, with some text describing the additional threats added by the proposed extensions. And since security solutions exist elsewhere (SEND), you should recommend their use. That's your responsibility. In the following paragraph, we address that SEND can prevent such RA DNS option spoofing: If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as a security mechanism for ND, all the ND options including the RDNSS and DNSSL options are automatically included in the signatures, so the transport for the RA options is integrity-protected; that is, SEND can prevent the spoofing of these DNS options with signatures. Also, SEND enables an IPv6 host to verify that the sender of an RA is actually a router authorized to act as a router. However, since any valid SEND router can still insert RDNSS and DNSSL options, SEND cannot verify which one is or is not authorized to send the options. > >>> ** Section 7: >>> Yet another remark: SEND is listed as one potential solution to add >>> signatures in ND packets issued from servers. >>> I don't know SEND at all, so may be my remarks are flawed (but in >>> that case the text should be at least clarified). >>> - Shouldn't the use of SEND be RECOMMENDED as a solution to mitigate >>> attacks? Current document is not clear. >>> - Does SEND enable an authentication of the sender (the document >>> only mentions integrity protection)? If there's no sender >>> authentication, then I agree that the added value of SEND would be >>> limited. I'd like the authors to clarify this as well. >>> >>> >> The details are in RFC 3791 and its companion documents. SEND does >> enable a host to verify that the sender of an RA is actually a router >> authorized to act as a router. >> > > The text in your proposed I-D update does not reflect this. Can you add it? Being able to authenticate the sender is as important as being able to check the packet integrity. According to the comments, the checking for valid router is mentioned in the middle: If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as a security mechanism for ND, all the ND options including the RDNSS and DNSSL options are automatically included in the signatures, so the transport for the RA options is integrity-protected; that is, SEND can prevent the spoofing of these DNS options with signatures. Also, SEND enables an IPv6 host to verify that the sender of an RA is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ actually a router authorized to act as a router. However, since any ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ valid SEND router can still insert RDNSS and DNSSL options, SEND cannot verify which one is or is not authorized to send the options. > > ** I'm coming back to a comment I made earlier and that has not been answered. > > In the updated I-D, section 5.3.1, I read: > > "In the case where the DNS options of RDNSS and DNSSL can be obtained > from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep > some DNS options from all sources. " > > I don't see (but I read very quickly so I may have missed > something) that secured RA/RDNSS/DNSSL messages be preferred in the choice. If some RA use SEND, they must be preferred over others. > In Section 5.3.1, the considerations on SEND is mentioned as follows: In the case where the DNS options of RDNSS and DNSSL can be obtained from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep some DNS options from all sources. Unless explicitly specified for the discovery mechanism, the exact number of addresses and domain names to keep is a matter of local policy and implementation choice. However, it is RECOMMENDED that at least three RDNSS addresses (or DNSSL domain names) can be stored from at least two different sources. The DNS options from Router Advertisements and DHCP SHOULD be stored into DNS Repository and Resolver Repository so that information from DHCP appears there first and therefore takes precedence. Thus, the DNS information from DHCP takes precedence over that from RA for DNS queries. On the other hand, for DNS ^^^^^^^^^^^^^^^^^^^^^^^^^ options announced by RA, if some RAs use the Secure Neighbor ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Discovery (SEND) protocol [RFC3971] for RA security, they MUST be ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ preferred over those which do not use SEND. Refer to Section 7 for ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the detailed discussion on SEND for RA DNS options. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I hope my comments are useful. > Cheers, > > Vincent > Thanks for your efforts on the improvement for this document. Best Regards, Paul _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From alberto@it.uc3m.es Tue Jul 6 08:32:54 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E06A3A63C9; Tue, 6 Jul 2010 08:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.698 X-Spam-Level: X-Spam-Status: No, score=-3.698 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxLrCCPqEkF8; Tue, 6 Jul 2010 08:32:44 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 7E10A3A6973; Tue, 6 Jul 2010 08:32:42 -0700 (PDT) X-uc3m-safe: yes Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id EF31E65521E; Tue, 6 Jul 2010 17:32:42 +0200 (CEST) From: =?ISO-8859-15?Q?Alberto_Garc=EDa?= To: "'Sandra Murphy'" , , , , Date: Tue, 6 Jul 2010 17:32:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008C_01CB1D31.3C488620" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcsdIELAT3gnY73lTtidmX3OxNhNnQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17490.000 X-Mailman-Approved-At: Tue, 06 Jul 2010 08:40:01 -0700 Cc: csi-chairs@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 15:32:54 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_008C_01CB1D31.3C488620 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit Hi, The text of this email has been extracted from a thorough review of draft-ietf-csi-proxy-send being made by Sandra Murphy. The reason why the email has been separated is to include the authors of draft-ietf-csi-send-cert in the discussion of this part of the text, since I think some of the issues raised by Sandra affect this document. I include my comments inline. | -----Mensaje original----- | De: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] | Enviado el: viernes, 02 de julio de 2010 2:31 | Para: iesg@ietf.org; secdir@ietf.org; draft-ietf-csi-proxy-send.all@tools.ietf.org | Asunto: secdir review of draft-ietf-csi-proxy-send-04 | | This is a review of draft draft-ietf-csi-proxy-send-04.txt. | | 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 provides new Neighbor Discovery options that will secure | proxied Neighbor Discovery messages. It is an update to: | | RFC4861: Neighbor Discovery in IPv6 | RFC4389: Neighbor Discovery Proxies (ND Proxy) | RFC3971: Send Neighbor Discovery (SEND) | | This draft relies on draft draft-ietf-csi-send-cert-04.txt. | | The need for new mechanisms for security for proxied messages is explained | in draft-ietf-csi-sndp-prob-04.txt. | | I've read all of these, but it is pretty new to me, so I could have missed | something. | | The Neighbor Discovery protocol communicates link-level addresses in the | protocol messages. The ND Proxy extension would make changes to those | fields. SEND, which secures the base ND protocol, relies on the sender of | a message computing a signature associated with the source IP address of | the message. Any ND Proxy changes to messages would invalidate the | signature and the ND Proxy itself could not generate a new signature | (since it would not have the private key associated with the source IP | address). This draft introduces a Proxy Signature (PS) option to secure | the proxied messages. | | RFC3971, the base SEND spec, defines a new Router Authorization | Certificate profile, dependent on RFC3779, which authorizes the router to | act as a router and act for certain prefixes. Message authorization in | SEND of some ND messages checks the prefixes listed in the certificate | against the prefixes mentioned in those messages. There is no explicit | representation in the certificate of the authority to act as a router. | Possession of the certificate in SEND serves as implicit authorization to | act as a router, as that was the only authorization defined. | | With the introduction of proxies, there was a need to distinguish the | various roles that a node might have in the network. No longer is | possession of a certificate adequate authorization. The draft | draft-ietf-csi-send-cert-04.txt uses the KeyPurposeId field to distinguish | three different roles: router, proxy and owner. That draft notes that | multiple key purposes are possible. I believe that it is also possible to | have single roles - so a node could be a proxy but not a router. Yes, of course single roles are supported. | With the extensions of the csi-send-cert draft, possession of a | certificate is no longer proof of any particular authorization. It seem | clear to me that the authorization validation described in RFC3971 is no | longer sufficient. I believe that a discussion is needed of what messages | require or allow each particular key purpose authorization. Issuing an | RA, for example, seems likely to require the "router" value of the key | purpose field, if the new certificate format was used for authorization. | Issuing an NA may require the "owner" value of the key purpose field, if | the new certificate format was used for authorization rather than a CGA. | I do not know if that discussion would be more appropriate here or in the | csi-send-cert draft, or another draft entirely that updates RFC3971 | directly. | | If a SPND proxy was using SEND to communicate with other nodes that | understood SPND, would it be OK to use a new format cert (with the | "router" KeyPurposeId) as a router certificate for the SEND RSA Signature | Options? | I see. I agree that this needs more precision. In draft-ietf-csi-send-cert-05, section 7 (it is the same text as in cert-04) it discusses the messages that are authorized by each KeyPurposeId - "router authorization value indicates that the certificate has been issued for allowing the router to advertise prefix(es)" (I understand that implicitly states that it authorizes the generation of RA messages. It is not crystal clear for me if it authorizes NA for routers, although if I had to take this text literally, I would suppose routers would need an 'owner' authorization if this PKI model substitutes RFC3971 CGA authorization, considering that the prefix for NA would be narrowed in general to one address, while the RA authorization is prefix-wide) - "proxy authorization value indicates that the certificate has been issued for allowing the proxy to perform proxying of neighbor discovery messages for the prefix(es) that are mentioned using the X.509 extensions for IP addresses" (I understand it now implicitly states it authorizes for ANY neighbor discovery message. By the way, this is the assumption underlying in general draft-ietf-csi-proxy-send-04: in the application scenarios, some require RA proxying, which is assumed to be performed by means of the proxy cert) - "owner authorization [...]For an address in such certificate the host can assign the address, send/ receive traffic from this address, and can respond to NSes about that address" (this is the clearest of all statements - although I think issuing secured NS and RS should also be considered) So, as defined now in draft-ietf-csi-proxy-send-04, proxy certificates provide authorization for securing *any* ND message. Considering the application scenarios, some require proxying RA (PMIPv6 and RFC4389), and the MIPv6 scenario just require NS/NA proxying. In summary so far, there is some specification of the authorization in draft-csi-send-cert, which I think it would be nice that it could be refined, and if so, my opinion is that the refinement of which ND message is authorized by each KeyPurposeId should be in that document. However, continuing with this issue, I must say that the way the 'proxy authorization' is defined, and the relationship with the other cases, is not satisfactory for me. I think the use of 'owner' should be restricted for hosts that really own the address (therefore, a substitution of the CGA mechanism) - as opposed to proxies. For the 'proxy authorization', I think it could be refined into something like "proxy host" authorization, and "proxy router" authorization. 'Proxy host' would authorize for proxying NA, NS and RS, and "proxy router" authorization would authorize RA and Redirect. This would provide a finer grain which I think would be desirable (for example, MIPv6 does not need protecting neither RA nor redirect). I think this would work (if so, it should be changed in draft-csi-send-cert). What do you think? (both authors of draft-csi-send-cert, Sandra, etc.). Regards, Alberto ------=_NextPart_000_008C_01CB1D31.3C488620 Content-Type: text/html; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable

Hi,

The text of this email has been extracted = from a thorough review of draft-ietf-csi-proxy-send = being made by Sandra Murphy.

The reason why the email has been separated = is to include the authors of draft-ietf-csi-send-cert in the discussion of = this part of the text, since I think some of the issues raised by Sandra affect = this document.

 

I include my comments = inline.

 

|=A0 -----Mensaje original-----

|=A0 De: Sandra Murphy = [mailto:Sandra.Murphy@sparta.com]

|=A0 Enviado el: viernes, 02 de julio de 2010 = 2:31

|=A0 Para: iesg@ietf.org; secdir@ietf.org; draft-ietf-csi-proxy-send.all@tools.ietf.org

|=A0 Asunto: = secdir review of draft-ietf-csi-proxy-send-04

|=A0

|=A0 This is = a review of draft draft-ietf-csi-proxy-send-04.txt.

|=A0

|=A0 I have = reviewed this document as part of the security directorate's

|=A0 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

|=A0 directors. Document editors and WG chairs should treat these comments = just

|=A0 like = any other last call comments.

|=A0

|=A0 This = document provides new Neighbor Discovery options that will = secure

|=A0 proxied = Neighbor Discovery messages.=A0 It is an update to:

|=A0

|=A0 RFC4861: Neighbor Discovery in IPv6

|=A0 RFC4389: Neighbor Discovery Proxies (ND Proxy)

|=A0 RFC3971: Send Neighbor Discovery (SEND)

|=A0

|=A0 This = draft relies on draft draft-ietf-csi-send-cert-04.txt.

|=A0

|=A0 The = need for new mechanisms for security for proxied messages is = explained

|=A0 in draft-ietf-csi-sndp-prob-04.txt.

|=A0

|=A0 I've = read all of these, but it is pretty new to me, so I could have = missed

|=A0 something.

|=A0

|=A0 The = Neighbor Discovery protocol communicates link-level addresses in = the

|=A0 protocol messages.=A0 The ND Proxy extension would make changes to those

|=A0 fields.=A0 SEND, which secures the base ND protocol, relies on the sender = of

|=A0 a = message computing a signature associated with the source IP address = of

|=A0 the = message.=A0 Any ND Proxy changes to messages would invalidate the

|=A0 signature and the ND Proxy itself could not generate a new signature

|=A0 (since = it would not have the private key associated with the source IP

|=A0 address).=A0 This draft introduces a Proxy Signature (PS) option to = secure

|=A0 the = proxied messages.

|=A0

|=A0 RFC3971, the base SEND spec, defines a new Router Authorization

|=A0 Certificate profile, dependent on RFC3779, which authorizes the router = to

|=A0 act as = a router and act for certain prefixes.=A0 Message authorization = in

|=A0 SEND of = some ND messages checks the prefixes listed in the certificate

|=A0 against = the prefixes mentioned in those messages.=A0 There is no = explicit

|=A0 representation in the certificate of the authority to act as a = router.

|=A0 Possession of the certificate in SEND serves as implicit authorization = to

|=A0 act as = a router, as that was the only authorization defined.

|=A0

|=A0 With = the introduction of proxies, there was a need to distinguish = the

|=A0 various = roles that a node might have in the network.=A0 No longer is

|=A0 possession of a certificate adequate authorization.=A0 The draft

|=A0 draft-ietf-csi-send-cert-04.txt uses the KeyPurposeId field to distinguish

|=A0 three = different roles: router, proxy and owner.=A0 That draft notes = that

|=A0 multiple key purposes are possible.=A0 I believe that it is also possible = to

|=A0 have = single roles – so a node could be a proxy but not a = router.

 

Yes, of course single roles are = supported.

=A0

|=A0 With = the extensions of the csi-send-cert draft, possession of a

|=A0 certificate is no longer proof of any particular authorization.=A0 It = seem

|=A0 clear = to me that the authorization validation described in RFC3971 is = no

|=A0 longer = sufficient.=A0 I believe that a discussion is needed of what = messages

|=A0 require = or allow each particular key purpose authorization.=A0 Issuing = an

|=A0 RA, for = example, seems likely to require the "router" value of the = key

|=A0 purpose = field, if the new certificate format was used for = authorization.

|=A0 Issuing = an NA may require the "owner" value of the key purpose field, = if

|=A0 the new = certificate format was used for authorization rather than a = CGA.

|=A0 I do = not know if that discussion would be more appropriate here or in = the

|=A0 csi-send-cert draft, or another draft entirely that updates RFC3971

|=A0 directly.

|=A0

|=A0 If a = SPND proxy was using SEND to communicate with other nodes that

|=A0 understood SPND, would it be OK to use a new format cert (with the

|=A0 "router" KeyPurposeId) as a router certificate for the SEND RSA = Signature

|=A0 Options?

|=A0

I see. I agree that this needs more = precision.

 

In draft-ietf-csi-send-cert-05, section 7 (it = is the same text as in cert-04) it discusses the messages that are authorized = by each KeyPurposeId

- "router authorization value indicates = that the

=A0=A0 certificate has been issued for = allowing the router to advertise

=A0=A0 = prefix(es)"

(I understand that implicitly states that it authorizes the generation of RA messages. It is not crystal clear for me = if it authorizes NA for routers, although if I had to take this text = literally, I would suppose routers would need an 'owner' authorization if this PKI = model substitutes RFC3971 CGA authorization, considering that the prefix for = NA would be narrowed in general to one address, while the RA authorization is prefix-wide)

- "proxy authorization value indicates = that the

=A0=A0 certificate has been issued for = allowing the proxy to perform

=A0=A0 proxying of neighbor discovery = messages for the prefix(es) that are

=A0=A0 mentioned using the X.509 extensions = for IP addresses"

(I understand it now implicitly states it = authorizes for ANY neighbor discovery message. By the way, this is the assumption underlying in general draft-ietf-csi-proxy-send-04: in the application scenarios, some require RA proxying, which is assumed to be performed by = means of the proxy cert)

- "owner authorization [...]For = an

=A0=A0 address in such certificate the host = can assign the address, send/

=A0=A0 receive traffic from this address, and = can respond to NSes about that

=A0=A0 = address"

(this is the clearest of all statements - = although I think issuing secured NS and RS should also be = considered)

 

So, as defined now in = draft-ietf-csi-proxy-send-04, proxy certificates provide authorization for securing *any* ND message. Considering the application scenarios, some require proxying RA (PMIPv6 = and RFC4389), and the MIPv6 scenario just require NS/NA proxying. =

 

In summary so far, there is some = specification of the authorization in draft-csi-send-cert, which I think it would be nice = that it could be refined, and if so, my opinion is that the refinement of which = ND message is authorized by each KeyPurposeId should be in that document.

However, continuing with this issue, I must = say that the way the 'proxy authorization' is defined, and the relationship with = the other cases, is not satisfactory for me.

I think the use of 'owner' should be = restricted for hosts that really own the address (therefore, a substitution of the CGA mechanism) - as opposed to proxies.

For the 'proxy authorization', I think it = could be refined into something like “proxy host” authorization, and “proxy router” authorization.

‘Proxy host’ would authorize for = proxying NA, NS and RS, and “proxy router” authorization would = authorize RA and Redirect. This would provide a finer grain which I think would be = desirable (for example, MIPv6 does not need protecting neither RA nor redirect). =

I think this would work (if so, it should be = changed in draft-csi-send-cert).

 

What do you think? (both authors of draft-csi-send-cert, Sandra, etc.).

 

Regards,

Alberto

 

 

------=_NextPart_000_008C_01CB1D31.3C488620-- From alberto@it.uc3m.es Tue Jul 6 08:33:17 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05ABC3A63C9; Tue, 6 Jul 2010 08:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.698 X-Spam-Level: X-Spam-Status: No, score=-3.698 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UftCls+7LNkM; Tue, 6 Jul 2010 08:32:44 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 7E0A73A65A6; Tue, 6 Jul 2010 08:32:43 -0700 (PDT) X-uc3m-safe: yes Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 514A86FBEB2; Tue, 6 Jul 2010 17:32:44 +0200 (CEST) From: =?ISO-8859-15?Q?Alberto_Garc=EDa?= To: "'Sandra Murphy'" , , , References: Date: Tue, 6 Jul 2010 17:32:41 +0200 Message-ID: <701EC68E5B2A43EB90CF83025269E464@bombo> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0093_01CB1D31.3D1F3710" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcsZfeJj2nmQCHGdTLucfKH28VDnuAAQqY0w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17490.000 X-Mailman-Approved-At: Tue, 06 Jul 2010 08:40:02 -0700 Cc: csi-chairs@tools.ietf.org Subject: Re: [secdir] (MAIN) secdir review of draft-ietf-csi-proxy-send-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 15:33:17 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0093_01CB1D31.3D1F3710 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit Hi Sandra First of all, thanks for your thorough review. You have included very relevant comments to improve the document. I think the first part of this email should be discussed with authors of draft-ietf-csi-send-cert, so I have split in two pieces this email, and copied the authors of draft-ietf-csi-send-cert in the part affecting them. The rest of the text is discussed in this email (I've included in the subject of this email '(MAIN)' to distinguish both threads). | -----Mensaje original----- | De: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] | Enviado el: viernes, 02 de julio de 2010 2:31 | Para: iesg@ietf.org; secdir@ietf.org; draft-ietf-csi-proxy-send.all@tools.ietf.org | Asunto: secdir review of draft-ietf-csi-proxy-send-04 [PART DISCUSSED IN OTHER EMAIL] | This draft validates the use of its new PS option against a proxy | KeyPurposeId in the certificate. However, I could not find that it | validates the prefixes in the proxied messages against the prefixes | mentioned in the certificate. Surely it should. RFC3971 requires that | the prefixes in a PI option match the router cert prefixes, but I'm not | sure that carries through to the proxied messages or those (like NA) that | refer to an address and have no PI option. Yes, definitely prefixes should be checked. New text should be added, since RFC3971 did not detail how certificates could be used to substitute CGA. | | I was curious as to the topological scenarios possible with proxies. | RFC4861 notes that multiple proxies might respond on a single link, | draft-csi-sndp-prob-04.txt discusses proxies that are nested, RFC4389 says | that a proxy never receives RAs from other proxies (which restricts I understand (RFC4389: 4.1.3.3) that there is a 'direction' in which RA flows (from upstream to downstream), and there are rules to control that only the appropriate interface propagates RA. | topologies), and this draft mentions proxying messages that already | contain a PS option. In Sec 5.2.2 of this draft, steps 6 and 7 of the | rules for receivers of the Proxy Signature option imply that there might | be multiple proxies on a link as well as proxy responses colliding with | direct responses. While there is a discussion of scenarios for proxying | ND messages, they are not discussions of topologies of the proxies | themselves. I believe that I would have benefited from an explanation of | the topology envisioned here. Well, we thought that a generic discussion of the topologies of the proxies would have been out of the scope of the document and the working group. | | Each SPND proxy must be able to distinguish secure nodes (RFC3971 or SPND | nodes) from insecure nodes (non-SEND) on the link for which it serves as | proxy. It decides whether to securely proxy ND messages received from | those nodes based on that info. Is there any thought as to how the SPND | proxy would know this? If this is manual configuration, that could be a | lot of work or impossible depending on the scenario. And if there are | multiple proxies on the link in some topologies, they must be consistent. Well, I think this is specific to each deployment scenario, and I think it is risky to include text going further than presenting the security considerations. Considering the 3 scenarios presented in the draft: - RFC4389 involves translating messages, so it is trivial to know the SEND/non-SEND nature of the node. This is general for translating scenarios, as commented in the draft in section 7. - PMIPv6 is very infrastructure dependent. The proxied element is the router. I would expect the provider to know if all MAGs support SEND or not (if any does not support SEND... then non-SEND operation should be used). - MIPv6. Here hosts are proxied, and the HA synthesizes messages on behalf of the hosts. This is for me the most complex scenario, and I'm not aware of any other solution than any kind of manual configuration (besides all nodes being required to be SEND). I think the previous info can be derived directly from the text of the draft. However, new scenarios may arise, and this could be handled easier. For example, assume proxy elements for saving energy by allowing hosts to go to sleep when not being heavily used (a-la ProxZZZy - www.ecma-international.org/publications/files/ECMA-ST/ECMA-393.pdf). In this case the host would be in the same link as the proxy, so previous communication should have occurred (in particular, to allow the host to tell the proxy that it goes to sleep), so the proxy may know in advance if the host is SEND or not. | | I was curious as to whether unsigned ND messages could be proxied securely | by a SPND node. Section 5.2.1 p 10 says the PS option MUST be added, | which satisfied me, but then Section 7.2 p 20 says there are cases where | the PS option MUST NOT be added. If that's a contradiction, it needs to | be addressed. Well, 5.2.1 describes operation considering that the originating message is protected by SEND, so the proxied message is also secured. So it MUST be added to be secured. I can add some words to clarify that. The part in which non-SEND hosts appear is section 7. This structure is analogous to the SEND specification. | | The text seems to make a distinction between "locally generated"/"issued" | messages for a proxied address and "forwarding" or "translating" a message | from a proxied address. I was never certain what cases might cause the | local generation of an address. RFC4389 seem to me to refer only to the | forwarding of messages. Perhaps the "local generate" term refers to the | scenario discussion in section 6.2 of Proxy Mobile IP, perhaps the term | refers to some of the exchanges in RFC4389 proxying. I'm not sure. Well, what it is trying to say is not that the address is being generated or not, but the message. The "forwarding" or "translating" case stands for the case in which a message is received by the proxy through one interface, and relayed to other. This is the case of RFC4389. The "locally generated"/"issued" or "synthesized" stands for messages that are generated by the proxy without receiving a message from the proxy. This is the MIPv6 and PMIP case. Do you think it would be more clear if this is included in the 'Terminology' section? | | After reading this, I was not sure that I had an adequate idea of the | error processing when different information has the potential to conflict. | I was particularly interested in the RA message. RFC4389 introduces a "P" | bit for the RA messages to indicate a proxied message. This draft | introduces a PS option to secure proxied messages. The new cert format | has a "proxy" value for the KeyPurposeId. I tried to work out the | combinations: | | P bit PS opt cert:"proxy" action | 0 no no no proxy needed (can use 3791) | 0 no yes no proxy needed (can use 3971) | 0 yes no silent discard of message | 0 yes yes weird but OK? | 1 no no "unsecured", even if 3971 signed? | cert says not a proxy, so drop? | 1 no yes "unsecured", even if 3971 signed? | If 3971 signed, check 3971 cert | prefixes or new cert prefixes? | 1 yes no silent discard of message | 1 yes yes secure proxy - all OK Well, the fourth case in the table needs some though, while the others are ok: The "P" bit of RFC4389 is only meaningful for proxies, i.e. hosts does not process it: the way the behavior of the receivers is defined in section 4.1.3.3 is "When [...] arrives on the upstream interface" or "[...] on the downstream interface"... The description always refers to upstream and downstream, which are only relevant for RFC4389 proxies. Then, for hosts the first column is irrelevant. Assume an RFC 4389 proxy with SPND enabled receives any message (in this case, the 3 'switches' - P bit, PS opt, cert opt- would be meaningful). First, security is checked, which means that the P bit should not be processed until the message is verified, and a "security level" ('secured' or 'unsecured') is defined for the message. Then I don't think a table in which the three elements are mixed together is a good representation of the problem. Instead, I think its better to view the process as a sequence of tie-breaking rules: 5.2.2 specifies the requirements for having a messages validated as secured. Rule #1 just discards parts of the message that must not be considered when analyzing its security. Rule #2 requires a valid certificate with 'proxy' value, and this certificate being linked to the message through the 'Key Hash' field. If this fails, then the message is unsecured. The rest of the rules check for the validity of the PS option. So, I would say: cert:"proxy" PS opt action no no unsecured no yes unsecured yes no This does not have much sense: you cannot know to which cert is referring a message if there is no PS opt with a Key Hash pointing to a cert. yes yes secured Then, the question stated in your table: ""unsecured", even if 3971 signed? | cert says not a proxy, so drop?" Would be 'unsecured', and then discard or not according to the configuration of the host regarding to backward compatibility (accept 'unsecured' if configured to do so, and in any case do not replace 'secured' information with 'unsecured' one) Now we can look at the P (RFC4389) bit. The case in which a secured message from a proxy is received, but the bit P is set to 0... this MUST NOT have been generated by a RFC4389 proxy (since RFC4389 proxies always set the P bit). It could have been generated by other proxy type - for example, a PMIPv6 MAG, which for the RFC4389 proxy would look as a 'regular' router. If the proxy were sure that only RFC4389 proxy operation is allowed, then this situation is really strange (a proxy that sends a RA message secured... that should be a RFC4389 proxy, but does not set the bit P to 1), and probably, it should discard the message. Does this fully address your question? Do you think it would clarify to add some text to the document? (I'm thinking specifically in the part of the scenarios, probably adding to section 6.3, 'rule' 1, in which a summary of the processing which RFC4863 proxies do before sending the packet, that the P bit must be set. And maybe a new sentence saying that proxies receiving this info, if they are sure that only RFC4389 proxy operation is allowed, could discard messages with valid PSO option but without the P bit? (<-- not sure that this is very clarifying...) | | As acknowledged in the Section 7.1, a RFC3971 message from a RFC3971 node | to another RFC3971 node proxied through a SPND proxy appears unsecured to | the receiver. That's no worse than proxying the message through a RFC3971 | proxy, so no harm done, for most messages. For Router Solicitation | messages, which according to RFC3489 don't get altered and can retain | their signatures, the outcome is worse. I think. I see your point. RFC 4389, section 4.1 (and also draft-ietf-csi-proxy-send) states that "This document covers the following types: Neighbor Solicitations, Neighbor Advertisements, Router Advertisements, and Redirects. These packets are ones that can carry link-layer addresses, and hence must be proxied [...]" But I think this is not completely true, since RFC4861 states that Router Solicitations can also carry source link-layer addresses: "4.1. Router Solicitation Message Format [...] Source link-layer address The link-layer address of the sender, if known. MUST NOT be included if the Source Address is the unspecified address. Otherwise, it SHOULD be included on link layers that have addresses." It is clear for me that if the RS message includes a "Source link-layer address option", it must also include a PS option. But, could a SEND-protected RS message which does not include a link-layer address be copied as-is in the other interface? I think yes, since CGAs would be validated consistently. This would be the device you mention as "RFC3971 proxy", which by the way, I don't think has been defined. I mean, should this "RFC3971 proxy" check for the validity of the original message, or just let it pass and let the receiver doing the check? I think it should check (as the SPND proxy does), but I don't have a clear opinion on this. Then, I see two options for proxying secure messages not including link-layer addresses: 1- Process as defined for the SPND proxy (which is check for validity of the original message, include PS option...) 2- check for validity of the original message, and if it is valid, forward as-is The first option seems more homogeneous. The second one allows the validation of some messages by nodes which are RFC3971 but not SPND. However, this is only for a very limited subset of the proxied information, which is the one not including link-layer addresses. I tend to prefer 1, but without a clear opinion. What do you think? Once clarified, the text of the RFC4389 scenario should be updated. | | Detailed comments: | | Sec 4, p 6: | | Proxy ND's certificate. When a ND message contains a PS option, | it MUST NOT contain CGA and RSA Signature options. This option | can be appended to any ND message: NA, NS, RS, RA and Redirect. | | Is that a "MAY" be appended? Page 10 says "MUST" be added, but section | 7.2 p 20 talks of cases where it MUST NOT be added. MUST be added to be secured. MUST NOT for non-SEND nodes. Obviously, (as commented above), a clarification saying that processing rules of section 5 are for generating/processing secured messages must be included | | o A modification of the SEND processing rules for all ND messages: | NA, NS, RS, RA, and Redirect. | | This draft and RFC4389 do not mention - if the proxied message is a NA, | and the proxy is a router, does the router bit get set? I think it should be set (I don't see any reason for not being set). Not sure if I should 'complement' RFC4389 in this document... | | Sec 5.2.1 p 10 | | 5.2.1. Processing rules for senders | | A ICMPv6 message sent by a Secure ND Proxy for a proxied address MUST | contain a PS option and MUST NOT contain either CGA or RSA Signature | options. | | Note contradiction in section 7.2 p 20. Commented above | | Sec 5.2.1 p 11 | | C. If the Secure ND Proxy is forwarding a SEND message already | containing a PS option, first the authenticity of the | intercepted message is verified as specified in Section 5.2.2 | of this specification. If the SEND message is valid, the | original PS option MUST be removed from the message. The | intercepted message is finally modified as described in | Section 4 of the ND Proxy specification [RFC4389]. | | Does this disagree with the RFC4389 statement that RA messages can not be | received from other proxies? That is, if an RA message P bit is set (and | if it contains a PS option, one hopes the P bit is set), RFC4389 sec | 4.1.3.3 says the interface must not be used as a proxy interface. No, I understand in a different way: RA messages can be proxied many times. Assume I1 I2 Router ------ P1 ------- P2 -----P3 With I1 being the interface of P2 connected to the router, and I2 the interface of P2 connected to P3. What RFC4389 says is that when P1 receives a RA, then it cannot be proxied to I1 (but it can to I2) I think there is no disagreement. | | 2. Timestamp and Nonce options MUST be included according to the | rules specified in SEND [RFC3971]. The value in the Timestamp | option MUST be generated by the proxy. If the proxy is | forwarding a message, the Nonce value in the proxied message MUST | be the same as in the forwarded message, otherwise it is | generated by the proxy. | | What is the "otherwise" here? If the proxy is *not* forwarding, which | might be if it is "locally generating" a message? If the Nonce is not | present in the forwarded messages? 'Otherwise' refers to synthesizing locally the message. I thing this two behaviors ('forwarding', 'generating locally') should be presented more clearly before this rule (although this concepts are somehow presented in rule 1). 'Otherwise' does not refer to the nonce. RFC3971 states that it is not present for unsolicited advertisements. If a proxy is receiving a message to be forwarded without the nonce (or otherwise), where it should be, it will be marked as unsecured. Then the proxy will include it "according to the rules specified in SEND [RFC3971]", as says the previous text. I can also change 'otherwise' with "If the proxy is synthesizing a message .", so ambiguity is definitely resolved. | | Sec 6.2 p 16 | | This scenario seems to be using the SPND feature because the MAG is using | a source address that does not really belong to it. It is not forwarding | any ND messages. So perhaps this is the case where the "locally | generated" terminology applies. Yes, this is one of the cases (the other is MIPv6 - note that in this case, although the MN and HA is communicating, when a host in the link of the HA generates a NS for the MN, the HA responds without retransmitting the request to the MN and then waiting back for the answer) | | To provide SEND protection, each MAG is configured to act as a proxy | by means of a certificate associated to the PMIPv6 domain, | authorizing each MAG to proxy securely ND messages. In addition, the | certificate must also authorize the MAG to advertise prefixes. Note | that the inclusion of multiple KeyPurposeId values is supported by | [I-D.ietf-csi-send-cert]. | | I believe that means that the new cert format must show both the router | and the proxy KeyPurposeID values because it is generating a RA. But no | such check is mentioned anywhere. Yes, you are right. Once clarified which KeyPurposeID should be used, this should be changed also | | Sec 6.2 p 16 | | A node receiving a message from the MAG containing the PS option MUST | apply the rules defined in Section 5.2.2. Note that unsolicited | messages sent by MAG are validated by the host according to timestamp | values specific to the MAG serving the link, not to any other MAG to | which the host has been connected before in other links. | | The host does not see any difference in the MAG, since the MAG is using | the same source IP address as all other MAGs to which the host has been | connected. According to my reading of RFC3971, that means that there's a | chance that unsolicited messages from the MAG would appear stale - as long | as the unsolicited message was received before a solicited advertisement. | Receipt of a solicited advertisement should update the timestamp at the | host, based on the nonce matching, by RFC3971 rules Well, there is a risk that unsolicited messages where considered unsecured due to different clocks in different proxies. Then, what is suggested in section 5.2.2, rule 6, is that "The receiver SHOULD store the peer-related timing information [.] separately for each different proxy (which can be identified by the different Key Hash values of the proxied message) and separately from the timing information associated to the IP of node for which the message is proxied". Maybe in section 6.2, a reference to section 5.2.2, rule 6 could be added, so this issue would be clarified. | | Sec 6.3 p 17/18 | | A Secure ND Proxy shall parse any IPv6 packet it receives on a proxy | interface to check whether it contains one of the following secured | ICMPv6 messages: NS, NA, RA, or Redirect. | | This seems to disagree with Section 5.2.1, p 10, which says the PS option | is added to *all* messages. However, it does agree with the discussion in | section 7.2 p 19/20, which says that the PS option is only generated on | behalf of RFC3917 nodes and SPND nodes. Yes, this sentence implicitly assumes that there may be unsecured messages, which is not the style of the rest of the document, and only appears clearly in section 7. I think it would be best to reword it so that it does not suggest yet the possibility of unsecured messages. | | Section 7.1 p 19 | | In the scenarios in which the proxy translates ND messages, the | messages to translate can either be originated in a RFC3971 node or | in an SPND node, without interoperability issues. | | The discussion immediately above this text says that RFC3971 nodes drop a | PS option in a proxied message and treat the message as unsecured, so I am | not sure what this is talking about. A secure proxied NA reply, for | example, would appear unsecured to the RFC3971 host and secure to the SPND | proxied host. Is "translates" an ND message different from | "forwards"/"proxies" an ND message - i.e., the PS option is not applied? The key word of this paragraph (the third) is 'originated', while in the first paragraph of section 7.1 the key word is 'received'. What this is saying is that a proxy can secure a message generated either in a RFC3971 or SPND node, since regarding to the rules of generating ND messages, both behave exactly the same (the difference is in the receiving rules for PS options). I can clarify a bit this differences | | | sec 7.2 p 20 | | Therefore, the Secure ND Proxy MUST generate messages containing the | PS option for SPND and RFC3971 hosts, and MUST NOT generate messages | containing the PS option for non-SEND nodes. | | This (and other places in the subsequent paragraphs) seems to contradict | sec 5.2.1 p 10 which says the PS option is a MUST, period. This is related with the acceptance of secured/unsecured message, and as discussed above, should be clarified, starting in section 5. | | What does the "for SPND and RFC3971 hosts" and the "for non-SEND hosts" | mean? I believe that it means that the proxy is forwarding messages on | their behalf. The use of the term "generate" here doesn't seem to mean | the same as "locally generated" elsewhere. Yes, you are right, this is imprecise. In this case "generate" means both 'forwarding' and 'synthesizing'. This should be clarified. | | I am not sure how the SPND would know which of the nodes on the proxy | interface were non-SEND, RFC3917, or SPND nodes. But if it can be This is not addressed in this document. I have commented about this above in this email, in a paragraph starting by "Well, I think this is specific to each deployment scenario [.]" | configured with that information, could it also be configured to know the | status of nodes on the outgoing interface? It might then detect that | doing the computation to add the PS option was a waste of effort because | there were no SPND nodes on that side. | | If the RFC3971 node produces a solicitation that needs to be forwarded | through the SPND proxy, and the SPND proxy forwards the advertisement it | received in reply along with the PS option, the RFC3971 will drop the PS | option. True? Should the SPND still produce the (wasted) signature? Yes, this is true. Of course this could optimize SPND operation. However, this may or may not be reasonable, depending on the scenario and particular configuration. For example, for PMIPv6, the proxy only performs its function for the MAG, not for any host, so it is not evident that the proxy knows if a node is SPND or not. For MIPv6, the proxy may or may not know the SPND or not (maybe, it knows when the node moves away, by accessing to some database, but not if the node is in the link.) I feel that this is too related with optimization, that should not be included in the document. Another option is to include a MAY statement in section 7 commenting this possibility, in a generic way, just for the sake of completeness. What do you think? | | Sec 7.2 page 20 | | o For translating ND messages for nodes that can arrive to the link | in which the proxy operates, | . | o For synthesizing ND messages on behalf of remote nodes, | | I think "translating" here means forwarding through the proxy and doing | the RFC4389 changes, while "synthesizing ND messages" means the mobile | node scenarios where no message is received for forwarding but one is | created (PMIPv6 and MIPv6?). | | An explanation of this difference and a consistent set of terms would have | helped a lot. Yes, I'm really convinced :-). I will | | o For translating ND messages for nodes that can arrive to the link | in which the proxy operates, the rule can be easily applied: only | messages validated in the Secure ND Proxy according to the SEND | specification [RFC3971] MUST be proxied securely by the inclusion | of a PS option. Unsecured ND messages could be proxied if | unsecured operation is enabled in the proxy, but the message | generated by the Secure ND Proxy for the received message MUST NOT | include a PS option. | | Is it possible for a proxy to receive a message with a PS option? Yes it is, for example for the RFC4389 case | Previous text (sec 5.2.1 part C) seems to indicate so. If the "MUST be | proxied securely" applies to SPND protected messages as well as RFC3971 | protected messages, then this case is the same as the previous paragraph | "MUST generate messages containing the PS option for SPND and RFC3971 | hosts . . .". Unless this is a difference between translating messages | and generating messages, of course. Yes. I include the PS option here. | | Sec 8 p 22 | | However, when two on-link hosts communicate using | their respective link-local addresses, the threats involved with a | compromised router and a compromised proxy ND differs because the | router is not able to siphon off traffic exchanged between the hosts | or mount a man-in-the-middle attack, while the proxy ND can, even if | the hosts use SEND. | | This should be explained in more detail. I believe that the reason is | that a SEND router would not be able to produce a NA reply to an NS that | would be believed, but the SPND could pretend to be proxying a NA reply | believably - as long as the recipient used SPND and could accept the PS | option. Yes, that's the reason why. I will include a text similar to this to explain. | | Proper configuration of when the PS option must or must not be | included, depending on the proxied nodes being SEND or non-SEND may | result in security considerations which are discussed in Section 7. | | This is pretty contorted. I believe that this is trying to say that | Section 7 discusses some of the security considerations resulting from the | decision to append or omit PS protections depending on the SEND awareness | of the proxied nodes. But I'm not sure. Yes, yours is a more accurate wording. I include, thanks | | Attacks to the timestamp of the secured ND message can be performed | as described in section 7.3 of [I-D.ietf-csi-sndp-prob]. | | I found that section of that draft to be particularly unclear. And it is | not normatively cited here. I'm not saying that it should be, but if that | draft does not progress (giving opportunity to improve the discussion), | the reader of this draft would be lost. Is there any way to summarize the | vulnerabilities so that the reader of this draft have some hint of what | can go wrong and why? [I-D.ietf-csi-sndp-prob] is in AUTH48 status, so. I assume it will progress. I agree that some hints should be included in draft-ietf-csi-proxy-send, and also indicating how the particular way Timestamp is handled here affects to security. Then, I suggest substituting the text you cited with the text below. I also think the detail (and credit) of the problem statement could be that of [I-D.ietf-csi-sndp-prob], so I end the paragraph referring to it, and I'm not explaining completely its text. Do you think this is ok? "Protection against reply attacks from unsolicited messages such as Neighbor Advertisements, Router Advertisements, and Redirects is provided by the use of the Timestamp option. When Secure ND Proxy is used, each proxy and the host for which a proxy acts on behalf are considered to be different peers in terms of Timestamp verification. Since the information provided by the host and a proxy maybe different, including different link-layer addresses, a reply attack could affect the operation of a third node: replying messages issued by a host that is no longer in the link can prevent the use of a proxy, and replying messages of a proxy when the host is back in the link can prevent the access to the host. This kind of attacks can be performed until the timestamp of the peer (either the host or a proxy) is no longer valid for the receiver. The window of vulnerability is in general larger for the first message received from a new peer than for subsequent messages received from the same peer (see RFC3971). A more detailed analysis of the possible attacks is described in section 7.3 of [I-D.ietf-csi-sndp-prob]." | | | | | NITS | | Sec 5.2.2 p 12 | | the IP of node for which the message is proxied. In this way, a | ^^^^^^^^^^^^^^ | the IP address of a node | | cached link-layer address created securily by means of RSA | ^^^^^^^^ | securely Ok | | Sec 6.1 p 13-14 | | Sometimes the Home Address is abbreviated HoA and sometimes as HA I have reviewed, and I think this section is correct: I find two places in which 'HA' is used as an address, being the 'Home Agent address' (different use from the 'box' 'Home Agent'): - HA_LL, which is the Link Layer of the Home Agent - In Figure 2, 'SRC = HA', which is correct since the it is the IP address of the HA (and not the HoA) the one used for this, as stated in RFC3775 | | Sec 6.2 p 16 | | link to which the MN is attached to, to be generated by the LMA when | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | to which the MN is attached, | the MN first attach to a PMIPv6 domain, | ^^^^^^ | attaches ok | | sec 7.2 p 20 | | options on behalf of nodes with SEND capabilities (i.e. that they | could use SEND to defend their messages if being in the same link | ^^^^^^^^ | present on | than the proxy, either RFC3971 nodes or SPND nodes). | ^^^^ | with Ok | | | sec 7.2 p 20 | | Not using the PS option for a | RFC3971 or SPND MN would make more vulnerable the address in | the home link when the MN is away than when it is in the home | link | | This is a bit awkward. I suggest moving the "more vulnerable" part" so | that it reads: | | Not using the PS option for a RFC3971 or SPND MN would make the address in | the home link more vulnerable when the MN is away than when it is in the | home link ok | | Sec 8 p 22 | | The security of proxied ND messages not including a PS option is the | same of an unsecured ND message. The security of a proxied ND | ^^ | as | message received by a non-SEND host or RFC3971 host is the same of an | ^^ | as | unsecured ND message. ok | | Sec 8 p 22 | | Attacks to the timestamp of the secured ND message can be performed | ^^ | on. Ok (although this may change, as commented above). Thanks again for your review!! I really appreciate your contribution. Alberto ------=_NextPart_000_0093_01CB1D31.3D1F3710 Content-Type: text/html; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable

Hi Sandra

First of all, thanks for your thorough = review. You have included very relevant comments to improve the = document.

 

I think the first part of this email should = be discussed with authors of draft-ietf-csi-send-cert, so I have split in = two pieces this email, and copied the authors of draft-ietf-csi-send-cert in the = part affecting them.

 

The rest of the text is discussed in this = email (I’ve included in the subject of this email ‘(MAIN)’ to = distinguish both threads).

 

|=A0 -----Mensaje original-----

|=A0 De: Sandra Murphy = [mailto:Sandra.Murphy@sparta.com]

|=A0 Enviado el: viernes, 02 de julio de 2010 = 2:31

|=A0 Para: iesg@ietf.org; secdir@ietf.org; draft-ietf-csi-proxy-send.all@tools.ietf.org

|=A0 Asunto: = secdir review of draft-ietf-csi-proxy-send-04

 

 

[PART DISCUSSED IN OTHER = EMAIL]

 

 

|=A0 This = draft validates the use of its new PS option against a proxy

|=A0 KeyPurposeId in the certificate.=A0 However, I could not find that it

|=A0 validates the prefixes in the proxied messages against the = prefixes

|=A0 mentioned in the certificate.=A0 Surely it should.=A0 RFC3971 requires = that

|=A0 the = prefixes in a PI option match the router cert prefixes, but I’m = not

|=A0 sure = that carries through to the proxied messages or those (like NA) = that

|=A0 refer = to an address and have no PI option.

Yes, definitely prefixes should be checked. = New text should be added, since RFC3971 did not detail how certificates could be = used to substitute CGA.

 

|=A0

|=A0 I was = curious as to the topological scenarios possible with proxies.

|=A0 RFC4861 = notes that multiple proxies might respond on a single link,

|=A0 draft-csi-sndp-prob-04.txt discusses proxies that are nested, RFC4389 says

|=A0 that a = proxy never receives RAs from other proxies (which restricts

I understand (RFC4389: 4.1.3.3) that there is = a 'direction' in which RA flows (from upstream to downstream), and there = are rules to control that only the appropriate interface propagates RA. =

 

|=A0 topologies), and this draft mentions proxying messages that already

|=A0 contain = a PS option.=A0 In Sec 5.2.2 of this draft, steps 6 and 7 of = the

|=A0 rules = for receivers of the Proxy Signature option imply that there = might

|=A0 be = multiple proxies on a link as well as proxy responses colliding = with

|=A0 direct = responses.=A0 While there is a discussion of scenarios for = proxying

|=A0 ND = messages, they are not discussions of topologies of the proxies

|=A0 themselves.=A0 I believe that I would have benefited from an explanation = of

|=A0 the = topology envisioned here.

 

Well, we thought that a generic discussion of = the topologies of the proxies would have been out of the scope of the = document and the working group.

 

|=A0

|=A0 Each = SPND proxy must be able to distinguish secure nodes (RFC3971 or = SPND

|=A0 nodes) = from insecure nodes (non-SEND) on the link for which it serves = as

|=A0 proxy.=A0 It decides whether to securely proxy ND messages received = from

|=A0 those = nodes based on that info.=A0 Is there any thought as to how the = SPND

|=A0 proxy = would know this?=A0 If this is manual configuration, that could be = a

|=A0 lot of = work or impossible depending on the scenario.=A0 And if there = are

|=A0 multiple proxies on the link in some topologies, they must be = consistent.

 

Well, I think this is specific to each = deployment scenario, and I think it is risky to include text going further than = presenting the security considerations.

Considering the 3 scenarios presented in the = draft:

- RFC4389 involves translating messages, so = it is trivial to know the SEND/non-SEND nature of the node. This is general = for translating scenarios, as commented in the draft in section = 7.

- PMIPv6 is very infrastructure dependent. = The proxied element is the router. I would expect the provider to know if all MAGs = support SEND or not (if any does not support SEND... then non-SEND operation = should be used).

- MIPv6. Here hosts are proxied, and the HA synthesizes messages on behalf of the hosts. This is for me the most = complex scenario, and I'm not aware of any other solution than any kind of = manual configuration (besides all nodes being required to be = SEND).

 

I think the previous info can be derived = directly from the text of the draft.

 

However, new scenarios may arise, and this = could be handled easier. For example, assume proxy elements for saving energy by allowing hosts to go to sleep when not being heavily used (a-la ProxZZZy = - www.ecma-international.org/publications/files/ECMA-ST/ECMA-393.pdf). In = this case the host would be in the same link as the proxy, so previous = communication should have occurred (in particular, to allow the host to tell the proxy = that it goes to sleep), so the proxy may know in advance if the host is SEND = or not.

 

 

|=A0

|=A0 I was = curious as to whether unsigned ND messages could be proxied = securely

|=A0 by a = SPND node.=A0 Section 5.2.1 p 10 says the PS option MUST be = added,

|=A0 which = satisfied me, but then Section 7.2 p 20 says there are cases = where

|=A0 the PS = option MUST NOT be added.=A0 If that’s a contradiction, it needs = to

|=A0 be = addressed.

 

Well, 5.2.1 describes operation considering = that the originating message is protected by SEND, so the proxied message is also secured. So it MUST be added to be secured. I can add some words to = clarify that.

The part in which non-SEND hosts appear is = section 7.

This structure is analogous to the SEND = specification.

 

|=A0

|=A0 The = text seems to make a distinction between "locally = generated"/"issued"

|=A0 messages for a proxied address and "forwarding" or "translating" a = message

|=A0 from a = proxied address.=A0 I was never certain what cases might cause = the

|=A0 local = generation of an address.=A0 RFC4389 seem to me to refer only to = the

|=A0 forwarding of messages.=A0 Perhaps the "local generate" term refers to = the

|=A0 scenario discussion in section 6.2 of Proxy Mobile IP, perhaps the = term

|=A0 refers = to some of the exchanges in RFC4389 proxying.=A0 I’m not = sure.

 

Well, what it is trying to say is not that = the address is being generated or not, but the message.

The "forwarding" or = "translating" case stands for the case in which a message is received by the proxy = through one interface, and relayed to other. This is the case of RFC4389. =

The "locally = generated"/"issued" or "synthesized" stands for messages that are generated by the = proxy without receiving a message from the proxy. This is the MIPv6 and PMIP = case.

Do you think it would be more clear if this = is included in the 'Terminology' section?

 

|=A0

|=A0 After = reading this, I was not sure that I had an adequate idea of the

|=A0 error = processing when different information has the potential to = conflict.

|=A0 I was = particularly interested in the RA message. RFC4389 introduces a = "P"

|=A0 bit for = the RA messages to indicate a proxied message.=A0 This = draft

|=A0 introduces a PS option to secure proxied messages.=A0 The new cert = format

|=A0 has a "proxy" value for the KeyPurposeId.=A0 I tried to work out = the

|=A0 combinations:

|=A0

|=A0 P = bit=A0=A0 PS opt=A0=A0 cert:"proxy" action

|=A0=A0=A0=A0 0=A0=A0=A0=A0=A0=A0 = no=A0=A0=A0=A0=A0=A0=A0=A0 no=A0=A0=A0=A0=A0=A0 no proxy needed (can use 3791)

|=A0=A0=A0=A0 0=A0=A0=A0=A0=A0=A0 = no=A0=A0=A0=A0=A0=A0=A0=A0 yes=A0=A0=A0=A0=A0 no proxy needed (can use 3971)

|=A0=A0=A0=A0 0=A0=A0=A0=A0=A0=A0 = yes=A0=A0=A0=A0=A0=A0=A0 no=A0=A0=A0=A0=A0=A0 silent discard of message

|=A0=A0=A0=A0 0=A0=A0=A0=A0=A0=A0 = yes=A0=A0=A0=A0=A0=A0=A0 yes=A0=A0=A0=A0=A0 weird but = OK?

|=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0 = no=A0=A0=A0=A0=A0=A0=A0=A0 no=A0=A0=A0=A0=A0=A0 "unsecured", even if 3971 signed?

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cert says not a proxy, so drop?

|=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0 = no=A0=A0=A0=A0=A0=A0=A0=A0 yes=A0=A0=A0=A0=A0 "unsecured", even if 3971 signed?

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 If 3971 signed, check 3971 cert

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 prefixes or new cert prefixes?

|=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0 = yes=A0=A0=A0=A0=A0=A0=A0 no=A0=A0=A0=A0=A0 =A0silent discard of message

|=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0 = yes=A0=A0=A0=A0=A0=A0=A0 yes=A0=A0=A0=A0=A0 secure proxy – all OK

 

Well, the fourth case in the table needs some = though, while the others are ok:

 

The "P" bit of RFC4389 is only = meaningful for proxies, i.e. hosts does not process it: the way the behavior of the receivers is defined in section 4.1.3.3 is "When [...] arrives on = the upstream interface" or "[...] on the downstream = interface"... The description always refers to upstream and downstream, which are only relevant for RFC4389 proxies.

Then, for hosts the first column is = irrelevant.

 

Assume an RFC 4389 proxy with SPND enabled = receives any message (in this case, the 3 'switches' - P bit, PS opt, cert opt- = would be meaningful).

First, security is checked, which means that = the P bit should not be processed until the message is verified, and a = "security level" ('secured' or 'unsecured') is defined for the message. Then = I don't think a table in which the three elements are mixed together is a good representation of the problem. Instead, I think its better to view the = process as a sequence of tie-breaking rules: 5.2.2 specifies the requirements = for having a messages validated as secured. Rule #1 just discards parts of = the message that must not be considered when analyzing its security. =

Rule #2 requires a valid certificate with = 'proxy' value, and this certificate being linked to the message through the 'Key = Hash' field. If this fails, then the message is unsecured. =

The rest of the rules check for the validity = of the PS option. So, I would = say:

 

cert:"proxy"=A0=A0=A0=A0=A0 PS opt=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 action

no=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = no =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = unsecured

no=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = yes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = unsecured

yes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = no=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 This does not have much sense: you cannot know to which cert is referring a = message if there is no PS opt with a Key Hash pointing to a = cert.

yes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = yes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = secured

 

Then, the question stated in your table: ""unsecured", even if 3971 = signed?

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cert says not a proxy, so drop?"

Would be 'unsecured', and then discard or not according to the configuration of the host regarding to backward = compatibility (accept 'unsecured' if configured to do so, and in any case do not = replace 'secured' information with 'unsecured' one)

 

Now we can look at the P (RFC4389) bit. The = case in which a secured message from a proxy is received, but the bit P is set = to 0... this MUST NOT have been generated by a RFC4389 proxy (since RFC4389 = proxies always set the P bit). It could have been generated by other proxy type = - for example, a PMIPv6 MAG, which for the RFC4389 proxy would look as a = 'regular' router.

If the proxy were sure that only RFC4389 = proxy operation is allowed, then this situation is really strange (a proxy = that sends a RA message secured... that should be a RFC4389 proxy, but does not set = the bit P to 1), and probably, it should discard the = message.

Does this fully address your = question?

 

Do you think it would clarify to add some = text to the document? (I'm thinking specifically in the part of the scenarios, = probably adding to section 6.3, 'rule' 1, in which a summary of the processing which = RFC4863 proxies do before sending the packet, that the P bit must be set. =

And maybe a new sentence saying that proxies = receiving this info, if they are sure that only RFC4389 proxy operation is = allowed, could discard messages with valid PSO option but without the P = bit? (<-- not sure that this is very = clarifying...)

 

|=A0

|=A0 As = acknowledged in the Section 7.1, a RFC3971 message from a RFC3971 = node

|=A0 to = another RFC3971 node proxied through a SPND proxy appears unsecured = to

|=A0 the = receiver.=A0 That’s no worse than proxying the message through a = RFC3971

|=A0 proxy, = so no harm done, for most messages.=A0 For Router = Solicitation

|=A0 messages, which according to RFC3489 don’t get altered and can = retain

|=A0 their = signatures, the outcome is worse. I think.

 

I see your = point.

RFC 4389, section 4.1 (and also draft-ietf-csi-proxy-send) states that

"This document covers the following = types:

=A0=A0 Neighbor Solicitations, Neighbor = Advertisements, Router

=A0=A0 Advertisements, and Redirects. These = packets are ones that can carry

=A0=A0 link-layer addresses, and hence must = be proxied [...]"

 

But I think this is not completely true, = since RFC4861 states that Router Solicitations can also carry source link-layer = addresses:

"4.1.=A0 Router Solicitation Message = Format

[...]

Source link-layer address The link-layer = address of the sender, if

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 known.=A0 MUST NOT be included if the Source Address

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 is the unspecified address.=A0 Otherwise, it SHOULD

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 be included on link layers that have addresses."

 

It is clear for me that if the RS message = includes a "Source link-layer address option", it must also include a PS = option.

 

But, could a SEND-protected RS message which = does not include a link-layer address be copied as-is in the other interface? I = think yes, since CGAs would be validated consistently. =

This would be the device you mention as = "RFC3971 proxy", which by the way, I don't think has been defined. I mean, = should this "RFC3971 proxy" check for the validity of the original = message, or just let it pass and let the receiver doing the check? I think it = should check (as the SPND proxy does), but I don't have a clear opinion on = this.

 

Then, I see two options for proxying secure = messages not including link-layer addresses:

1- Process as defined for the SPND proxy = (which is check for validity of the original message, include PS = option...)

2- check for validity of the original = message, and if it is valid, forward as-is

 

The first option seems more homogeneous. The = second one allows the validation of some messages by nodes which are RFC3971 = but not SPND. However, this is only for a very limited subset of the proxied information, which is the one not including link-layer = addresses.

I tend to prefer 1, but without a clear = opinion.

What do you = think?

Once clarified, the text of the RFC4389 = scenario should be updated.

 

 

|=A0

|=A0 Detailed comments:

|=A0

|=A0 Sec 4, = p 6:

|=A0

|=A0=A0=A0=A0=A0=A0=A0=A0 Proxy ND's certificate.=A0 = When a ND message contains a PS option,

|=A0=A0=A0=A0=A0=A0=A0=A0 it MUST NOT contain = CGA and RSA Signature options.=A0 This option

|=A0=A0=A0=A0=A0=A0=A0=A0 can be appended to = any ND message: NA, NS, RS, RA and Redirect.

|=A0

|=A0 Is that = a "MAY" be appended?=A0 Page 10 says "MUST" be added, = but section

|=A0 7.2 p = 20 talks of cases where it MUST NOT be added.

MUST be added to be = secured.

MUST NOT for non-SEND = nodes.

 

Obviously, (as commented above), a = clarification saying that processing rules of section 5 are for generating/processing = secured messages must be included

 

|=A0

|=A0=A0=A0=A0=A0 o=A0 A modification of the = SEND processing rules for all ND messages:

|=A0=A0=A0=A0=A0=A0=A0=A0 NA, NS, RS, RA, and = Redirect.

|=A0

|=A0 This = draft and RFC4389 do not mention – if the proxied message is a = NA,

|=A0 and the = proxy is a router, does the router bit get set?

 

I think it should be set (I don't see any = reason for not being set).

Not sure if I should 'complement' RFC4389 in = this document...

 

|=A0

|=A0 Sec = 5.2.1 p 10

|=A0

|=A0 5.2.1.=A0 Processing rules for senders

|=A0

|=A0=A0=A0=A0=A0 A ICMPv6 message sent by a Secure ND Proxy for a proxied address = MUST

|=A0=A0=A0=A0=A0 contain a PS option and MUST = NOT contain either CGA or RSA Signature

|=A0=A0=A0=A0=A0 = options.

|=A0

|=A0 Note = contradiction in section 7.2 p 20.

Commented above

 

|=A0

|=A0 Sec = 5.2.1 p 11

|=A0

|=A0=A0=A0=A0=A0=A0=A0=A0=A0 C.=A0 If the = Secure ND Proxy is forwarding a SEND message already

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = containing a PS option, first the authenticity of the

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = intercepted message is verified as specified in Section 5.2.2

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 of = this specification.=A0 If the SEND message is valid, the

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = original PS option MUST be removed from the message.=A0 The

|=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0intercepted message is finally modified as described in

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Section 4 of the ND Proxy specification [RFC4389].

|=A0

|=A0 Does = this disagree with the RFC4389 statement that RA messages can not = be

|=A0 received from other proxies?=A0 That is, if an RA message P bit is set = (and

|=A0 if it = contains a PS option, one hopes the P bit is set), RFC4389 sec

|=A0 4.1.3.3 = says the interface must not be used as a proxy interface.

 

No, I understand in a different way: RA = messages can be proxied many times. Assume

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = I1=A0 I2

Router ------ P1 = ------- P2 -----P3

 

With I1 being the interface of P2 connected = to the router, and I2 the interface of P2 connected to = P3.

What RFC4389 says is that when P1 receives a = RA, then it cannot be proxied to I1 (but it can to = I2)

 

I think there is no = disagreement.

 

|=A0

|=A0=A0=A0=A0=A0 2.=A0 Timestamp and Nonce = options MUST be included according to the

|=A0=A0=A0=A0=A0=A0=A0=A0=A0 rules specified = in SEND [RFC3971].=A0 The value in the Timestamp

|=A0=A0=A0=A0=A0=A0=A0=A0=A0 option MUST be = generated by the proxy.=A0 If the proxy is

|=A0=A0=A0=A0=A0=A0=A0=A0=A0 forwarding a = message, the Nonce value in the proxied message MUST

|=A0=A0=A0=A0=A0=A0=A0=A0=A0 be the same as = in the forwarded message, otherwise it is

|=A0=A0=A0=A0=A0=A0=A0=A0=A0 generated by the = proxy.

|=A0

|=A0 What is = the "otherwise" here?=A0 If the proxy is *not* forwarding, = which

|=A0 might = be if it is "locally generating" a message?=A0 If the Nonce is = not

|=A0 present = in the forwarded messages?

 

‘Otherwise’ refers to = synthesizing locally the message. I thing this two behaviors (‘forwarding’, = ‘generating locally’) should be presented more clearly before this rule = (although this concepts are somehow presented in rule = 1).

 

‘Otherwise’ does not refer to the = nonce. RFC3971 states that it is not present for unsolicited advertisements. If = a proxy is receiving a message to be forwarded without the nonce (or = otherwise), where it should be, it will be marked as unsecured. Then the proxy will = include it “according to the

=A0=A0=A0=A0=A0 rules specified in SEND = [RFC3971]”, as says the previous text.

 

I can also change ‘otherwise’ = with “If the proxy is synthesizing a message …”, so = ambiguity is definitely resolved.

 

=A0

|=A0

|=A0 Sec 6.2 = p 16

|=A0

|=A0 This = scenario seems to be using the SPND feature because the MAG is = using

|=A0 a = source address that does not really belong to it.=A0 It is not = forwarding

|=A0 any ND = messages.=A0 So perhaps this is the case where the "locally

|=A0 generated" terminology applies.

 

Yes, this is one of the cases (the other is = MIPv6 – note that in this case, although the MN and HA is communicating, = when a host in the link of the HA generates a NS for the MN, the HA responds = without retransmitting the request to the MN and then waiting back for the = answer)

|=A0

|=A0=A0=A0=A0=A0 To provide SEND protection, = each MAG is configured to act as a proxy

|=A0=A0=A0=A0=A0 by means of a certificate = associated to the PMIPv6 domain,

|=A0=A0=A0=A0=A0 authorizing each MAG to = proxy securely ND messages.=A0 In addition, the

|=A0=A0=A0=A0=A0 certificate must also = authorize the MAG to advertise prefixes.=A0 Note

|=A0=A0=A0=A0=A0 that the inclusion of = multiple KeyPurposeId values is supported by

|=A0=A0=A0=A0=A0 = [I-D.ietf-csi-send-cert].

|=A0

|=A0 I = believe that means that the new cert format must show both the router

|=A0 and the = proxy KeyPurposeID values because it is generating a RA.=A0 But = no

|=A0 such = check is mentioned anywhere.

 

Yes, you are right. Once clarified which = KeyPurposeID should be used, this should be changed also

 

|=A0

|=A0 Sec 6.2 = p 16

|=A0

|=A0=A0=A0=A0=A0 A node receiving a message = from the MAG containing the PS option MUST

|=A0=A0=A0=A0=A0 apply the rules defined in = Section 5.2.2.=A0 Note that unsolicited

|=A0=A0=A0=A0=A0 messages sent by MAG are = validated by the host according to timestamp

|=A0=A0=A0=A0=A0 values specific to the MAG = serving the link, not to any other MAG to

|=A0=A0=A0=A0=A0 which the host has been = connected before in other links.

|=A0

|=A0 The = host does not see any difference in the MAG, since the MAG is = using

|=A0 the = same source IP address as all other MAGs to which the host has = been

|=A0 connected.=A0 According to my reading of RFC3971, that means that there’s = a

|=A0 chance = that unsolicited messages from the MAG would appear stale – as = long

|=A0 as the = unsolicited message was received before a solicited = advertisement.

|=A0 Receipt = of a solicited advertisement should update the timestamp at = the

|=A0 host, = based on the nonce matching, by RFC3971 rules

 

Well, there is a risk that unsolicited = messages where considered unsecured due to different clocks in different proxies. Then, = what is suggested in section 5.2.2, rule 6, is that “The receiver = SHOULD store the peer-related timing information […] separately for each = different proxy (which can be identified by the different Key Hash values of the = proxied message) and separately from the timing information associated to the IP = of node for which the message is = proxied”.

Maybe in section 6.2, a reference to section = 5.2.2, rule 6 could be added, so this issue would be = clarified.

 

|=A0

|=A0 Sec 6.3 = p 17/18

|=A0

|=A0=A0=A0=A0=A0 A Secure ND Proxy shall = parse any IPv6 packet it receives on a proxy

|=A0=A0=A0=A0=A0 interface to check whether = it contains one of the following secured

|=A0=A0=A0=A0=A0 ICMPv6 messages: NS, NA, RA, = or Redirect.

|=A0

|=A0 This = seems to disagree with Section 5.2.1, p 10, which says the PS = option

|=A0 is = added to *all* messages.=A0 However, it does agree with the discussion = in

|=A0 section = 7.2 p 19/20, which says that the PS option is only generated on

|=A0 behalf = of RFC3917 nodes and SPND nodes.

 

Yes, this sentence implicitly assumes that = there may be unsecured messages, which is not the style of the rest of the = document, and only appears clearly in section 7.

I think it would be best to reword it so that = it does not suggest yet the possibility of unsecured = messages.

 

|=A0

|=A0 Section = 7.1 p 19

|=A0

|=A0=A0=A0=A0=A0 In the scenarios in which = the proxy translates ND messages, the

|=A0=A0=A0=A0=A0 messages to translate can = either be originated in a RFC3971 node or

|=A0=A0=A0=A0=A0 in an SPND node, without = interoperability issues.

|=A0

|=A0 The = discussion immediately above this text says that RFC3971 nodes drop = a

|=A0 PS = option in a proxied message and treat the message as unsecured, so I = am

|=A0 not = sure what this is talking about. =A0A secure proxied NA reply, = for

|=A0 example, would appear unsecured to the RFC3971 host and secure to the = SPND

|=A0 proxied = host. Is "translates" an ND message different = from

|=A0 "forwards"/"proxies" an ND message – i.e., the PS option is not = applied?

 

The key word of this paragraph (the third) is = ‘originated’, while in the first paragraph of section 7.1 the key word is = ‘received’. What this is saying is that a proxy can secure a message generated = either in a RFC3971 or SPND node, since regarding to the rules of generating ND = messages, both behave exactly the same (the difference is in the receiving rules = for PS options).

I can clarify a bit this = differences

 

|=A0

|=A0

|=A0 sec 7.2 = p 20

|=A0

|=A0=A0=A0=A0=A0 Therefore, the Secure ND = Proxy MUST generate messages containing the

|=A0=A0=A0=A0=A0 PS option for SPND and = RFC3971 hosts, and MUST NOT generate messages

|=A0=A0=A0=A0=A0 containing the PS option for = non-SEND nodes.

|=A0

|=A0 This = (and other places in the subsequent paragraphs) seems to = contradict

|=A0 sec = 5.2.1 p 10 which says the PS option is a MUST, period.

This is related with the acceptance of secured/unsecured message, and as discussed above, should be clarified, starting in section 5.

 

|=A0

|=A0 What = does the "for SPND and RFC3971 hosts" and the "for non-SEND = hosts"

|=A0 mean?=A0 I believe that it means that the proxy is forwarding messages = on

|=A0 their = behalf.=A0 The use of the term "generate" here doesn’t seem to = mean

|=A0 the = same as "locally generated" elsewhere.

Yes, you are right, this is imprecise. In = this case “generate” means both ‘forwarding’ and ‘synthesizing’. This = should be clarified.

 

|=A0

|=A0 I am = not sure how the SPND would know which of the nodes on the = proxy

|=A0 interface were non-SEND, RFC3917, or SPND nodes.=A0 But if it can = be

This is not addressed in this document. I = have commented about this above in this email, in a paragraph starting by = “Well, I think this is specific to each deployment scenario = […]”

 

|=A0 configured with that information, could it also be configured to know = the

|=A0 status = of nodes on the outgoing interface?=A0 It might then detect = that

|=A0 doing = the computation to add the PS option was a waste of effort = because

|=A0 there = were no SPND nodes on that side.

|=A0

|=A0 If the = RFC3971 node produces a solicitation that needs to be forwarded

|=A0 through = the SPND proxy, and the SPND proxy forwards the advertisement = it

|=A0 received in reply along with the PS option, the RFC3971 will drop the = PS

|=A0 option.=A0 True?=A0 Should the SPND still produce the (wasted) = signature?

Yes, this is true. Of course this could = optimize SPND operation.

 

However, this may or may not be reasonable, = depending on the scenario and particular configuration. For example, for PMIPv6, = the proxy only performs its function for the MAG, not for any host, so it is = not evident that the proxy knows if a node is SPND or not. For MIPv6, the proxy may = or may not know the SPND or not (maybe, it knows when the node moves away, by accessing to some database, but not if the node is in the = link…)

 

I feel that this is too related with = optimization, that should not be included in the document. Another option is to = include a MAY statement in section 7 commenting this possibility, in a generic way, = just for the sake of completeness. What do you = think?

 

 

|=A0

|=A0 Sec 7.2 = page 20

|=A0

|=A0=A0=A0=A0 o=A0 For translating ND = messages for nodes that can arrive to the link

|=A0=A0=A0=A0=A0=A0=A0=A0 in which the proxy = operates,

|=A0 …

|=A0=A0=A0=A0=A0 o=A0 For synthesizing ND = messages on behalf of remote nodes,

|=A0

|=A0 I think "translating" here means forwarding through the proxy and = doing

|=A0 the = RFC4389 changes, while "synthesizing ND messages" means the = mobile

|=A0 node = scenarios where no message is received for forwarding but one is

|=A0 created = (PMIPv6 and MIPv6?).

|=A0

|=A0 An = explanation of this difference and a consistent set of terms would = have

|=A0 helped = a lot.

Yes, I’m really convinced = J. I will

 

|=A0

|=A0=A0=A0=A0=A0 o=A0 For translating ND = messages for nodes that can arrive to the link

|=A0=A0=A0=A0=A0=A0=A0=A0 in which the proxy = operates, the rule can be easily applied: only

|=A0=A0=A0=A0=A0=A0=A0=A0 messages validated = in the Secure ND Proxy according to the SEND

|=A0=A0=A0=A0=A0=A0=A0=A0 specification = [RFC3971] MUST be proxied securely by the inclusion

|=A0=A0=A0=A0=A0=A0=A0=A0 of a PS option.=A0 = Unsecured ND messages could be proxied if

|=A0=A0=A0=A0=A0=A0=A0=A0 unsecured operation = is enabled in the proxy, but the message

|=A0=A0=A0=A0=A0=A0=A0=A0 generated by the = Secure ND Proxy for the received message MUST NOT

|=A0=A0=A0=A0=A0=A0=A0=A0 include a PS = option.

|=A0

|=A0 Is it = possible for a proxy to receive a message with a PS option?

Yes it is, for example for the RFC4389 = case

 

|=A0 Previous text (sec 5.2.1 part C) seems to indicate so.=A0 If the "MUST = be

|=A0 proxied securely" applies to SPND protected messages as well as = RFC3971

|=A0 protected messages, then this case is the same as the previous = paragraph

|=A0 "MUST generate messages containing the PS option for SPND and RFC3971

|=A0 hosts . = . .".=A0 Unless this is a difference between translating = messages

|=A0 and = generating messages, of course.

Yes. I include the PS option here. =

 

|=A0

|=A0 Sec 8 p = 22

|=A0

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = However, when two on-link hosts communicate using

|=A0=A0=A0=A0=A0 their respective link-local = addresses, the threats involved with a

|=A0=A0=A0=A0=A0 compromised router and a = compromised proxy ND differs because the

|=A0=A0=A0=A0=A0 router is not able to siphon = off traffic exchanged between the hosts

|=A0=A0=A0=A0=A0 or mount a man-in-the-middle = attack, while the proxy ND can, even if

|=A0=A0=A0=A0=A0 the hosts use = SEND.

|=A0

|=A0 This = should be explained in more detail.=A0 I believe that the reason = is

|=A0 that a = SEND router would not be able to produce a NA reply to an NS = that

|=A0 would = be believed, but the SPND could pretend to be proxying a NA = reply

|=A0 believably – as long as the recipient used SPND and could accept the = PS

|=A0 option.

Yes, that’s the reason why. I will = include a text similar to this to explain.

 

|=A0

|=A0=A0=A0=A0=A0 Proper configuration of when = the PS option must or must not be

|=A0=A0=A0=A0=A0 included, depending on the = proxied nodes being SEND or non-SEND may

|=A0=A0=A0=A0=A0 result in security = considerations which are discussed in Section 7.

|=A0

|=A0 This is = pretty contorted.=A0 I believe that this is trying to say = that

|=A0 Section = 7 discusses some of the security considerations resulting from = the

|=A0 decision to append or omit PS protections depending on the SEND = awareness

|=A0 of the = proxied nodes.=A0 But I’m not sure.

Yes, yours is a more accurate wording. I = include, thanks

 

|=A0

|=A0=A0=A0=A0=A0 Attacks to the timestamp of = the secured ND message can be performed

|=A0=A0=A0=A0=A0 as described in section 7.3 = of [I-D.ietf-csi-sndp-prob].

|=A0

|=A0 I found = that section of that draft to be particularly unclear.=A0 And it = is

|=A0 not = normatively cited here.=A0 I’m not saying that it should be, but if = that

|=A0 draft = does not progress (giving opportunity to improve the = discussion),

|=A0 the = reader of this draft would be lost.=A0 Is there any way to summarize = the

|=A0 vulnerabilities so that the reader of this draft have some hint of = what

|=A0 can go = wrong and why?

 

[I-D.ietf-csi-sndp-prob] is in AUTH48 status, = so… I assume it will progress.

I agree that some hints should be included in draft-ietf-csi-proxy-send, and also indicating how the particular way = Timestamp is handled here affects to security. Then, I suggest substituting the = text you cited with the text below.

I also think the detail (and credit) of the = problem statement could be that of [I-D.ietf-csi-sndp-prob], so I end the = paragraph referring to it, and I’m not explaining completely its = text.

Do you think this is = ok?

 

“Protection against reply attacks from unsolicited messages such as Neighbor Advertisements, Router = Advertisements, and Redirects is provided by the use of the Timestamp option. When = Secure ND Proxy is used, each proxy and the host for which a proxy acts on behalf are considered to be different peers in terms of Timestamp verification. = Since the information provided by the host and a proxy maybe different, including different link-layer addresses, a reply attack could affect the = operation of a third node: replying messages issued by a host that is no longer in the = link can prevent the use of a proxy, and replying messages of a proxy when = the host is back in the link can prevent the access to the host. This kind of = attacks can be performed until the timestamp of the peer (either the host or a = proxy) is no longer valid for the receiver. The window of vulnerability is in general = larger for the first message received from a new peer than for subsequent = messages received from the same peer (see RFC3971). A more detailed analysis of = the possible attacks is described in section 7.3 of = [I-D.ietf-csi-sndp-prob].”

 

|=A0

|=A0

|=A0

|=A0

|=A0 NITS

|=A0

|=A0 Sec = 5.2.2 p 12

|=A0

|=A0=A0=A0=A0=A0=A0=A0=A0=A0 the IP of node = for which the message is proxied.=A0 In this way, a

|=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ^^^^^^^^^^^^^^

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the IP = address of a node

|=A0

|=A0=A0=A0=A0=A0=A0=A0=A0=A0 cached = link-layer address created securily by means of RSA

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 ^^^^^^^^

|=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0securely

Ok

 

|=A0

|=A0 Sec 6.1 = p 13-14

|=A0

|=A0 Sometimes the Home Address is abbreviated HoA and sometimes as HA

 

I have reviewed, and I think this section is = correct: I find two places in which ‘HA’ is used as an address, being = the ‘Home Agent address’ (different use from the ‘box’ = ‘Home Agent’):

- HA_LL, which is the Link Layer of the Home = Agent

- In Figure 2, ‘SRC =3D HA’, = which is correct since the it is the IP address of the HA (and not the HoA) the = one used for this, as stated in RFC3775

 

 

|=A0

|=A0 Sec 6.2 = p 16

|=A0

|=A0=A0=A0=A0=A0 = link to which the MN is attached to, to be generated by the LMA = when

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 to which the = MN is attached,

|=A0=A0=A0=A0=A0 the MN first attach to a = PMIPv6 domain,

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 ^^^^^^

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 attaches

ok

 

|=A0

|=A0 sec 7.2 = p 20

|=A0

|=A0=A0=A0=A0=A0 = options on behalf of nodes with SEND capabilities (i.e. that = they

|=A0=A0=A0=A0=A0 = could use SEND to defend their messages if being in the same = link

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 ^^^^^^^^

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 present on

|=A0=A0=A0=A0=A0 = than the proxy, either RFC3971 nodes or SPND nodes).

|=A0=A0=A0=A0=A0 = ^^^^

|=A0=A0=A0=A0=A0 with <or = "as">

 

Ok

 

|=A0

|=A0

|=A0 sec 7.2 = p 20

|=A0

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Not using the PS option for a

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 RFC3971 or = SPND MN would make more vulnerable the address in

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the home = link when the MN is away than when it is in the home

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = link

|=A0

|=A0 This is = a bit awkward.=A0 I suggest moving the "more vulnerable" part" = so

|=A0 that it = reads:

|=A0

|=A0 Not = using the PS option for a RFC3971 or SPND MN would make the = address in

|=A0 the = home link more vulnerable when the MN is away than when it is in = the

|=A0 home = link

ok

 

|=A0

|=A0 Sec 8 p = 22

|=A0

|=A0=A0=A0=A0=A0 = The security of proxied ND messages not including a PS option is = the

|=A0=A0=A0=A0=A0 = same of an unsecured ND message.=A0 The security of a proxied ND

|=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0^^

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 as

|=A0=A0=A0=A0=A0 message received by a = non-SEND host or RFC3971 host is the same of an

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 ^^

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 as

|=A0=A0=A0=A0 =A0unsecured ND = message.

ok

 

|=A0

|=A0 Sec 8 p = 22

|=A0

|=A0=A0=A0=A0=A0 Attacks to the timestamp of = the secured ND message can be performed

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^^

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 on.

 

Ok (although this may change, as commented = above).

 

 

Thanks again for your review!! =

I really appreciate your = contribution.

 

Alberto

------=_NextPart_000_0093_01CB1D31.3D1F3710-- From Sandra.Murphy@cobham.com Tue Jul 6 09:55:46 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D783A69B0; Tue, 6 Jul 2010 09:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG5OtfvlYrj2; Tue, 6 Jul 2010 09:55:43 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id E7C613A699C; Tue, 6 Jul 2010 09:55:42 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o66GtiRh009030; Tue, 6 Jul 2010 11:55:44 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o66GtiwB029134; Tue, 6 Jul 2010 11:55:44 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.96]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Jul 2010 12:55:43 -0400 Date: Tue, 6 Jul 2010 12:55:43 -0400 (Eastern Daylight Time) From: Sandra Murphy To: =?ISO-8859-15?Q?Alberto_Garc=EDa?= In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="326479267-6848-1278435343=:4996" X-OriginalArrivalTime: 06 Jul 2010 16:55:43.0592 (UTC) FILETIME=[1279A680:01CB1D2C] Cc: draft-ietf-csi-proxy-send.all@tools.ietf.org, csi-chairs@tools.ietf.org, iesg@ietf.org, draft-ietf-csi-send-cert@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 16:55:46 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --326479267-6848-1278435343=:4996 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Thank you. I was debating whether a message about message authorization=20 vs cert authorization values was more appropriately directed to the csi=20 group or the send-cert authors. This spares me the trouble of trying to=20 make up my mind. :-) I think this should prove to be an interesting discussion. --Sandy On Tue, 6 Jul 2010, Alberto Garc=EDa wrote: > Hi, > > The text of this email has been extracted from a thorough review of > draft-ietf-csi-proxy-send being made by Sandra Murphy. > > The reason why the email has been separated is to include the authors of > draft-ietf-csi-send-cert in the discussion of this part of the text, sinc= e I > think some of the issues raised by Sandra affect this document. > > > > I include my comments inline. > > > > | -----Mensaje original----- > > | De: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] > > | Enviado el: viernes, 02 de julio de 2010 2:31 > > | Para: iesg@ietf.org; secdir@ietf.org; > draft-ietf-csi-proxy-send.all@tools.ietf.org > > | Asunto: secdir review of draft-ietf-csi-proxy-send-04 > > | > > | This is a review of draft draft-ietf-csi-proxy-send-04.txt. > > | > > | I have reviewed this document as part of the security directorate's > > | ongoing effort to review all IETF documents being processed by the IES= G. > > | 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 provides new Neighbor Discovery options that will secure > > | proxied Neighbor Discovery messages. It is an update to: > > | > > | RFC4861: Neighbor Discovery in IPv6 > > | RFC4389: Neighbor Discovery Proxies (ND Proxy) > > | RFC3971: Send Neighbor Discovery (SEND) > > | > > | This draft relies on draft draft-ietf-csi-send-cert-04.txt. > > | > > | The need for new mechanisms for security for proxied messages is > explained > > | in draft-ietf-csi-sndp-prob-04.txt. > > | > > | I've read all of these, but it is pretty new to me, so I could have > missed > > | something. > > | > > | The Neighbor Discovery protocol communicates link-level addresses in t= he > > | protocol messages. The ND Proxy extension would make changes to those > > | fields. SEND, which secures the base ND protocol, relies on the sende= r > of > > | a message computing a signature associated with the source IP address = of > > | the message. Any ND Proxy changes to messages would invalidate the > > | signature and the ND Proxy itself could not generate a new signature > > | (since it would not have the private key associated with the source IP > > | address). This draft introduces a Proxy Signature (PS) option to secu= re > > | the proxied messages. > > | > > | RFC3971, the base SEND spec, defines a new Router Authorization > > | Certificate profile, dependent on RFC3779, which authorizes the router= to > > | act as a router and act for certain prefixes. Message authorization i= n > > | SEND of some ND messages checks the prefixes listed in the certificate > > | against the prefixes mentioned in those messages. There is no explici= t > > | representation in the certificate of the authority to act as a router. > > | Possession of the certificate in SEND serves as implicit authorization= to > > | act as a router, as that was the only authorization defined. > > | > > | With the introduction of proxies, there was a need to distinguish the > > | various roles that a node might have in the network. No longer is > > | possession of a certificate adequate authorization. The draft > > | draft-ietf-csi-send-cert-04.txt uses the KeyPurposeId field to > distinguish > > | three different roles: router, proxy and owner. That draft notes that > > | multiple key purposes are possible. I believe that it is also possibl= e > to > > | have single roles - so a node could be a proxy but not a router. > > > > Yes, of course single roles are supported. > > > > | With the extensions of the csi-send-cert draft, possession of a > > | certificate is no longer proof of any particular authorization. It se= em > > | clear to me that the authorization validation described in RFC3971 is = no > > | longer sufficient. I believe that a discussion is needed of what > messages > > | require or allow each particular key purpose authorization. Issuing a= n > > | RA, for example, seems likely to require the "router" value of the key > > | purpose field, if the new certificate format was used for authorizatio= n. > > | Issuing an NA may require the "owner" value of the key purpose field, = if > > | the new certificate format was used for authorization rather than a CG= A. > > | I do not know if that discussion would be more appropriate here or in = the > > | csi-send-cert draft, or another draft entirely that updates RFC3971 > > | directly. > > | > > | If a SPND proxy was using SEND to communicate with other nodes that > > | understood SPND, would it be OK to use a new format cert (with the > > | "router" KeyPurposeId) as a router certificate for the SEND RSA Signat= ure > > | Options? > > | > > I see. I agree that this needs more precision. > > > > In draft-ietf-csi-send-cert-05, section 7 (it is the same text as in > cert-04) it discusses the messages that are authorized by each KeyPurpose= Id > > - "router authorization value indicates that the > > certificate has been issued for allowing the router to advertise > > prefix(es)" > > (I understand that implicitly states that it authorizes the generation of= RA > messages. It is not crystal clear for me if it authorizes NA for routers, > although if I had to take this text literally, I would suppose routers wo= uld > need an 'owner' authorization if this PKI model substitutes RFC3971 CGA > authorization, considering that the prefix for NA would be narrowed in > general to one address, while the RA authorization is prefix-wide) > > - "proxy authorization value indicates that the > > certificate has been issued for allowing the proxy to perform > > proxying of neighbor discovery messages for the prefix(es) that are > > mentioned using the X.509 extensions for IP addresses" > > (I understand it now implicitly states it authorizes for ANY neighbor > discovery message. By the way, this is the assumption underlying in gener= al > draft-ietf-csi-proxy-send-04: in the application scenarios, some require = RA > proxying, which is assumed to be performed by means of the proxy cert) > > - "owner authorization [...]For an > > address in such certificate the host can assign the address, send/ > > receive traffic from this address, and can respond to NSes about that > > address" > > (this is the clearest of all statements - although I think issuing secure= d > NS and RS should also be considered) > > > > So, as defined now in draft-ietf-csi-proxy-send-04, proxy certificates > provide authorization for securing *any* ND message. Considering the > application scenarios, some require proxying RA (PMIPv6 and RFC4389), and > the MIPv6 scenario just require NS/NA proxying. > > > > In summary so far, there is some specification of the authorization in > draft-csi-send-cert, which I think it would be nice that it could be > refined, and if so, my opinion is that the refinement of which ND message= is > authorized by each KeyPurposeId should be in that document. > > However, continuing with this issue, I must say that the way the 'proxy > authorization' is defined, and the relationship with the other cases, is = not > satisfactory for me. > > I think the use of 'owner' should be restricted for hosts that really own > the address (therefore, a substitution of the CGA mechanism) - as opposed= to > proxies. > > For the 'proxy authorization', I think it could be refined into something > like "proxy host" authorization, and "proxy router" authorization. > > 'Proxy host' would authorize for proxying NA, NS and RS, and "proxy route= r" > authorization would authorize RA and Redirect. This would provide a finer > grain which I think would be desirable (for example, MIPv6 does not need > protecting neither RA nor redirect). > > I think this would work (if so, it should be changed in > draft-csi-send-cert). > > > > What do you think? (both authors of draft-csi-send-cert, Sandra, etc.). > > > > Regards, > > Alberto > > > > > > --326479267-6848-1278435343=:4996-- From secdir-bounces@mit.edu Tue Jul 6 10:08:27 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFBCF3A6A49 for ; Tue, 6 Jul 2010 10:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.116 X-Spam-Level: X-Spam-Status: No, score=-4.116 tagged_above=-999 required=5 tests=[AWL=2.483, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jd8+NqYP1lTL for ; Tue, 6 Jul 2010 10:08:26 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 6DBF63A6A50 for ; Tue, 6 Jul 2010 10:08:26 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o66H8SGJ024532 for ; Tue, 6 Jul 2010 13:08:28 -0400 Received: from mailhub-dmz-1.mit.edu (MAILHUB-DMZ-1.MIT.EDU [18.9.21.41]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o66H8OEM024483 for ; Tue, 6 Jul 2010 13:08:24 -0400 Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by mailhub-dmz-1.mit.edu (8.13.8/8.9.2) with ESMTP id o66H744H021206 for ; Tue, 6 Jul 2010 13:08:23 -0400 X-AuditID: 12074424-b7b63ae000000a0b-99-4c336307ee3d Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id 97.38.02571.703633C4; Tue, 6 Jul 2010 13:08:23 -0400 (EDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o66H8GVB009291; Tue, 6 Jul 2010 12:08:16 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o66H8E3A029830; Tue, 6 Jul 2010 12:08:15 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.96]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Jul 2010 13:08:14 -0400 Date: Tue, 6 Jul 2010 13:08:14 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Jaehoon Jeong In-Reply-To: <5A6980BCAE9E6D438D4D8A05540F6FB70115513677@BRM-EXCH-3.corp.brocade.com> Message-ID: References: <4C248D9A.5080508@inrialpes.fr> <5A6980BCAE9E6D438D4D8A05540F6FB70113043B9B@BRM-EXCH-3.corp.brocade.com> <4C25CA06.1080809@piuha.net> <5A6980BCAE9E6D438D4D8A05540F6FB70113658855@BRM-EXCH-3.corp.brocade.com> <4C2F3541.7000206@inrialpes.fr> <5A6980BCAE9E6D438D4D8A05540F6FB70115513677@BRM-EXCH-3.corp.brocade.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 06 Jul 2010 17:08:14.0733 (UTC) FILETIME=[D230ABD0:01CB1D2D] X-Brightmail-Tracker: AAAAAhTzSz4U9B3E X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Cc: 6man Chairs <6man-chairs@tools.ietf.org>, draft-ietf-csi-send-cert@tools.ietf.org, "secdir@mit.edu" , draft-ietf-csi-proxy-send.all@tools.ietf.org, Jari Arkko , IESG , "draft-ietf-6man-dns-options-bis.all@tools.ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 17:08:28 -0000 There is presently a discussion between the secdir and the authors of a new csi document that describes ways to use a new authorization value to provide more fine grained protection than "is a router". I notice that SEND protection of RA is mentioned below, with the caveat that RFC3971 SEND does not distinguish the specific authority of authorized routers. Perhaps this work in csi would be of value. --Sandy P.S. I added the appropriate recipient expansions for the csi drafts to the recipient list. That makes for a bunch of recipients, not all of whom would be interested in a longer exchange on the topic. Please consider trimming the list if you reply . On Sat, 3 Jul 2010, Jaehoon Jeong wrote: > Hi Vincent, > I would like to address your comments as below. > > The updated I-D is located in the following link: > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-ietf-6man-dns-options-bis-06.txt > > On Sat, Jul 3, 2010 at 11:31 AM, Jaehoon Jeong wrote: >> >> >> -----Original Message----- >> From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] >> Sent: Saturday, July 03, 2010 8:04 AM >> To: Jaehoon Jeong >> Cc: Jari Arkko; draft-ietf-6man-dns-options-bis.all@tools.ietf.org; secdir@mit.edu; IESG; 6man Chairs; vincent.roca@inrialpes.fr >> Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03 >> >> Dear authors, >> >> Thanks for your prompt reply. A few additional comments (it's my role ;-)) >> >> ** new "Security Considerations" section says: >>> This attack >>> is similar to Neighbor Discovery attacks that use Redirect or >>> Neighbor Advertisement messages to redirect traffic to individual >>> addresses to malicious parties. In general, the attacks related to >>> RDNSS and DNSSL are similar to both Neighbor Discovery attacks and >>> attacks against unauthenticated DHCP, as both can be used for both >>> "wholesale" traffic redirection and more specific attacks. >>> >> You're right, other attacks are possible that lead to the same result. ND and unauthenticated DHCP are such possibilities. However, IMHO this is not a sufficient reason not to RECOMMEND a security solution for RA. >> Indeed, if ND / DHCP are made robust but nothing is done for RA, then the threat remains. >> >> So the updated text does not fully satisfies me, even if the new paragraph is more clear than the old one. > > I reorganize the text such that the description for SEND (as a security solution for RA) follows the above paragraph: > ... > In general, the attacks related to RDNSS and DNSSL are similar to both > Neighbor Discovery attacks and attacks against unauthenticated DHCP, > as both can be used for both "wholesale" traffic redirection and more > specific attacks. > > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as > a security mechanism for ND, all the ND options including the RDNSS > and DNSSL options are automatically included in the signatures, so > the transport for the RA options is integrity-protected; that is, > SEND can prevent the spoofing of these DNS options with signatures. > Also, SEND enables an IPv6 host to verify that the sender of an RA is > actually a router authorized to act as a router. However, since any > valid SEND router can still insert RDNSS and DNSSL options, SEND > cannot verify which one is or is not authorized to send the options. > >> >>>> ** Section 7: >>>> Another point... the authors explain than network devices like >>>> switches can be configured in such a way to disable ND/DHCP from some >>>> ports. That's great and I agree it helps preventing attacks. >>>> However this is limited to wired networks. Nothing is said concerning >>>> ND configurations in wireless networks. The situation is rather >>>> different since any host can issue ND/DHCP traffic as if it were a >>>> legitimate server if I understand correctly. The document MUST >>>> include this kind of discussion. >>>> >>>> >>> But this is generic issue with spoofing RAs and I am not sure it is >>> the task of this document to specify the solutions. One solution >>> exists in SEND (RFC 3791). >>> >> Once again I agree. You don't have to specify technical solutions. However you need to provide a good security analysis, perhaps inherited from that of the base RA document for the generic RA threats, with some text describing the additional threats added by the proposed extensions. And since security solutions exist elsewhere (SEND), you should recommend their use. That's your responsibility. > > In the following paragraph, we address that SEND can prevent such RA DNS option spoofing: > > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as > a security mechanism for ND, all the ND options including the RDNSS > and DNSSL options are automatically included in the signatures, so > the transport for the RA options is integrity-protected; that is, > SEND can prevent the spoofing of these DNS options with signatures. > Also, SEND enables an IPv6 host to verify that the sender of an RA is > actually a router authorized to act as a router. However, since any > valid SEND router can still insert RDNSS and DNSSL options, SEND > cannot verify which one is or is not authorized to send the options. > >> >>>> ** Section 7: >>>> Yet another remark: SEND is listed as one potential solution to add >>>> signatures in ND packets issued from servers. >>>> I don't know SEND at all, so may be my remarks are flawed (but in >>>> that case the text should be at least clarified). >>>> - Shouldn't the use of SEND be RECOMMENDED as a solution to mitigate >>>> attacks? Current document is not clear. >>>> - Does SEND enable an authentication of the sender (the document only >>>> mentions integrity protection)? If there's no sender authentication, >>>> then I agree that the added value of SEND would be limited. I'd like >>>> the authors to clarify this as well. >>>> >>>> >>> The details are in RFC 3791 and its companion documents. SEND does >>> enable a host to verify that the sender of an RA is actually a router >>> authorized to act as a router. >>> >> >> The text in your proposed I-D update does not reflect this. Can you add it? Being able to authenticate the sender is as important as being able to check the packet integrity. > > According to the comments, the checking for valid router is mentioned in the middle: > > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as > a security mechanism for ND, all the ND options including the RDNSS > and DNSSL options are automatically included in the signatures, so > the transport for the RA options is integrity-protected; that is, > SEND can prevent the spoofing of these DNS options with signatures. > Also, SEND enables an IPv6 host to verify that the sender of an RA is > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > actually a router authorized to act as a router. However, since any > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > valid SEND router can still insert RDNSS and DNSSL options, SEND > cannot verify which one is or is not authorized to send the options. > >> >> ** I'm coming back to a comment I made earlier and that has not been answered. >> >> In the updated I-D, section 5.3.1, I read: >> >> "In the case where the DNS options of RDNSS and DNSSL can be obtained >> from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep >> some DNS options from all sources. " >> >> I don't see (but I read very quickly so I may have missed >> something) that secured RA/RDNSS/DNSSL messages be preferred in the choice. If some RA use SEND, they must be preferred over others. >> > > In Section 5.3.1, the considerations on SEND is mentioned as follows: > > In the case where the DNS options of RDNSS and DNSSL can be obtained > from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep > some DNS options from all sources. Unless explicitly specified for > the discovery mechanism, the exact number of addresses and domain > names to keep is a matter of local policy and implementation choice. > However, it is RECOMMENDED that at least three RDNSS addresses (or > DNSSL domain names) can be stored from at least two different > sources. The DNS options from Router Advertisements and DHCP SHOULD > be stored into DNS Repository and Resolver Repository so that > information from DHCP appears there first and therefore takes > precedence. Thus, the DNS information from DHCP takes precedence > over that from RA for DNS queries. On the other hand, for DNS > ^^^^^^^^^^^^^^^^^^^^^^^^^ > options announced by RA, if some RAs use the Secure Neighbor > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Discovery (SEND) protocol [RFC3971] for RA security, they MUST be > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > preferred over those which do not use SEND. Refer to Section 7 for > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the detailed discussion on SEND for RA DNS options. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> I hope my comments are useful. >> Cheers, >> >> Vincent >> > > Thanks for your efforts on the improvement for this document. > > Best Regards, > Paul > > > _______________________________________________ > secdir mailing list > secdir@mit.edu > https://mailman.mit.edu/mailman/listinfo/secdir > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From secdir-bounces@mit.edu Tue Jul 6 10:11:19 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22E7D3A6846 for ; Tue, 6 Jul 2010 10:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.288 X-Spam-Level: X-Spam-Status: No, score=-4.288 tagged_above=-999 required=5 tests=[AWL=2.311, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeRwffdZXqYV for ; Tue, 6 Jul 2010 10:11:15 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 288A13A699C for ; Tue, 6 Jul 2010 10:11:15 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o66HBHS2024945 for ; Tue, 6 Jul 2010 13:11:17 -0400 Received: from mailhub-dmz-3.mit.edu (MAILHUB-DMZ-3.MIT.EDU [18.9.21.42]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o66HBFW6024919 for ; Tue, 6 Jul 2010 13:11:15 -0400 Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by mailhub-dmz-3.mit.edu (8.13.8/8.9.2) with ESMTP id o66HB5jc001449 for ; Tue, 6 Jul 2010 13:11:14 -0400 X-AuditID: 12074425-b7b12ae0000009fd-c3-4c3363b27abe Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by dmz-mailsec-scanner-8.mit.edu (Symantec Brightmail Gateway) with SMTP id E0.5D.02557.2B3633C4; Tue, 6 Jul 2010 13:11:14 -0400 (EDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o66HA5s6032180; Tue, 6 Jul 2010 10:11:09 -0700 Received: from brm-exedge.brocade.com (brm-exedge.brocade.com [144.49.197.7]) by mx0b-000f0801.pphosted.com with ESMTP id pv26e867p-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 06 Jul 2010 10:11:09 -0700 Received: from brm-excashub-1.corp.brocade.com (172.16.72.131) by BRM-EXEDGE-1.corp.brocade.com (172.16.72.149) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 6 Jul 2010 11:10:31 -0600 Received: from brm-exch-3.corp.brocade.com ([169.254.3.246]) by brm-excashub-1.corp.brocade.com ([172.16.72.131]) with mapi; Tue, 6 Jul 2010 11:11:07 -0600 From: Jaehoon Jeong To: Sandra Murphy Date: Tue, 6 Jul 2010 11:11:05 -0600 Thread-Topic: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03 Thread-Index: AcsdLdVMvXCzLbgnQXms1IFQCsxdCgAAFXrw Message-ID: <5A6980BCAE9E6D438D4D8A05540F6FB70115649EA0@BRM-EXCH-3.corp.brocade.com> References: <4C248D9A.5080508@inrialpes.fr> <5A6980BCAE9E6D438D4D8A05540F6FB70113043B9B@BRM-EXCH-3.corp.brocade.com> <4C25CA06.1080809@piuha.net> <5A6980BCAE9E6D438D4D8A05540F6FB70113658855@BRM-EXCH-3.corp.brocade.com> <4C2F3541.7000206@inrialpes.fr> <5A6980BCAE9E6D438D4D8A05540F6FB70115513677@BRM-EXCH-3.corp.brocade.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-06_01:2010-02-06, 2010-07-06, 2010-07-06 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1007060083 X-Brightmail-Tracker: AAAAAhTzSz4U9B3E X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id o66HBFW6024919 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Tue, 06 Jul 2010 11:10:52 -0700 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, "draft-ietf-csi-send-cert@tools.ietf.org" , "secdir@mit.edu" , "draft-ietf-csi-proxy-send.all@tools.ietf.org" , Jari Arkko , IESG , "draft-ietf-6man-dns-options-bis.all@tools.ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 17:11:19 -0000 Sandra, Thanks for this useful information. Best Regards, Paul -----Original Message----- From: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] Sent: Tuesday, July 06, 2010 12:08 PM To: Jaehoon Jeong Cc: Vincent Roca; 6man Chairs; secdir@mit.edu; draft-ietf-6man-dns-options-bis.all@tools.ietf.org; Jari Arkko; IESG; draft-ietf-csi-proxy-send.all@tools.ietf.org; draft-ietf-csi-send-cert@tools.ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03 There is presently a discussion between the secdir and the authors of a new csi document that describes ways to use a new authorization value to provide more fine grained protection than "is a router". I notice that SEND protection of RA is mentioned below, with the caveat that RFC3971 SEND does not distinguish the specific authority of authorized routers. Perhaps this work in csi would be of value. --Sandy P.S. I added the appropriate recipient expansions for the csi drafts to the recipient list. That makes for a bunch of recipients, not all of whom would be interested in a longer exchange on the topic. Please consider trimming the list if you reply . On Sat, 3 Jul 2010, Jaehoon Jeong wrote: > Hi Vincent, > I would like to address your comments as below. > > The updated I-D is located in the following link: > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/d > raft-ietf-6man-dns-options-bis-06.txt > > On Sat, Jul 3, 2010 at 11:31 AM, Jaehoon Jeong wrote: >> >> >> -----Original Message----- >> From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] >> Sent: Saturday, July 03, 2010 8:04 AM >> To: Jaehoon Jeong >> Cc: Jari Arkko; draft-ietf-6man-dns-options-bis.all@tools.ietf.org; >> secdir@mit.edu; IESG; 6man Chairs; vincent.roca@inrialpes.fr >> Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03 >> >> Dear authors, >> >> Thanks for your prompt reply. A few additional comments (it's my role >> ;-)) >> >> ** new "Security Considerations" section says: >>> This attack >>> is similar to Neighbor Discovery attacks that use Redirect or >>> Neighbor Advertisement messages to redirect traffic to individual >>> addresses to malicious parties. In general, the attacks related to >>> RDNSS and DNSSL are similar to both Neighbor Discovery attacks and >>> attacks against unauthenticated DHCP, as both can be used for both >>> "wholesale" traffic redirection and more specific attacks. >>> >> You're right, other attacks are possible that lead to the same result. ND and unauthenticated DHCP are such possibilities. However, IMHO this is not a sufficient reason not to RECOMMEND a security solution for RA. >> Indeed, if ND / DHCP are made robust but nothing is done for RA, then the threat remains. >> >> So the updated text does not fully satisfies me, even if the new paragraph is more clear than the old one. > > I reorganize the text such that the description for SEND (as a security solution for RA) follows the above paragraph: > ... > In general, the attacks related to RDNSS and DNSSL are similar to both > Neighbor Discovery attacks and attacks against unauthenticated DHCP, > as both can be used for both "wholesale" traffic redirection and more > specific attacks. > > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as > a security mechanism for ND, all the ND options including the RDNSS > and DNSSL options are automatically included in the signatures, so > the transport for the RA options is integrity-protected; that is, > SEND can prevent the spoofing of these DNS options with signatures. > Also, SEND enables an IPv6 host to verify that the sender of an RA is > actually a router authorized to act as a router. However, since any > valid SEND router can still insert RDNSS and DNSSL options, SEND > cannot verify which one is or is not authorized to send the options. > >> >>>> ** Section 7: >>>> Another point... the authors explain than network devices like >>>> switches can be configured in such a way to disable ND/DHCP from >>>> some ports. That's great and I agree it helps preventing attacks. >>>> However this is limited to wired networks. Nothing is said >>>> concerning ND configurations in wireless networks. The situation is >>>> rather different since any host can issue ND/DHCP traffic as if it >>>> were a legitimate server if I understand correctly. The document >>>> MUST include this kind of discussion. >>>> >>>> >>> But this is generic issue with spoofing RAs and I am not sure it is >>> the task of this document to specify the solutions. One solution >>> exists in SEND (RFC 3791). >>> >> Once again I agree. You don't have to specify technical solutions. However you need to provide a good security analysis, perhaps inherited from that of the base RA document for the generic RA threats, with some text describing the additional threats added by the proposed extensions. And since security solutions exist elsewhere (SEND), you should recommend their use. That's your responsibility. > > In the following paragraph, we address that SEND can prevent such RA DNS option spoofing: > > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as > a security mechanism for ND, all the ND options including the RDNSS > and DNSSL options are automatically included in the signatures, so > the transport for the RA options is integrity-protected; that is, > SEND can prevent the spoofing of these DNS options with signatures. > Also, SEND enables an IPv6 host to verify that the sender of an RA is > actually a router authorized to act as a router. However, since any > valid SEND router can still insert RDNSS and DNSSL options, SEND > cannot verify which one is or is not authorized to send the options. > >> >>>> ** Section 7: >>>> Yet another remark: SEND is listed as one potential solution to add >>>> signatures in ND packets issued from servers. >>>> I don't know SEND at all, so may be my remarks are flawed (but in >>>> that case the text should be at least clarified). >>>> - Shouldn't the use of SEND be RECOMMENDED as a solution to >>>> mitigate attacks? Current document is not clear. >>>> - Does SEND enable an authentication of the sender (the document >>>> only mentions integrity protection)? If there's no sender >>>> authentication, then I agree that the added value of SEND would be >>>> limited. I'd like the authors to clarify this as well. >>>> >>>> >>> The details are in RFC 3791 and its companion documents. SEND does >>> enable a host to verify that the sender of an RA is actually a >>> router authorized to act as a router. >>> >> >> The text in your proposed I-D update does not reflect this. Can you add it? Being able to authenticate the sender is as important as being able to check the packet integrity. > > According to the comments, the checking for valid router is mentioned in the middle: > > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as > a security mechanism for ND, all the ND options including the RDNSS > and DNSSL options are automatically included in the signatures, so > the transport for the RA options is integrity-protected; that is, > SEND can prevent the spoofing of these DNS options with signatures. > Also, SEND enables an IPv6 host to verify that the sender of an RA is > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > actually a router authorized to act as a router. However, since any > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > valid SEND router can still insert RDNSS and DNSSL options, SEND > cannot verify which one is or is not authorized to send the options. > >> >> ** I'm coming back to a comment I made earlier and that has not been answered. >> >> In the updated I-D, section 5.3.1, I read: >> >> "In the case where the DNS options of RDNSS and DNSSL can be obtained >> from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep >> some DNS options from all sources. " >> >> I don't see (but I read very quickly so I may have missed >> something) that secured RA/RDNSS/DNSSL messages be preferred in the choice. If some RA use SEND, they must be preferred over others. >> > > In Section 5.3.1, the considerations on SEND is mentioned as follows: > > In the case where the DNS options of RDNSS and DNSSL can be obtained > from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep > some DNS options from all sources. Unless explicitly specified for > the discovery mechanism, the exact number of addresses and domain > names to keep is a matter of local policy and implementation choice. > However, it is RECOMMENDED that at least three RDNSS addresses (or > DNSSL domain names) can be stored from at least two different > sources. The DNS options from Router Advertisements and DHCP SHOULD > be stored into DNS Repository and Resolver Repository so that > information from DHCP appears there first and therefore takes > precedence. Thus, the DNS information from DHCP takes precedence > over that from RA for DNS queries. On the other hand, for DNS > ^^^^^^^^^^^^^^^^^^^^^^^^^ > options announced by RA, if some RAs use the Secure Neighbor > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Discovery (SEND) protocol [RFC3971] for RA security, they MUST be > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > preferred over those which do not use SEND. Refer to Section 7 for > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the detailed discussion on SEND for RA DNS options. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> I hope my comments are useful. >> Cheers, >> >> Vincent >> > > Thanks for your efforts on the improvement for this document. > > Best Regards, > Paul > > > _______________________________________________ > secdir mailing list > secdir@mit.edu > https://mailman.mit.edu/mailman/listinfo/secdir > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From rogaglia@cisco.com Wed Jul 7 02:11:38 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5548C3A659C; Wed, 7 Jul 2010 02:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oq004+xPoNvo; Wed, 7 Jul 2010 02:11:35 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8AA723A67D3; Wed, 7 Jul 2010 02:11:34 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 3815 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAArhM0xAZnwM/2dsb2JhbACgB3GlZZpihSQEiD0 X-IronPort-AV: E=Sophos;i="4.53,551,1272844800"; d="p7s'?scan'208";a="129504915" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 07 Jul 2010 09:11:37 +0000 Received: from Roque-Gaglianos-MacBook-Pro.local ([144.254.21.53]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o679BTh1004480; Wed, 7 Jul 2010 09:11:29 GMT Received: from [127.0.0.1] by Roque-Gaglianos-MacBook-Pro.local (PGP Universal service); Wed, 07 Jul 2010 11:11:43 +0200 X-PGP-Universal: processed; by Roque-Gaglianos-MacBook-Pro.local on Wed, 07 Jul 2010 11:11:43 +0200 Mime-Version: 1.0 (Apple Message framework v1081) From: Roque Gagliano In-Reply-To: Date: Wed, 7 Jul 2010 11:11:31 +0200 Message-Id: <99775B3B-8619-4EDC-9F6F-23C231C44F18@cisco.com> References: To: =?iso-8859-1?Q?Alberto_Garc=EDa?= X-Mailer: Apple Mail (2.1081) Content-Type: multipart/signed; boundary=Apple-Mail-62--461019046; protocol="application/pkcs7-signature"; micalg=sha1 X-Mailman-Approved-At: Wed, 07 Jul 2010 05:58:03 -0700 Cc: draft-ietf-csi-send-cert@tools.ietf.org, secdir@ietf.org, 'Sandra Murphy' , draft-ietf-csi-proxy-send.all@tools.ietf.org, iesg@ietf.org, csi-chairs@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 09:11:38 -0000 --Apple-Mail-62--461019046 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Alberto, > In draft-ietf-csi-send-cert-05, section 7 (it is the same text as in = cert-04) it discusses the messages that are authorized by each = KeyPurposeId >=20 > - "router authorization value indicates that the >=20 > certificate has been issued for allowing the router to advertise >=20 > prefix(es)" >=20 >=20 What about the following text? "router authorization value indicates that the certificate has been issued for allowing the router to generate RA = messages for the prefix(es) that are mentioned in the X.509 extensions for IP = addresses"" > (I understand that implicitly states that it authorizes the generation = of RA messages. It is not crystal clear for me if it authorizes NA for = routers, although if I had to take this text literally, I would suppose = routers would need an 'owner' authorization if this PKI model = substitutes RFC3971 CGA authorization, considering that the prefix for = NA would be narrowed in general to one address, while the RA = authorization is prefix-wide) >=20 > - "proxy authorization value indicates that the >=20 > certificate has been issued for allowing the proxy to perform >=20 > proxying of neighbor discovery messages for the prefix(es) that are >=20 > mentioned using the X.509 extensions for IP addresses" >=20 > (I understand it now implicitly states it authorizes for ANY neighbor = discovery message. By the way, this is the assumption underlying in = general draft-ietf-csi-proxy-send-04: in the application scenarios, some = require RA proxying, which is assumed to be performed by means of the = proxy cert) >=20 >=20 What about the following text? - "proxy authorization value indicates that the certificate has been issued for allowing the proxy to perform proxying of RA messages for the prefix(es) that are mentioned in the X.509 extensions for IP addresses" > - "owner authorization [...]For an >=20 > address in such certificate the host can assign the address, send/ >=20 > receive traffic from this address, and can respond to NSes about = that >=20 > address" >=20 > (this is the clearest of all statements - although I think issuing = secured NS and RS should also be considered) >=20 What about the following text? - "owner authorization [...]For an address in such certificate the host can assign the address, send/ receive traffic from this address, and can respond to ND messages = about that address" > So, as defined now in draft-ietf-csi-proxy-send-04, proxy certificates = provide authorization for securing *any* ND message. Considering the = application scenarios, some require proxying RA (PMIPv6 and RFC4389), = and the MIPv6 scenario just require NS/NA proxying. >=20 > =20 >=20 > In summary so far, there is some specification of the authorization in = draft-csi-send-cert, which I think it would be nice that it could be = refined, and if so, my opinion is that the refinement of which ND = message is authorized by each KeyPurposeId should be in that document. >=20 > However, continuing with this issue, I must say that the way the = 'proxy authorization' is defined, and the relationship with the other = cases, is not satisfactory for me. >=20 > I think the use of 'owner' should be restricted for hosts that really = own the address (therefore, a substitution of the CGA mechanism) - as = opposed to proxies. >=20 > For the 'proxy authorization', I think it could be refined into = something like =93proxy host=94 authorization, and =93proxy router=94 = authorization. >=20 > =91Proxy host=92 would authorize for proxying NA, NS and RS, and = =93proxy router=94 authorization would authorize RA and Redirect. This = would provide a finer grain which I think would be desirable (for = example, MIPv6 does not need protecting neither RA nor redirect). >=20 >=20 So, what you are proposing is to modify the name of the current EKU to = "proxy router" and generate a new EKU named "proxy host"? As a side note, I would like to proposse that you modify the first = paragraph of Section 5.2.2 (Processing rules for receivers) by making a = reference to the draft-csi-send-cert Section 9 as the certificate = validation method.=20 Additional, In the draft-csi-send-cert document, we could add the = following text at the end of Section 9 (validation): "The host MUST verify that the required Key PurposedId(s) value is = present as described in Section 7." In this sense we close the loop as: - you validate the certificate using SIDR defined validation = method. - you then validate your particular KeyPurpisedId using the text = in Section 9. Roque. =09 > I think this would work (if so, it should be changed in = draft-csi-send-cert). >=20 > =20 >=20 > What do you think? (both authors of draft-csi-send-cert, Sandra, = etc.). >=20 > =20 >=20 > Regards, >=20 > Alberto >=20 > =20 >=20 > =20 >=20 --Apple-Mail-62--461019046 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQL5vTKNUCwWQOjacT KoWGmzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDUxMjAwMDAwMFoXDTExMDUxMjIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDlJvcXVlIEdh Z2xpYW5vMSEwHwYJKoZIhvcNAQkBFhJyb2dhZ2xpYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDGyowL31WLYDEbY59gvyg0OcBMh/AqsE5EpWzobCsYs1secYJvZlKm 5+2CjNWTQziHYo19cp7DG9XDLLGdLW7HC0VikR65cxIURXJoUKQO3QJYV99mrtnwCKf/FyzxeF11 pRILFbkgvpAZjCLig/RgNLt5cGGl8FGCe22sBWdBxU+sQiffsS774edvd3xFiRPaB/sOVPc4fbvw twOkEuas4IaH9Oivt1ZUvrFmBnS8mCYbk0OKjKjIEeS62TPsGCZv3f9Ffgm0Az4On6MiP1dARKp/ it5aow047hoFNXFCsWVLeEyDLk3avqS3/9fH//9NWvj0Mq/FhkaEw4Sv66TLAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAIxI8f9LAL0e mThKlUnwxlBH+q2htxBy9vBt24uGl8dunGyK4Aq7PAQiCF2XJfM2sWSRpdkIdbd9cD5upkcteP4s pL/T85qsfT1dLiQDTZ6/o19umk6DkqG0DpR+n+7jTUGdCzDhhzTZZblqY0afimcQ79uqZcF5ojDl N5Np93N3djqAmD37aKG1KE8xzBP0WiwxfVIGYua098YIsioWb0zvGmPd9JdMO55+jwkjFAOsT5kK ivXkjDnZJ1HM8GVQjGPnYBDEJBmC2B+kdbpi17cntYE/6V/SgrpB4t14YuswgMYRh1lGP7eKiiAj mwnaJL9aMMrqBwHLY/BLEA+3hRsxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYabMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDcwNzA5 MTEzMlowIwYJKoZIhvcNAQkEMRYEFCta9oeidjrqsj3DSU4fPviXQGmWMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEC+b0yjVAsFkDo2nEyqFhpswggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYab MA0GCSqGSIb3DQEBAQUABIIBABp6VrOd40g/t/qhLqC8RjMSiWfifyCdXozxh1bUgIJH/dsBhIkQ A1kU55fMlaCGKqX8G/AZYQIXzavt3wtFRRSt0fVzWVB53PlKt2h4es5RwHpdgQOzzcIo29WWXnKx qZb7QMhpRhQwQz2Nomuo2ESD4MmwPauKGBZyBTy32zAMT8KnHeDwsXgESte5QS5tDg8A+sL7ojg6 tfrcPuu6zrypLe6aAOaqbuovHOsBNhOldhH7QT8JiBjV9yOEe4SqxqM2oLF/vwvaLG+ntfY8snwI Kvg0QW70o6xpwJ35P9tTiqDhXgwaaUqGBXUoK0TDRCaIFNSBDtXkCn/m6Woi3vYAAAAAAAA= --Apple-Mail-62--461019046-- From alberto@it.uc3m.es Wed Jul 7 05:39:09 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EC5E3A67A1; Wed, 7 Jul 2010 05:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oi4920nTwVFd; Wed, 7 Jul 2010 05:39:08 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id AE5123A67EB; Wed, 7 Jul 2010 05:39:07 -0700 (PDT) X-uc3m-safe: yes Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id E78DEBE6349; Wed, 7 Jul 2010 14:39:03 +0200 (CEST) From: =?ISO-8859-15?Q?Alberto_Garc=EDa?= To: "'Roque Gagliano'" References: <99775B3B-8619-4EDC-9F6F-23C231C44F18@cisco.com> Date: Wed, 7 Jul 2010 14:39:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <99775B3B-8619-4EDC-9F6F-23C231C44F18@cisco.com> Thread-Index: AcsdtGjQw9p8LRybRauUN66MJTFk3gAEcssQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17490.007 X-Mailman-Approved-At: Wed, 07 Jul 2010 05:58:03 -0700 Cc: draft-ietf-csi-send-cert@tools.ietf.org, secdir@ietf.org, 'Sandra Murphy' , draft-ietf-csi-proxy-send.all@tools.ietf.org, iesg@ietf.org, csi-chairs@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 12:39:09 -0000 Hi Roque,=20 Thanks for your fast answer. | -----Mensaje original----- | De: Roque Gagliano [mailto:rogaglia@cisco.com] | Enviado el: mi=E9rcoles, 07 de julio de 2010 11:12 | Para: Alberto Garc=EDa | CC: 'Sandra Murphy'; iesg@ietf.org; secdir@ietf.org; draft-ietf-csi-proxy- | send.all@tools.ietf.org; draft-ietf-csi-send-cert@tools.ietf.org; = csi- | chairs@tools.ietf.org | Asunto: Re: secdir review of draft-ietf-csi-proxy-send-04 | =20 | Hi Alberto, | =20 | > In draft-ietf-csi-send-cert-05, section 7 (it is the same text as = in cert-04) it | discusses the messages that are authorized by each KeyPurposeId | > | > - "router authorization value indicates that the | > certificate has been issued for allowing the router to advertise | > prefix(es)" | > | > | What about the following text? | =20 | "router authorization value indicates that the | certificate has been issued for allowing the router to generate RA messages for | the | prefix(es) that are mentioned in the X.509 extensions for IP addresses"" Yes, although I would also include Redirect messages, since the 'router function' pack is RA+Redirect | =20 | =20 | > (I understand that implicitly states that it authorizes the = generation of RA | messages. It is not crystal clear for me if it authorizes NA for = routers, although if | I had to take this text literally, I would suppose routers would need = an 'owner' | authorization if this PKI model substitutes RFC3971 CGA = authorization, | considering that the prefix for NA would be narrowed in general to = one address, | while the RA authorization is prefix-wide) | > | > - "proxy authorization value indicates that the | > certificate has been issued for allowing the proxy to perform | > proxying of neighbor discovery messages for the prefix(es) that = are | > | > mentioned using the X.509 extensions for IP addresses" | > | > (I understand it now implicitly states it authorizes for ANY = neighbor discovery | message. By the way, this is the assumption underlying in general draft-ietf-csi- | proxy-send-04: in the application scenarios, some require RA = proxying, which is | assumed to be performed by means of the proxy cert) | > | > | What about the following text? | =20 | - "proxy authorization value indicates that the | certificate has been issued for allowing the proxy to perform | proxying of RA messages for the prefix(es) that are | mentioned in the X.509 extensions for IP addresses" Yes, also including Redirect.=20 | =20 | =20 | > - "owner authorization [...]For an | > address in such certificate the host can assign the address, = send/ | > receive traffic from this address, and can respond to NSes about that | > address" | > | > (this is the clearest of all statements - although I think issuing secured NS and | RS should also be considered) | > | What about the following text? | =20 | - "owner authorization [...]For an | address in such certificate the host can assign the address, send/ | receive traffic from this address, and can respond to ND messages about that | address" Ummm. I think this is more than 'respond', since it also authorizes the = node to sign RS and NS. I would detail the messages that are covered by this authorization: NS, NA, RS. What do you think? | =20 | > So, as defined now in draft-ietf-csi-proxy-send-04, proxy = certificates provide | authorization for securing *any* ND message. Considering the = application | scenarios, some require proxying RA (PMIPv6 and RFC4389), and the = MIPv6 | scenario just require NS/NA proxying. | > | > In summary so far, there is some specification of the authorization = in draft-csi- | send-cert, which I think it would be nice that it could be refined, = and if so, my | opinion is that the refinement of which ND message is authorized by = each | KeyPurposeId should be in that document. | > | > However, continuing with this issue, I must say that the way the = 'proxy | authorization' is defined, and the relationship with the other cases, = is not | satisfactory for me. | > | > I think the use of 'owner' should be restricted for hosts that = really own the | address (therefore, a substitution of the CGA mechanism) - as opposed = to proxies. | > | > For the 'proxy authorization', I think it could be refined into something like | "proxy host" authorization, and "proxy router" authorization. | > | > 'Proxy host' would authorize for proxying NA, NS and RS, and "proxy router" | authorization would authorize RA and Redirect. This would provide a = finer grain | which I think would be desirable (for example, MIPv6 does not need protecting | neither RA nor redirect). | > | > | =20 | So, what you are proposing is to modify the name of the current EKU = to "proxy | router" and generate a new EKU named "proxy host"? Yes. | =20 | As a side note, I would like to proposse that you modify the first paragraph of | Section 5.2.2 (Processing rules for receivers) by making a reference = to the draft- | csi-send-cert Section 9 as the certificate validation method. Sure. I can include it in 5.2.2, processing step #2, in which = certificates are considered | =20 | Additional, In the draft-csi-send-cert document, we could add the following text | at the end of Section 9 (validation): | =20 | "The host MUST verify that the required Key PurposedId(s) value is present as | described in Section 7." | =20 | In this sense we close the loop as: | - you validate the certificate using SIDR defined validation method. | - you then validate your particular KeyPurpisedId using the text in | Section 9. I agree that the validation section can be complemented a bit, for = example, stating that at least one KeyPurposeId MUST be present. The part 'the required' in the text you propose is not clear to me: required... for = what, in which sense? Just one question (which could affect validation): I assume (maybe I'm wrong) that a certificate is bound to a Certified IPv6 address space, in = the sense that the KeyPurposeId affects to ALL the addresses (or prefixes) = of the certificate. Then, I don't understand how a given prefix can be at = the same time 'router' or 'owner', or 'proxy router' or 'proxy host'. For = me, all this functionalities should inherently incompatible for a given = prefix (for example, a router maybe is authorized as a 'router' for a prefix, = but should be authorized as 'owner' for just a single address of the prefix (don't think it is a good idea to allow to be 'owner' of the whole = prefix, which in fact it is not). Also, either a node is 'router' for a prefix, = or 'proxy router', but both do not make sense. The same for 'owner' and = 'proxy owner/host' If some combinations are possible, but others are not, it should also be specified, I think. Regards, Alberto=20 | =20 | Roque. | =20 | =20 | =20 | =20 | =20 | > I think this would work (if so, it should be changed in draft-csi-send-cert). | > | > | > | > What do you think? (both authors of draft-csi-send-cert, Sandra, = etc.). | > | > | > | > Regards, | > | > Alberto | > | > | > | > | > From rogaglia@cisco.com Wed Jul 7 06:26:15 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96B7B3A67CF; Wed, 7 Jul 2010 06:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.32 X-Spam-Level: X-Spam-Status: No, score=-9.32 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ut4jKKAWKH74; Wed, 7 Jul 2010 06:26:14 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D5B883A6812; Wed, 7 Jul 2010 06:26:13 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 3815 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEcdNExAZnwN/2dsb2JhbACgF3GmA5pqhSQEiD0 X-IronPort-AV: E=Sophos;i="4.53,552,1272844800"; d="p7s'?scan'208";a="129558754" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2010 13:26:16 +0000 Received: from Roque-Gaglianos-MacBook-Pro.local ([144.254.21.53]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o67DQ9QE001621; Wed, 7 Jul 2010 13:26:10 GMT Received: from [127.0.0.1] by Roque-Gaglianos-MacBook-Pro.local (PGP Universal service); Wed, 07 Jul 2010 15:26:20 +0200 X-PGP-Universal: processed; by Roque-Gaglianos-MacBook-Pro.local on Wed, 07 Jul 2010 15:26:20 +0200 Mime-Version: 1.0 (Apple Message framework v1081) From: Roque Gagliano In-Reply-To: Date: Wed, 7 Jul 2010 15:26:09 +0200 Message-Id: <911338BA-7E6A-41CB-BB01-BFF7A819F050@cisco.com> References: <99775B3B-8619-4EDC-9F6F-23C231C44F18@cisco.com> To: =?iso-8859-1?Q?Alberto_Garc=EDa?= X-Mailer: Apple Mail (2.1081) Content-Type: multipart/signed; boundary=Apple-Mail-72--445740959; protocol="application/pkcs7-signature"; micalg=sha1 X-Mailman-Approved-At: Wed, 07 Jul 2010 06:30:12 -0700 Cc: draft-ietf-csi-send-cert@tools.ietf.org, secdir@ietf.org, 'Sandra Murphy' , draft-ietf-csi-proxy-send.all@tools.ietf.org, iesg@ietf.org, csi-chairs@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 13:26:15 -0000 --Apple-Mail-72--445740959 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Alberto, Please see inline. Roque. On Jul 7, 2010, at 2:39 PM, Alberto Garc=EDa wrote: > Hi Roque,=20 > Thanks for your fast answer. >=20 > | -----Mensaje original----- > | De: Roque Gagliano [mailto:rogaglia@cisco.com] > | Enviado el: mi=E9rcoles, 07 de julio de 2010 11:12 > | Para: Alberto Garc=EDa > | CC: 'Sandra Murphy'; iesg@ietf.org; secdir@ietf.org; > draft-ietf-csi-proxy- > | send.all@tools.ietf.org; draft-ietf-csi-send-cert@tools.ietf.org; = csi- > | chairs@tools.ietf.org > | Asunto: Re: secdir review of draft-ietf-csi-proxy-send-04 > | =20 > | Hi Alberto, > | =20 > | > In draft-ietf-csi-send-cert-05, section 7 (it is the same text as = in > cert-04) it > | discusses the messages that are authorized by each KeyPurposeId > | > > | > - "router authorization value indicates that the > | > certificate has been issued for allowing the router to = advertise > | > prefix(es)" > | > > | > > | What about the following text? > | =20 > | "router authorization value indicates that the > | certificate has been issued for allowing the router to generate = RA > messages for > | the > | prefix(es) that are mentioned in the X.509 extensions for IP > addresses"" >=20 > Yes, although I would also include Redirect messages, since the = 'router > function' pack is RA+Redirect >=20 ok. > | =20 > | =20 > | > (I understand that implicitly states that it authorizes the = generation > of RA > | messages. It is not crystal clear for me if it authorizes NA for = routers, > although if > | I had to take this text literally, I would suppose routers would = need an > 'owner' > | authorization if this PKI model substitutes RFC3971 CGA = authorization, > | considering that the prefix for NA would be narrowed in general to = one > address, > | while the RA authorization is prefix-wide) > | > > | > - "proxy authorization value indicates that the > | > certificate has been issued for allowing the proxy to perform > | > proxying of neighbor discovery messages for the prefix(es) = that are > | > > | > mentioned using the X.509 extensions for IP addresses" > | > > | > (I understand it now implicitly states it authorizes for ANY = neighbor > discovery > | message. By the way, this is the assumption underlying in general > draft-ietf-csi- > | proxy-send-04: in the application scenarios, some require RA = proxying, > which is > | assumed to be performed by means of the proxy cert) > | > > | > > | What about the following text? > | =20 > | - "proxy authorization value indicates that the > | certificate has been issued for allowing the proxy to perform > | proxying of RA messages for the prefix(es) that are > | mentioned in the X.509 extensions for IP addresses" >=20 > Yes, also including Redirect.=20 ok. >=20 > | =20 > | =20 > | > - "owner authorization [...]For an > | > address in such certificate the host can assign the address, = send/ > | > receive traffic from this address, and can respond to NSes = about > that > | > address" > | > > | > (this is the clearest of all statements - although I think = issuing > secured NS and > | RS should also be considered) > | > > | What about the following text? > | =20 > | - "owner authorization [...]For an > | address in such certificate the host can assign the address, = send/ > | receive traffic from this address, and can respond to ND = messages > about that > | address" >=20 > Ummm. I think this is more than 'respond', since it also authorizes = the node > to sign RS and NS. I would detail the messages that are covered by = this > authorization: NS, NA, RS. > What do you think? >=20 > - "owner authorization [...]For an > | address in such certificate the host can assign the address, = send/ > | receive traffic from this address, and can send NS, NA and RS = messages > about that address" ok, but lets keep the respond in the sentence: - "owner authorization [...]For an address in such certificate the host = can assign the address, send/receive traffic from this address, and can = send or respond NS, NA and RS messages about that address" > | =20 > | > So, as defined now in draft-ietf-csi-proxy-send-04, proxy = certificates > provide > | authorization for securing *any* ND message. Considering the = application > | scenarios, some require proxying RA (PMIPv6 and RFC4389), and the = MIPv6 > | scenario just require NS/NA proxying. > | > > | > In summary so far, there is some specification of the = authorization in > draft-csi- > | send-cert, which I think it would be nice that it could be refined, = and > if so, my > | opinion is that the refinement of which ND message is authorized by = each > | KeyPurposeId should be in that document. > | > > | > However, continuing with this issue, I must say that the way the = 'proxy > | authorization' is defined, and the relationship with the other = cases, is > not > | satisfactory for me. > | > > | > I think the use of 'owner' should be restricted for hosts that = really > own the > | address (therefore, a substitution of the CGA mechanism) - as = opposed to > proxies. > | > > | > For the 'proxy authorization', I think it could be refined into > something like > | "proxy host" authorization, and "proxy router" authorization. > | > > | > 'Proxy host' would authorize for proxying NA, NS and RS, and = "proxy > router" > | authorization would authorize RA and Redirect. This would provide a = finer > grain > | which I think would be desirable (for example, MIPv6 does not need > protecting > | neither RA nor redirect). > | > > | > > | =20 > | So, what you are proposing is to modify the name of the current EKU = to > "proxy > | router" and generate a new EKU named "proxy host"? >=20 > Yes. Ok. >=20 > | =20 > | As a side note, I would like to proposse that you modify the first > paragraph of > | Section 5.2.2 (Processing rules for receivers) by making a = reference to > the draft- > | csi-send-cert Section 9 as the certificate validation method. >=20 > Sure. I can include it in 5.2.2, processing step #2, in which = certificates > are considered >=20 > | =20 > | Additional, In the draft-csi-send-cert document, we could add the > following text > | at the end of Section 9 (validation): > | =20 > | "The host MUST verify that the required Key PurposedId(s) value is > present as > | described in Section 7." > | =20 > | In this sense we close the loop as: > | - you validate the certificate using SIDR defined validation = method. > | - you then validate your particular KeyPurpisedId using the text = in > | Section 9. >=20 > I agree that the validation section can be complemented a bit, for = example, > stating that at least one KeyPurposeId MUST be present. The part 'the > required' in the text you propose is not clear to me: required... for = what, > in which sense? >=20 I was referring to verify that the KeyPurposeId matches the application. = What about replacing "required" by "correspondent" "The host MUST verify that the correspondent Key PurposedId(s) value = is present as described in Section 7." >=20 > Just one question (which could affect validation): I assume (maybe I'm > wrong) that a certificate is bound to a Certified IPv6 address space, = in the > sense that the KeyPurposeId affects to ALL the addresses (or prefixes) = of > the certificate. Then, I don't understand how a given prefix can be at = the > same time 'router' or 'owner', or 'proxy router' or 'proxy host'. For = me, > all this functionalities should inherently incompatible for a given = prefix > (for example, a router maybe is authorized as a 'router' for a prefix, = but > should be authorized as 'owner' for just a single address of the = prefix > (don't think it is a good idea to allow to be 'owner' of the whole = prefix, > which in fact it is not). Also, either a node is 'router' for a = prefix, or > 'proxy router', but both do not make sense. The same for 'owner' and = 'proxy > owner/host' > If some combinations are possible, but others are not, it should also = be > specified, I think. It is true that some combinations do not work. You will need more than = one certificate in those cases. Roque. >=20 > Regards, > Alberto=20 >=20 >=20 > | =20 > | Roque. > | =20 > | =20 > | =20 > | =20 > | =20 > | > I think this would work (if so, it should be changed in > draft-csi-send-cert). > | > > | > > | > > | > What do you think? (both authors of draft-csi-send-cert, Sandra, = etc.). > | > > | > > | > > | > Regards, > | > > | > Alberto > | > > | > > | > > | > > | > >=20 >=20 --Apple-Mail-72--445740959 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQL5vTKNUCwWQOjacT KoWGmzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDUxMjAwMDAwMFoXDTExMDUxMjIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDlJvcXVlIEdh Z2xpYW5vMSEwHwYJKoZIhvcNAQkBFhJyb2dhZ2xpYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDGyowL31WLYDEbY59gvyg0OcBMh/AqsE5EpWzobCsYs1secYJvZlKm 5+2CjNWTQziHYo19cp7DG9XDLLGdLW7HC0VikR65cxIURXJoUKQO3QJYV99mrtnwCKf/FyzxeF11 pRILFbkgvpAZjCLig/RgNLt5cGGl8FGCe22sBWdBxU+sQiffsS774edvd3xFiRPaB/sOVPc4fbvw twOkEuas4IaH9Oivt1ZUvrFmBnS8mCYbk0OKjKjIEeS62TPsGCZv3f9Ffgm0Az4On6MiP1dARKp/ it5aow047hoFNXFCsWVLeEyDLk3avqS3/9fH//9NWvj0Mq/FhkaEw4Sv66TLAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAIxI8f9LAL0e mThKlUnwxlBH+q2htxBy9vBt24uGl8dunGyK4Aq7PAQiCF2XJfM2sWSRpdkIdbd9cD5upkcteP4s pL/T85qsfT1dLiQDTZ6/o19umk6DkqG0DpR+n+7jTUGdCzDhhzTZZblqY0afimcQ79uqZcF5ojDl N5Np93N3djqAmD37aKG1KE8xzBP0WiwxfVIGYua098YIsioWb0zvGmPd9JdMO55+jwkjFAOsT5kK ivXkjDnZJ1HM8GVQjGPnYBDEJBmC2B+kdbpi17cntYE/6V/SgrpB4t14YuswgMYRh1lGP7eKiiAj mwnaJL9aMMrqBwHLY/BLEA+3hRsxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYabMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDcwNzEz MjYxMFowIwYJKoZIhvcNAQkEMRYEFLSECxZDjNESlGvcMyr7OZzRuzt/MIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEC+b0yjVAsFkDo2nEyqFhpswggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYab MA0GCSqGSIb3DQEBAQUABIIBAGo0KecgsKkHly8DUs+tGa7F8TOWgltRtlL9Jh5u9WXM2rh55Tn3 Ub89ayip+FCmQo++wP40NsIb+5Jcf4V/Da/lgVBlmEPgm8f3Uu4KCKw2Nc+I8SrnxFnlM9xae8j1 w91dJj9Qvu5yZKlkwQKqreeavmFsXDvANwgEHp+fp0qDIWoi+GQ1JhWyUIzdlCobpWdLJst8HBkI 0SF//CQzwSk0516jq6Lx5yAw8II/miypxMG6jpn0Akwgm4DLXS9Cb9d9T0TL/W8qgQPcyjHcxl0Q pQLkY2dh+twvrecnRMCyTi9F6Nk6rYlJv2PTadmAsYbF3bWHu+Kkt2naS3oMpmEAAAAAAAA= --Apple-Mail-72--445740959-- From alberto@it.uc3m.es Wed Jul 7 09:28:14 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 594EA3A67B3; Wed, 7 Jul 2010 09:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuPIJvdkZ0Ma; Wed, 7 Jul 2010 09:28:13 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 7C1A73A679F; Wed, 7 Jul 2010 09:28:12 -0700 (PDT) X-uc3m-safe: yes Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 294086FC4D2; Wed, 7 Jul 2010 18:28:10 +0200 (CEST) From: =?ISO-8859-15?Q?Alberto_Garc=EDa?= To: "'Roque Gagliano'" References: <99775B3B-8619-4EDC-9F6F-23C231C44F18@cisco.com> <911338BA-7E6A-41CB-BB01-BFF7A819F050@cisco.com> Date: Wed, 7 Jul 2010 18:28:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acsd1/xnb/cMiJktQZa01B3qXSQOsQAGB08w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: <911338BA-7E6A-41CB-BB01-BFF7A819F050@cisco.com> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17492.000 X-Mailman-Approved-At: Wed, 07 Jul 2010 10:51:18 -0700 Cc: draft-ietf-csi-send-cert@tools.ietf.org, secdir@ietf.org, 'Sandra Murphy' , draft-ietf-csi-proxy-send.all@tools.ietf.org, iesg@ietf.org, csi-chairs@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 16:28:14 -0000 Hi Roque | -----Mensaje original----- | De: Roque Gagliano [mailto:rogaglia@cisco.com] | Enviado el: mi=E9rcoles, 07 de julio de 2010 15:26 | Para: Alberto Garc=EDa | CC: 'Sandra Murphy'; iesg@ietf.org; secdir@ietf.org; draft-ietf-csi-proxy- | send.all@tools.ietf.org; draft-ietf-csi-send-cert@tools.ietf.org; = csi- | chairs@tools.ietf.org | Asunto: Re: secdir review of draft-ietf-csi-proxy-send-04 | =20 | Hi Alberto, | =20 | Please see inline. | =20 | Roque. | =20 | On Jul 7, 2010, at 2:39 PM, Alberto Garc=EDa wrote: | =20 | > Hi Roque, | > Thanks for your fast answer. | > | > | -----Mensaje original----- | > | De: Roque Gagliano [mailto:rogaglia@cisco.com] | > | Enviado el: mi=E9rcoles, 07 de julio de 2010 11:12 | > | Para: Alberto Garc=EDa | > | CC: 'Sandra Murphy'; iesg@ietf.org; secdir@ietf.org; | > draft-ietf-csi-proxy- | > | send.all@tools.ietf.org; = draft-ietf-csi-send-cert@tools.ietf.org; csi- | > | chairs@tools.ietf.org | > | Asunto: Re: secdir review of draft-ietf-csi-proxy-send-04 | > | | > | Hi Alberto, | > | | > | > In draft-ietf-csi-send-cert-05, section 7 (it is the same text = as in | > cert-04) it | > | discusses the messages that are authorized by each KeyPurposeId | > | > | > | > - "router authorization value indicates that the | > | > certificate has been issued for allowing the router to advertise | > | > prefix(es)" | > | > | > | > | > | What about the following text? | > | | > | "router authorization value indicates that the | > | certificate has been issued for allowing the router to = generate RA | > messages for | > | the | > | prefix(es) that are mentioned in the X.509 extensions for IP | > addresses"" | > | > Yes, although I would also include Redirect messages, since the = 'router | > function' pack is RA+Redirect | > | =20 | ok. | =20 | > | | > | | > | > (I understand that implicitly states that it authorizes the generation | > of RA | > | messages. It is not crystal clear for me if it authorizes NA for routers, | > although if | > | I had to take this text literally, I would suppose routers would need an | > 'owner' | > | authorization if this PKI model substitutes RFC3971 CGA authorization, | > | considering that the prefix for NA would be narrowed in general = to one | > address, | > | while the RA authorization is prefix-wide) | > | > | > | > - "proxy authorization value indicates that the | > | > certificate has been issued for allowing the proxy to = perform | > | > proxying of neighbor discovery messages for the prefix(es) = that are | > | > | > | > mentioned using the X.509 extensions for IP addresses" | > | > | > | > (I understand it now implicitly states it authorizes for ANY neighbor | > discovery | > | message. By the way, this is the assumption underlying in = general | > draft-ietf-csi- | > | proxy-send-04: in the application scenarios, some require RA proxying, | > which is | > | assumed to be performed by means of the proxy cert) | > | > | > | > | > | What about the following text? | > | | > | - "proxy authorization value indicates that the | > | certificate has been issued for allowing the proxy to perform | > | proxying of RA messages for the prefix(es) that are | > | mentioned in the X.509 extensions for IP addresses" | > | > Yes, also including Redirect. | =20 | ok. | =20 | > | > | | > | | > | > - "owner authorization [...]For an | > | > address in such certificate the host can assign the = address, send/ | > | > receive traffic from this address, and can respond to NSes about | > that | > | > address" | > | > | > | > (this is the clearest of all statements - although I think = issuing | > secured NS and | > | RS should also be considered) | > | > | > | What about the following text? | > | | > | - "owner authorization [...]For an | > | address in such certificate the host can assign the address, send/ | > | receive traffic from this address, and can respond to ND = messages | > about that | > | address" | > | > Ummm. I think this is more than 'respond', since it also authorizes = the node | > to sign RS and NS. I would detail the messages that are covered by = this | > authorization: NS, NA, RS. | > What do you think? | > | > - "owner authorization [...]For an | > | address in such certificate the host can assign the address, send/ | > | receive traffic from this address, and can send NS, NA and RS messages | > about that address" | =20 | =20 | ok, but lets keep the respond in the sentence: | - "owner authorization [...]For an address in such certificate the = host can assign | the address, send/receive traffic from this address, and can send or respond NS, | NA and RS messages about that address" I wonder if the 'respond' close to the 'RS' may induce the reader to = think that the 'owner' could generate a RA, which in fact it can't. I would = take out the respond, but if you think it is clear enough...=20 | =20 | > | | > | > So, as defined now in draft-ietf-csi-proxy-send-04, proxy certificates | > provide | > | authorization for securing *any* ND message. Considering the application | > | scenarios, some require proxying RA (PMIPv6 and RFC4389), and = the MIPv6 | > | scenario just require NS/NA proxying. | > | > | > | > In summary so far, there is some specification of the authorization in | > draft-csi- | > | send-cert, which I think it would be nice that it could be = refined, and | > if so, my | > | opinion is that the refinement of which ND message is authorized = by each | > | KeyPurposeId should be in that document. | > | > | > | > However, continuing with this issue, I must say that the way = the 'proxy | > | authorization' is defined, and the relationship with the other cases, is | > not | > | satisfactory for me. | > | > | > | > I think the use of 'owner' should be restricted for hosts that really | > own the | > | address (therefore, a substitution of the CGA mechanism) - as opposed to | > proxies. | > | > | > | > For the 'proxy authorization', I think it could be refined = into | > something like | > | "proxy host" authorization, and "proxy router" authorization. | > | > | > | > 'Proxy host' would authorize for proxying NA, NS and RS, and "proxy | > router" | > | authorization would authorize RA and Redirect. This would = provide a finer | > grain | > | which I think would be desirable (for example, MIPv6 does not = need | > protecting | > | neither RA nor redirect). | > | > | > | > | > | | > | So, what you are proposing is to modify the name of the current = EKU to | > "proxy | > | router" and generate a new EKU named "proxy host"? | > | > Yes. | =20 | Ok. | =20 | > | > | | > | As a side note, I would like to proposse that you modify the = first | > paragraph of | > | Section 5.2.2 (Processing rules for receivers) by making a = reference to | > the draft- | > | csi-send-cert Section 9 as the certificate validation method. | > | > Sure. I can include it in 5.2.2, processing step #2, in which certificates | > are considered | > | > | | > | Additional, In the draft-csi-send-cert document, we could add = the | > following text | > | at the end of Section 9 (validation): | > | | > | "The host MUST verify that the required Key PurposedId(s) value = is | > present as | > | described in Section 7." | > | | > | In this sense we close the loop as: | > | - you validate the certificate using SIDR defined validation method. | > | - you then validate your particular KeyPurpisedId using the text in | > | Section 9. | > | > I agree that the validation section can be complemented a bit, for example, | > stating that at least one KeyPurposeId MUST be present. The part = 'the | > required' in the text you propose is not clear to me: required... = for what, | > in which sense? | > | =20 | I was referring to verify that the KeyPurposeId matches the = application. What | about replacing "required" by "correspondent" | =20 | "The host MUST verify that the correspondent Key PurposedId(s) = value is | present as described in Section 7." ok | =20 | > | > Just one question (which could affect validation): I assume (maybe = I'm | > wrong) that a certificate is bound to a Certified IPv6 address = space, in the | > sense that the KeyPurposeId affects to ALL the addresses (or = prefixes) of | > the certificate. Then, I don't understand how a given prefix can be = at the | > same time 'router' or 'owner', or 'proxy router' or 'proxy host'. = For me, | > all this functionalities should inherently incompatible for a given prefix | > (for example, a router maybe is authorized as a 'router' for a = prefix, but | > should be authorized as 'owner' for just a single address of the = prefix | > (don't think it is a good idea to allow to be 'owner' of the whole prefix, | > which in fact it is not). Also, either a node is 'router' for a = prefix, or | > 'proxy router', but both do not make sense. The same for 'owner' = and 'proxy | > owner/host' | > If some combinations are possible, but others are not, it should = also be | > specified, I think. | =20 | It is true that some combinations do not work. You will need more = than one | certificate in those cases. In fact, I don't know if there is any combination that work (I think = there is no one). If there is no one, then only one KeyPurposeId MUST be = allowed per certificate (even if in the future there are cases in which many authorization roles are possible, then many certificates should be = used).=20 Or, if you think that many KeyPurposeIds must be supported, it should be clearly stated which combinations are not allowed (I think all of the combinations of KeyPurposeId currently being defined). Or I am missing anything? Regards, Alberto | =20 | Roque. | =20 | > | > Regards, | > Alberto | > | > | > | | > | Roque. | > | | > | | > | | > | | > | | > | > I think this would work (if so, it should be changed in | > draft-csi-send-cert). | > | > | > | > | > | > | > | > What do you think? (both authors of draft-csi-send-cert, = Sandra, etc.). | > | > | > | > | > | > | > | > Regards, | > | > | > | > Alberto | > | > | > | > | > | > | > | > | > | > | > | > From turners@ieca.com Thu Jul 8 08:49:42 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F9BD3A6B12 for ; Thu, 8 Jul 2010 08:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hXyEqQw-U7I for ; Thu, 8 Jul 2010 08:49:41 -0700 (PDT) Received: from smtp111.biz.mail.sp1.yahoo.com (smtp111.biz.mail.sp1.yahoo.com [69.147.92.224]) by core3.amsl.com (Postfix) with SMTP id 8E3BE3A6B01 for ; Thu, 8 Jul 2010 08:49:41 -0700 (PDT) Received: (qmail 85133 invoked from network); 8 Jul 2010 15:49:43 -0000 Received: from thunderfish.local (turners@71.191.1.152 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 08 Jul 2010 08:49:43 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 3DyKfMQVM1kBjaVxpcIChX3Oq45ywRAwdqX9sb7Nzt6A.kp onE0XOfrEdIVzuFCFA3qxOPUSx2TA_1VsX1B9LWgdHL1Oop0Oysnd06G84Is 8vjP5lFzlWo8iTrBzhN_Pou26sa0G00_MpsHzYYYbhWPuIeIVve.qipwLAnf lEzbR6Kd3khyYJ128NE5kgxE5RQ5yI8nui.SzTxEJuoMVR4Y.QJ.Ni3WRrEd IsQvlbdAxFjfn3N6N3Q.XK8A.cj1isc2wG5RE2Ueo5fwpV7YHxUrbNL20F13 NjjaDV_WuR.5d282q54qTUB8hMJg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C35F396.80004@ieca.com> Date: Thu, 08 Jul 2010 11:49:42 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Reminder: Agendas Due 2010-07-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 15:49:42 -0000 Just a reminder that WG agendas are due next Wednesday. spt From tlyu@mit.edu Thu Jul 8 09:38:45 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC7F3A6AF3; Thu, 8 Jul 2010 09:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[AWL=-1.611, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DXlp4Iyufh3; Thu, 8 Jul 2010 09:38:44 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by core3.amsl.com (Postfix) with ESMTP id F39D33A6B05; Thu, 8 Jul 2010 09:38:43 -0700 (PDT) X-AuditID: 1209190d-b7c19ae0000009ea-83-4c35ff171c11 Received: from mailhub-auth-2.mit.edu (MAILHUB-AUTH-2.MIT.EDU [18.7.62.36]) by dmz-mailsec-scanner-2.mit.edu (Symantec Brightmail Gateway) with SMTP id D0.BF.02538.71FF53C4; Thu, 8 Jul 2010 12:38:47 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id o68Gck1n003709; Thu, 8 Jul 2010 12:38:47 -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.6/8.12.4) with ESMTP id o68Gchu8003950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Jul 2010 12:38:44 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id o68Gch2U022780; Thu, 8 Jul 2010 12:38:43 -0400 (EDT) To: secdir@ietf.org, iesg@ietf.org, draft-ietf-netmod-yang-usage.all@tools.ietf.org From: Tom Yu Date: Thu, 08 Jul 2010 12:38:43 -0400 Message-ID: Lines: 27 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: AAAAAA== Subject: [secdir] secdir review of draft-ietf-netmod-yang-usage-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 16:38:45 -0000 This document provides usage guidelines for the YANG data modeling language so that standards track YANG data models will be more readable and interoperable. The Security Considerations section of this document states that it does not introduce any new or increased risks to the management system. In fact, the document includes advice for consistently communicating those risks in the context of YANG modules. The Security Considerations section makes reference to a URL http://www.ops.ietf.org/yang-security-considerations.txt which had no content when I last visited it, so I was unable to review it. Section 3.4 lists the items whose security risks must be documented in a conforming specification. It omits the requirement, stated in Section 4.13, that potentially harmful operations must be mentioned in the Security Considerations section of the conforming specification. Section 3.4 should probably include the requirement from 4.13. Editorial: Is the use of "" in the example in Section 3.1 adequately protected from tools that might interpret that string as beginning a code component that is never completed? From secdir-bounces@mit.edu Thu Jul 8 05:40:39 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D32213A6AB0 for ; Thu, 8 Jul 2010 05:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.779 X-Spam-Level: X-Spam-Status: No, score=-4.779 tagged_above=-999 required=5 tests=[AWL=1.820, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlVGWtypi+oe for ; Thu, 8 Jul 2010 05:40:39 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id C6E6B3A6AAF for ; Thu, 8 Jul 2010 05:40:38 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o68CegLp004614 for ; Thu, 8 Jul 2010 08:40:42 -0400 Received: from mailhub-dmz-4.mit.edu (MAILHUB-DMZ-4.MIT.EDU [18.7.62.38]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o68Ceeob004611 for ; Thu, 8 Jul 2010 08:40:40 -0400 Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by mailhub-dmz-4.mit.edu (8.13.8/8.9.2) with ESMTP id o68CdodW030570 for ; Thu, 8 Jul 2010 08:40:40 -0400 X-AuditID: 1209190c-b7c34ae000000a06-8c-4c35c747374f Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by dmz-mailsec-scanner-1.mit.edu (Symantec Brightmail Gateway) with SMTP id B1.C1.02566.847C53C4; Thu, 8 Jul 2010 08:40:40 -0400 (EDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o68Cda6R003400; Thu, 8 Jul 2010 05:40:38 -0700 Received: from brm-exedge.brocade.com (brm-exedge.brocade.com [144.49.197.7]) by mx0b-000f0801.pphosted.com with ESMTP id pwbvy82ev-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 08 Jul 2010 05:40:38 -0700 Received: from brm-excashub-2.corp.brocade.com (172.16.72.231) by BRM-EXEDGE-1.corp.brocade.com (172.16.72.149) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 8 Jul 2010 06:39:58 -0600 Received: from brm-exch-3.corp.brocade.com ([169.254.2.126]) by brm-excashub-2.corp.brocade.com ([172.16.72.231]) with mapi; Thu, 8 Jul 2010 06:40:37 -0600 From: Jaehoon Jeong To: Russ Housley Date: Thu, 8 Jul 2010 06:40:33 -0600 Thread-Topic: DISCUSS: draft-ietf-6man-dns-options-bis Thread-Index: AcsW4VriwT/jItJqQzGQvY6Ny1E6HwHuJcZw Message-ID: <5A6980BCAE9E6D438D4D8A05540F6FB7012F81EFE2@BRM-EXCH-3.corp.brocade.com> References: <20100628164527.1FAF928C0E6@core3.amsl.com> In-Reply-To: <20100628164527.1FAF928C0E6@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-08_01:2010-02-06, 2010-07-08, 2010-07-08 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1007080042 X-Brightmail-Tracker: AAAAAA== X-MIME-Autoconverted: from base64 to 8bit by pch.mit.edu id o68Ceeob004611 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Thu, 08 Jul 2010 10:14:01 -0700 Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "ben@nostrum.com" , "secdir@mit.edu" , "iesg@ietf.org" , "draft-ietf-6man-dns-options-bis@tools.ietf.org" Subject: Re: [secdir] DISCUSS: draft-ietf-6man-dns-options-bis X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 12:40:39 -0000 Hi Russ, Could you lift your DISCUSS on this draft? As you know, our authors addressed the comments from Gen-ART and SecDir along with the warnings raised by IESG (in Section 5.3.2) through the new version: http://datatracker.ietf.org/doc/draft-ietf-6man-dns-options-bis/ Thanks. Best Regards, Paul -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Monday, June 28, 2010 11:45 AM To: iesg@ietf.org Cc: ben@nostrum.com; 6man-chairs@tools.ietf.org; draft-ietf-6man-dns-options-bis@tools.ietf.org Subject: DISCUSS: draft-ietf-6man-dns-options-bis Discuss: There has been discussion of the Gen-ART Review by Ben Campbell from 2010-06-21. There seems to be agreement on the way to resolve the concerns that were raised, but a revision has not been posted (yet). _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From andyb@iwl.com Thu Jul 8 10:12:08 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E11A3A6B13 for ; Thu, 8 Jul 2010 10:12:08 -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=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yly11+O6L553 for ; Thu, 8 Jul 2010 10:12:06 -0700 (PDT) Received: from smtp152.iad.emailsrvr.com (smtp152.iad.emailsrvr.com [207.97.245.152]) by core3.amsl.com (Postfix) with ESMTP id D0E623A679F for ; Thu, 8 Jul 2010 10:12:06 -0700 (PDT) Received: from relay15.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay15.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id E8BA71B40D6; Thu, 8 Jul 2010 13:12:10 -0400 (EDT) Received: by relay15.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 765CB1B40F8; Thu, 8 Jul 2010 13:12:10 -0400 (EDT) Message-ID: <4C3606C9.3000500@iwl.com> Date: Thu, 08 Jul 2010 10:11:37 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100528 Thunderbird/3.0.5 MIME-Version: 1.0 To: Tom Yu References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 08 Jul 2010 10:14:02 -0700 Cc: draft-ietf-netmod-yang-usage.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-netmod-yang-usage-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 17:12:08 -0000 On 07/08/2010 09:38 AM, Tom Yu wrote: > This document provides usage guidelines for the YANG data modeling > language so that standards track YANG data models will be more > readable and interoperable. > > The Security Considerations section of this document states that it > does not introduce any new or increased risks to the management > system. In fact, the document includes advice for consistently > communicating those risks in the context of YANG modules. > > The Security Considerations section makes reference to a URL > > http://www.ops.ietf.org/yang-security-considerations.txt > > oops; not sure why the URL in the draft is wrong. Here is the correct URL: http://www.ops.ietf.org/netconf/yang-security-considerations.txt > which had no content when I last visited it, so I was unable to review > it. > > Section 3.4 lists the items whose security risks must be documented in > a conforming specification. It omits the requirement, stated in Section > 4.13, that potentially harmful operations must be mentioned in the > Security Considerations section of the conforming specification. > Section 3.4 should probably include the requirement from 4.13. > > OK -- good catch > Editorial: > > Is the use of "" in the example in Section 3.1 adequately > protected from tools that might interpret that string as beginning a > code component that is never completed? > good point -- I will add a so a tool will not get fooled. The usage within single quotes should be OK. Andy From julienl@qualcomm.com Fri Jul 9 10:24:43 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFEC83A6AA3; Fri, 9 Jul 2010 10:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQyL+zsYudu5; Fri, 9 Jul 2010 10:24:40 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 0AD963A65A6; Fri, 9 Jul 2010 10:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1278696283; x=1310232283; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20marcelo=20bagnulo=20braun=20 |CC:=20"secdir@ietf.org"=20,=20"iesg@iet f.org"=20,=0D=0A=09"draft-ietf-behave-v6v4 -xlate-stateful@tools.ietf.org"=0D=0A=09,=0D=0A=09"behave-ch airs@tools.ietf.org"=20 |Date:=20Fri,=209=20Jul=202010=2010:24:14=20-0700 |Subject:=20RE:=20secdir=20review=20of=20draft-ietf-behav e-v6v4-xlate-stateful-11|Thread-Topic:=20secdir=20review =20of=20draft-ietf-behave-v6v4-xlate-stateful-11 |Thread-Index:=20AcsfRcdm6p0M3B7jSGKnFLJPdC1nLwARaEkA |Message-ID:=20|References:=20=0D=0A=20<4C36E625.4060008@it.uc3m.es>|In-Reply-To:=20 <4C36E625.4060008@it.uc3m.es>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=PGtNSxkPFEOcLc5uZDhAuZGLglrlP9Th0XI5KyfLd50=; b=TzW6YIadno79yQ3JODtAMiON5HBa/19Q1x3nT1jTEZ7MORtfGBBOrjWF Tz5llDgbD8I9xKlDeqHSA3VhuoYdAjDVPfURqGt9/UkrmmfKKPeX4terq TVoqW160V//0HAwN12YPpnje4rE7ycpSyAZMCjj2MhPru5A62dcXRgLHb U=; X-IronPort-AV: E=McAfee;i="5400,1158,6038"; a="46847065" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 09 Jul 2010 10:24:40 -0700 X-IronPort-AV: E=Sophos;i="4.53,563,1272870000"; d="scan'208";a="81935745" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 09 Jul 2010 10:24:39 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 9 Jul 2010 10:24:16 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Fri, 9 Jul 2010 10:24:16 -0700 From: "Laganier, Julien" To: marcelo bagnulo braun Date: Fri, 9 Jul 2010 10:24:14 -0700 Thread-Topic: secdir review of draft-ietf-behave-v6v4-xlate-stateful-11 Thread-Index: AcsfRcdm6p0M3B7jSGKnFLJPdC1nLwARaEkA Message-ID: References: <4C36E625.4060008@it.uc3m.es> In-Reply-To: <4C36E625.4060008@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave-chairs@tools.ietf.org" , "draft-ietf-behave-v6v4-xlate-stateful@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-behave-v6v4-xlate-stateful-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 17:24:43 -0000 Hi Marcelo, Thank you for clarifying. I do not have further questions/comments. --julien marcelo bagnulo braun wrote: >=20 > Hi Julien, >=20 > Thanks for the review >=20 > Replies below. >=20 >=20 > El 28/06/10 23:09, Laganier, Julien escribi=F3: > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > > > Document abstract: > > > > This document describes stateful NAT64 translation, which allows > > IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, > or > > ICMP. The public IPv4 address can be shared among several IPv6- > only > > clients. When the stateful NAT64 is used in conjunction with > DNS64 > > no changes are usually required in the IPv6 client or the IPv4 > > server. > > > > Comments: > > > > The document is a nice read and in a good shape. I have a few > comments below: > > > > Section 1.2. "Overview": Repeated use of the term "transport address" > but it is only defined later in the Terminology section 2. > mmm, a definition for transport address is provided in the overview > section before the term is used. In particular, section 1,2 reads: >=20 > In order to be able to > perform IPv6-IPv4 translation, NAT64 requires state, binding an > IPv6 > address and TCP/UDP port (hereafter called an IPv6 transport > address) > to an IPv4 address and TCP/UDP port (hereafter called an IPv4 > transport address). >=20 >=20 > wouldn't that suffice? >=20 > > Suggest moving "1.2 Overview" in its own standalone section numbered > 3, just after terminology. > > >=20 >=20 > > Section 2 describes Hairpinning and Section 3.8 specifies NAT64 > support for Hairpinning. The document states that "Hairpinning support > is important for peer-to-peer applications, as there are cases when two > different hosts on the same side of a NAT can only communicate using > sessions that hairpin through the NAT." I understand that it is > important for NAT44 because only RFC1918 ambiguous address space is > available for hosts behind NAT44 which can make it impossible for host > to communicate. I however do not understand why it is needed with NAT64 > where non-ambiguous IPv6 address space is available to hosts behind the > NAT64. Why would the host be able to communicate only through a NAT64? > It seems that putting an IPv6 router next to the NAT64 would avoid the > need for hairpinning NAT64. Maybe I am missing something... If there's > a easy explanation, suggest extending the terminology with it. > > > mmm, probably some people that are more knowledgeable than me in the > type of apps that make use of hairpinning could expand on this, but my > understanding is that the problem is not related with the addresses > being non unique, but wiht which address the host is able to discover. > I mean, suppose you have two IPv6 hosts sitting behind a NAT64. > Suppose that the rendez vous server (or whatever you call it) is in V4 > land. > Then The rendez vous server will inform the V6 host about the v4 > address > of the other v6 host. So in this case, the v6 hosts will have to use > the > v4 address of the other host to initiate a communication. That is what > hairpinning is needed for. > Does this makes sense? >=20 > This described in great detail in > http://tools.ietf.org/html/rfc4787#page-16 which is refered in the > nat64 > draft. >=20 >=20 > > Section 5.2.: "To avoid this type of abuse, a NAT64 MAY keep track of > the sequence number of TCP packets in order to verify that proper > sequencing of exchanged segments, in particular, the SYNs and the > FINs." =3D> I think you mean "in particular, those of the SYNs and the > FINs." > right, fixed >=20 > > Also, it seems to me that you want to keep track of is the whole > TCP state rather than the only the sequence numbers, i.e., whether the > connection is opened, half-closed, by watching at SYNs, RSTs and FINs. > > >=20 > right, but we already do that, we keep track of the SYNs, the FINs and > the RSTs. The only thing we do not mandate to keep track of is the seq > number. >=20 > Regards, marcelo > > --julien > > > > > > > > > > From catherine.meadows@nrl.navy.mil Fri Jul 9 18:23:37 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17C243A6946; Fri, 9 Jul 2010 18:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyGPNuo9Tmiw; Fri, 9 Jul 2010 18:23:35 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id 929553A66B4; Fri, 9 Jul 2010 18:23:34 -0700 (PDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id o6A1NXkD004333; Fri, 9 Jul 2010 21:23:33 -0400 (EDT) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id o6A1NQiU001670; Fri, 9 Jul 2010 21:23:30 -0400 (EDT) Received: (from [IPv6:::1] [10.0.0.13]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2010070921232529951 ; Fri, 09 Jul 2010 21:23:26 -0400 From: Catherine Meadows Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Jul 2010 21:21:17 -0400 Message-Id: <51173F8E-94BF-4347-B7A8-909BA5433443@nrl.navy.mil> To: iesg@ietf.org, secdir@ietf.org, sarvi@cisco.com, dburnett@voxeo.com, oran@cisco.com, eburger@standardstrack.com Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [secdir] secdir review of draft-ietf-speechsc-mrcpv2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jul 2010 01:23: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. = =20 These comments were written primarily for the benefit of the security = area directors. =20 Document editors and WG chairs should treat these comments just like any = other last call comments. This draft describes the Media Resource Control Protocol Version 2 = (MRCPv2) which allows client hosts to control media service resources residing in = servers on a network. MRCPv2 makes use of the Session Initiation Protocol (SIP) to initiate = and manage sessions and the Session Description Protocol (SDP) to manage and exchange = capabilities. Both clients and servers rely on TLS for security. Most of the security requirements for this protocol are similar to = requirements for any protocol that manages control data, some of which must be sensitive. These are = outlined in the Security Considerations section. MRCPv2 also supports the use of voice = identification to support a limited form of limitation: the identification of which member of a group a = principal belongs to after the fact that the principal belongs to the group has been ascertained by other means. = This is known as Speaker Verification and Identification. I found the initial discussion of Speaker Verification and = Identification in Section 11 a little confusing, and there is one sentence in particular that could be made more clear: The fourth paragraph in that section begins: Speaker identification is the process of associating an unknown speaker with a member in a population. It does not employ a claim of identity. But the paragraph immediately before that starts In speaker verification, a recorded utterance is compared to a previously stored voiceprint which is in turn associated with a claimed identity for that user.=20 That sounds like it *does* employ a claim of identity. The fourth paragraph goes on to say that speaker ID should be used when you already have verified that the speaker is a member of a group (e.g. by cryptographic means), and you want to verify which member of the group s/he is. This suggests that It does not employ a claim of identity. really means that=20 It does not provide a proof of identity by itself. If that is the case, it should say that. I also note that the speaker verification is restricted to identifying = the identity of someone who is already verified to be a member of a group. This = suggests that attempting to use it without this prior verification is unsafe. A quick scan through RFC = 4313 didn't turn up any references to this issue. If it is unsafe, then the ID should say so, and if there is a = related requirement in RFC 4313 that should be referenced. Also, I would recommend saying that speaker verification = MUST NOT be implemented without prior verification as a member of a group. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil From weiler@watson.org Sat Jul 10 17:49:25 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 312163A68DC for ; Sat, 10 Jul 2010 17:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRpHtvpK2AKW for ; Sat, 10 Jul 2010 17:49:24 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 345733A67F0 for ; Sat, 10 Jul 2010 17:49:23 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o6B0nTlu097090 for ; Sat, 10 Jul 2010 20:49:29 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o6B0nSAc097086 for ; Sat, 10 Jul 2010 20:49:29 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 10 Jul 2010 20:49:28 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Sat, 10 Jul 2010 20:49:29 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 00:49:25 -0000 Scott Kelly is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2010-07-15 Reviewer Deadline Draft Pat Cain T 2010-07-13 draft-ietf-pkix-certimage-08 Dave Cridland T 2010-07-13 draft-ietf-v6ops-v6inixp-08 Love Hornquist-Astrand T 2010-07-13 draft-ietf-eai-mailinglist-07 Sam Weiler T 2010-07-13 draft-ietf-v6ops-rogue-ra-01 Nico Williams TR2010-07-13 draft-ietf-v6ops-ra-guard-06 Larry Zhu T 2010-07-13 draft-ietf-opsawg-mpls-tp-oam-def-06 Last calls and special requests: Reviewer Deadline Draft Derek Atkins 2010-07-09 draft-ietf-avt-forward-shifted-red-05 Rob Austein 2010-07-12 draft-ietf-forces-applicability-09 Richard Barnes 2010-07-12 draft-ietf-ipsecme-roadmap-07 Alan DeKok 2010-07-12 draft-ietf-forces-implementation-report-02 Donald Eastlake 2010-07-12 draft-ietf-isis-ipv6-te-07 Shawn Emery 2010-07-14 draft-ietf-ippm-twamp-reflect-octets-07 Stephen Farrell 2010-07-25 draft-baker-v6ops-greynet-04 Tobias Gondrom 2010-08-04 draft-davis-u-langtag-ext-03 Phillip Hallam-Baker 2010-07-23 draft-ietf-geopriv-arch-02 Steve Hanna 2010-07-20 draft-ietf-ippm-spatial-composition-15 Dan Harkins 2010-07-23 draft-ietf-kitten-gssapi-naming-exts-08 Sam Hartman 2010-07-23 draft-ietf-msec-ipsec-group-counter-modes-05 Paul Hoffman 2010-07-23 draft-ietf-pkix-asn1-translation-02 Love Hornquist-Astrand 2010-07-23 draft-ietf-pkix-ocspagility-08 Jeffrey Hutzelman 2010-07-23 draft-ietf-pkix-ta-mgmt-reqs-05 Charlie Kaufman 2010-08-04 draft-presuhn-rfc2482-historic-02 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Brian Weis 2010-07-16 draft-daboo-srv-caldav-05 Nico Williams 2010-07-16 draft-turner-suiteb-cmc-03 Kurt Zeilenga 2010-07-23 draft-hammer-hostmeta-13 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-07 Glen Zorn 2010-07-26 draft-cakulev-mikey-ibake-01 From d3e3e3@gmail.com Sun Jul 11 20:57:00 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A74C28C111; Sun, 11 Jul 2010 20:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4d0WUGgNlAl; Sun, 11 Jul 2010 20:56:59 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 541FA3A68E6; Sun, 11 Jul 2010 20:56:58 -0700 (PDT) Received: by wyb40 with SMTP id 40so3240796wyb.31 for ; Sun, 11 Jul 2010 20:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=JWZo+dxNLkrPi8/FP0I5ZOOt2bTaCXG54iP08LIy6KI=; b=VhJr2SMAlosCUUKR0smZqfa62E10/C1EHUO0ikl6td9DvxEtQsLMKH+izhV6KZRfz6 iCiQN/h6zgdjbcbDfMWxjBW1UC2KCVwH/dH8V7BRIPTXVDU9jk5bJyH1VS2e4vbzkX+Q N83aQsJ5h8cvdnEyimSO4VuqlEj7M0gvOar5c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=hnvr/rNhNXtUVtacnAWgwH/qW/CHf9wvO1LvN9GU2RaaQ+nDgnQibQnEqA3yoYfAbx bpDflHxDHrDnrF+LS2W7xhXP52yxwUFdTYO0mAmD5eekd2psuvopHuU2S2plWDARNt8j THjWkGylAhuL7+N/gkUzK8fXJD6C7Iv141l3Y= MIME-Version: 1.0 Received: by 10.216.187.21 with SMTP id x21mr7500035wem.51.1278907022542; Sun, 11 Jul 2010 20:57:02 -0700 (PDT) Received: by 10.216.88.70 with HTTP; Sun, 11 Jul 2010 20:57:02 -0700 (PDT) Date: Sun, 11 Jul 2010 23:57:02 -0400 Message-ID: From: Donald Eastlake To: secdir@ietf.org, iesg@ietf.org, jon.harrison@dataconnection.com, jon.berger@dataconnection.com, mike.bartlett@dataconnection.com, Christian Hopps , David Ward Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [secdir] draft-ietf-isis-ipv6-te-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 03:57:00 -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. Document editors and WG chairs should treat these comments just like any other last call comments. This document primarily specifies the IS-IS code points and TLV/sub-TLV data structures for IS-IS support of traffic engineering and generalized multi-protocol label switching. The Security Considerations section is probably correct when it says that it raises no new security considerations. However, I would like to see a Reference to RFC 5304 added as pertaining to general IS-IS Security Considerations. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From stbryant@cisco.com Mon Jul 12 07:39:36 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EB183A67DB; Mon, 12 Jul 2010 07:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.502 X-Spam-Level: X-Spam-Status: No, score=-10.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4LVbCQFBHnj; Mon, 12 Jul 2010 07:39:34 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 548643A6971; Mon, 12 Jul 2010 07:39:09 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGXGOkxAZnwN/2dsb2JhbACgPnGkYYF+CwGYP4J6gi0EiEw X-IronPort-AV: E=Sophos;i="4.55,188,1278288000"; d="scan'208,217";a="131379619" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 Jul 2010 14:33:34 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6CEXX9R012909; Mon, 12 Jul 2010 14:33:33 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o6CEXU601231; Mon, 12 Jul 2010 15:33:30 +0100 (BST) Message-ID: <4C3B27BA.7050200@cisco.com> Date: Mon, 12 Jul 2010 15:33:30 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: Donald Eastlake References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050305060307020304070605" Cc: David Ward , jon.berger@dataconnection.com, Christian Hopps , secdir@ietf.org, mike.bartlett@dataconnection.com, jon.harrison@dataconnection.com, iesg@ietf.org Subject: Re: [secdir] draft-ietf-isis-ipv6-te-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 14:39:36 -0000 This is a multi-part message in MIME format. --------------050305060307020304070605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/07/2010 04:57, Donald Eastlake 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. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document primarily specifies the IS-IS code points and > TLV/sub-TLV data structures for IS-IS support of traffic engineering > and generalized multi-protocol label switching. The Security > Considerations section is probably correct when it says that it raises > no new security considerations. However, I would like to see a > Reference to RFC 5304 added as pertaining to general IS-IS Security > Considerations. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3@gmail.com If we replace the security text with: This document raises no new security issues for IS-IS; for general security considerations for IS-IS see [RFC5304 ]. Will that address this concern? (i.e. make it the same as RFC 5305 ) - Stewart --------------050305060307020304070605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 12/07/2010 04:57, Donald Eastlake 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.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document primarily specifies the IS-IS code points and
TLV/sub-TLV data structures for IS-IS support of traffic engineering
and generalized multi-protocol label switching. The Security
Considerations section is probably correct when it says that it raises
no new security considerations. However, I would like to see a
Reference to RFC 5304 added as pertaining to general IS-IS Security
Considerations.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3@gmail.com
If we replace the security text with:
   This document raises no new security issues for IS-IS; for general
   security considerations for IS-IS see [RFC5304].
Will that  address this concern?

(i.e. make it the same as RFC 5305)

- Stewart


--------------050305060307020304070605-- From d3e3e3@gmail.com Mon Jul 12 08:09:25 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 695373A6957; Mon, 12 Jul 2010 08:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQ1NRPBYPQtz; Mon, 12 Jul 2010 08:09:24 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 35A6F3A6927; Mon, 12 Jul 2010 08:09:24 -0700 (PDT) Received: by wwi17 with SMTP id 17so93247wwi.13 for ; Mon, 12 Jul 2010 08:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JTZhuPuJQh8AbINcLUV/1iZG8cXKRxMhdd3b5Z42rmM=; b=V+bhMZ6ulHqokuMJJaVns2w++74boyiRkCgJ8ftcDWgBzZmK+8P7GPt3rXqYunBt6n RQOwKEq/bWHHFP7Ca6naBojNtNiKn0rxUEO2kDK+33TfTVmpGCPZLME/FLpw3Vf31IZS daDa4e4wAsGP2yPgNGgIBYhIJtaponEUrqlvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WvU4f91DXMePxBPxLtJylshk43wYjI4jTUOZHKtKjN1GnRYqwTi/nFwAFR7+YuIlaX 7pCKncwqXVSGkHDgIcmdsZuwoBVv+jIYG+Z1dKfmhdRfsSLMgCyoHzohlSrTwMU7f/KF t6t/vynPpCpcF3onhl29SIu7G2PvxI3nxvwrI= MIME-Version: 1.0 Received: by 10.227.156.11 with SMTP id u11mr9006652wbw.146.1278947368643; Mon, 12 Jul 2010 08:09:28 -0700 (PDT) Received: by 10.216.88.70 with HTTP; Mon, 12 Jul 2010 08:09:28 -0700 (PDT) In-Reply-To: <4C3B27BA.7050200@cisco.com> References: <4C3B27BA.7050200@cisco.com> Date: Mon, 12 Jul 2010 11:09:28 -0400 Message-ID: From: Donald Eastlake To: stbryant@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: David Ward , jon.berger@dataconnection.com, Christian Hopps , secdir@ietf.org, mike.bartlett@dataconnection.com, jon.harrison@dataconnection.com, iesg@ietf.org Subject: Re: [secdir] draft-ietf-isis-ipv6-te-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 15:09:25 -0000 Indeed, that would be fine for me.. Thanks, Donald On Mon, Jul 12, 2010 at 10:33 AM, Stewart Bryant wrote= : > On 12/07/2010 04:57, Donald Eastlake 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. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document primarily specifies the IS-IS code points and > TLV/sub-TLV data structures for IS-IS support of traffic engineering > and generalized multi-protocol label switching. The Security > Considerations section is probably correct when it says that it raises > no new security considerations. However, I would like to see a > Reference to RFC 5304 added as pertaining to general IS-IS Security > Considerations. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) > =A0155 Beaver Street > =A0Milford, MA 01757 USA > =A0d3e3e3@gmail.com > > If we replace the security text with: > > This document raises no new security issues for IS-IS; for general > security considerations for IS-IS see [RFC5304]. > > Will that=A0 address this concern? > > (i.e. make it the same as RFC 5305) > > - Stewart > > > From new-work-bounces@ietf.org Thu Jul 8 14:00:03 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79783A696F; Thu, 8 Jul 2010 14:00:03 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6AF3C3A68FD; Thu, 8 Jul 2010 14:00:01 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100708210001.6AF3C3A68FD@core3.amsl.com> Date: Thu, 8 Jul 2010 14:00:01 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 12 Jul 2010 09:21:32 -0700 Subject: [secdir] [New-work] WG Review: Recharter of Common Authentication Technology Next Generation (kitten) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 21:00:04 -0000 A modified charter has been submitted for the Common Authentication Technology Next Generation (kitten) working group in the Security Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Thursday, July 15, 2010. Common Authentication Technology Next Generation (kitten) -------------------- Current Status: Active Working Group Last modified: 2010-07-08 Personnel: Chair(s): Tom Yu Shawn Emery Security Area Director(s): Tim Polk Sean Turner Security Area Advisor: Tim Polk Mailing Lists: General Discussion: kitten@ietf.org To Suscribe: https://www.ietf.org/mailman/listinfo/kitten Archive: http://www.ietf.org/mail-archive/web/kitten/current/maillist.html Description of Working Group: The Generic Security Services (GSS) API and Simple Authentication and Security Layer (SASL) provide various applications with a security framework for secure network communication. The purpose of the Common Authentication Technology Next Generation (Kitten) working group (WG) is to develop extensions/improvements to the GSS-API, shepherd specific GSS-API security mechanisms, and provide guidance for any new SASL- related submissions. This working is chartered to specify the following extensions and improvements (draft-yu-kitten-api-wishlist-00) to the GSS-API: * Provide new interfaces for credential management, which include the following: initializing credentials iterating credentials exporting/importing credentials * Specify interface for asynchronous calls. * Define interfaces for better error message reporting. * Provide a more programmer friendly GSS-API for application developers. This could include reducing the number of interface parameters, for example, by eliminating parameters which are commonly used with the default values. This WG is also chartered to transition proposed SASL mechanisms as GSS-API mechanisms: * A SASL Mechanism for OpenID draft-lear-ietf-sasl-openid-00 * A SASL Mechanism for SAML draft-wierenga-ietf-sasl-saml-00 The transition from SASL to GSS-API mechanisms will allow a greater set of applications to utilize said mechanisms with SASL implementations that support the use of GSS-API mechanisms in SASL (draft-ietf-sasl- gs2). * Shepherd draft-ietf-sasl-digest-to-historic to publication. This WG should review proposals for new SASL and GSS-API mechanisms, but may take on work on such mechanisms only through a revision of this charter. The WG should also review non-mechanism proposals related to SASL and the GSS-API. However, work that adds SASL or GSS-API support in application protocols should be handled by the application's WG. Deliverables: * GSS-API: initializing credentials [editor: TBD] * GSS-API: iterating credentials [editor: TBD] * GSS-API: exporting/importing credentials [editor: TBD] * GSS-API: specification for asynchronous calls [editor: TBD] * GSS-API: interfaces/improvements for better error message reporting [editor: TBD] * GSS-API: programmer friendly interfaces [editor: TBD] * GSS-API: transition SASL mechanism for OpenID [editor: TBD] * GSS-API: transition SASL mechanism for SAML [editor: TBD] * GSS-API: publish draft-ietf-kitten-gssapi-extensions-iana [editor: Nicolas Williams] * GSS-API: publish draft-ietf-kitten-gssapi-naming-exts [editor: Leif Johansson] * SASL: publish draft-melnikov-digest-to-historic [editor: Alexey Melnikov] Goals and Milestones: June 2010 Submit naming-exts to the IESG as Proposed Standard June 2010 WGLC on gssapi-extensions-iana July 2010 Submit gssapi-extensions-iana to the IESG as Proposed Standard TBD Other Listed Work Items _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From marcelo@it.uc3m.es Fri Jul 9 02:05:16 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5FD3A6BC9; Fri, 9 Jul 2010 02:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.229 X-Spam-Level: X-Spam-Status: No, score=-106.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJukjWwNqPbv; Fri, 9 Jul 2010 02:05:02 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id A42123A6BCC; Fri, 9 Jul 2010 02:04:38 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (53.30.18.95.dynamic.jazztel.es [95.18.30.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id AE69DBDFA16; Fri, 9 Jul 2010 11:04:37 +0200 (CEST) Message-ID: <4C36E625.4060008@it.uc3m.es> Date: Fri, 09 Jul 2010 11:04:37 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Laganier, Julien" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17494.006 X-Mailman-Approved-At: Mon, 12 Jul 2010 09:21:32 -0700 Cc: "behave-chairs@tools.ietf.org" , "draft-ietf-behave-v6v4-xlate-stateful@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-behave-v6v4-xlate-stateful-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 09:05:16 -0000 Hi Julien, Thanks for the review Replies below. El 28/06/10 23:09, Laganier, Julien escribió: > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. > > Document abstract: > > This document describes stateful NAT64 translation, which allows > IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or > ICMP. The public IPv4 address can be shared among several IPv6-only > clients. When the stateful NAT64 is used in conjunction with DNS64 > no changes are usually required in the IPv6 client or the IPv4 > server. > > Comments: > > The document is a nice read and in a good shape. I have a few comments below: > > Section 1.2. "Overview": Repeated use of the term "transport address" but it is only defined later in the Terminology section 2. mmm, a definition for transport address is provided in the overview section before the term is used. In particular, section 1,2 reads: In order to be able to perform IPv6-IPv4 translation, NAT64 requires state, binding an IPv6 address and TCP/UDP port (hereafter called an IPv6 transport address) to an IPv4 address and TCP/UDP port (hereafter called an IPv4 transport address). wouldn't that suffice? > Suggest moving "1.2 Overview" in its own standalone section numbered 3, just after terminology. > > Section 2 describes Hairpinning and Section 3.8 specifies NAT64 support for Hairpinning. The document states that "Hairpinning support is important for peer-to-peer applications, as there are cases when two different hosts on the same side of a NAT can only communicate using sessions that hairpin through the NAT." I understand that it is important for NAT44 because only RFC1918 ambiguous address space is available for hosts behind NAT44 which can make it impossible for host to communicate. I however do not understand why it is needed with NAT64 where non-ambiguous IPv6 address space is available to hosts behind the NAT64. Why would the host be able to communicate only through a NAT64? It seems that putting an IPv6 router next to the NAT64 would avoid the need for hairpinning NAT64. Maybe I am missing something... If there's a easy explanation, suggest extending the terminology with it. > mmm, probably some people that are more knowledgeable than me in the type of apps that make use of hairpinning could expand on this, but my understanding is that the problem is not related with the addresses being non unique, but wiht which address the host is able to discover. I mean, suppose you have two IPv6 hosts sitting behind a NAT64. Suppose that the rendez vous server (or whatever you call it) is in V4 land. Then The rendez vous server will inform the V6 host about the v4 address of the other v6 host. So in this case, the v6 hosts will have to use the v4 address of the other host to initiate a communication. That is what hairpinning is needed for. Does this makes sense? This described in great detail in http://tools.ietf.org/html/rfc4787#page-16 which is refered in the nat64 draft. > Section 5.2.: "To avoid this type of abuse, a NAT64 MAY keep track of the sequence number of TCP packets in order to verify that proper sequencing of exchanged segments, in particular, the SYNs and the FINs." => I think you mean "in particular, those of the SYNs and the FINs." right, fixed > Also, it seems to me that you want to keep track of is the whole TCP state rather than the only the sequence numbers, i.e., whether the connection is opened, half-closed, by watching at SYNs, RSTs and FINs. > right, but we already do that, we keep track of the SYNs, the FINs and the RSTs. The only thing we do not mandate to keep track of is the seq number. Regards, marcelo > --julien > > > > > From jan.melen@ericsson.com Fri Jul 9 03:00:16 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D363B3A6999; Fri, 9 Jul 2010 03:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.064 X-Spam-Level: X-Spam-Status: No, score=-5.064 tagged_above=-999 required=5 tests=[AWL=1.535, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEbi4DvwwZ+5; Fri, 9 Jul 2010 03:00:13 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 6B8263A68FC; Fri, 9 Jul 2010 03:00:12 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-22-4c36f328c748 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C3.49.10125.823F63C4; Fri, 9 Jul 2010 12:00:08 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jul 2010 12:00:07 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jul 2010 12:00:07 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 65F3C271F; Fri, 9 Jul 2010 13:00:07 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2E6964F8B1; Fri, 9 Jul 2010 13:00:07 +0300 (EEST) Received: from esealmw967.eemea.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BFCAD4F38B; Fri, 9 Jul 2010 13:00:06 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-36--285303694; protocol="application/pkcs7-signature"; micalg=sha1 From: Jan Melen In-Reply-To: Date: Fri, 9 Jul 2010 13:00:06 +0300 Message-Id: <66B7E019-3782-4780-8CB7-C77D61E19DBF@ericsson.com> References: To: David McGrew X-Mailer: Apple Mail (2.1081) X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 09 Jul 2010 10:00:07.0593 (UTC) FILETIME=[82B36990:01CB1F4D] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Mon, 12 Jul 2010 09:21:32 -0700 Cc: draft-ietf-hip-hiccups.all@tools.ietf.org, IESG , secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-hip-hiccups-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 10:00:16 -0000 --Apple-Mail-36--285303694 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Now -03 version is available and this should address all your previously = identified concerns: http://datatracker.ietf.org/doc/draft-ietf-hip-hiccups/ Regards, Jan On Jul 1, 2010, at 4:02 PM, Jan Melen wrote: >=20 > Thanks for review. I will submit a new version as soon as I have gone = through all the other review comments from other reviewers. >=20 > On Jun 15, 2010, at 12:38 AM, David McGrew wrote: >=20 >> I have reviewed this document as part of the security directorate's =20= >> ongoing effort to review all IETF documents being processed by the =20= >> IESG. These comments were written primarily for the benefit of the =20= >> security area directors. Document editors and WG chairs should treat = =20 >> these comments just like any other last call comments. >>=20 >> There are several points where the draft could be made more clear, =20= >> some of which might impact security. I've listed those below, =20 >> intermingled with some nits. >>=20 >> Abstract and Section 1. "secure" is used where "authenticated" would = =20 >> be better, since this protocol does not provide any confidentiality =20= >> services or encryption. >>=20 >=20 > Changed as proposed >=20 >=20 >> RFC 4949 lists "message integrity code (MIC)" as a deprecated term, =20= >> but this term is defined and used. In this case what is meant is =20 >> "collision-resistant hash"; that phrase should be used in Sections 2 =20= >> and 7. "Checksum" is an inappropriate term for a collision-resistant = =20 >> hash and it should be replaced in Section 4. For the security =20 >> considerations section: does the hash need strong collision-=20 >> resistance, or just second preimage resistance (also called weak =20 >> collision-resistance)? >=20 >=20 > Replaced with collision-resistance and added preimage requirements to = security considerations. >=20 >=20 >> Section 4 nits: "with help of MIC." -> "with the help of the MIC." >> "HIP DATA packet"-> "The HIP DATA packet" >> "Hash algorithm used to generate MIC is same " -> "The hash algorithm = =20 >> used to generate the MIC is the same " >=20 > Done >=20 >>=20 >> Section 4.1. I suggest emphasizing the requirement for the "Sequence = =20 >> Number" fields in distinct SEQ_DATA parameters to be distinct. >>=20 >=20 > Done >=20 >> Section 4.3. says "Payload Data 8 last bytes of the payload data over = =20 >> which the MIC is calculated. This field is used to uniquely bind =20 >> PAYLOAD_MIC parameter to next header, in case there are multiple =20 >> copies of same type." It seems to me that this uniqueness is not =20= >> guaranteed, but that if the last-8-bytes is not unique, the MIC =20 >> verification process would fail, but that there is no way that an =20 >> attacker could exploit this fact. I suggest noting this property in = =20 >> the security considerations. >>=20 >=20 > Added to Security considerations >=20 >> Section 4.3: The PAYLOAD_MIC parameter has a field called "Payload =20= >> MIC". It would be less confusing if the latter was called "MIC = Value" =20 >> or some other named that is distinct from the parameter name. >=20 > Done >=20 >> Section 4.3 nit: "Identifies the data that protected by this MIC." = add =20 >> "is". >=20 > Done. >=20 >> Section 5.1 nit: "A HIP DATA packet MUST contain SEQ_DATA or ACK_DATA = =20 >> parameter if both parameters are missing then packet MUST be dropped =20= >> as invalid." -> "A HIP DATA packet MUST contain either a SEQ_DATA or =20= >> ACK_DATA parameter; if both parameters are missing, then the packet =20= >> MUST be dropped as invalid." >=20 > Done. >=20 >> Section 5.2 says "The receiver MUST validate these MICs." It should =20= >> also describe how to validate them, and S 5.3 would be a more =20 >> appropriate place to detail that process. >=20 > That is already defined in 5.3.1 so I added reference to that. >=20 >=20 >> Section 5.2 says " ... no SEQ_DATA sequence number is reused before =20= >> the receiver has closed the processing window for the previous packet = =20 >> using the same SEQ_DATA sequence number." Important question: what =20= >> enables the receiver to tell the difference? I assume that there = are =20 >> some other fields (e.g. nonces) associated with the connection that =20= >> might serve this purpose; if that is right, I suggest documenting = that =20 >> fact. >=20 > It can be easily checked by comparing the MIC value and I added also a = statement on that to section 5.3.1. >=20 > Regards, > Jan >=20 >=20 --Apple-Mail-36--285303694 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEJzCCBCMw ggMLoAMCAQICEBcym0rvC4ysd7OuULv1nZMwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0wOTA4MTMwNzAx MjZaFw0xMjA4MTMwNzAxMjRaMGAxETAPBgNVBAoMCEVyaWNzc29uMRIwEAYDVQQDDAlKYW4gTWVs ZW4xEDAOBgNVBAUTB2xtZmptZ20xJTAjBgkqhkiG9w0BCQEWFmphbi5tZWxlbkBlcmljc3Nvbi5j b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJMm59CngqBfJmkbsn3BqfjoMPGBvrNecqG5 fwqLxxyxt4Gs9lNM4rt/bDx1mkXe/IvVdEwYa07vha4OMCKVEMS2n3M07vMvHODqEgKNBYYxXx1D VkdAxHFLoEHIjG8twhbQA80vO/A8spxbabBVDbV/SQbQCTGYB00pZ7QFe8qDAgMBAAGjggGCMIIB fjCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9Fcmlj c3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVzdC50ZWxpYS5jb20vY249 RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nzb24/Y2VydGlmaWNhdGVy ZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAhBgNVHREEGjAYgRZqYW4ubWVsZW5AZXJpY3Nzb24u Y29tMEYGA1UdIAQ/MD0wOwYGKoVwawEBMDEwLwYIKwYBBQUHAgEWI2h0dHA6Ly93d3cuZXJpY3Nz b24uY29tL2xlZ2FsLnNodG1sMB0GA1UdDgQWBBSyqywTA2aW8THpjWat4NxGgZDw7zAfBgNVHSME GDAWgBSWJ8O43qVfXUQ+OVLlRbF2X2MwmzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQAD ggEBAC1qz1fyRs2hKzFsvp8FZBxHbsBZn2mDlyt/hSWaZxNfuVoD5YfRkhep5FJrTksF0aM7kxN8 0NdqydRgtn0UWuwwfwguHqlv7gDnMlkVa2zy/6xyl8TahFskC8/3KHbeTBTvzvZ6FS6K1bHZqzWc d92JvBoq4aMloDnqjVoPbs3Cw5MMiLlQyBZVGe2qixv8pziwvyWnj1/UBgL9tBnqihMbJyDPA1Sq 2jC27m6uq3W1IVLmFGIO7DKD1vxVcwGZK9Zh73jkwBzV/B4KoyJOBYKaTUd1nqauRHR26kITQwK3 MBHKTuaEXPSwrmHs098GqPHj7SRPl2ZwIWB9LupJW8AxggISMIICDgIBATBNMDkxETAPBgNVBAoM CEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEBcym0rvC4ys d7OuULv1nZMwCQYFKw4DAhoFAKCCARswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTAwNzA5MTAwMDA3WjAjBgkqhkiG9w0BCQQxFgQUyndQCM9wt1MCan2j2HHqSaz5 4eMwXAYJKwYBBAGCNxAEMU8wTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQTAxAhAXMptK7wuMrHezrlC79Z2TMF4GCyqGSIb3DQEJEAILMU+g TTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QTAxAhAXMptK7wuMrHezrlC79Z2TMA0GCSqGSIb3DQEBAQUABIGAjR3J0VIp8dMMeBYegJIG69c7 yQy/qt/p8Q2XnQFe+nttNt6gYnv9qA+2y9S+3CW2pHsyqKGcOI5G9fSNoCUW1Mh60A1uKxupzhuV rnx5SAlcL3RiKm3La/2bkJ3R3R9pY9qY9CH8BEBM3dg/jBVtAHFnzlj0xVO8bwrI5LLLqOYAAAAA AAA= --Apple-Mail-36--285303694-- From new-work-bounces@ietf.org Fri Jul 9 09:31:45 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E9AB3A6AAD; Fri, 9 Jul 2010 09:31:44 -0700 (PDT) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A3C93A6A91 for ; Fri, 9 Jul 2010 09:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpExta6WTyMk for ; Fri, 9 Jul 2010 09:31:28 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id B0A283A687B for ; Fri, 9 Jul 2010 09:31:26 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OXGU7-0003WQ-CP; Fri, 09 Jul 2010 12:31:31 -0400 Message-Id: From: Ian Jacobs To: new-work@ietf.org Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Jul 2010 11:31:30 -0500 X-Mailer: Apple Mail (2.936) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 12 Jul 2010 09:21:32 -0700 Subject: [secdir] [New-work] Proposed W3C Charter: Web Performance Working Group (until 2010-08-06) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 16:31:45 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Rich Web Client Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Web Performance Working Group: http://www.w3.org/2010/06/webperf As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2010-08-06 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Philippe Le H=E9garet, Team Contact . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2006/rwc/Activity [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From secdir-bounces@mit.edu Sat Jul 10 19:31:43 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 818503A6926 for ; Sat, 10 Jul 2010 19:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.989 X-Spam-Level: X-Spam-Status: No, score=-4.989 tagged_above=-999 required=5 tests=[AWL=1.610, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScS7uRcX6SYX for ; Sat, 10 Jul 2010 19:31:42 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 87A273A6925 for ; Sat, 10 Jul 2010 19:31:41 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o6B2VlRf013571 for ; Sat, 10 Jul 2010 22:31:47 -0400 Received: from mailhub-dmz-4.mit.edu (MAILHUB-DMZ-4.MIT.EDU [18.7.62.38]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o6B2ViAC013563 for ; Sat, 10 Jul 2010 22:31:44 -0400 Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by mailhub-dmz-4.mit.edu (8.13.8/8.9.2) with ESMTP id o6B2Vi1V029524 for ; Sat, 10 Jul 2010 22:31:44 -0400 X-AuditID: 12074425-b7b12ae0000009fd-87-4c392d0faf0d Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by dmz-mailsec-scanner-8.mit.edu (Symantec Brightmail Gateway) with SMTP id 35.45.02557.F0D293C4; Sat, 10 Jul 2010 22:31:44 -0400 (EDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o6B2VZi2000910; Sat, 10 Jul 2010 19:31:35 -0700 Received: from brm-exedge.brocade.com (brm-exedge.brocade.com [144.49.197.7]) by mx0a-000f0801.pphosted.com with ESMTP id pxk7r08us-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 10 Jul 2010 19:31:34 -0700 Received: from brm-excashub-1.corp.brocade.com (172.16.72.131) by BRM-EXEDGE-1.corp.brocade.com (172.16.72.149) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 10 Jul 2010 20:31:32 -0600 Received: from brm-exch-3.corp.brocade.com ([169.254.2.126]) by brm-excashub-1.corp.brocade.com ([172.16.72.131]) with mapi; Sat, 10 Jul 2010 20:31:33 -0600 From: Jaehoon Jeong To: Tony Cheneau Date: Sat, 10 Jul 2010 20:31:29 -0600 Thread-Topic: Clarification question on draft-ietf-6man-dns-options-bis-06 Thread-Index: AcsgP/PhUzGllTOETiSz2GREGYKluAAYKjIQ Message-ID: <5A6980BCAE9E6D438D4D8A05540F6FB7012FFD262B@BRM-EXCH-3.corp.brocade.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-09_02:2010-02-06, 2010-07-09, 2010-07-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1007100142 X-Brightmail-Tracker: AAAAAA== X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id o6B2ViAC013563 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Mon, 12 Jul 2010 09:21:32 -0700 Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "ben@nostrum.com" , "secdir@mit.edu" , "iesg@ietf.org" , "draft-ietf-6man-dns-options-bis@tools.ietf.org" Subject: Re: [secdir] Clarification question on draft-ietf-6man-dns-options-bis-06 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 02:31:43 -0000 Hi Tony, Thanks for this update. If this draft can support the identification of DNS option source, I will refer to this draft in the next revision of our draft. Best Regards, Paul -----Original Message----- From: Tony Cheneau [mailto:tony.cheneau@it-sudparis.eu] Sent: Saturday, July 10, 2010 9:55 AM To: draft-ietf-6man-dns-options-bis@tools.ietf.org Subject: Clarification question on draft-ietf-6man-dns-options-bis-06 Hello, I read your document and I have the following comment on the Security Consideration section. (I know it may be a late comment due to the IESG processing...) The document states: If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as a security mechanism for ND, all the ND options including the RDNSS and DNSSL options are automatically included in the signatures, so the transport for the RA options is integrity-protected; that is, SEND can prevent the spoofing of these DNS options with signatures. Also, SEND enables an IPv6 host to verify that the sender of an RA is actually a router authorized to act as a router. However, since any valid SEND router can still insert RDNSS and DNSSL options, SEND cannot verify which one is or is not authorized to send the options. I agree that currently SEND does not provide any mechanism to indicate if a router can or cannot insert RDNSS and DNSSL options. However, I think the document draft-ietf-csi-send-cert-05 could help with that issue. The section 7 of the document describes Extended Key Usage for the certificate deployed in SEND. While it currently defines roles for Routers, Routers acting as Proxy and Address Owner, I think it could be extended to a new usage that indicates that the Router was indeed authorized to insert RDNSS and DNSSL options. Hope it helps. Best regards, Tony Cheneau _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From pcain@coopercain.com Mon Jul 12 12:10:20 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE3293A69BE; Mon, 12 Jul 2010 12:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9ZcezMV6mN1; Mon, 12 Jul 2010 12:10:19 -0700 (PDT) Received: from server1.acmehacking.com (server1.acmehacking.com [72.51.39.79]) by core3.amsl.com (Postfix) with ESMTP id A16943A6BAE; Mon, 12 Jul 2010 12:10:19 -0700 (PDT) Received: from familyroom (familyroom8.bc.edu [136.167.27.76]) (authenticated bits=0) by server1.acmehacking.com (8.14.3/8.13.8) with ESMTP id o6CJAMEK011035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Jul 2010 14:10:26 -0500 Received: from familyroom by familyroom (PGP Universal service); Mon, 12 Jul 2010 15:10:31 -0500 X-PGP-Universal: processed; by familyroom on Mon, 12 Jul 2010 15:10:31 -0500 From: "Patrick Cain" To: , Date: Mon, 12 Jul 2010 15:10:25 -0400 Message-ID: <047701cb21f5$e53a79f0$afaf6dd0$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acsh9dGIkA3ZlWNlS8urA8UssNq/Ng== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us Cc: secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-pkix-certimage-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 19:10:20 -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. This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a [RFC5280] public key certificate by defining a new otherLogos image type according to [RFC3709]. ----- >From a security perspective the document looks okay to me. I did see one 'TBD' OID reference that I hope the authors haven't forgotten about. Pat Cain From stefan@aaa-sec.com Mon Jul 12 13:42:58 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4EB3A69F7 for ; Mon, 12 Jul 2010 13:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.134 X-Spam-Level: X-Spam-Status: No, score=-1.134 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzFwZ4rXpKgZ for ; Mon, 12 Jul 2010 13:42:57 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.112]) by core3.amsl.com (Postfix) with ESMTP id 29F203A6B65 for ; Mon, 12 Jul 2010 13:42:56 -0700 (PDT) Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 3226A38892A for ; Mon, 12 Jul 2010 22:43:10 +0200 (CEST) Received: (qmail 32977 invoked from network); 12 Jul 2010 20:43:06 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.9]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 12 Jul 2010 20:43:06 -0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Mon, 12 Jul 2010 22:43:03 +0200 From: Stefan Santesson To: Patrick Cain , Message-ID: Thread-Topic: [secdir] secdir review of draft-ietf-pkix-certimage-08 Thread-Index: Acsh9dGIkA3ZlWNlS8urA8UssNq/NgADQEkm In-Reply-To: <047701cb21f5$e53a79f0$afaf6dd0$@com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-pkix-certimage-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 20:42:58 -0000 Pat, Thanks for the review. On 10-07-12 9:10 PM, "Patrick Cain" wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document specifies a method to bind a visual representation of a > certificate in the form of a certificate image to a [RFC5280] public > key certificate by defining a new otherLogos image type according to > [RFC3709]. > > ----- > > From a security perspective the document looks okay to me. > I did see one 'TBD' OID reference that I hope the authors haven't forgotten > about. > Thanks, it will be fixed in the next version. /Stefan From derek@ihtfp.com Mon Jul 12 19:17:03 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DF963A6452; Mon, 12 Jul 2010 19:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.129 X-Spam-Level: X-Spam-Status: No, score=-0.129 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O61e7Ajmc4ma; Mon, 12 Jul 2010 19:17:02 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by core3.amsl.com (Postfix) with ESMTP id 2D8623A6844; Mon, 12 Jul 2010 19:17:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 6A7202602AC; Mon, 12 Jul 2010 22:17:06 -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 13415-09; Mon, 12 Jul 2010 22:17:03 -0400 (EDT) Received: from pgpdev.ihtfp.org (unknown [192.168.248.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 055B42602AB; Mon, 12 Jul 2010 22:17:02 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.4/8.14.3/Submit) id o6D2Gwhq028719; Mon, 12 Jul 2010 22:16:58 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Mon, 12 Jul 2010 22:16:58 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: tom111.taylor@bell.net, Qiaobing.Xie@gmail.com, avt-chairs@tools.ietf.org Subject: [secdir] sec-dir review of draft-ietf-avt-forward-shifted-red-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 02:17:03 -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. This document defines a simple enhancement to RFC 2198 to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media). The security considerations section is not written in gramatically correct English. While this reader was able to decipher the meaning, I hope that someone with more editorial capabilities can massage the text into actual correct English sentences. Beyond the editorial issues, the document does address the single issue I see, which is the potential denial of service attack where the sender sends bogus forward-shifted data, potentially claiming large buffers in the receiver. Once the security considerations section is cleaned up it will more clearly state that "outrageous values" should be ignored. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From turners@ieca.com Tue Jul 13 06:33:16 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A503A6958 for ; Tue, 13 Jul 2010 06:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhuI6oohG4Wd for ; Tue, 13 Jul 2010 06:33:15 -0700 (PDT) Received: from smtp111.biz.mail.sp1.yahoo.com (smtp111.biz.mail.sp1.yahoo.com [69.147.92.224]) by core3.amsl.com (Postfix) with SMTP id 7E3C23A67A7 for ; Tue, 13 Jul 2010 06:33:15 -0700 (PDT) Received: (qmail 61325 invoked from network); 13 Jul 2010 13:33:24 -0000 Received: from thunderfish.local (turners@96.241.2.232 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 13 Jul 2010 06:33:24 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: HdD.sLMVM1l4ATCcShGMfGgbRYCDb_tlJhJvPUJzB81ygTu SAD5.S.n7xaKoZ.YlsE9ngzVgA0K1z6KWvpeu.odenOxr12CuSMqTIQlZFF8 pK.8P1pYG8xn2G5PPcH8ouVE0KhDKrvRDYpKwwvRwHVO1cXCjIJG.mkTVex4 rij9rAaH6GJ0QdG81ddOgK9QmUn_CMlFOofWPOTEpH9eAgqKFpU9B_.5QKH7 1DFjxdf57gnDPPXpiVOQ8b19Joc0mK1GAyI7m8uu9k2CtconmeOmXQTrW8eD 8FTMn.FWrzqiSWApM1Np8l0ygyx62za0ixzEPuJr9n3jyc_2LpwCEdw0mJes Ut4Pf1rLhUSv8 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C3C6B23.20003@ieca.com> Date: Tue, 13 Jul 2010 09:33:23 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: secdir@ietf.org References: <4C35F396.80004@ieca.com> In-Reply-To: <4C35F396.80004@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [secdir] Reminder: Agendas Due 2010-07-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 13:33:16 -0000 Preliminary agendas are due tomorrow. spt Sean Turner wrote: > Just a reminder that WG agendas are due next Wednesday. > > spt > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From dave.cridland@isode.com Tue Jul 13 07:43:00 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEBF03A6899; Tue, 13 Jul 2010 07:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQK2MX4qa97i; Tue, 13 Jul 2010 07:43:00 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 7C4603A6803; Tue, 13 Jul 2010 07:42:59 -0700 (PDT) Received: from puncture ((unknown) [217.155.137.60]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 13 Jul 2010 15:42:51 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: <2255.1279032169.744311@puncture> Date: Tue, 13 Jul 2010 15:42:49 +0100 From: Dave Cridland To: , Security Area Directorate , The IESG MIME-Version: 1.0 Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: [secdir] secdir review of draft-ietf-v6ops-v6inixp-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 14:43:00 -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. This document describes operational considerations for the adoption of IPv6 in peering points. The document includes very little on security, suggesting that it may be useful not to annouce routes for the IXP itself, and reminding the reader than shenanigans on the LAN itself will cause problems. I think this is as much as can be said by the document, and my only concern is that it's not clear to me if any of the many references might prove particularly important WRT security - that said, my feeling is that this document is adequately addressing security. Dave. From hartmans@mit.edu Wed Jul 14 04:55:30 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6649F3A696E; Wed, 14 Jul 2010 04:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-QxLx58kDCD; Wed, 14 Jul 2010 04:55:29 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id C00D03A6903; Wed, 14 Jul 2010 04:55:28 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4D4C9203C7; Wed, 14 Jul 2010 07:55:36 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7FA5E40D4; Wed, 14 Jul 2010 07:55:26 -0400 (EDT) From: Sam Hartman To: ietf@ietf.org, draft-ietf-msec-ipsec-group-counter-modes@tools.ietf.org, secdir@ietf.org Date: Wed, 14 Jul 2010 07:55:26 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [secdir] secdir review of draft-ietf-msec-ipsec-group-counter-modes X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 11:55:30 -0000 This is a secdir review of the above draft. The text looks fine. However, I'm concerned that this specification does not provide sufficient detail for interoperable implementation. It makes it clear that a GKMS needs to allocate SIDs but does not cite any mechanism for a GKMS to do so. I think you need to either add a normative reference to a hopefully already existing description of how to distribute this parameter, or recast this document as an informational document describing a general method but not implementing a protocol. From weiler+secdir@watson.org Thu Jul 15 06:13:23 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEB73A68D6 for ; Thu, 15 Jul 2010 06:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Lv7kMJ846pd for ; Thu, 15 Jul 2010 06:13:21 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 8F66F3A6887 for ; Thu, 15 Jul 2010 06:13:21 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o6FDDVAW029553 for ; Thu, 15 Jul 2010 09:13:31 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o6FDDVSo029549 for ; Thu, 15 Jul 2010 09:13:31 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 15 Jul 2010 09:13:31 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 15 Jul 2010 09:13:31 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 13:13:23 -0000 The next IESG telechat is after the Maastricht meeting. Barry Leiba is next in our rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2010-08-12 Reviewer Deadline Draft Rob Austein T 2010-08-10 draft-ietf-forces-applicability-09 Richard Barnes T 2010-08-10 draft-ietf-ipsecme-roadmap-08 Alan DeKok T 2010-08-10 draft-ietf-forces-implementation-report-02 Shawn Emery T 2010-08-10 draft-ietf-ippm-twamp-reflect-octets-07 Tobias Gondrom T 2010-08-10 draft-davis-u-langtag-ext-03 Charlie Kaufman T 2010-08-10 draft-presuhn-rfc2482-historic-02 Last calls and special requests: Reviewer Deadline Draft Stephen Farrell 2010-07-25 draft-baker-v6ops-greynet-04 Phillip Hallam-Baker 2010-07-23 draft-ietf-geopriv-arch-02 Steve Hanna 2010-07-20 draft-ietf-ippm-spatial-composition-15 Dan Harkins 2010-07-23 draft-ietf-kitten-gssapi-naming-exts-08 Paul Hoffman 2010-07-23 draft-ietf-pkix-asn1-translation-02 Love Hornquist-Astrand 2010-07-23 draft-ietf-pkix-ocspagility-08 Jeffrey Hutzelman 2010-07-23 draft-ietf-pkix-ta-mgmt-reqs-05 Scott Kelly 2010-07-26 draft-ietf-v6ops-ipv6-cpe-router-06 Stephen Kent 2010-07-26 draft-ietf-isis-bfd-tlv-02 Tero Kivinen 2010-08-10 draft-livingood-woundy-congestion-mgmt-05 Julien Laganier 2010-07-29 draft-ietf-nsis-nslp-auth-03 David McGrew 2010-03-10 draft-ietf-ecrit-framework-11 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Brian Weis 2010-07-16 draft-daboo-srv-caldav-05 Nico Williams 2010-07-16 draft-turner-suiteb-cmc-03 Kurt Zeilenga 2010-07-23 draft-hammer-hostmeta-13 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-07 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-07 Glen Zorn 2010-07-26 draft-cakulev-mikey-ibake-01 From bew@cisco.com Thu Jul 15 10:33:43 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F9103A6B41; Thu, 15 Jul 2010 10:33:41 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78H1ntpsm5QC; Thu, 15 Jul 2010 10:33:36 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B3FC43A6AD0; Thu, 15 Jul 2010 10:33:34 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO/iPkyrRN+K/2dsb2JhbACfZHGkQJsJgneCLQSDfoRSiT0 X-IronPort-AV: E=Sophos;i="4.55,209,1278288000"; d="scan'208";a="267717618" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2010 17:33:45 +0000 Received: from dhcp-128-107-163-140.cisco.com (dhcp-128-107-163-140.cisco.com [128.107.163.140]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6FHXjbA018046; Thu, 15 Jul 2010 17:33:45 GMT Message-Id: <0BD40125-37F4-42E7-84BE-F16E3241FD6D@cisco.com> From: Brian Weis To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Jul 2010 10:33:44 -0700 References: X-Mailer: Apple Mail (2.936) Cc: draft-ietf-msec-ipsec-group-counter-modes@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-msec-ipsec-group-counter-modes X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 17:33:44 -0000 Hi Sam, Thanks for your review. On Jul 14, 2010, at 4:55 AM, Sam Hartman wrote: > > > This is a secdir review of the above draft. > > The text looks fine. However, I'm concerned that this specification > does > not provide sufficient detail for interoperable implementation. It > makes it clear that a GKMS needs to allocate SIDs but does not cite > any > mechanism for a GKMS to do so. > > I think you need to either add a normative reference to a hopefully > already existing description of how to distribute this parameter, or > recast this document as an informational document describing a general > method but not implementing a protocol. There is an I-D for one GKMS (draft-ietf-msec-gdoi-update-06) that includes support for SIDs which could be referenced. It is expected to head to WGLC soon. Would citing that document address your concern? Thanks, Brian > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir -- Brian Weis Security Standards and Technology, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From hartmans@mit.edu Thu Jul 15 12:01:42 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33D183A6B38; Thu, 15 Jul 2010 12:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d20YHtgIbqAp; Thu, 15 Jul 2010 12:01:41 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 4E9E33A6B6E; Thu, 15 Jul 2010 12:01:39 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3DDBE203C7; Thu, 15 Jul 2010 15:01:45 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3F13C40D4; Thu, 15 Jul 2010 15:01:32 -0400 (EDT) From: Sam Hartman To: Brian Weis References: <0BD40125-37F4-42E7-84BE-F16E3241FD6D@cisco.com> Date: Thu, 15 Jul 2010 15:01:32 -0400 In-Reply-To: <0BD40125-37F4-42E7-84BE-F16E3241FD6D@cisco.com> (Brian Weis's message of "Thu, 15 Jul 2010 10:33:44 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-msec-ipsec-group-counter-modes@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-msec-ipsec-group-counter-modes X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 19:01:42 -0000 >>>>> "Brian" == Brian Weis writes: Brian> There is an I-D for one GKMS (draft-ietf-msec-gdoi-update-06) Brian> that includes support for SIDs which could be referenced. It Brian> is expected to head to WGLC soon. Would citing that document Brian> address your concern? A normative reference to that would definitely address my concern. An informative reference would not. From charliek@microsoft.com Thu Jul 15 12:40:02 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD6A3A6A4F; Thu, 15 Jul 2010 12:40:02 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1YJ5SMXktsG; Thu, 15 Jul 2010 12:40:01 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 102D13A6972; Thu, 15 Jul 2010 12:40:00 -0700 (PDT) Received: from TK5EX14CASC130.redmond.corp.microsoft.com (157.54.52.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 15 Jul 2010 12:40:11 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.169]) by TK5EX14CASC130.redmond.corp.microsoft.com ([157.54.52.9]) with mapi id 14.01.0180.004; Thu, 15 Jul 2010 12:40:11 -0700 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-presuhn-rfc2482-historic.all@tools.ietf.org" Thread-Topic: secdir review of draft-presuhn-rfc2482-historic-02.txt Thread-Index: AcskUh71Zu+DwcPZQKygSwOh6fkWqQ== Date: Thu, 15 Jul 2010 19:40:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] secdir review of draft-presuhn-rfc2482-historic-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 19:40: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 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 is an easy one. It proposes reclassifying an Informational RFC to Hist= oric. There are no non-trivial security considerations. RFC2482 is an informational RFC describing an escape sequence in UTF* chara= cter encodings to embed language tags. While the history of the feature is = not clearly stated in the document, it appears that this was an up-and-comi= ng feature in the ISO10646 / UNICODE world at the time RFC2482 was submitte= d, but that it since has fallen on hard times and is now The UNICODE Consor= tium strongly recommends against its use. The original proposal had no secu= rity considerations, and this document notes correctly that not using the f= eature can only improve security. The authors of the new document include t= he authors of the old, so this is unlikely to be some sort of turf war. Other notes: RFC2482 said: This document has been accepted by ISO/IEC JTC1/SC2/WG2 in meeting #34 to be submitted as a recommendation from WG2 for inclusion in Plane 14 in part 2 of ISO/IEC 10646. It would be good to note whether WG2 ever accepted the proposal and whether= either ISO/IEC JTC1/SC2/WG2 or WG2 have officially deprecated it to reassu= re the reader that there is no controversy over its status in those communi= ties. From gonzalo.camarillo@ericsson.com Fri Jul 16 03:18:10 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5920A3A6850; Fri, 16 Jul 2010 03:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.863 X-Spam-Level: X-Spam-Status: No, score=-103.863 tagged_above=-999 required=5 tests=[AWL=-1.264, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RahoZU755joZ; Fri, 16 Jul 2010 03:18:06 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id BE1623A69A9; Fri, 16 Jul 2010 03:17:53 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-2c-4c4031dcd2f6 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1E.16.06895.CD1304C4; Fri, 16 Jul 2010 12:18:04 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jul 2010 12:18:04 +0200 Received: from [131.160.126.225] ([131.160.126.225]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jul 2010 12:18:03 +0200 Message-ID: <4C4031DA.60908@ericsson.com> Date: Fri, 16 Jul 2010 13:18:02 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Carl Wallace References: <76AC5FEF83F1E64491446437EA81A61F7CF4A7B323@srvxchg> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Jul 2010 10:18:03.0198 (UTC) FILETIME=[2CB3F5E0:01CB24D0] X-Brightmail-Tracker: AAAAAA== Cc: Sumanth Channabasappa , "secdir@ietf.org" , Sandeep Sharma , "Flemming Andreasen \(fandreas\)" , "iesg@ietf.org" , "rkumar@cisco.com" , "joestone@cisco.com" Subject: Re: [secdir] secdir review of draft-stone-mgcp-vbd-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 10:18:10 -0000 Hi Carl, thanks for your review. The authors will submit a revised I-D addressing your comments as soon as they are back from vacation. Thanks, Gonzalo On 28/06/2010 3:34 PM, Carl Wallace wrote: > Informational track is fine, I was just asking why it was chosen. > > > > If you and the ADs are satisfied that the presentation of things like > the table in 3.1 is sufficiently descriptive that’s fine with me (though > I’d prefer at least an explicit reference for some of the shorthand). > > > > I have no other items to add to security considerations, your proposed > changes sound good. > > > > *From:* Sandeep Sharma [mailto:S.Sharma@CableLabs.com] > *Sent:* Sunday, June 27, 2010 5:17 PM > *To:* Carl Wallace; secdir@ietf.org > *Cc:* iesg@ietf.org; rkumar@cisco.com; joestone@cisco.com; 'Flemming > Andreasen (fandreas)'; Sumanth Channabasappa > *Subject:* RE: secdir review of draft-stone-mgcp-vbd-07 > > > > Carl, > > > > Thanks for the review comments. I consulted with the co-authors and > Flemming and our responses are indicated below. > > > > -----Original Message----- > From: Carl Wallace [mailto:CWallace@cygnacom.com] > Sent: Wednesday, June 23, 2010 9:03 AM > To: secdir@ietf.org > Cc: iesg@ietf.org; rkumar@cisco.com; joestone@cisco.com; Sandeep Sharma > Subject: secdir review of draft-stone-mgcp-vbd-07 > > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the IESG. > > These comments were written primarily for the benefit of the security > > area directors. Document editors and WG chairs should treat these > > comments just like any other last call comments. > > > > This document defines new MGCP packages. This document is pretty far > > outside my sandbox, but I did have a couple of questions and comments. > > > > - Why is this an Informational document instead of Standards track? It > > seems to be defining new packages that are not already defined > > elsewhere. > > > > SJS> MGCP (RFC 3435) and other MGCP packages are Informational RFCs, so > it seems consistent to have this one being informational as well. > > > > - I struggled with the presentation a bit and found myself reading > > references to understand some of the shorthand in this document. For > > example, in section 3.1 the column headers are not described in this > > draft. > > > > SJS> This is a standard MGCP package format as defined in RFC 3435 > (Section 6, and in this case Section 6.6 in particular) > > > > - The security considerations section is brief and primarily references > > RFC 3435, which essentially has two security considerations: use IPSec > > and use SDP encryption keys. The latter is not recommended in the > > current SDP draft. This section should directly state the security > > considerations it wants to assert. > > > > SJS> We agree with your comments about SDP encryption keys (RFC 3435 > Section 5.1). We will call out IPsec specifically and then add a few > paragraphs about ways to more adequately protect RTP media streams these > days (SRTP which should probably have at least a "SHOULD" recommendation > here) as well as some of the specific issues that may arise if an > attacker is able to modify/inject VBD data in the RTP media stream. We > would also greatly appreciate if you can provide additional > guidance/considerations (if any) that you believe should be addressed. > From hartmans@painless-security.com Fri Jul 16 05:35:43 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D05AC3A657C for ; Fri, 16 Jul 2010 05:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FX0eMS0+DrhK for ; Fri, 16 Jul 2010 05:35:41 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id A771C3A688C for ; Fri, 16 Jul 2010 05:35:30 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 02A5F203CB; Fri, 16 Jul 2010 08:35:38 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5AEC740D4; Fri, 16 Jul 2010 08:35:23 -0400 (EDT) From: Sam Hartman To: secdir@ietf.org Date: Fri, 16 Jul 2010 08:35:23 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Margaret Wasserman , PaddyNallur , Dong Zhang Subject: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 12:35:43 -0000 Hi. I've been working with the authors of draft-dong-savi-cga-header-03. The basic idea is that you can use cryptographically-generated IPv6 addresses for a reasonably secure form of IP-based access control. The main advantage of this is administrative simplicity. I've asked Nico Williams and Jeff Hutzelman to take a look and have had a discussion with both of them about the proposal. Julieng Loganier has also done previous work in this space. The authors have also been talking to the internet ADs and int-area chairs about the work. Comments so far definitely suggest that this is something worth discussing. So, we'd like to briefly introduce the proposal and solicit comments and see if we can get a group of people interested in working on this sort of thing together. I realize the SAAG agenda is reasonably full, but would it be possible to get five minutes and say three slides to briefly introduce the proposal? Also, I'd like to encourage people on this list to read and comment on the proposal. At this point, the basic idea is more important than the specific mechanism described in the draft. As I mentioned, the authors are working with the int-area to introduce the proposal there; we believe input is required from both areas. Thanks for your consideration and comments, --Sam From Kurt.Zeilenga@Isode.com Fri Jul 16 07:17:38 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC683A6A1C; Fri, 16 Jul 2010 07:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIjs881w4FK1; Fri, 16 Jul 2010 07:17:38 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D77853A696E; Fri, 16 Jul 2010 07:17:36 -0700 (PDT) Received: from [192.168.1.101] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 16 Jul 2010 15:17:47 +0100 X-SMTP-Protocol-Errors: NORDNS From: Kurt Zeilenga Date: Fri, 16 Jul 2010 07:17:44 -0700 Message-Id: <19622F34-F03E-4DE6-AB8F-711B99CCAECE@Isode.com> To: IETF X-Mailer: Apple Mail (2.1081) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: draft-hammer-hostmeta@tools.ietf.org, IESG IESG , Security Area Directorate Subject: [secdir] SECDIR review: draft-hammer-hostmeta X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 14:17:38 -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 should treat these comments just like = any other last call comments. I have a number of security-related concerns with this specification. First, I'm concerned by assumptions in the document that each of: http://example.com http://example.com:8080 https://example.com https://example.com:8443 identify resources under the control of same entity. It is fairly = common to there to be multiple http/https services running on a single = host, each service possibly operated by different entities as delegated = by the "host" administrator. I think it would be better (from a = security perspective) to have "service"-level metadata, not "host" level = meta data. That is, make no assumption that the above URIs are under = control of the same entity, or even if so, that it desirable to a single = policy/metadata covering multiple services. And I think it very important to always fetch the meta data from the = service one is accessing. The document calls for client to fetch = https://example.com/.well-known/host-meta even when = https://example.com:8443 is URI wants policy for. =20 Even worse, the document calls for the client to, if the above fetch = does not produce a "valid" hostmeta document, for the client to fetch = http://example.com/.well-known/host-meta. An attacker could easily = cause https://example.com/.well-known/host-meta to fail to produce a = "valid" hostmeta document, and serve its own hostmeta document in = response to the client's http://example.com/.well-known/host-meta, = without supplanting the https://example.com:8443 service. The document fails to discuss such attacks. I recommend reworking this document to provide service-level, not = host-level, metadata. In particular, the metadata document should = always be retrieved through the service the client is interested in = using, such as by fetching "/.well-known/metadata". If the authors rather continue pursuing a "host-based" solution, the = security considerations should include a discussion of the above issues. Regards, Kurt= From rbarnes@bbn.com Fri Jul 16 10:56:53 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 233163A6AA7; Fri, 16 Jul 2010 10:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQzSHhsJ+VhT; Fri, 16 Jul 2010 10:56:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 4E4BD3A680D; Fri, 16 Jul 2010 10:56:52 -0700 (PDT) Received: from [192.1.255.159] (port=63538 helo=col-dhcp-192-1-255-159.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OZp9j-000OXu-Or; Fri, 16 Jul 2010 13:57:03 -0400 Message-Id: <7485D041-D760-407C-97B5-6DEA2B91065C@bbn.com> From: "Richard L. Barnes" To: secdir@ietf.org, iesg@ietf.org, IETF IETF , draft-ietf-ipsecme-roadmap@tools.ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Jul 2010 13:57:02 -0400 X-Mailer: Apple Mail (2.936) Subject: [secdir] secdir review of draft-ietf-ipsecme-roadmap X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 17:56:53 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document reviews the landscape of existing IPsec-related documents, providing a list of documents (by topic) and brief descriptions. The document's claim that there are no security considerations with this document seems accurate to me. From new-work-bounces@ietf.org Mon Jul 12 14:33:43 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA3133A6CB2; Mon, 12 Jul 2010 14:33:33 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 52C103A68A9; Mon, 12 Jul 2010 14:30:22 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100712213022.52C103A68A9@core3.amsl.com> Date: Mon, 12 Jul 2010 14:30:22 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 18 Jul 2010 12:34:40 -0700 Subject: [secdir] [New-work] WG Review: Recharter of Host Identity Protocol (hip) 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: Mon, 12 Jul 2010 21:33:44 -0000 A modified charter has been submitted for the Host Identity Protocol (hip) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Monday, July 19, 2010. Host Identity Protocol (hip) -------------------- Current Status: Active Working Group Last Modified: 2010-07-12 Personnel Chairs: David Ward Gonzalo Camarillo Area Director: Ralph Droms Mailing List Address: hipsec@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/hipsec Archive: http://www.ietf.org/mail-archive/web/hipsec/ Jabber Chat Room Address: xmpp:hip@jabber.ietf.org Logs: http://jabber.ietf.org/logs/hip/ Description of Working Group The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys, from which end-point identifiers are taken. The public keys are typically, but not necessarily, self generated. HIP uses existing IP addressing and forwarding for locators and packet delivery. The architecture and protocol details for these mechanisms are currently specified in the following Experimental RFCs: o HIP Architecture (RFC 4423) o Host Identity Protocol (RFC 5201) There are several publicly known interoperating implementations, some of which are open source. The HIP WG was chartered to publish protocol specifications in documents whose quality and security properties would meet the requirements for publication as standards track documents. These specifications have been published as Experimental RFCs, because the effects of the protocol on applications and on the Internet as a whole were unknown. The Experimental RFCs produced by the HIP WG allowed the community to experiment with HIP technologies and learn from these experiments. The IRTF HIP RG will publish a document with results from the HIP experiment. The results to be published will justify publication of the HIP protocols in standards track documents. This WG will produce standards track versions of the main HIP RFCs taking as a base the existing Experimental RFCs. The WG will also specify certificate handling in HIP in a standards track RFC. Additionally, the WG will finish the WG items it was working on before starting the standards track work. These WG items relate to how to build HIP-based overlays and will result in Experimental RFCs. In parallel with this working group, the IRTF HIP RG mentioned above has a broader scope that includes efforts both on developing the more forward looking aspects of the HIP architecture and on exploring the effects that HIP may have on the applications and the Internet. The following are charter items for the working group: o Revise RFCs 4423, 4843, 5201, 5202, 5203, 5204, 5205, 5206, and 5770 as standards track RFCs. o Specify in a standards track RFC how to carry certificates in the base exchange. This was removed from the base HIP spec so that the mechanism is specified in a stand-alone spec. o Specify in an Experimental RFC how to build a HIP-based overlay using RELOAD. o Specify in an Experimental RFC how to transport HIP messages over encrypted connections that were established using HIP. Goals and Milestones Done Submit Native API specification to the IESG Done Submit Framework for HIP overlays specification to the IESG Done Submit Multi-hop routing mechanism for HIP Done Submit Upper-layer data transport in HIP to the IESG Sep 2010 WGLC Certs in HIP base exchange specification Sep 2010 WGLC RFC4423bis Sep 2010 WGLC RFC4843bis Sep 2010 WGLC RFC5201bis Sep 2010 WGLC RFC5202bis Oct 2010 Submit Certs in HIP base exchange specification to the IESG Oct 2010 Submit RFC4423bis to the IESG Oct 2010 Submit RFC4843bis to the IESG Oct 2010 Submit RFC5201bis to the IESG Oct 2010 Submit RFC5202bis to the IESG Dec 2010 WGLC RFC5203bis Dec 2010 WGLC RFC5204bis Dec 2010 WGLC RFC5205bis Dec 2010 WGLC the mobility portion of RFC5206bis Jan 2011 Submit RFC5203bis to the IESG Jan 2011 Submit RFC5204bis to the IESG Jan 2011 Submit RFC5205bis to the IESG Jan 2011 Submit the mobility portion of RFC5206bis to the IESG Feb 2011 WGLC RFC5770bis Feb 2011 WGLC the multihoming portion of RFC5206bis Mar 2011 Submit RFC5770bis to the IESG Mar 2011 Submit the multihoming portion of RFC5206bis to the IESG Apr 2011 Recharter or close the WG _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From secdir-bounces@mit.edu Tue Jul 13 08:28:01 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 576A43A6846 for ; Tue, 13 Jul 2010 08:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.579 X-Spam-Level: **** X-Spam-Status: No, score=4.579 tagged_above=-999 required=5 tests=[BAYES_99=3.5, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+EmCBxnBfMt for ; Tue, 13 Jul 2010 08:28:00 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id EEF023A67E7 for ; Tue, 13 Jul 2010 08:27:59 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o6DFS85u009256 for ; Tue, 13 Jul 2010 11:28:08 -0400 Received: from CDQWTEOW ([200.38.69.4]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o6DFS5vr009242 for ; Tue, 13 Jul 2010 11:28:06 -0400 Message-ID: <000d01cb229f$f5a35e60$6400a8c0@ingramn> From: "Debra Pacheco" To: Date: Tue, 13 Jul 2010 10:27:52 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam: Not detected X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Sun, 18 Jul 2010 12:34:40 -0700 Subject: [secdir] Why go to Yale? Beat the system for a superior life. achilary aborning afterimages X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 15:28:01 -0000 Hi!! Do you want a good future, grow in money earning power, and pat on the back :)? Special offer: We can assist with Diplomas from prestigious universities based on your present knowledge and work experience. Get a Degree in 5 weeks with our program! ~Our program will let EVERYONE with professional experience get a 100% verified Degree: ~Doctorate ~Bachelors ~Masters - Just think about it... - Just follow YOUR Dreams! - Live a wonderful life by earning or upgrading your degree. This is a exellent way to make a right move and receive your due benefits... if you are qualified but are lacking that piece of paper. Get one from us in a short time. Contact Today to start improving your life! ~CONTACT US FOR A FREE CONSULTATION~ 1-301-396-3506 Please leave us a message with your phone number with country code if outside USA and name and we will call you as soon as possible. It's your chance... Make the right move. Best regards. Do Not Reply to this Email. We do not reply to text inquiries, and our server will reject all response traffic. We apologize for any inconvenience this may have caused you. ague admirable airthed ahush afterbirth _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From dburnett@voxeo.com Wed Jul 14 06:19:49 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 143A23A681C; Wed, 14 Jul 2010 06:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqrHGh+iE6kO; Wed, 14 Jul 2010 06:19:47 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 55FC83A68B7; Wed, 14 Jul 2010 06:19:47 -0700 (PDT) Received: from [97.120.147.6] (account dburnett@voxeo.com HELO [192.168.0.7]) by voxeo.com (CommuniGate Pro SMTP 5.3.8) with ESMTPSA id 67724911; Wed, 14 Jul 2010 13:19:55 +0000 Message-Id: <769E404D-4D62-494F-9594-80F38CD922DF@voxeo.com> From: Dan Burnett To: Catherine Meadows In-Reply-To: <51173F8E-94BF-4347-B7A8-909BA5433443@nrl.navy.mil> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Jul 2010 09:19:47 -0400 References: <51173F8E-94BF-4347-B7A8-909BA5433443@nrl.navy.mil> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Sun, 18 Jul 2010 12:34:39 -0700 Cc: sarvi@cisco.com, oran@cisco.com, iesg@ietf.org, eburger@standardstrack.com, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-speechsc-mrcpv2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 13:19:49 -0000 Thank you for your comments. Our intent for the text does not exactly match the interpretation you give below. The general reply I have is that Speaker Verification and Speaker Identification are two different processes, one of which employs a claim of identity and one of which does not. Neither requires prior verification of the speaker being a member of a group. Please see my specific replies, embedded below. Dan Burnett On Jul 9, 2010, at 9:21 PM, Catherine Meadows wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. > These comments were written primarily for the benefit of the > security area directors. > Document editors and WG chairs should treat these comments just like > any other last call comments. > > This draft describes the Media Resource Control Protocol Version 2 > (MRCPv2) > which allows client hosts to control media service resources > residing in servers on a network. > MRCPv2 makes use of the Session Initiation Protocol (SIP) to > initiate and manage sessions > and the Session Description Protocol (SDP) to manage and exchange > capabilities. Both clients > and servers rely on TLS for security. > > Most of the security requirements for this protocol are similar to > requirements for any protocol > that manages control data, some of which must be sensitive. These > are outlined in the Security > Considerations section. MRCPv2 also supports the use of voice > identification to support a limited > form of limitation: the identification of which member of a group a > principal belongs to after the fact that > the principal belongs to the group has been ascertained by other > means. This is known as > Speaker Verification and Identification. Although a population claim is implicitly included in the process, there is no requirement that the principal be determined to belong to the population or a group within the population. The verification/ identification resource may return as a result that the principal is not a member of the population. > > I found the initial discussion of Speaker Verification and > Identification in Section 11 a little confusing, > and there is one sentence in particular that could be made more clear: > > The fourth paragraph in that section begins: > > Speaker identification is the process of associating an unknown > speaker with a member in a population. It does not employ a claim > of > identity. Speaker identification does not employ a claim of identity (other than implicitly to the population). > > But the paragraph immediately before that starts > > In speaker verification, a recorded utterance is compared to a > previously stored voiceprint which is in turn associated with a > claimed identity for that user. > Speaker *verification* does employ a claim of identity. "Speaker identification" identifies a speaker, while "speaker verification" verifies that a speaker is who he/she claims to be. > That sounds like it *does* employ a claim of identity. > > The fourth paragraph goes on to say that speaker ID should > be used when you already have verified that the speaker is a member > of a group (e.g. by cryptographic means), and you want to verify which > member of the group s/he is. This suggests that Actually, it says "When an individual claims to belong to a group (e.g., one of the owners of a joint bank account) a group authentication is performed." Here is the way to think of it: a voice authentication database contains a collection (called a population) of voice prints, one per individual who has been enrolled into the database as a member of the population. Each individual may have a unique (non-private) key associated with his/her voiceprint, or may share a unique (non- private) key representing a group (an enumerated subset of the population), or both. By most technology providers, identification is considered to be the process whereby one or more audio samples are compared to the voiceprints of the entire population to determine whether they match an individual in the population. Because there is no claim of identity as an individual or subgroup of the population, this is commonly referred to as requiring "no claim of identity". Note that in this case no keys (individual or group) need to be provided as input to the process, since all keys are implied. Note also that if the audio samples do not match any of the voiceprints in the population, the resource will return a code indicating this. By most technology providers, verification is considered to be the process whereby one or more audio samples are compared to the voiceprint of a given key to determine whether whether they match that specific voiceprint. This is a claim of identity. In this case the key (the claimed identity) needs to be provided as input to the process. Note that if the audio samples do not match the referenced voiceprint, the resource vill return a code indicating this. Some technology providers also provide something called multi- verification, where one or more audio samples are compared to multiple voiceprints (indicated by multiple keys) to determine whether the samples match any of the voiceprints. This is essentially a claim that the samples are from a speaker whose voiceprint is referenced by one of the given keys. As with verification, if the audio samples do not match any of the referenced voiceprints, the resource will return a code indicating failure to match. Some technology providers also provide something called group identification, where one or more audio samples are compared to multiple voiceprints that are represented by a group key to determine whether the samples match any of the voiceprints associated with the group key. Although this can be considered a claim of identity in the group, it is not a claim of a specific individual identity. Upon a match the return value can be either the group key or the specific individual key within the group, depending upon the resource. If the audio samples do not match a voiceprint of a member of the group, the resource will return a code indicating failure to match. The implementation in MRCP of all of the above capabilities is a list of input keys, each of which may represent an individual or a group, as appropriate for the specific resource, and a list of output keys representing individuals and/or groups, as appropriate for the specific resource. In the event that there is no match to any of the inputs (where an empty input list implies all keys are possible), an error code is returned. In none of these scenarios is there a situation where a speaker must first be identified to be a member of a particular group. > > It does not employ a claim of > identity. > > really means that > > It does not provide a proof of identity by itself. > > If that is the case, it should say that. > > I also note that the speaker verification is restricted to > identifying the identity > of someone who is already verified to be a member of a group. This > suggests that attempting to use > it without this prior verification is unsafe. A quick scan through > RFC 4313 didn't turn up any references to this > issue. If it is unsafe, then the ID should say so, and if there is > a related requirement in RFC 4313 that should > be referenced. Also, I would recommend saying that speaker > verification MUST NOT be implemented without > prior verification as a member of a group. > > > > > > Catherine Meadows > Naval Research Laboratory > Code 5543 > 4555 Overlook Ave., S.W. > Washington DC, 20375 > phone: 202-767-3490 > fax: 202-404-7942 > email: catherine.meadows@nrl.navy.mil > From phoffman@imc.org Sun Jul 18 17:49:44 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16D443A69B8 for ; Sun, 18 Jul 2010 17:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaLC7aiCk9xl for ; Sun, 18 Jul 2010 17:49:43 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 216943A69B6 for ; Sun, 18 Jul 2010 17:49:42 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o6J0nsJF037572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Jul 2010 17:49:56 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7485D041-D760-407C-97B5-6DEA2B91065C@bbn.com> References: <7485D041-D760-407C-97B5-6DEA2B91065C@bbn.com> Date: Sun, 18 Jul 2010 17:49:53 -0700 To: secdir@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: draft-ietf-pkix-asn1-translation@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-pkix-asn1-translation X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 00:49:44 -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 covers how to convert formats described in one version of ASN.1 to another. There are no significant security concerns in this document. From shanna@juniper.net Sun Jul 18 23:33:25 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1B083A687A; Sun, 18 Jul 2010 23:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.374 X-Spam-Level: X-Spam-Status: No, score=-5.374 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWjNbKfyaSyK; Sun, 18 Jul 2010 23:33:23 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 123EC3A6407; Sun, 18 Jul 2010 23:33:19 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTEPxvQmWj8J3gtwFaD3PQH1W4wItzCuC@postini.com; Sun, 18 Jul 2010 23:33:37 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 18 Jul 2010 23:31:34 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 19 Jul 2010 02:31:34 -0400 From: Stephen Hanna To: "secdir@ietf.org" , "iesg@ietf.org" , "ietf@ietf.org" , "draft-ietf-ippm-spatial-composition@tools.ietf.org" Date: Mon, 19 Jul 2010 02:31:33 -0400 Thread-Topic: secdir review of draft-ietf-ippm-spatial-composition-15.txt Thread-Index: AcslEFISFuNQhbB+QaW6sG9LyNEL5AB3/Z6A Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {AB750BE7-0792-482F-8946-66359297442E} x-cr-hashedpuzzle: CIyY C+jl DuBn FSIx G47F IzIM aqK4 ce6x cxP0 dvoy f2xa mnAj n1Sp ocmL p7GV q8ta; 4; ZAByAGEAZgB0AC0AaQBlAHQAZgAtAGkAcABwAG0ALQBzAHAAYQB0AGkAYQBsAC0AYwBvAG0AcABvAHMAaQB0AGkAbwBuAEAAdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnADsAaQBlAHMAZwBAAGkAZQB0AGYALgBvAHIAZwA7AGkAZQB0AGYAQABpAGUAdABmAC4AbwByAGcAOwBzAGUAYwBkAGkAcgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {AB750BE7-0792-482F-8946-66359297442E}; cwBoAGEAbgBuAGEAQABqAHUAbgBpAHAAZQByAC4AbgBlAHQA; Mon, 19 Jul 2010 03:20:53 GMT; cwBlAGMAZABpAHIAIAByAGUAdgBpAGUAdwAgAG8AZgAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBpAHAAcABtAC0AcwBwAGEAdABpAGEAbAAtAGMAbwBtAHAAbwBzAGkAdABpAG8AbgAtADEANQAuAHQAeAB0AA== acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] secdir review of draft-ietf-ippm-spatial-composition-15.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 06:33:25 -0000 I have reviewed this document as part of the security directorate's =20 ongoing effort to review all IETF documents being processed by the =20 IESG. These comments were written primarily for the benefit of the =20 security area directors. Document editors and WG chairs should treat =20 these comments just like any other last call comments. This document gives guidance on composing path metrics from sub-path metrics within the IP Performance Metrics framework. I am not an expert on IPPM but after some analysis I have concluded that the security considerations in this draft are adequate. They raise all the relevant security issues that I could come up with and provide guidance for how those issues can be addressed. From qiaobing.xie@gmail.com Mon Jul 19 10:06:56 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CD0A3A6B4D; Mon, 19 Jul 2010 10:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ql+sp0w9FdJH; Mon, 19 Jul 2010 10:06:55 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 66E5D3A68A4; Mon, 19 Jul 2010 10:06:55 -0700 (PDT) Received: by iwn38 with SMTP id 38so5292548iwn.31 for ; Mon, 19 Jul 2010 10:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=bA3RWqS4RMWk4avyG2ssDnDOqn8iYuPS2UQRTflJbxA=; b=MtvTAwDRJHNbVNi6BeXvzYwnDkYo3q5LriYA7rObK0hwWpSlwBdws+oML3uLoU8xO+ ypD6OAmYc/CvK0rgKOQ6uNsPAWGVJ1PjB0SFvL5PjvGDrfiXFHT1DFaTj8iVM1NEMgUZ E5OFYClshT7zLnqR18ItpFqsS7CdA5xYitwk8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=bDksS6ppJW23ayXLBbQzNeD6oF7LvQRc17j/IONvditik35PvfCROBgdAqqp3QhyuW HxYr3pUg5wMxa6CYV9nFH8a0oDaEAr6fQzs/tBv09tuFaWtkg4eDx3zPQpCTF+lUBEi8 pztzJFXqY+oxaT+LDnLZYRNUReZfc5WggquMs= Received: by 10.231.184.168 with SMTP id ck40mr4484935ibb.174.1279559229697; Mon, 19 Jul 2010 10:07:09 -0700 (PDT) Received: from Qiaobing-Xies-MacBook-Pro.local (24-171-16-115.dhcp.stls.mo.charter.com [24.171.16.115]) by mx.google.com with ESMTPS id g31sm26024354ibh.16.2010.07.19.10.07.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 10:07:07 -0700 (PDT) Message-ID: <4C448639.3050309@gmail.com> Date: Mon, 19 Jul 2010 12:07:05 -0500 From: Qiaobing Xie User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Derek Atkins References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 19 Jul 2010 10:35:30 -0700 Cc: tom111.taylor@bell.net, iesg@ietf.org, avt-chairs@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] sec-dir review of draft-ietf-avt-forward-shifted-red-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 17:06:56 -0000 Derek, Thanks for the comments. I will try to reword the security section to make it more readable when I update the draft. -Q Derek Atkins wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document defines a simple enhancement to RFC 2198 to support RTP > sessions with forward-shifted redundant encodings, i.e., redundant > data sent before the corresponding primary data. Forward-shifted > redundancy can be used to conceal losses of a large number of > consecutive media frames (e.g., consecutive loss of seconds or even > tens of seconds of media). > > The security considerations section is not written in gramatically > correct English. While this reader was able to decipher the meaning, > I hope that someone with more editorial capabilities can massage the > text into actual correct English sentences. > > Beyond the editorial issues, the document does address the single > issue I see, which is the potential denial of service attack where the > sender sends bogus forward-shifted data, potentially claiming large > buffers in the receiver. Once the security considerations section is > cleaned up it will more clearly state that "outrageous values" should > be ignored. > > -derek > From secdir-bounces@mit.edu Tue Jul 20 03:25:15 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A34B3A6C5F for ; Tue, 20 Jul 2010 03:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.505 X-Spam-Level: X-Spam-Status: No, score=-5.505 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbauYYbMxESj for ; Tue, 20 Jul 2010 03:25:13 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id B803A3A6C6B for ; Tue, 20 Jul 2010 03:25:11 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o6KAPQfm017364 for ; Tue, 20 Jul 2010 06:25:26 -0400 Received: from mailhub-dmz-2.mit.edu (MAILHUB-DMZ-2.MIT.EDU [18.7.62.37]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o6KAPNd3017358 for ; Tue, 20 Jul 2010 06:25:24 -0400 Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by mailhub-dmz-2.mit.edu (8.13.8/8.9.2) with ESMTP id o6KAPFf5001663 for ; Tue, 20 Jul 2010 06:25:23 -0400 X-AuditID: 1209190d-b7c82ae000000a16-af-4c45799488a1 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by dmz-mailsec-scanner-2.mit.edu (Symantec Brightmail Gateway) with SMTP id 68.E7.02582.599754C4; Tue, 20 Jul 2010 06:25:25 -0400 (EDT) X-IronPort-AV: E=Sophos;i="4.55,231,1278280800"; d="scan'208";a="64118082" Received: from zmbs1.inria.fr ([128.93.142.14]) by mail1-relais-roc.national.inria.fr with ESMTP; 20 Jul 2010 12:25:22 +0200 Date: Tue, 20 Jul 2010 12:24:28 +0200 (CEST) From: Vincent Roca To: Jaehoon Jeong Message-ID: <2060945452.10380.1279621468787.JavaMail.root@zmbs1.inria.fr> In-Reply-To: <5A6980BCAE9E6D438D4D8A05540F6FB70115649BE6@BRM-EXCH-3.corp.brocade.com> MIME-Version: 1.0 X-Originating-IP: [194.199.24.116] X-Mailer: Zimbra 6.0.7_GA_2470.RHEL5_64 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2470.RHEL5_64) X-Brightmail-Tracker: AAAAAhUrKiQVLCSW X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id o6KAPNd3017358 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Cc: 6man Chairs <6man-chairs@tools.ietf.org>, secdir@mit.edu, draft-ietf-6man-dns-options-bis all , Jari Arkko , IESG Subject: Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 10:25:15 -0000 Dear authors, First of all, sorry for this late answer. Otherwise I read -06 version and I'm now happy with modifications made in Section 5.3. Concerning Section 7 "Security Considerations", I still find the current text confusing (sorry): - there is no clear discussion of what are the additional =A0=A0threats specific to the proposed RDNSS/DNSSL. = =A0=A0Instead I see a discussion explaining that the situation is =A0=A0not worse than before because an attacker can launch other =A0=A0types of attacks on ND. You're right and you can mention this =A0=A0quickly, but do not limit yourself to such a discussion. - the new text on SEND is much better. However there is no =A0=A0explicit recommendation (no RECOMMENDED/SHOULD keyword). =A0=A0How should I understand this? Is it deliberate? Why? So I suggest that you add two subsections (with a suggested structure): =A0=A0 =A07.1. Security threats =A0=A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0 =A0=A0 =A07.2. Recommendations =A0=A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0 NB: In paragraph discussing filtering on switches: "is recommended" -> "is RECOMMENDED" NB2: I wouldn't like to give you the feeling that I set myself against you, this is not my goal. Cheers, =A0=A0 Vincent ----- Original Message ----- > From: "Jaehoon Jeong" > To: "Jari Arkko" > Cc: "Vincent Roca" , "draft-ietf-6man-dns-opti= ons-bis all" > , secdir@mit.edu, "IE= SG" , "6man Chairs" > <6man-chairs@tools.ietf.org> > Sent: Tuesday, July 6, 2010 4:37:06 PM > Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03 > Hi Jari, > Is this update fine to you along with Section 5.3.2 (Warnings for DNS > Options Configuration)? > = > The difference between 05-version and 06-version is located at: > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/wdif= f%20draft-ietf-6man-dns-options-bis-05_txt%20draft-ietf-6man-dns-options-bi= s-06_txt.htm > = > If so, I will submit the version 06-ID today. > = > Thanks. > = > Best Regards, > Paul > = > -----Original Message----- > From: Jaehoon Jeong [mailto:pjeong@Brocade.com] > Sent: Saturday, July 03, 2010 12:33 PM > To: Vincent Roca > Cc: Jari Arkko; draft-ietf-6man-dns-options-bis.all@tools.ietf.org; > secdir@mit.edu; IESG; 6man Chairs > Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03 > = > Hi Vincent, > I would like to address your comments as below. > = > The updated I-D is located in the following link: > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draf= t-ietf-6man-dns-options-bis-06.txt > = > On Sat, Jul 3, 2010 at 11:31 AM, Jaehoon Jeong > wrote: > > > > > > -----Original Message----- > > From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] > > Sent: Saturday, July 03, 2010 8:04 AM > > To: Jaehoon Jeong > > Cc: Jari Arkko; draft-ietf-6man-dns-options-bis.all@tools.ietf.org; > > secdir@mit.edu; IESG; 6man Chairs; vincent.roca@inrialpes.fr > > Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03 > > > > Dear authors, > > > > Thanks for your prompt reply. A few additional comments (it's my > > role > > ;-)) > > > > ** new "Security Considerations" section says: > >> =A0 =A0This attack > >> =A0 =A0is similar to Neighbor Discovery attacks that use Redirect or > >> =A0 =A0Neighbor Advertisement messages to redirect traffic to > >> =A0 =A0individual > >> =A0 =A0addresses to malicious parties. In general, the attacks related > >> =A0 =A0to > >> =A0 =A0RDNSS and DNSSL are similar to both Neighbor Discovery attacks > >> =A0 =A0and > >> =A0 =A0attacks against unauthenticated DHCP, as both can be used for > >> =A0 =A0both > >> =A0 =A0"wholesale" traffic redirection and more specific attacks. > >> > > You're right, other attacks are possible that lead to the same > > result. ND and unauthenticated DHCP are such possibilities. However, > > IMHO this is not a sufficient reason not to RECOMMEND a security > > solution for RA. > > Indeed, if ND / DHCP are made robust but nothing is done for RA, > > then the threat remains. > > > > So the updated text does not fully satisfies me, even if the new > > paragraph is more clear than the old one. > = > I reorganize the text such that the description for SEND (as a > security solution for RA) follows the above paragraph: > ... > In general, the attacks related to RDNSS and DNSSL are similar to both > Neighbor Discovery attacks and attacks against unauthenticated DHCP, > as both can be used for both "wholesale" traffic redirection and more > specific attacks. > = > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as > a security mechanism for ND, all the ND options including the RDNSS > and DNSSL options are automatically included in the signatures, so > the transport for the RA options is integrity-protected; that is, > SEND can prevent the spoofing of these DNS options with signatures. > Also, SEND enables an IPv6 host to verify that the sender of an RA is > actually a router authorized to act as a router. However, since any > valid SEND router can still insert RDNSS and DNSSL options, SEND > cannot verify which one is or is not authorized to send the options. > = > > > >>> ** Section 7: > >>> Another point... the authors explain than network devices like > >>> switches can be configured in such a way to disable ND/DHCP from > >>> some ports. That's great and I agree it helps preventing attacks. > >>> However this is limited to wired networks. Nothing is said > >>> concerning ND configurations in wireless networks. The situation > >>> is > >>> rather different since any host can issue ND/DHCP traffic as if it > >>> were a legitimate server if I understand correctly. The document > >>> MUST include this kind of discussion. > >>> > >>> > >> But this is generic issue with spoofing RAs and I am not sure it is > >> the task of this document to specify the solutions. One solution > >> exists in SEND (RFC 3791). > >> > > Once again I agree. You don't have to specify technical solutions. > > However you need to provide a good security analysis, perhaps > > inherited from that of the base RA document for the generic RA > > threats, with some text describing the additional threats added by > > the proposed extensions. And since security solutions exist > > elsewhere (SEND), you should recommend their use. That's your > > responsibility. > = > In the following paragraph, we address that SEND can prevent such RA > DNS option spoofing: > = > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as > a security mechanism for ND, all the ND options including the RDNSS > and DNSSL options are automatically included in the signatures, so > the transport for the RA options is integrity-protected; that is, > SEND can prevent the spoofing of these DNS options with signatures. > Also, SEND enables an IPv6 host to verify that the sender of an RA is > actually a router authorized to act as a router. However, since any > valid SEND router can still insert RDNSS and DNSSL options, SEND > cannot verify which one is or is not authorized to send the options. > = > > > >>> ** Section 7: > >>> Yet another remark: SEND is listed as one potential solution to > >>> add > >>> signatures in ND packets issued from servers. > >>> I don't know SEND at all, so may be my remarks are flawed (but in > >>> that case the text should be at least clarified). > >>> - Shouldn't the use of SEND be RECOMMENDED as a solution to > >>> mitigate > >>> attacks? Current document is not clear. > >>> - Does SEND enable an authentication of the sender (the document > >>> only mentions integrity protection)? If there's no sender > >>> authentication, then I agree that the added value of SEND would be > >>> limited. I'd like the authors to clarify this as well. > >>> > >>> > >> The details are in RFC 3791 and its companion documents. SEND does > >> enable a host to verify that the sender of an RA is actually a > >> router > >> authorized to act as a router. > >> > > > > The text in your proposed I-D update does not reflect this. Can you > > add it? Being able to authenticate the sender is as important as > > being able to check the packet integrity. > = > According to the comments, the checking for valid router is mentioned > in the middle: > = > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as > a security mechanism for ND, all the ND options including the RDNSS > and DNSSL options are automatically included in the signatures, so > the transport for the RA options is integrity-protected; that is, > SEND can prevent the spoofing of these DNS options with signatures. > Also, SEND enables an IPv6 host to verify that the sender of an RA is > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > actually a router authorized to act as a router. However, since any > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > valid SEND router can still insert RDNSS and DNSSL options, SEND > cannot verify which one is or is not authorized to send the options. > = > > > > ** I'm coming back to a comment I made earlier and that has not been > > answered. > > > > In the updated I-D, section 5.3.1, I read: > > > > =A0"In the case where the DNS options of RDNSS and DNSSL can be > > =A0obtained > > =A0 from multiple sources, such as RA and DHCP, the IPv6 host SHOULD > > =A0 keep > > =A0 some DNS options from all sources. " > > > > I don't see (but I read very quickly so I may have missed > > something) that secured RA/RDNSS/DNSSL messages be preferred in the > > choice. If some RA use SEND, they must be preferred over others. > > > = > In Section 5.3.1, the considerations on SEND is mentioned as follows: > = > In the case where the DNS options of RDNSS and DNSSL can be obtained > from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep > some DNS options from all sources. Unless explicitly specified for > the discovery mechanism, the exact number of addresses and domain > names to keep is a matter of local policy and implementation choice. > However, it is RECOMMENDED that at least three RDNSS addresses (or > DNSSL domain names) can be stored from at least two different > sources. The DNS options from Router Advertisements and DHCP SHOULD > be stored into DNS Repository and Resolver Repository so that > information from DHCP appears there first and therefore takes > precedence. Thus, the DNS information from DHCP takes precedence > over that from RA for DNS queries. On the other hand, for DNS > ^^^^^^^^^^^^^^^^^^^^^^^^^ > options announced by RA, if some RAs use the Secure Neighbor > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Discovery (SEND) protocol [RFC3971] for RA security, they MUST be > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > preferred over those which do not use SEND. Refer to Section 7 for > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the detailed discussion on SEND for RA DNS options. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > = > > I hope my comments are useful. > > Cheers, > > > > =A0 =A0Vincent > > > = > Thanks for your efforts on the improvement for this document. > = > Best Regards, > Paul _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From dharkins@lounge.org Tue Jul 20 10:09:19 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748283A68EA; Tue, 20 Jul 2010 10:09:19 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGqCGSsBLfNb; Tue, 20 Jul 2010 10:09:18 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id B33C93A6832; Tue, 20 Jul 2010 10:09:18 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 4B525A888112; Tue, 20 Jul 2010 10:09:34 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 20 Jul 2010 10:09:34 -0700 (PDT) Message-ID: <105c695af5c310908100f0f35b45fe2d.squirrel@www.trepanning.net> Date: Tue, 20 Jul 2010 10:09:34 -0700 (PDT) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-ietf-kitten-gssapi-naming-exts.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-kitten-gssapi-naming-exts X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 17:09:19 -0000 Hello, I have reviewed draft-ietf-kitten-gssapi-naming-exts 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 extends the GSS-API naming model to include support for "name attributes". This support can be used by an application to make authorization decisions. I found no problems in the draft that the ADs should take special note of. The draft is well-written and introduces and uses terminology well, with one nit. It introduces terms with certain marking and then uses them either without the marking (which is fine) or with some other marking. For instance, "An attribute is 'authenticated' iff...." and then the concept of an authenticated attribute is used without the single quote. But sometimes attributes "MUST be represented as *authenticated* GSS-API name attributes named using the _same_ OID mapped to a URN." OK, so what's the significance of the asterisks now? And the underscore? I found no value in these marks and suggest removing them. If the authors intend for the marks to convey some meaning then perhaps a Notations section is in order. One last nit: Section 6.2.1 refers to "(see comment above)" which should be "(see Section 5)". regards, Dan. From secdir-bounces@mit.edu Tue Jul 20 07:00:31 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CAFE3A694A for ; Tue, 20 Jul 2010 07:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.106 X-Spam-Level: X-Spam-Status: No, score=-5.106 tagged_above=-999 required=5 tests=[AWL=1.493, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swVVCz0SkvFs for ; Tue, 20 Jul 2010 07:00:29 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 68F9B3A6883 for ; Tue, 20 Jul 2010 07:00:29 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o6KE0iUr030357 for ; Tue, 20 Jul 2010 10:00:44 -0400 Received: from mailhub-dmz-4.mit.edu (MAILHUB-DMZ-4.MIT.EDU [18.7.62.38]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o6KE0fsd030346 for ; Tue, 20 Jul 2010 10:00:41 -0400 Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by mailhub-dmz-4.mit.edu (8.13.8/8.9.2) with ESMTP id o6KE0XFv025153 for ; Tue, 20 Jul 2010 10:00:41 -0400 X-AuditID: 1209190f-b7b0aae000000a7d-e9-4c45ac0b8706 Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by dmz-mailsec-scanner-4.mit.edu (Symantec Brightmail Gateway) with SMTP id BF.40.02685.B0CA54C4; Tue, 20 Jul 2010 10:00:44 -0400 (EDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o6KE0YD7005032; Tue, 20 Jul 2010 07:00:34 -0700 Received: from brm-exedge.brocade.com (brm-exedge.brocade.com [144.49.197.8]) by mx0a-000f0801.pphosted.com with ESMTP id q5744g4n0-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 20 Jul 2010 07:00:34 -0700 Received: from brm-excashub-2.corp.brocade.com (172.16.72.231) by BRM-EXEDGE-2.corp.brocade.com (172.16.72.249) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 08:00:14 -0600 Received: from brm-exch-3.corp.brocade.com ([169.254.2.126]) by brm-excashub-2.corp.brocade.com ([172.16.72.231]) with mapi; Tue, 20 Jul 2010 08:00:20 -0600 From: Jaehoon Jeong To: Vincent Roca Date: Tue, 20 Jul 2010 08:00:18 -0600 Thread-Topic: SecDir review of draft-ietf-6man-dns-options-bis-03 Thread-Index: Acsn9d/mING62nGjQsKl2TpbxLkM1AAHeLNA Message-ID: References: <5A6980BCAE9E6D438D4D8A05540F6FB70115649BE6@BRM-EXCH-3.corp.brocade.com> <2060945452.10380.1279621468787.JavaMail.root@zmbs1.inria.fr> In-Reply-To: <2060945452.10380.1279621468787.JavaMail.root@zmbs1.inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-20_05:2010-07-20, 2010-07-20, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1007200060 X-Brightmail-Tracker: AAAAAhUrKiQVLCSW X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id o6KE0fsd030346 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Tue, 20 Jul 2010 11:19:26 -0700 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, "secdir@mit.edu" , draft-ietf-6man-dns-options-bis all , Jari Arkko , IESG Subject: Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 14:00:31 -0000 Hi Vincent, I will work on Security considerations according to your guidelines. Thanks. Best Regards, Paul -----Original Message----- From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] = Sent: Tuesday, July 20, 2010 5:24 AM To: Jaehoon Jeong Cc: draft-ietf-6man-dns-options-bis all; secdir@mit.edu; IESG; 6man Chairs;= Jari Arkko Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03 Dear authors, First of all, sorry for this late answer. Otherwise I read -06 version and I'm now happy with modifications made in S= ection 5.3. Concerning Section 7 "Security Considerations", I still find the current te= xt confusing (sorry): - there is no clear discussion of what are the additional =A0=A0threats specific to the proposed RDNSS/DNSSL. = =A0=A0Instead I see a discussion explaining that the situation is =A0=A0not worse than before because an attacker can launch other =A0=A0types of attacks on ND. You're right and you can mention this =A0=A0quickly, but do not limit yourself to such a discussion. - the new text on SEND is much better. However there is no =A0=A0explicit recommendation (no RECOMMENDED/SHOULD keyword). =A0=A0How should I understand this? Is it deliberate? Why? So I suggest that you add two subsections (with a suggested structure): =A0=A0 =A07.1. Security threats =A0=A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0 =A0=A0 =A07.2. Recommendations =A0=A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0 NB: In paragraph discussing filtering on switches: "is recommended" -> "is RECOMMENDED" NB2: I wouldn't like to give you the feeling that I set myself against you,= this is not my goal. Cheers, =A0=A0 Vincent ----- Original Message ----- > From: "Jaehoon Jeong" > To: "Jari Arkko" > Cc: "Vincent Roca" , "draft-ietf-6man-dns-opti= ons-bis all" > , secdir@mit.edu, "IE= SG" , "6man Chairs" > <6man-chairs@tools.ietf.org> > Sent: Tuesday, July 6, 2010 4:37:06 PM > Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03 > Hi Jari, > Is this update fine to you along with Section 5.3.2 (Warnings for DNS = > Options Configuration)? > = > The difference between 05-version and 06-version is located at: > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/w > diff%20draft-ietf-6man-dns-options-bis-05_txt%20draft-ietf-6man-dns-op > tions-bis-06_txt.htm > = > If so, I will submit the version 06-ID today. > = > Thanks. > = > Best Regards, > Paul > = > -----Original Message----- > From: Jaehoon Jeong [mailto:pjeong@Brocade.com] > Sent: Saturday, July 03, 2010 12:33 PM > To: Vincent Roca > Cc: Jari Arkko; draft-ietf-6man-dns-options-bis.all@tools.ietf.org; > secdir@mit.edu; IESG; 6man Chairs > Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03 > = > Hi Vincent, > I would like to address your comments as below. > = > The updated I-D is located in the following link: > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/d > raft-ietf-6man-dns-options-bis-06.txt > = > On Sat, Jul 3, 2010 at 11:31 AM, Jaehoon Jeong > wrote: > > > > > > -----Original Message----- > > From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] > > Sent: Saturday, July 03, 2010 8:04 AM > > To: Jaehoon Jeong > > Cc: Jari Arkko; draft-ietf-6man-dns-options-bis.all@tools.ietf.org; > > secdir@mit.edu; IESG; 6man Chairs; vincent.roca@inrialpes.fr > > Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03 > > > > Dear authors, > > > > Thanks for your prompt reply. A few additional comments (it's my = > > role > > ;-)) > > > > ** new "Security Considerations" section says: > >> =A0 =A0This attack > >> =A0 =A0is similar to Neighbor Discovery attacks that use Redirect or > >> =A0 =A0Neighbor Advertisement messages to redirect traffic to > >> =A0 =A0individual > >> =A0 =A0addresses to malicious parties. In general, the attacks related > >> =A0 =A0to > >> =A0 =A0RDNSS and DNSSL are similar to both Neighbor Discovery attacks > >> =A0 =A0and > >> =A0 =A0attacks against unauthenticated DHCP, as both can be used for > >> =A0 =A0both > >> =A0 =A0"wholesale" traffic redirection and more specific attacks. > >> > > You're right, other attacks are possible that lead to the same = > > result. ND and unauthenticated DHCP are such possibilities. However, = > > IMHO this is not a sufficient reason not to RECOMMEND a security = > > solution for RA. > > Indeed, if ND / DHCP are made robust but nothing is done for RA, = > > then the threat remains. > > > > So the updated text does not fully satisfies me, even if the new = > > paragraph is more clear than the old one. > = > I reorganize the text such that the description for SEND (as a = > security solution for RA) follows the above paragraph: > ... > In general, the attacks related to RDNSS and DNSSL are similar to both = > Neighbor Discovery attacks and attacks against unauthenticated DHCP, = > as both can be used for both "wholesale" traffic redirection and more = > specific attacks. > = > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as = > a security mechanism for ND, all the ND options including the RDNSS = > and DNSSL options are automatically included in the signatures, so the = > transport for the RA options is integrity-protected; that is, SEND can = > prevent the spoofing of these DNS options with signatures. > Also, SEND enables an IPv6 host to verify that the sender of an RA is = > actually a router authorized to act as a router. However, since any = > valid SEND router can still insert RDNSS and DNSSL options, SEND = > cannot verify which one is or is not authorized to send the options. > = > > > >>> ** Section 7: > >>> Another point... the authors explain than network devices like = > >>> switches can be configured in such a way to disable ND/DHCP from = > >>> some ports. That's great and I agree it helps preventing attacks. > >>> However this is limited to wired networks. Nothing is said = > >>> concerning ND configurations in wireless networks. The situation = > >>> is rather different since any host can issue ND/DHCP traffic as if = > >>> it were a legitimate server if I understand correctly. The = > >>> document MUST include this kind of discussion. > >>> > >>> > >> But this is generic issue with spoofing RAs and I am not sure it is = > >> the task of this document to specify the solutions. One solution = > >> exists in SEND (RFC 3791). > >> > > Once again I agree. You don't have to specify technical solutions. > > However you need to provide a good security analysis, perhaps = > > inherited from that of the base RA document for the generic RA = > > threats, with some text describing the additional threats added by = > > the proposed extensions. And since security solutions exist = > > elsewhere (SEND), you should recommend their use. That's your = > > responsibility. > = > In the following paragraph, we address that SEND can prevent such RA = > DNS option spoofing: > = > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as = > a security mechanism for ND, all the ND options including the RDNSS = > and DNSSL options are automatically included in the signatures, so the = > transport for the RA options is integrity-protected; that is, SEND can = > prevent the spoofing of these DNS options with signatures. > Also, SEND enables an IPv6 host to verify that the sender of an RA is = > actually a router authorized to act as a router. However, since any = > valid SEND router can still insert RDNSS and DNSSL options, SEND = > cannot verify which one is or is not authorized to send the options. > = > > > >>> ** Section 7: > >>> Yet another remark: SEND is listed as one potential solution to = > >>> add signatures in ND packets issued from servers. > >>> I don't know SEND at all, so may be my remarks are flawed (but in = > >>> that case the text should be at least clarified). > >>> - Shouldn't the use of SEND be RECOMMENDED as a solution to = > >>> mitigate attacks? Current document is not clear. > >>> - Does SEND enable an authentication of the sender (the document = > >>> only mentions integrity protection)? If there's no sender = > >>> authentication, then I agree that the added value of SEND would be = > >>> limited. I'd like the authors to clarify this as well. > >>> > >>> > >> The details are in RFC 3791 and its companion documents. SEND does > >> enable a host to verify that the sender of an RA is actually a > >> router > >> authorized to act as a router. > >> > > > > The text in your proposed I-D update does not reflect this. Can you > > add it? Being able to authenticate the sender is as important as > > being able to check the packet integrity. > = > According to the comments, the checking for valid router is mentioned > in the middle: > = > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as > a security mechanism for ND, all the ND options including the RDNSS > and DNSSL options are automatically included in the signatures, so > the transport for the RA options is integrity-protected; that is, > SEND can prevent the spoofing of these DNS options with signatures. > Also, SEND enables an IPv6 host to verify that the sender of an RA is > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > actually a router authorized to act as a router. However, since any > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > valid SEND router can still insert RDNSS and DNSSL options, SEND > cannot verify which one is or is not authorized to send the options. > = > > > > ** I'm coming back to a comment I made earlier and that has not been > > answered. > > > > In the updated I-D, section 5.3.1, I read: > > > > =A0"In the case where the DNS options of RDNSS and DNSSL can be > > =A0obtained > > =A0 from multiple sources, such as RA and DHCP, the IPv6 host SHOULD > > =A0 keep > > =A0 some DNS options from all sources. " > > > > I don't see (but I read very quickly so I may have missed > > something) that secured RA/RDNSS/DNSSL messages be preferred in the > > choice. If some RA use SEND, they must be preferred over others. > > > = > In Section 5.3.1, the considerations on SEND is mentioned as follows: > = > In the case where the DNS options of RDNSS and DNSSL can be obtained > from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep > some DNS options from all sources. Unless explicitly specified for > the discovery mechanism, the exact number of addresses and domain > names to keep is a matter of local policy and implementation choice. > However, it is RECOMMENDED that at least three RDNSS addresses (or > DNSSL domain names) can be stored from at least two different > sources. The DNS options from Router Advertisements and DHCP SHOULD > be stored into DNS Repository and Resolver Repository so that > information from DHCP appears there first and therefore takes > precedence. Thus, the DNS information from DHCP takes precedence > over that from RA for DNS queries. On the other hand, for DNS > ^^^^^^^^^^^^^^^^^^^^^^^^^ > options announced by RA, if some RAs use the Secure Neighbor > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Discovery (SEND) protocol [RFC3971] for RA security, they MUST be > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > preferred over those which do not use SEND. Refer to Section 7 for > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the detailed discussion on SEND for RA DNS options. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > = > > I hope my comments are useful. > > Cheers, > > > > =A0 =A0Vincent > > > = > Thanks for your efforts on the improvement for this document. > = > Best Regards, > Paul _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From new-work-bounces@ietf.org Tue Jul 20 10:00:04 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61DBB3A6C7A; Tue, 20 Jul 2010 10:00:04 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DD4203A6C68; Tue, 20 Jul 2010 10:00:01 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100720170001.DD4203A6C68@core3.amsl.com> Date: Tue, 20 Jul 2010 10:00:01 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 20 Jul 2010 11:19:26 -0700 Subject: [secdir] [New-work] WG Review: Authority to Citizen Alert (ATOCA) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 17:00:04 -0000 A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, July 27, 2010. Authority to Citizen Alert (ATOCA) ---------------------------------- Current Status: Proposed Working Group Last Modified: 2010-07-15 Chairs(s) TBD Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion: earlywarning@ietf.org To Subscribe: Archive: Real-time Applications and Infrastructure Area Advisor: Robert Sparks Description of Working Group: There are a variety of mechanisms that authorities have available to notify citizens and visitors during emergency events. Traditionally, they have done so with broadcast networks (radio and television). For commercial mobile devices, broadcasting services such as the Public Warning System (PWS), the Earthquake and Tsunami Warning System (ETWS), and the Commercial Mobile Alert System (CMAS) are standardized and are in various stages of deployment. The Internet provides another way for authority-to-citizen alerts to be sent, but it also presents new challenges. While there are some existing layer 2 mechanisms for delivering alerts, the work in this group focuses on delivering alerts to IP endpoints only. The general message pattern that this group is intended to address is the sending of alerts from a set of pre-authorized agents (e.g., governmental agencies) to a large population without impacting layer 2 networks (e.g. causing congestion or denial of service). The goal of this group is not to specify how originators of alerts obtain authorization, but rather how an ATOCA system can verify authorization and deliver messages to the intended recipients. A critical element of the work are the mechanisms that assure that only those pre-authorized agents can send alerts via ATOCA, through an interface to authorized alert distribution networks (e.g., iPAWS/DM-Open in the U.S.). The ATOCA effort is differentiated from and is not intended to replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), as the recipients of ATOCA alerts are the wide range of devices connected to the Internet and various private IP networks, which humans may have "at hand" to get such events, as well as automatons who may take action based on the alerts. This implies that the content of the alert contains some information, which is intended to be consumed by humans, and some which is intended to be consumed by automatons. Ideally, the alerts would contain, or refer to media other than text media (e.g., audio and/or video). The initial work in the group is focused on small messages, which may be mechanically rendered by the device in other forms (text to speech for example). Future work in the group may investigate rich media. In situations of a major emergency there could be scenarios where there are multiple alerts generated that may require that a priority mechanism (defined by alert originator policy) has to be used. The work on a resource priority mechanism is out of scope of the initial charter, but may be revisited at a later date. Which devices should get alerts is primarily driven by location. The first set of recipients that must be catered for are those within the area identified by the alert originator to be affected by the emergency event. In many jurisdictions, there are regulations that define whether recipients/devices within the affected area have opt-in or opt-out capability, but the protocols ATOCA will define will include both opt-in and opt-out mechanisms. The group will explore how to support both opt-in and opt-out at the level of communication protocols and/or device behavior. Another class of recipients that are in scope of the work are explicit opt-in subscriptions which ask for alerts for a specified location, not necessarily the physical location of the device itself. An example of such a subscription would be 'send me alerts for location x' (previously determined as the location of interest). This work may build on existing IETF GEOPRIV location work. There are efforts in other fora on early warning, which will be considered in this effort. For example, we expect to make use of the OASIS Common Alerting Protocol (CAP) for the encoding of alerts. OGC, ATIS, TIA, ITU-T, ETSI and 3GPP also have alert efforts underway, and consultation with these efforts will be undertaken to avoid unnecessary duplication of effort and also to avoid unintentional negative impacts on the networks. Of course, existing protocols for delivering messages (e.g., SIP, XMPP, or SMTP) will be the basis for the message delivery system of this working group. Any service discovery mechanisms defined by the group are expected to reuse existing discovery frameworks. The security implications of mechanisms that can send alerts to billions of devices are profound, but the utility of the mechanism encourages us to face the problems and solve them. In addition, the potential performance and congestion impacts to networks resulting from sending alert information to billions of devices must be considered and solved if such a service is implementable. To avoid manual configuration of servers distributing alerts a discovery mechanism will be specified. NOTE FOR CHARTER REVIEW (this section to be removed before charter approval): Some early drafts related to this proposed work are * draft-norreys-ecrit-authority2individuals-requirements * draft-rosen-ecrit-lost-early-warning * draft-rosen-atoca-server-discovery * draft-rosen-atoca-cap * draft-schulzrinne-atoca-requirements Goals and Milestones Jan 2011 Submit "Terminology and Framework" to the IESG for publication as Informational Apr 2011 Submit "Addressing security, performance and congestion issues for alert distribution" to the IESG for publication as Informational Apr 2011 Submit conveying point-to-point Authority to Citizen Alerts to the IESG for publication as Proposed Standard May 2011 Submit "Discovering alerting servers" to the IESG for publication as Proposed Standard Jun 2011 Submit conveying point-to-multipoint Authority to Citizen Alerts to the IESG for publication as Proposed Standard Aug 2011 Submit "Considerations for interworking with currently deployed alert distribution systems" to the IESG for publication as Informational _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From leifj@sunet.se Tue Jul 20 12:14:23 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 470BA3A6BF7; Tue, 20 Jul 2010 12:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQNt4QsKOvtZ; Tue, 20 Jul 2010 12:14:17 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 5AD723A6934; Tue, 20 Jul 2010 12:14:15 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o6KJERfc009648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jul 2010 21:14:29 +0200 (CEST) Message-ID: <4C45F593.5030609@sunet.se> Date: Tue, 20 Jul 2010 21:14:27 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Lightning/1.0b1 Shredder/3.0.3pre MIME-Version: 1.0 To: Dan Harkins References: <105c695af5c310908100f0f35b45fe2d.squirrel@www.trepanning.net> In-Reply-To: <105c695af5c310908100f0f35b45fe2d.squirrel@www.trepanning.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 20 Jul 2010 12:26:15 -0700 Cc: draft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-kitten-gssapi-naming-exts X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 19:14:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/20/2010 07:09 PM, Dan Harkins wrote: > > Hello, > > I have reviewed draft-ietf-kitten-gssapi-naming-exts 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 extends the GSS-API naming model to include support for > "name attributes". This support can be used by an application to make > authorization decisions. I found no problems in the draft that the > ADs should take special note of. > > The draft is well-written and introduces and uses terminology well, > with one nit. It introduces terms with certain marking and then uses > them either without the marking (which is fine) or with some other > marking. For instance, "An attribute is 'authenticated' iff...." and > then the concept of an authenticated attribute is used without the > single quote. But sometimes attributes "MUST be represented as > *authenticated* GSS-API name attributes named using the _same_ OID > mapped to a URN." OK, so what's the significance of the asterisks now? > And the underscore? I found no value in these marks and suggest removing > them. If the authors intend for the marks to convey some meaning then > perhaps a Notations section is in order. > > One last nit: Section 6.2.1 refers to "(see comment above)" which should > be "(see Section 5)". > > regards, > > Dan. Thanks for the review Dan! Your comments are very valuable and I intend to update the document accordingly. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxF9Y8ACgkQ8Jx8FtbMZnevFQCeKE18nQdJhrEHvM+37x4fpppw rFcAoJK65i6pCv9/0RsEj0KMl2orPUHm =5nVY -----END PGP SIGNATURE----- From julienl@qualcomm.com Tue Jul 20 16:00:48 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 422B33A68D5 for ; Tue, 20 Jul 2010 16:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zwt2crMqwACu for ; Tue, 20 Jul 2010 16:00:46 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 66C0C3A65A5 for ; Tue, 20 Jul 2010 16:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1279666860; x=1311202860; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"secdir@ietf.org"=20|Date:=20Tue, =2020=20Jul=202010=2016:00:40=20-0700|Subject:=20are=20IP sec/IKE=20MUST=20or=20SHOULD=20implement=20for=20IPv6 |Thread-Topic:=20are=20IPsec/IKE=20MUST=20or=20SHOULD=20i mplement=20for=20IPv6|Thread-Index:=20AcsoUnHYpLxB809CR3+ ghsOW84CqmwADK+PA|Message-ID:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=gRwLvrg7gmrM+PXHGHRCMRw27GducjRk0wq6MIS84SE=; b=jTLXO/tancapWvyj7T966SMQ4GqmTa8CHUxo4MfDyS42fxFroKi0NdDP tNpAiqO6OZxyZXjep9fpTr+n1zenvgteT0dMOtHt9TThnC65XIx+fk3nd FrCSTOpSGonOeVsjm+tCHjDa7LAj7D3ulGZE8uzeC+XdQ2k/gzBwpA+nM Y=; X-IronPort-AV: E=McAfee;i="5400,1158,6049"; a="48096499" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine01.qualcomm.com with ESMTP; 20 Jul 2010 16:00:40 -0700 X-IronPort-AV: E=Sophos;i="4.55,232,1278313200"; d="scan'208";a="44857943" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 20 Jul 2010 16:00:40 -0700 Received: from nasanexhc04.na.qualcomm.com (172.30.48.17) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 16:00:41 -0700 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.0.694.0; Tue, 20 Jul 2010 16:00:42 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Tue, 20 Jul 2010 16:00:42 -0700 From: "Laganier, Julien" To: "secdir@ietf.org" Date: Tue, 20 Jul 2010 16:00:40 -0700 Thread-Topic: are IPsec/IKE MUST or SHOULD implement for IPv6 Thread-Index: AcsoUnHYpLxB809CR3+ghsOW84CqmwADK+PA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] are IPsec/IKE MUST or SHOULD implement for IPv6 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 23:00:48 -0000 FYI, ongoing discussion just started in 6man. --julien -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Tho= mas Narten Sent: Tuesday, July 20, 2010 2:27 PM To: ipv6@ietf.org Subject: Node Requirements: Issue 17 - IPsec/IKE Folks, A revised version of draft-ietf-6man-node-req-bis-05.txt has been published, but it's Security section needs work. In particular, the WG needs to answer the following questions: - Should IPsec be a SHOULD or MUST? - What about IKEv2? Let me start with some background: RFC 4294 says the following: > 8. Security >=20 > This section describes the specification of IPsec for the IPv6 node. >=20 > 8.1. Basic Architecture >=20 > Security Architecture for the Internet Protocol [RFC-4301] MUST be > supported. > > 8.2. Security Protocols >=20 > ESP [RFC-4303] MUST be supported. AH [RFC-4302] MUST be supported. ... > 8.4. Key Management Methods > An implementation MUST support the manual configuration of the > security key and SPI. The SPI configuration is needed in order to > delineate between multiple keys. >=20 > Key management SHOULD be supported. Examples of key management > systems include IKEv2 [RFC-4306] and Kerberos; S/MIME and TLS include > key management functions. >=20 > Where key refresh, anti-replay features of AH and ESP, or on-demand > creation of Security Associations (SAs) is required, automated keying > MUST be supported. >=20 > Key management methods for multicast traffic are also being worked on > by the MSEC WG. There are a couple of problems with the above text. First, AH [RFC4302] is listed as a MUST. This is old/obsolete. The newer versions of the IPsec architecture have changed this to a MAY. ESP now includes integrity protection, so one can achieve authentication via ESP and NULL encryption. Thus, the node requirements document will change AH to a MAY. (This should not be a controversial change.) The real issue though is as follows: The key managment recommendation is only a SHOULD, yet doesn't actually recommend one particular protocol. That said, the only available key management protocol is effectively IKE. Thus, the Node Requirements recommendation is a SHOULD for IKE (and IKEv2 in particular). But, RFC 4301 (the Security Architecture) is listed as a MUST. If one looks at 4301 closely, it effectively mandates IKEv2 (see http://www.ietf.org/mail-archive/web/ipsec/current/msg06259.html). That is, the IPv6 Node Requirements RFC says SHOULD for IKEv2, yet indirectly also says MUST for IKEv2. Talk about wanting it both ways... Some more thoughts. 1) Mandating IPsec (just ESP) without also supporting a key management protocol has rather limited applicability. For many years, the IPv6 WG has insisted on IPsec being a MUST (for strong security), but in the absence of key management, that requirement (IMO) rings hollow. 2) The IPv6 WG has in the past been hesitant to mandate IKE for all hosts. This was viewed as a difficult requirement for some devices. Although there are more implementations of IKE today, I suspect there would still be hesitation to mandate IKE on all nodes. 3) We've gained a lot of experience with security and security protocols over the last decade. If there is one overarching lesson, it's that security isn't easy, and it's not just about protocols. It's also about key distribution, certificates, operational practices, etc. Moreover, it is now recognized that with security, there is no one-size-fits-all panacea. We have a plethora of security technologies (ssh, ssl, tls, IPsec, etc.) and some really are more appropriate for some applications than others. So IPsec is not going to turn out to be the single "holy grail" security technology. It has its place, and I expect we'll see a lot more usage of it over the next decade, but it is not likely to displace all other approaches. And for some classes of devices and applications, other security protocols will be more appropriate than IPsec. 4) The breadth and range of devices that support IP is simply staggering. Many are small, and some are so small, they really do have legitmate issues with supporting IKEv2. Does it make sense for the IETF to mandate that an iPod run IPsec and/or IKE? Sensor devices? Personally, I don't think so. Even the current recommendation that IPsec/ESP be a MUST seems a bit like ivory-tower syndrome. IPsec does make sense in a lot of environments, but simply isn't required in all devices. And having the IETF say it is required hasn't forced all vendors to implement IPsec in their devices. Thus, it is my recommendation that the next version of the node requirements document make support for IPsec and IKE both SHOULDs only, with a lot more explanatory text that makes it clear that there are some types of devices where IPsec is not necessarily the best choice. Thoughts? Proposed new text: 10. Security This section describes the specification of IPsec for IPv6 nodes. Achieving security in practice is a complex undertaking. Operational procedures, protocols, key distribution mechanisms, certificate management approaches, etc. are all components that impact whether security is actually achieved in practice. More importantly, deficiencies or a poor fit in any one individual component can significantly reduce the overall effectiveness of an particular security approach. IPsec provides channel security at the Internet layer, making it possible to provide secure communication for communication flows between pairs of internet hosts. IPsec provides sufficient flexibility and granularity that individual TCP connections can (selectively) be protected, etc. IKEv2 is the key management protocol for IPsec. Although manual keying can be used with IPsec in some cases, the overall applicability of statically configured keys is limited. Thus, IPsec without IKEv2 has only limited value. A range of security technologies and approaches proliferate today (e.g., IPsec, TLS, SSL, SSH, HTTPS, etc.) No one approach has emerged as an ideal technology for all needs. It seems clear that for the foresable future, that situation will not change. Moreover, IPsec is not viewed as the ideal security technology for all approaches and is unlikely to displace the others. That is, IPsec is not viewed as a good choice for all security needs. Previously, IPv6 mandated implementation of IPsec and recommended the key management approach of IKE. This document updates that recommendation by making support of both IPsec and IKEv2 a SHOULD for IPv6 nodes. In particular, it is recognized that there are a range of device types and environments where other approaches to security than IPsec can be more appropriate. This is particularly the case for smaller specialized, single-purpose devices that support only very limited applications or run on constrained hardware. In other environments, support for IPsec and IKEv2 should be considered a very strong SHOULD, if not a MUST. =20 10.1. Requirements Security Architecture for the Internet Protocol [RFC4301] SHOULD be supported by all nodes. Those nodes implementing the Security Archecture MUST support ESP [RFC4303] and MAY support AH [RFC4302]. In addition, such nodes SHOULD implement IKEv2 [RFC4306]. 10.2. Transforms and Algorithms The current set of mandatory-to-implement algorithms for ESP and AH are defined in 'Cryptographic Algorithm Implementation Requirements For ESP and AH' [RFC4835]. IPv6 nodes implementing IPsec MUST conform to the requirements in [RFC4835]. 10.3. Key Management Methods An implementation MUST support the manual configuration of the security key and SPI. The SPI configuration is needed in order to delineate between multiple keys. Where key refresh, anti-replay features of AH and ESP, or on-demand creation of Security Associations (SAs) is required, IKEv2 keying MUST be supported. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From kent@bbn.com Tue Jul 20 18:04:02 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E008F3A6A85; Tue, 20 Jul 2010 18:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVtm0zbVpO4c; Tue, 20 Jul 2010 18:04:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id E259C3A6A84; Tue, 20 Jul 2010 18:04:01 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38710 helo=[10.84.131.109]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ObNjN-000IOT-Bz; Tue, 20 Jul 2010 21:04:17 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 20 Jul 2010 21:03:08 -0400 To: Sam Hartman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Margaret Wasserman , PaddyNallur , saag@ietf.org, Dong Zhang , secdir@ietf.org Subject: Re: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 01:04:03 -0000 Sam, Based on a quick reading, I am troubled by many aspects of this proposal. CGAs were intended to afford privacy for IPv6 users, while allowing a first-hop router to verify the binding between the host asserting the address and the address in question. The proposal to use CGAs in ACLs seems to negate the privacy feature, because it would (I assume) call for the CGAs to be static (for ease of ACL management). The proposal says that "any host along the path" can engage in an exchange to cause the subject host to verify itself as the "owner" of the address. this is a very big deviation from the much more limited, local SeND context. The proposal also calls for the sender to generate the signature on the payload of the packet, ala IPsec in Transport mode. The document cites RFC 3971 (the SeND) spec, which calls for sig generation is a very different context, i.e., NDP packets in the SeND exchange. This proposal includes an example (from the wireless context) suggesting that the sig is to be generated for every packet sent by a host, a requirement that would place a substantial burden on a host. IPsec rejected solutions of this sort for performance reasons. Conversely, if only an initial packet exchange, involves the signed packet from the host, the secruity offered is much lower, making it vulnerable to MITM attacks. Also note that SeND requires a trust anchor to be shared between the host and its local router. This is a reasonable assumption for that local context, but it less viable in a more general source/destination context that may extend outside a local space, as many of the offered examples do. Steve From kivinen@iki.fi Wed Jul 21 04:40:36 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6DE83A688B; Wed, 21 Jul 2010 04:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwZbJCZsNyiu; Wed, 21 Jul 2010 04:40:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 43B193A6823; Wed, 21 Jul 2010 04:40:34 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o6LBdhPq020547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jul 2010 14:39:43 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o6LBdgB0019023; Wed, 21 Jul 2010 14:39:42 +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: <19526.56446.871198.214543@fireball.kivinen.iki.fi> Date: Wed, 21 Jul 2010 14:39:42 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 11 min Cc: tom_klieber@cable.comcast.com, richard_woundy@cable.comcast.com, chris_bastian@cable.comcast.com, jason_livingood@cable.comcast.com, jim_mills@cable.comcast.com Subject: [secdir] Review of draft-livingood-woundy-congestion-mgmt-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 11:40:36 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes the congestion management system used by the comcast. As such it does not describe any specific protocol, just the architecture and management algorithms to manage congestion. The security considerations section says ---------------------------------------------------------------------- 12. Security Considerations It is important that an ISP secure access to the Congestion Management Servers and the QoS Servers, as well as QoS signaling to the CMTSes, so that unauthorized users and/or hosts cannot make unauthorized changes to QoS settings in the network. It is also important to secure access to the Statistics Collection Server since this contains ISP-proprietary traffic data. ---------------------------------------------------------------------- and as such it seems to list the most obvious security threats i.e. the actual protocols run between the different nodes and that those protocols needs to be secured, altought I would not consider protecting the ISP-proprietary traffic data as the most important reason why statistics collection server access needs to be secured. The privacy issues (i.e from that statistics data it might be possible to find out who is making connections to where) and ability to protect against feeding false statistics information is more important than protecting ISP-proprietary traffic data. There is no description what happens to the statistics data after the inspection interval, i.e. whether it is stored for long time or whether it is immediately deleted. Getting access to statistics data later might allow all kind of traffic analysis etc and the document does not describe on what granularity the actual statistics are collected so the traffic analysis done afterwards might offer quite lot information. It should be enough to collect only per "cable modem" statistics, i.e. remove actual TCP flow or connection information from the statistics (not sure if that is done or not), and for the congestion management reasons it should be enough to keep only the last n minutes worth of statistics. -- kivinen@iki.fi From julienl@qualcomm.com Wed Jul 21 10:35:54 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23A03A68D6; Wed, 21 Jul 2010 10:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5HnR0O+JAyf; Wed, 21 Jul 2010 10:35:45 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id A5AAA3A68ED; Wed, 21 Jul 2010 10:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1279733754; x=1311269754; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Stephen=20Kent=20,=20Sam=20Hartman =20|CC:=20Margaret=20Wasserman=20< mrw@painless-security.com>,=20PaddyNallur=0D=0A=09,=20"saag@ietf.org"=20, =20Dong=20Zhang=0D=0A=09,=20"sec dir@ietf.org"=20|Date:=20Wed,=2021=20Jul =202010=2010:35:46=20-0700|Subject:=20RE:=20[secdir]=20In terest=20in=20draft-dong-savi-cga-header-03.txt=3B=0D=0A =20possibility=20of=20a=20five=20minute=20slot=20at=20saa g?|Thread-Topic:=20[secdir]=20Interest=20in=20draft-dong- savi-cga-header-03.txt=3B=0D=0A=20possibility=20of=20a=20 five=20minute=20slot=20at=20saag?|Thread-Index:=20AcsocKd 4SicpdHDxRZSxcRwNZ8KtsAAh9UJQ|Message-ID:=20|References:=20=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=sNroSeXZZPj87GvocXDIH8NuKhzKFwnWSUAUuWvFGsg=; b=gE9unjDT4f28lp4K6nM5uf8rE88jfuphlXr45XlllB14tw/bfmB6q67c CKLCq8xQNxqng0s89M2Ie6UNkRudSFQr0wrBD2tvylwBAfy/ImB4xAJzF xo1hUXpyJR4XDYf2RirqopYCwM3CU2EwruRmhJskSbZscEJ2JT6+8JaCR M=; X-IronPort-AV: E=McAfee;i="5400,1158,6050"; a="48184217" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine01.qualcomm.com with ESMTP; 21 Jul 2010 10:35:46 -0700 X-IronPort-AV: E=Sophos;i="4.55,238,1278313200"; d="scan'208";a="45262700" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 21 Jul 2010 10:35:46 -0700 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 21 Jul 2010 10:35:47 -0700 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.694.0; Wed, 21 Jul 2010 10:35:48 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Wed, 21 Jul 2010 10:35:47 -0700 From: "Laganier, Julien" To: Stephen Kent , Sam Hartman Date: Wed, 21 Jul 2010 10:35:46 -0700 Thread-Topic: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? Thread-Index: AcsocKd4SicpdHDxRZSxcRwNZ8KtsAAh9UJQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Margaret Wasserman , PaddyNallur , "saag@ietf.org" , Dong Zhang , "secdir@ietf.org" Subject: Re: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 17:35:55 -0000 Steve, Stephen Kent wrote: >=20 > Sam, >=20 > Based on a quick reading, I am troubled by many aspects of this > proposal. >=20 > CGAs were intended to afford privacy for IPv6 users, while allowing a > first-hop router to verify the binding between the host asserting the > address and the address in question. My recollection is that a form of CGA were first proposed to secure the bin= ding between a host asserting that a Mobile IPv6 home address is reachable = at a care-of address (via a MIPv6 Binding Update) and the home address in q= uestion. >From my perspective the key intent behind the use CGA's was the ability to = verify the binding without recourse to an infrastructure, not privacy. I also don't see how the use of CGA's would afford to an IPv6 user any bett= er privacy than another IPv6 address given that it is uniquely bound to a l= ong (1024+ bits) public key. =20 > The proposal to use CGAs in ACLs seems to negate the privacy feature, > because it would (I assume) call for the CGAs to be static (for ease > of ACL management). I agree that if CGAs were to be used in ACLs they would need to be static (= or long-term), but this does not negate a privacy feature that CGA's do not= have. =20 > The proposal says that "any host along the path" can engage in an > exchange to cause the subject host to verify itself as the "owner" of > the address. this is a very big deviation from the much more limited, > local SeND context. As above, CGA use is not limited to a local context such as SEND. In partic= ular, the use of CGA's for Mobile IPv6 security is in a _global_ context. =20 > The proposal also calls for the sender to generate the signature on > the payload of the packet, ala IPsec in Transport mode. The document > cites RFC 3971 (the SeND) spec, which calls for sig generation is a > very different context, i.e., NDP packets in the SeND exchange. >=20 > This proposal includes an example (from the wireless context) > suggesting that the sig is to be generated for every packet sent by a > host, a requirement that would place a substantial burden on a host. > IPsec rejected solutions of this sort for performance reasons. If there were to be only one intermediary on-path node going to verify that= the packets were generated by the CGA owner, it would be possible to execu= te a key exchange protocol bound to the CGAs of the sending host and the ve= rifying node, and use symmetric keying material derived from that exchange = to afford integrity protection to every packet at a cost comparable to that= of IPsec providing integrity protection. =20 > Conversely, if only an initial packet exchange, involves the signed > packet from the host, the secruity offered is much lower, making it > vulnerable to MITM attacks. As above, an initial packet exchange could be used to derive symmetric keys= bound to the CGA's of the parties involved. =20 > Also note that SeND requires a trust anchor to be shared between the > host and its local router. This is a reasonable assumption for that > local context, but it less viable in a more general source/destination > context that may extend outside a local space, as many of the offered > examples do. The SEND trust anchor is used by hosts to verify a router certificates chai= n. The router public key being certified is used to sign the router adverti= sement messages of the router discovery function of ND.=20 In contrast, hosts uses uncertified public keys that are used to generate C= GA's and sign neighbor solicitations and advertisement messages of the addr= ess resolution function of ND. =20 Thus the SEND requirement of hosts and router sharing a trust anchor is ent= irely orthogonal to the use and generation of CGA's. --julien From kent@bbn.com Thu Jul 22 04:15:38 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89F6B3A6A90; Thu, 22 Jul 2010 04:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3y5z9K81alK; Thu, 22 Jul 2010 04:15:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id DBA8A3A6828; Thu, 22 Jul 2010 04:15:36 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55735 helo=[192.168.9.234]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ObtkO-0005ZX-6d; Thu, 22 Jul 2010 07:15:28 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 21 Jul 2010 20:45:49 -0400 To: "Laganier, Julien" From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-932325169==_ma============" Cc: Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 11:15:38 -0000 --============_-932325169==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:35 AM -0700 7/21/10, Laganier, Julien wrote: >Steve, > >Stephen Kent wrote: >> >> Sam, >> >> Based on a quick reading, I am troubled by many aspects of this >> proposal. >> >> CGAs were intended to afford privacy for IPv6 users, while allowing a >> first-hop router to verify the binding between the host asserting the >> address and the address in question. > >My recollection is that a form of CGA were first proposed to secure >the binding between a host asserting that a Mobile IPv6 home address >is reachable at a care-of address (via a MIPv6 Binding Update) and >the home address in question. Section 7.3 of RFC 3792 (the original CGA RFC) says: 7.3. Privacy Considerations CGAs can give the same level of pseudonymity as the IPv6 address privacy extensions defined in RFC 3041 [RFC3041]. An IP host can generate multiple pseudo-random CGAs by executing the CGA generation algorithm of Section 4 multiple times and by using a different random or pseudo-random initial value for the modifier every time. The host should change its address periodically as in [RFC3041]. When privacy protection is needed, the (pseudo)random number generator used in address generation SHOULD be strong enough to produce unpredictable and unlinkable values. Advice on random number generation can be found in [RFC1750]. This text motivates my characterization of the privacy aspects of CGAs, which depends on the ability of a hos to use different CGAs, either serially or in parallel. I think of the CGA mechanism as a way to enable use of varried address by a host, but to also enable a first hop router, to have confidence that an address of this sort (generated in an auto-config fashion) is not being hijacked by another local host. > >From my perspective the key intent behind the use CGA's was the >ability to verify the binding without recourse to an infrastructure, >not privacy. > >I also don't see how the use of CGA's would afford to an IPv6 user >any better privacy than another IPv6 address given that it is >uniquely bound to a long (1024+ bits) public key. I think the text above, and the cited text in RFC 3041 explains the rationale for privacy assertions re CGAs. > >> The proposal to use CGAs in ACLs seems to negate the privacy feature, >> because it would (I assume) call for the CGAs to be static (for ease >> of ACL management). > >I agree that if CGAs were to be used in ACLs they would need to be >static (or long-term), but this does not negate a privacy feature >that CGA's do not have. yes, it does, because the privacy is afforded by the host generating a sequence of CGAs for parallel or serial use is in conflict with use of a static CGA as an address space identifier for access control purposes. > >> The proposal says that "any host along the path" can engage in an >> exchange to cause the subject host to verify itself as the "owner" of >> the address. this is a very big deviation from the much more limited, >> local SeND context. > >As above, CGA use is not limited to a local context such as SEND. In >particular, the use of CGA's for Mobile IPv6 security is in a >_global_ context. I admit that I was not thinking about CGAs in the mobile IP context; RFC 3972 does refer to mobile nodes, but does not say much in that regard. RFC 4581, which updated 3972, never mentions mobile nodes. > > The proposal also calls for the sender to generate the signature on >> the payload of the packet, ala IPsec in Transport mode. The document >> cites RFC 3971 (the SeND) spec, which calls for sig generation is a >> very different context, i.e., NDP packets in the SeND exchange. >> >> This proposal includes an example (from the wireless context) > > suggesting that the sig is to be generated for every packet sent by a >> host, a requirement that would place a substantial burden on a host. >> IPsec rejected solutions of this sort for performance reasons. > >If there were to be only one intermediary on-path node going to >verify that the packets were generated by the CGA owner, it would be >possible to execute a key exchange protocol bound to the CGAs of the >sending host and the verifying node, and use symmetric keying >material derived from that exchange to afford integrity protection >to every packet at a cost comparable to that of IPsec providing >integrity protection. yes, one could do what you suggest above, but that would be duplicating IPsec (ESP-NULL) functionality, which I hope would be frowned upon :-). > > Conversely, if only an initial packet exchange, involves the signed >> packet from the host, the secruity offered is much lower, making it >> vulnerable to MITM attacks. > >As above, an initial packet exchange could be used to derive >symmetric keys bound to the CGA's of the parties involved. and IPsec would be a good idea here too :-). > >> Also note that SeND requires a trust anchor to be shared between the >> host and its local router. This is a reasonable assumption for that >> local context, but it less viable in a more general source/destination >> context that may extend outside a local space, as many of the offered >> examples do. > >The SEND trust anchor is used by hosts to verify a router >certificates chain. The router public key being certified is used to >sign the router advertisement messages of the router discovery >function of ND. > >In contrast, hosts uses uncertified public keys that are used to >generate CGA's and sign neighbor solicitations and advertisement >messages of the address resolution function of ND. > >Thus the SEND requirement of hosts and router sharing a trust anchor >is entirely orthogonal to the use and generation of CGA's. Mostly, but not quite. if a host is challenged to provide a signed sequence of packets by a purported intermediary, how does the host know that the challenge is legitimate, and not just a DoS attack? Steve --============_-932325169==_ma============ Content-Type: text/html; charset="us-ascii" RE: [secdir] Interest in draft-dong-savi-cga-header-03.txt
At 10:35 AM -0700 7/21/10, Laganier, Julien wrote:
Steve,

Stephen Kent wrote:
>
> Sam,
>
> Based on a quick reading, I am troubled by many aspects of this
> proposal.
>
> CGAs were intended to afford privacy for IPv6 users, while allowing a
> first-hop router to verify the binding between the host asserting the
> address and the address in question.

My recollection is that a form of CGA were first proposed to secure the binding between a host asserting that a Mobile IPv6 home address is reachable at a care-of address (via a MIPv6 Binding Update) and the home address in question.

Section 7.3 of RFC 3792 (the original CGA RFC) says:

7.3.  Privacy Considerations

   CGAs can give the same level of pseudonymity as the IPv6 address
   privacy extensions defined in RFC 3041 [RFC3041].  An IP host can
   generate multiple pseudo-random CGAs by executing the CGA generation
   algorithm of Section 4 multiple times and by using a different random
   or pseudo-random initial value for the modifier every time.  The host
   should change its address periodically as in [RFC3041].  When privacy
   protection is needed, the (pseudo)random number generator used in
   address generation SHOULD be strong enough to produce unpredictable
   and unlinkable values.  Advice on random number generation can be
   found in [RFC1750].
This text  motivates my characterization of the privacy aspects of CGAs, which depends on the ability of a hos to use different CGAs, either serially or in parallel.  I think of the CGA mechanism as a way to enable use of varried address by a host, but to also enable a first hop router, to have confidence that an address of this sort (generated in an auto-config fashion) is not being hijacked by another local host.

>From my perspective the key intent behind the use CGA's was the ability to verify the binding without recourse to an infrastructure, not privacy.
I also don't see how the use of CGA's would afford to an IPv6 user any better privacy than another IPv6 address given that it is uniquely bound to a long (1024+ bits) public key.

I think the text above, and the cited text in RFC 3041 explains the rationale for privacy assertions re CGAs.

 
> The proposal to use CGAs in ACLs seems to negate the privacy feature,
> because it would (I assume) call for the CGAs to be static (for ease
> of ACL management).

I agree that if CGAs were to be used in ACLs they would need to be static (or long-term), but this does not negate a privacy feature that CGA's do not have.

yes, it does, because the privacy is afforded by the host generating a sequence of CGAs for parallel or serial use is in conflict with use of a static CGA as an address space identifier for access control purposes.

 
> The proposal says that "any host along the path" can engage in an
> exchange to cause the subject host to verify itself as the "owner" of
> the address. this is a very big deviation from the much more limited,
> local SeND context.

As above, CGA use is not limited to a local context such as SEND. In particular, the use of CGA's for Mobile IPv6 security is in a _global_ context.

I admit that I was not thinking about CGAs in the mobile IP context; RFC 3972 does refer to mobile nodes, but does not say much in that regard. RFC 4581, which updated 3972, never mentions mobile nodes.

 > The proposal also calls for the sender to generate the signature on
> the payload of the packet, ala IPsec in Transport mode.  The document
> cites RFC 3971 (the SeND) spec, which calls for sig generation is a
> very different context, i.e., NDP packets in the SeND exchange.
>
> This proposal includes an example (from the wireless context)
> suggesting that the sig is to be generated for every packet sent by a
> host, a requirement that would place a substantial burden on a host.
> IPsec rejected solutions of this sort for performance reasons.
If there were to be only one intermediary on-path node going to verify that the packets were generated by the CGA owner, it would be possible to execute a key exchange protocol bound to the CGAs of the sending host and the verifying node, and use symmetric keying material derived from that exchange to afford integrity protection to every packet at a cost comparable to that of IPsec providing integrity protection.

yes, one could do what you suggest above, but that would be duplicating IPsec (ESP-NULL) functionality, which I hope would be frowned upon :-).

 > Conversely, if only an initial packet exchange, involves the signed
> packet from the host, the secruity offered is much lower, making it
> vulnerable to MITM attacks.

As above, an initial packet exchange could be used to derive symmetric keys bound to the CGA's of the parties involved.

and IPsec would be a good idea here too :-).

 
> Also note that SeND requires a trust anchor to be shared between the
> host and its local router. This is a reasonable assumption for that
> local context, but it less viable in a more general source/destination
> context that may extend outside a local space, as many of the offered
> examples do.

The SEND trust anchor is used by hosts to verify a router certificates chain. The router public key being certified is used to sign the router advertisement messages of the router discovery function of ND.

In contrast, hosts uses uncertified public keys that are used to generate CGA's and sign neighbor solicitations and advertisement messages of the address resolution function of ND. 
Thus the SEND requirement of hosts and router sharing a trust anchor is entirely orthogonal to the use and generation of CGA's.

Mostly, but not quite. if a host is challenged to provide a signed sequence of packets by a purported intermediary, how does the host know that the challenge is legitimate, and not just a DoS attack?

Steve
--============_-932325169==_ma============-- From secdir-bounces@mit.edu Thu Jul 22 05:37:14 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AAAF3A68B9 for ; Thu, 22 Jul 2010 05:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=-0.314, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMd9ODpFkcqi for ; Thu, 22 Jul 2010 05:37:12 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id DA4693A67EA for ; Thu, 22 Jul 2010 05:37:00 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o6MCbGZW030670 for ; Thu, 22 Jul 2010 08:37:16 -0400 Received: from mailhub-dmz-4.mit.edu (MAILHUB-DMZ-4.MIT.EDU [18.7.62.38]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o6MCbCCQ030657 for ; Thu, 22 Jul 2010 08:37:13 -0400 Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by mailhub-dmz-4.mit.edu (8.13.8/8.9.2) with ESMTP id o6MCb26n031938 for ; Thu, 22 Jul 2010 08:37:12 -0400 X-AuditID: 1209190d-b7c82ae000000a16-a6-4c483b787589 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by dmz-mailsec-scanner-2.mit.edu (Symantec Brightmail Gateway) with SMTP id 79.B6.02582.97B384C4; Thu, 22 Jul 2010 08:37:14 -0400 (EDT) X-IronPort-AV: E=Sophos;i="4.55,243,1278280800"; d="scan'208";a="64270214" Received: from zmbs1.inria.fr ([128.93.142.14]) by mail1-relais-roc.national.inria.fr with ESMTP; 22 Jul 2010 14:37:10 +0200 Date: Thu, 22 Jul 2010 14:36:08 +0200 (CEST) From: Vincent Roca To: Jaehoon Jeong Message-ID: <1655704977.54.1279802168445.JavaMail.root@zmbs1.inria.fr> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [194.199.24.116] X-Mailer: Zimbra 6.0.7_GA_2470.RHEL5_64 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2470.RHEL5_64) X-Brightmail-Tracker: AAAAAhVGFDQVRuR3 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id o6MCbCCQ030657 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Tony Cheneau , secdir@mit.edu, Jari Arkko , IESG , draft-ietf-6man-dns-options-bis all Subject: Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 12:37:14 -0000 Hello Paul, I'm okay with the new text :-) I've just found a typo (section 7, 2nd line): s/secuity/security/ Regards, Vincent ----- Original Message ----- > From: "Jaehoon Jeong" > To: "Vincent Roca" > Cc: "draft-ietf-6man-dns-options-bis all" , secdir@mit.edu, "IESG" > , "6man Chairs" <6man-chairs@tools.ietf.org>, "Jari Arkko"= , "Tony Cheneau" > > Sent: Thursday, July 22, 2010 12:53:38 AM > Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03 > Hi Vincent, > I updated the document according to your guidelines as follows: > - The new ID: > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draf= t-ietf-6man-dns-options-bis-07.txt > = > - Difference between 06-version and 07-version: > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/wdif= f%20draft-ietf-6man-dns-options-bis-06_txt%20draft-ietf-6man-dns-options-bi= s-07_txt.htm > = > Tony Cheneau provided the text about DNS option authorization as > below: > ----------------------------------------------------------------------- > I agree that currently SEND does not provide any mechanism > to indicate if a router can or cannot insert RDNSS and DNSSL options. > However, I think the document draft-ietf-csi-send-cert-05 could help > with that issue. The section 7 of the document describes > Extended Key Usage for the certificate deployed in SEND. > While it currently defines roles for Routers, Routers acting as Proxy > and > Address Owner, I think it could be extended to a new usage > that indicates that the Router was indeed authorized > to insert RDNSS and DNSSL options. > ----------------------------------------------------------------------- > = > I reflected his comments on this update. > = > Could you check whether this update is fine to you or not? > = > If it is fine to you, I will submit it to the IETF repository. > = > Thanks. > = > Best Regards, > Paul > = > = > -----Original Message----- > From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] > Sent: Tuesday, July 20, 2010 5:24 AM > To: Jaehoon Jeong > Cc: draft-ietf-6man-dns-options-bis all; secdir@mit.edu; IESG; 6man > Chairs; Jari Arkko > Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03 > = > Dear authors, > = > First of all, sorry for this late answer. > = > Otherwise I read -06 version and I'm now happy with modifications made > in Section 5.3. > = > Concerning Section 7 "Security Considerations", I still find the > current text confusing (sorry): > = > - there is no clear discussion of what are the additional > threats specific to the proposed RDNSS/DNSSL. > Instead I see a discussion explaining that the situation is > not worse than before because an attacker can launch other > types of attacks on ND. You're right and you can mention this > quickly, but do not limit yourself to such a discussion. > = > - the new text on SEND is much better. However there is no > explicit recommendation (no RECOMMENDED/SHOULD keyword). > How should I understand this? Is it deliberate? Why? > = > = > So I suggest that you add two subsections (with a suggested > structure): > 7.1. Security threats > > > attacks> > 7.2. Recommendations > > > > = > NB: In paragraph discussing filtering on switches: > "is recommended" -> "is RECOMMENDED" > = > NB2: I wouldn't like to give you the feeling that I set myself against > you, this is not my goal. > = > = > Cheers, > = > Vincent > = > = > ----- Original Message ----- > > From: "Jaehoon Jeong" > > To: "Jari Arkko" > > Cc: "Vincent Roca" , > > "draft-ietf-6man-dns-options-bis all" > > , > > secdir@mit.edu, "IESG" , "6man Chairs" > > <6man-chairs@tools.ietf.org> > > Sent: Tuesday, July 6, 2010 4:37:06 PM > > Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03 > > Hi Jari, > > Is this update fine to you along with Section 5.3.2 (Warnings for > > DNS > > Options Configuration)? > > > > The difference between 05-version and 06-version is located at: > > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/w > > diff%20draft-ietf-6man-dns-options-bis-05_txt%20draft-ietf-6man-dns-op > > tions-bis-06_txt.htm > > > > If so, I will submit the version 06-ID today. > > > > Thanks. > > > > Best Regards, > > Paul > > > > -----Original Message----- > > From: Jaehoon Jeong [mailto:pjeong@Brocade.com] > > Sent: Saturday, July 03, 2010 12:33 PM > > To: Vincent Roca > > Cc: Jari Arkko; draft-ietf-6man-dns-options-bis.all@tools.ietf.org; > > secdir@mit.edu; IESG; 6man Chairs > > Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03 > > > > Hi Vincent, > > I would like to address your comments as below. > > > > The updated I-D is located in the following link: > > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/d > > raft-ietf-6man-dns-options-bis-06.txt > > > > On Sat, Jul 3, 2010 at 11:31 AM, Jaehoon Jeong > > wrote: > > > > > > > > > -----Original Message----- > > > From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] > > > Sent: Saturday, July 03, 2010 8:04 AM > > > To: Jaehoon Jeong > > > Cc: Jari Arkko; > > > draft-ietf-6man-dns-options-bis.all@tools.ietf.org; > > > secdir@mit.edu; IESG; 6man Chairs; vincent.roca@inrialpes.fr > > > Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03 > > > > > > Dear authors, > > > > > > Thanks for your prompt reply. A few additional comments (it's my > > > role > > > ;-)) > > > > > > ** new "Security Considerations" section says: > > >> =A0 =A0This attack > > >> =A0 =A0is similar to Neighbor Discovery attacks that use Redirect or > > >> =A0 =A0Neighbor Advertisement messages to redirect traffic to > > >> =A0 =A0individual > > >> =A0 =A0addresses to malicious parties. In general, the attacks > > >> =A0 =A0related > > >> =A0 =A0to > > >> =A0 =A0RDNSS and DNSSL are similar to both Neighbor Discovery attacks > > >> =A0 =A0and > > >> =A0 =A0attacks against unauthenticated DHCP, as both can be used for > > >> =A0 =A0both > > >> =A0 =A0"wholesale" traffic redirection and more specific attacks. > > >> > > > You're right, other attacks are possible that lead to the same > > > result. ND and unauthenticated DHCP are such possibilities. > > > However, > > > IMHO this is not a sufficient reason not to RECOMMEND a security > > > solution for RA. > > > Indeed, if ND / DHCP are made robust but nothing is done for RA, > > > then the threat remains. > > > > > > So the updated text does not fully satisfies me, even if the new > > > paragraph is more clear than the old one. > > > > I reorganize the text such that the description for SEND (as a > > security solution for RA) follows the above paragraph: > > ... > > In general, the attacks related to RDNSS and DNSSL are similar to > > both > > Neighbor Discovery attacks and attacks against unauthenticated DHCP, > > as both can be used for both "wholesale" traffic redirection and > > more > > specific attacks. > > > > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used > > as > > a security mechanism for ND, all the ND options including the RDNSS > > and DNSSL options are automatically included in the signatures, so > > the > > transport for the RA options is integrity-protected; that is, SEND > > can > > prevent the spoofing of these DNS options with signatures. > > Also, SEND enables an IPv6 host to verify that the sender of an RA > > is > > actually a router authorized to act as a router. However, since any > > valid SEND router can still insert RDNSS and DNSSL options, SEND > > cannot verify which one is or is not authorized to send the options. > > > > > > > >>> ** Section 7: > > >>> Another point... the authors explain than network devices like > > >>> switches can be configured in such a way to disable ND/DHCP from > > >>> some ports. That's great and I agree it helps preventing > > >>> attacks. > > >>> However this is limited to wired networks. Nothing is said > > >>> concerning ND configurations in wireless networks. The situation > > >>> is rather different since any host can issue ND/DHCP traffic as > > >>> if > > >>> it were a legitimate server if I understand correctly. The > > >>> document MUST include this kind of discussion. > > >>> > > >>> > > >> But this is generic issue with spoofing RAs and I am not sure it > > >> is > > >> the task of this document to specify the solutions. One solution > > >> exists in SEND (RFC 3791). > > >> > > > Once again I agree. You don't have to specify technical solutions. > > > However you need to provide a good security analysis, perhaps > > > inherited from that of the base RA document for the generic RA > > > threats, with some text describing the additional threats added by > > > the proposed extensions. And since security solutions exist > > > elsewhere (SEND), you should recommend their use. That's your > > > responsibility. > > > > In the following paragraph, we address that SEND can prevent such RA > > DNS option spoofing: > > > > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used > > as > > a security mechanism for ND, all the ND options including the RDNSS > > and DNSSL options are automatically included in the signatures, so > > the > > transport for the RA options is integrity-protected; that is, SEND > > can > > prevent the spoofing of these DNS options with signatures. > > Also, SEND enables an IPv6 host to verify that the sender of an RA > > is > > actually a router authorized to act as a router. However, since any > > valid SEND router can still insert RDNSS and DNSSL options, SEND > > cannot verify which one is or is not authorized to send the options. > > > > > > > >>> ** Section 7: > > >>> Yet another remark: SEND is listed as one potential solution to > > >>> add signatures in ND packets issued from servers. > > >>> I don't know SEND at all, so may be my remarks are flawed (but > > >>> in > > >>> that case the text should be at least clarified). > > >>> - Shouldn't the use of SEND be RECOMMENDED as a solution to > > >>> mitigate attacks? Current document is not clear. > > >>> - Does SEND enable an authentication of the sender (the document > > >>> only mentions integrity protection)? If there's no sender > > >>> authentication, then I agree that the added value of SEND would > > >>> be > > >>> limited. I'd like the authors to clarify this as well. > > >>> > > >>> > > >> The details are in RFC 3791 and its companion documents. SEND > > >> does > > >> enable a host to verify that the sender of an RA is actually a > > >> router > > >> authorized to act as a router. > > >> > > > > > > The text in your proposed I-D update does not reflect this. Can > > > you > > > add it? Being able to authenticate the sender is as important as > > > being able to check the packet integrity. > > > > According to the comments, the checking for valid router is > > mentioned > > in the middle: > > > > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used > > as > > a security mechanism for ND, all the ND options including the RDNSS > > and DNSSL options are automatically included in the signatures, so > > the transport for the RA options is integrity-protected; that is, > > SEND can prevent the spoofing of these DNS options with signatures. > > Also, SEND enables an IPv6 host to verify that the sender of an RA > > is > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > actually a router authorized to act as a router. However, since any > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > valid SEND router can still insert RDNSS and DNSSL options, SEND > > cannot verify which one is or is not authorized to send the options. > > > > > > > > ** I'm coming back to a comment I made earlier and that has not > > > been > > > answered. > > > > > > In the updated I-D, section 5.3.1, I read: > > > > > > =A0"In the case where the DNS options of RDNSS and DNSSL can be > > > =A0obtained > > > =A0 from multiple sources, such as RA and DHCP, the IPv6 host SHOULD > > > =A0 keep > > > =A0 some DNS options from all sources. " > > > > > > I don't see (but I read very quickly so I may have missed > > > something) that secured RA/RDNSS/DNSSL messages be preferred in > > > the > > > choice. If some RA use SEND, they must be preferred over others. > > > > > > > In Section 5.3.1, the considerations on SEND is mentioned as > > follows: > > > > In the case where the DNS options of RDNSS and DNSSL can be obtained > > from multiple sources, such as RA and DHCP, the IPv6 host SHOULD > > keep > > some DNS options from all sources. Unless explicitly specified for > > the discovery mechanism, the exact number of addresses and domain > > names to keep is a matter of local policy and implementation choice. > > However, it is RECOMMENDED that at least three RDNSS addresses (or > > DNSSL domain names) can be stored from at least two different > > sources. The DNS options from Router Advertisements and DHCP SHOULD > > be stored into DNS Repository and Resolver Repository so that > > information from DHCP appears there first and therefore takes > > precedence. Thus, the DNS information from DHCP takes precedence > > over that from RA for DNS queries. On the other hand, for DNS > > ^^^^^^^^^^^^^^^^^^^^^^^^^ > > options announced by RA, if some RAs use the Secure Neighbor > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Discovery (SEND) protocol [RFC3971] for RA security, they MUST be > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > preferred over those which do not use SEND. Refer to Section 7 for > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > the detailed discussion on SEND for RA DNS options. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > I hope my comments are useful. > > > Cheers, > > > > > > =A0 =A0Vincent > > > > > > > Thanks for your efforts on the improvement for this document. > > > > Best Regards, > > Paul _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From secdir-bounces@mit.edu Wed Jul 21 15:53:44 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B166E3A6863 for ; Wed, 21 Jul 2010 15:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.181 X-Spam-Level: X-Spam-Status: No, score=-5.181 tagged_above=-999 required=5 tests=[AWL=1.418, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GNwaHCOaA2Y for ; Wed, 21 Jul 2010 15:53:43 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id DDE0B3A659C for ; Wed, 21 Jul 2010 15:53:40 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o6LMrvcF024638 for ; Wed, 21 Jul 2010 18:53:57 -0400 Received: from mailhub-dmz-2.mit.edu (MAILHUB-DMZ-2.MIT.EDU [18.7.62.37]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o6LMrrTG024635 for ; Wed, 21 Jul 2010 18:53:53 -0400 Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by mailhub-dmz-2.mit.edu (8.13.8/8.9.2) with ESMTP id o6LMqqSN002838 for ; Wed, 21 Jul 2010 18:53:53 -0400 X-AuditID: 12074424-b7c35ae000000a07-c1-4c477a811198 Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id DD.77.02567.18A774C4; Wed, 21 Jul 2010 18:53:54 -0400 (EDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o6LMjeao025305; Wed, 21 Jul 2010 15:53:44 -0700 Received: from brm-exedge.brocade.com (brm-exedge.brocade.com [144.49.197.8]) by mx0a-000f0801.pphosted.com with ESMTP id q68up01n8-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 21 Jul 2010 15:53:43 -0700 Received: from brm-excashub-2.corp.brocade.com (172.16.72.231) by BRM-EXEDGE-2.corp.brocade.com (172.16.72.249) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 21 Jul 2010 16:53:33 -0600 Received: from brm-exch-3.corp.brocade.com ([169.254.2.126]) by brm-excashub-2.corp.brocade.com ([172.16.72.231]) with mapi; Wed, 21 Jul 2010 16:53:42 -0600 From: Jaehoon Jeong To: Vincent Roca Date: Wed, 21 Jul 2010 16:53:38 -0600 Thread-Topic: SecDir review of draft-ietf-6man-dns-options-bis-03 Thread-Index: Acsn9d/mING62nGjQsKl2TpbxLkM1ABMIEfw Message-ID: References: <5A6980BCAE9E6D438D4D8A05540F6FB70115649BE6@BRM-EXCH-3.corp.brocade.com> <2060945452.10380.1279621468787.JavaMail.root@zmbs1.inria.fr> In-Reply-To: <2060945452.10380.1279621468787.JavaMail.root@zmbs1.inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-21_09:2010-07-21, 2010-07-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1007210102 X-Brightmail-Tracker: AAAAAhVGFDQVRuR3 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id o6LMrrTG024635 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Thu, 22 Jul 2010 06:47:38 -0700 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Tony Cheneau , "secdir@mit.edu" , Jari Arkko , IESG , draft-ietf-6man-dns-options-bis all Subject: Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 22:53:44 -0000 Hi Vincent, I updated the document according to your guidelines as follows: - The new ID: http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-= ietf-6man-dns-options-bis-07.txt - Difference between 06-version and 07-version: http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/wdiff%= 20draft-ietf-6man-dns-options-bis-06_txt%20draft-ietf-6man-dns-options-bis-= 07_txt.htm Tony Cheneau provided the text about DNS option authorization as below: ----------------------------------------------------------------------- I agree that currently SEND does not provide any mechanism = to indicate if a router can or cannot insert RDNSS and DNSSL options. = However, I think the document draft-ietf-csi-send-cert-05 could help = with that issue. The section 7 of the document describes = Extended Key Usage for the certificate deployed in SEND. = While it currently defines roles for Routers, Routers acting as Proxy and = Address Owner, I think it could be extended to a new usage = that indicates that the Router was indeed authorized = to insert RDNSS and DNSSL options. ----------------------------------------------------------------------- I reflected his comments on this update. Could you check whether this update is fine to you or not? If it is fine to you, I will submit it to the IETF repository. Thanks. Best Regards, Paul -----Original Message----- From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] = Sent: Tuesday, July 20, 2010 5:24 AM To: Jaehoon Jeong Cc: draft-ietf-6man-dns-options-bis all; secdir@mit.edu; IESG; 6man Chairs;= Jari Arkko Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03 Dear authors, First of all, sorry for this late answer. Otherwise I read -06 version and I'm now happy with modifications made in S= ection 5.3. Concerning Section 7 "Security Considerations", I still find the current te= xt confusing (sorry): - there is no clear discussion of what are the additional =A0=A0threats specific to the proposed RDNSS/DNSSL. = =A0=A0Instead I see a discussion explaining that the situation is =A0=A0not worse than before because an attacker can launch other =A0=A0types of attacks on ND. You're right and you can mention this =A0=A0quickly, but do not limit yourself to such a discussion. - the new text on SEND is much better. However there is no =A0=A0explicit recommendation (no RECOMMENDED/SHOULD keyword). =A0=A0How should I understand this? Is it deliberate? Why? So I suggest that you add two subsections (with a suggested structure): =A0=A0 =A07.1. Security threats =A0=A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0 =A0=A0 =A07.2. Recommendations =A0=A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0 NB: In paragraph discussing filtering on switches: "is recommended" -> "is RECOMMENDED" NB2: I wouldn't like to give you the feeling that I set myself against you,= this is not my goal. Cheers, =A0=A0 Vincent ----- Original Message ----- > From: "Jaehoon Jeong" > To: "Jari Arkko" > Cc: "Vincent Roca" , "draft-ietf-6man-dns-opti= ons-bis all" > , secdir@mit.edu, "IE= SG" , "6man Chairs" > <6man-chairs@tools.ietf.org> > Sent: Tuesday, July 6, 2010 4:37:06 PM > Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03 > Hi Jari, > Is this update fine to you along with Section 5.3.2 (Warnings for DNS = > Options Configuration)? > = > The difference between 05-version and 06-version is located at: > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/w > diff%20draft-ietf-6man-dns-options-bis-05_txt%20draft-ietf-6man-dns-op > tions-bis-06_txt.htm > = > If so, I will submit the version 06-ID today. > = > Thanks. > = > Best Regards, > Paul > = > -----Original Message----- > From: Jaehoon Jeong [mailto:pjeong@Brocade.com] > Sent: Saturday, July 03, 2010 12:33 PM > To: Vincent Roca > Cc: Jari Arkko; draft-ietf-6man-dns-options-bis.all@tools.ietf.org; > secdir@mit.edu; IESG; 6man Chairs > Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03 > = > Hi Vincent, > I would like to address your comments as below. > = > The updated I-D is located in the following link: > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/d > raft-ietf-6man-dns-options-bis-06.txt > = > On Sat, Jul 3, 2010 at 11:31 AM, Jaehoon Jeong > wrote: > > > > > > -----Original Message----- > > From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] > > Sent: Saturday, July 03, 2010 8:04 AM > > To: Jaehoon Jeong > > Cc: Jari Arkko; draft-ietf-6man-dns-options-bis.all@tools.ietf.org; > > secdir@mit.edu; IESG; 6man Chairs; vincent.roca@inrialpes.fr > > Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03 > > > > Dear authors, > > > > Thanks for your prompt reply. A few additional comments (it's my = > > role > > ;-)) > > > > ** new "Security Considerations" section says: > >> =A0 =A0This attack > >> =A0 =A0is similar to Neighbor Discovery attacks that use Redirect or > >> =A0 =A0Neighbor Advertisement messages to redirect traffic to > >> =A0 =A0individual > >> =A0 =A0addresses to malicious parties. In general, the attacks related > >> =A0 =A0to > >> =A0 =A0RDNSS and DNSSL are similar to both Neighbor Discovery attacks > >> =A0 =A0and > >> =A0 =A0attacks against unauthenticated DHCP, as both can be used for > >> =A0 =A0both > >> =A0 =A0"wholesale" traffic redirection and more specific attacks. > >> > > You're right, other attacks are possible that lead to the same = > > result. ND and unauthenticated DHCP are such possibilities. However, = > > IMHO this is not a sufficient reason not to RECOMMEND a security = > > solution for RA. > > Indeed, if ND / DHCP are made robust but nothing is done for RA, = > > then the threat remains. > > > > So the updated text does not fully satisfies me, even if the new = > > paragraph is more clear than the old one. > = > I reorganize the text such that the description for SEND (as a = > security solution for RA) follows the above paragraph: > ... > In general, the attacks related to RDNSS and DNSSL are similar to both = > Neighbor Discovery attacks and attacks against unauthenticated DHCP, = > as both can be used for both "wholesale" traffic redirection and more = > specific attacks. > = > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as = > a security mechanism for ND, all the ND options including the RDNSS = > and DNSSL options are automatically included in the signatures, so the = > transport for the RA options is integrity-protected; that is, SEND can = > prevent the spoofing of these DNS options with signatures. > Also, SEND enables an IPv6 host to verify that the sender of an RA is = > actually a router authorized to act as a router. However, since any = > valid SEND router can still insert RDNSS and DNSSL options, SEND = > cannot verify which one is or is not authorized to send the options. > = > > > >>> ** Section 7: > >>> Another point... the authors explain than network devices like = > >>> switches can be configured in such a way to disable ND/DHCP from = > >>> some ports. That's great and I agree it helps preventing attacks. > >>> However this is limited to wired networks. Nothing is said = > >>> concerning ND configurations in wireless networks. The situation = > >>> is rather different since any host can issue ND/DHCP traffic as if = > >>> it were a legitimate server if I understand correctly. The = > >>> document MUST include this kind of discussion. > >>> > >>> > >> But this is generic issue with spoofing RAs and I am not sure it is = > >> the task of this document to specify the solutions. One solution = > >> exists in SEND (RFC 3791). > >> > > Once again I agree. You don't have to specify technical solutions. > > However you need to provide a good security analysis, perhaps = > > inherited from that of the base RA document for the generic RA = > > threats, with some text describing the additional threats added by = > > the proposed extensions. And since security solutions exist = > > elsewhere (SEND), you should recommend their use. That's your = > > responsibility. > = > In the following paragraph, we address that SEND can prevent such RA = > DNS option spoofing: > = > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as = > a security mechanism for ND, all the ND options including the RDNSS = > and DNSSL options are automatically included in the signatures, so the = > transport for the RA options is integrity-protected; that is, SEND can = > prevent the spoofing of these DNS options with signatures. > Also, SEND enables an IPv6 host to verify that the sender of an RA is = > actually a router authorized to act as a router. However, since any = > valid SEND router can still insert RDNSS and DNSSL options, SEND = > cannot verify which one is or is not authorized to send the options. > = > > > >>> ** Section 7: > >>> Yet another remark: SEND is listed as one potential solution to = > >>> add signatures in ND packets issued from servers. > >>> I don't know SEND at all, so may be my remarks are flawed (but in = > >>> that case the text should be at least clarified). > >>> - Shouldn't the use of SEND be RECOMMENDED as a solution to = > >>> mitigate attacks? Current document is not clear. > >>> - Does SEND enable an authentication of the sender (the document = > >>> only mentions integrity protection)? If there's no sender = > >>> authentication, then I agree that the added value of SEND would be = > >>> limited. I'd like the authors to clarify this as well. > >>> > >>> > >> The details are in RFC 3791 and its companion documents. SEND does > >> enable a host to verify that the sender of an RA is actually a > >> router > >> authorized to act as a router. > >> > > > > The text in your proposed I-D update does not reflect this. Can you > > add it? Being able to authenticate the sender is as important as > > being able to check the packet integrity. > = > According to the comments, the checking for valid router is mentioned > in the middle: > = > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as > a security mechanism for ND, all the ND options including the RDNSS > and DNSSL options are automatically included in the signatures, so > the transport for the RA options is integrity-protected; that is, > SEND can prevent the spoofing of these DNS options with signatures. > Also, SEND enables an IPv6 host to verify that the sender of an RA is > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > actually a router authorized to act as a router. However, since any > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > valid SEND router can still insert RDNSS and DNSSL options, SEND > cannot verify which one is or is not authorized to send the options. > = > > > > ** I'm coming back to a comment I made earlier and that has not been > > answered. > > > > In the updated I-D, section 5.3.1, I read: > > > > =A0"In the case where the DNS options of RDNSS and DNSSL can be > > =A0obtained > > =A0 from multiple sources, such as RA and DHCP, the IPv6 host SHOULD > > =A0 keep > > =A0 some DNS options from all sources. " > > > > I don't see (but I read very quickly so I may have missed > > something) that secured RA/RDNSS/DNSSL messages be preferred in the > > choice. If some RA use SEND, they must be preferred over others. > > > = > In Section 5.3.1, the considerations on SEND is mentioned as follows: > = > In the case where the DNS options of RDNSS and DNSSL can be obtained > from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep > some DNS options from all sources. Unless explicitly specified for > the discovery mechanism, the exact number of addresses and domain > names to keep is a matter of local policy and implementation choice. > However, it is RECOMMENDED that at least three RDNSS addresses (or > DNSSL domain names) can be stored from at least two different > sources. The DNS options from Router Advertisements and DHCP SHOULD > be stored into DNS Repository and Resolver Repository so that > information from DHCP appears there first and therefore takes > precedence. Thus, the DNS information from DHCP takes precedence > over that from RA for DNS queries. On the other hand, for DNS > ^^^^^^^^^^^^^^^^^^^^^^^^^ > options announced by RA, if some RAs use the Secure Neighbor > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Discovery (SEND) protocol [RFC3971] for RA security, they MUST be > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > preferred over those which do not use SEND. Refer to Section 7 for > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the detailed discussion on SEND for RA DNS options. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > = > > I hope my comments are useful. > > Cheers, > > > > =A0 =A0Vincent > > > = > Thanks for your efforts on the improvement for this document. > = > Best Regards, > Paul _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From margaretw42@gmail.com Thu Jul 22 05:50:39 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72C63A6835; Thu, 22 Jul 2010 05:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BT43vhY3qtdZ; Thu, 22 Jul 2010 05:50:38 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id DFF053A67B8; Thu, 22 Jul 2010 05:50:37 -0700 (PDT) Received: by qwe5 with SMTP id 5so3229076qwe.31 for ; Thu, 22 Jul 2010 05:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=4FJn+5kUVVjkXsZvPqF9SncU6OX6irUvr0Fx5Tw1J48=; b=NS5vHE5xadbj9XGGigQkwILxujitxFul5TDmbOSWZWKD5drJi/ppJlcD8dLJ8/TlXF kMsstSyY5gRdGWXnozauxWG/2Phd6EiFNJAt5NapYkDNy9XE9z1a1a5xaKmDEbZyZoOI Zkc3lQCvse6/ImKKLBgtACEgM1p8El4ECH+zk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=KCFg3KF7DsXgfkw0VxkI7zGxBa0BE/KAmRpo0kk/rZ7VfFZhAbK+zQ1wWQHok/tG3k a8RInJ7T7NxE4JydJiBqB6xrYnUNaQjG6zSn+S1xCoVg0YmjxeYBI1ZIiYtz2V2yIEoZ IgyM0BVq59yhZQ43+fxregc1DiSkp4endkoB0= Received: by 10.224.73.102 with SMTP id p38mr1138388qaj.270.1279803054330; Thu, 22 Jul 2010 05:50:54 -0700 (PDT) Received: from [172.17.172.250] ([65.174.54.2]) by mx.google.com with ESMTPS id h20sm30457839qcm.33.2010.07.22.05.50.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Jul 2010 05:50:43 -0700 (PDT) Message-Id: <438B2D37-5C58-4E1F-9E69-75E80D76C570@gmail.com> From: Margaret Wasserman To: Stephen Kent In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Jul 2010 08:50:16 -0400 References: X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Thu, 22 Jul 2010 06:47:38 -0700 Cc: "Laganier, Julien" , Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 12:50:40 -0000 Hi Steve, Thanks for your feedback! On Jul 21, 2010, at 8:45 PM, Stephen Kent wrote: >> >> I agree that if CGAs were to be used in ACLs they would need to be >> static (or long-term), but this does not negate a privacy feature >> that CGA's do not have. > > yes, it does, because the privacy is afforded by the host generating > a sequence of CGAs for parallel or serial use is in conflict with > use of a static CGA as an address space identifier for access > control purposes. There may be an inherent incompatibility between access control and anonymity, but that does not mean that the use of CGAs for access control is mutually exclusive with their use for privacy by the same node. A node could have a CGA (or a set of CGAs) that it uses to access certain resources. Those address(es) could be used in access control lists, etc. However, the same node could still generate CGAs or IPv6 Privacy Addresses for temporary use when anonymity/privacy is desired. I would argue that the use of CGAs for privacy, as you have cited it, is under-specified. There is mention of the concept that hosts could use CGAs for privacy, but there is no explanation of how those addresses would be managed, how long they should live, how application- level programs should request them, etc. IPv6 Privacy Addresses (as defined in RFC 4941) are much better specified for this purpose. >> >> If there were to be only one intermediary on-path node going to >> verify that the packets were generated by the CGA owner, it would >> be possible to execute a key exchange protocol bound to the CGAs of >> the sending host and the verifying node, and use symmetric keying >> material derived from that exchange to afford integrity protection >> to every packet at a cost comparable to that of IPsec providing >> integrity protection. > > yes, one could do what you suggest above, but that would be > duplicating IPsec (ESP-NULL) functionality, which I hope would be > frowned upon :-). There is also a possibility that the use of CGAs and a CGA extension in the early packets of an exchange could be used to set-up an IPsec SA for the remainder of the flow. In cases where a flow will consist of more than a few packets, this would probably be a better approach than signing all of the packets in an exchange. >> > Conversely, if only an initial packet exchange, involves the signed >> > packet from the host, the secruity offered is much lower, making it >> > vulnerable to MITM attacks. >> >> As above, an initial packet exchange could be used to derive >> symmetric keys bound to the CGA's of the parties involved. > > and IPsec would be a good idea here too :-). I agree. :-) > Mostly, but not quite. if a host is challenged to provide a signed > sequence of packets by a purported intermediary, how does the host > know that the challenge is legitimate, and not just a DoS attack? As we discuss in the security considerations section, this is an open issue with the specification. There are some possibilities for how to deal with this issue -- perhaps we could require that the requester generate it's own CGA, sign the request and include an CGA extension header on the request? Or perhaps it would be better for the requester to do some other costly operation to make this attack as expensive for the attacker as it would be for the target? There may be other possibilities for how to address this issue... it is one of the things that we should work out in the IETF before publishing this document. Margaret From secdir-bounces@mit.edu Thu Jul 22 06:37:12 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970D33A6AF5 for ; Thu, 22 Jul 2010 06:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.232 X-Spam-Level: X-Spam-Status: No, score=-5.232 tagged_above=-999 required=5 tests=[AWL=1.367, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kA53Pp1xMhy for ; Thu, 22 Jul 2010 06:37:02 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 1CFFC3A6B36 for ; Thu, 22 Jul 2010 06:36:52 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o6MDb7wX007131 for ; Thu, 22 Jul 2010 09:37:07 -0400 Received: from mailhub-dmz-4.mit.edu (MAILHUB-DMZ-4.MIT.EDU [18.7.62.38]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o6MDb57T007127 for ; Thu, 22 Jul 2010 09:37:05 -0400 Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by mailhub-dmz-4.mit.edu (8.13.8/8.9.2) with ESMTP id o6MDagTs008096 for ; Thu, 22 Jul 2010 09:37:05 -0400 X-AuditID: 1209190f-b7b0aae000000a7d-32-4c4849843a64 Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by dmz-mailsec-scanner-4.mit.edu (Symantec Brightmail Gateway) with SMTP id 89.7B.02685.489484C4; Thu, 22 Jul 2010 09:37:08 -0400 (EDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o6MDYoeJ030316; Thu, 22 Jul 2010 06:36:53 -0700 Received: from brm-exedge.brocade.com (brm-exedge.brocade.com [144.49.197.8]) by mx0a-000f0801.pphosted.com with ESMTP id q68up0ftv-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 22 Jul 2010 06:36:53 -0700 Received: from brm-excashub-2.corp.brocade.com (172.16.72.231) by BRM-EXEDGE-2.corp.brocade.com (172.16.72.249) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 22 Jul 2010 07:36:41 -0600 Received: from brm-exch-3.corp.brocade.com ([169.254.2.126]) by brm-excashub-2.corp.brocade.com ([172.16.72.231]) with mapi; Thu, 22 Jul 2010 07:36:51 -0600 From: Jaehoon Jeong To: Vincent Roca Date: Thu, 22 Jul 2010 07:36:51 -0600 Thread-Topic: SecDir review of draft-ietf-6man-dns-options-bis-03 Thread-Index: Acspn1kO1WEvOs2fSmuBM/Tx2WwXjgAA25GA Message-ID: References: <1655704977.54.1279802168445.JavaMail.root@zmbs1.inria.fr> In-Reply-To: <1655704977.54.1279802168445.JavaMail.root@zmbs1.inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-22_03:2010-07-22, 2010-07-22, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1007220052 X-Brightmail-Tracker: AAAAAhVGFDQVRuR3 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id o6MDb57T007127 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Thu, 22 Jul 2010 06:47:38 -0700 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Tony Cheneau , "secdir@mit.edu" , Jari Arkko , IESG , draft-ietf-6man-dns-options-bis all Subject: Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 13:37:12 -0000 Hi Vincent, After fixing this typo, I will submit the new version. Thanks very much for your contribution. Best Regards, Paul -----Original Message----- From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] Sent: Thursday, July 22, 2010 7:36 AM To: Jaehoon Jeong Cc: draft-ietf-6man-dns-options-bis all; secdir@mit.edu; IESG; 6man Chairs; Jari Arkko; Tony Cheneau Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03 Hello Paul, I'm okay with the new text :-) I've just found a typo (section 7, 2nd line): s/secuity/security/ Regards, Vincent ----- Original Message ----- > From: "Jaehoon Jeong" > To: "Vincent Roca" > Cc: "draft-ietf-6man-dns-options-bis all" , secdir@mit.edu, "IESG" > , "6man Chairs" <6man-chairs@tools.ietf.org>, "Jari Arkko" , "Tony Cheneau" > > Sent: Thursday, July 22, 2010 12:53:38 AM > Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03 > Hi Vincent, > I updated the document according to your guidelines as follows: > - The new ID: > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/d > raft-ietf-6man-dns-options-bis-07.txt > > - Difference between 06-version and 07-version: > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/w > diff%20draft-ietf-6man-dns-options-bis-06_txt%20draft-ietf-6man-dns-op > tions-bis-07_txt.htm > > Tony Cheneau provided the text about DNS option authorization as > below: > ---------------------------------------------------------------------- > - I agree that currently SEND does not provide any mechanism to > indicate if a router can or cannot insert RDNSS and DNSSL options. > However, I think the document draft-ietf-csi-send-cert-05 could help > with that issue. The section 7 of the document describes Extended Key > Usage for the certificate deployed in SEND. > While it currently defines roles for Routers, Routers acting as Proxy > and Address Owner, I think it could be extended to a new usage that > indicates that the Router was indeed authorized to insert RDNSS and > DNSSL options. > ---------------------------------------------------------------------- > - > > I reflected his comments on this update. > > Could you check whether this update is fine to you or not? > > If it is fine to you, I will submit it to the IETF repository. > > Thanks. > > Best Regards, > Paul > > > -----Original Message----- > From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] > Sent: Tuesday, July 20, 2010 5:24 AM > To: Jaehoon Jeong > Cc: draft-ietf-6man-dns-options-bis all; secdir@mit.edu; IESG; 6man > Chairs; Jari Arkko > Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03 > > Dear authors, > > First of all, sorry for this late answer. > > Otherwise I read -06 version and I'm now happy with modifications made > in Section 5.3. > > Concerning Section 7 "Security Considerations", I still find the > current text confusing (sorry): > > - there is no clear discussion of what are the additional threats > specific to the proposed RDNSS/DNSSL. > Instead I see a discussion explaining that the situation is not worse > than before because an attacker can launch other types of attacks on > ND. You're right and you can mention this quickly, but do not limit > yourself to such a discussion. > > - the new text on SEND is much better. However there is no explicit > recommendation (no RECOMMENDED/SHOULD keyword). > How should I understand this? Is it deliberate? Why? > > > So I suggest that you add two subsections (with a suggested > structure): > 7.1. Security threats > > situation is not worse than ND or DHCP > attacks> > 7.2. Recommendations > at the DNS resolver is RECOMMENDED> > > NB: In paragraph discussing filtering on switches: > "is recommended" -> "is RECOMMENDED" > > NB2: I wouldn't like to give you the feeling that I set myself against > you, this is not my goal. > > > Cheers, > > Vincent > > > ----- Original Message ----- > > From: "Jaehoon Jeong" > > To: "Jari Arkko" > > Cc: "Vincent Roca" , > > "draft-ietf-6man-dns-options-bis all" > > , > > secdir@mit.edu, "IESG" , "6man Chairs" > > <6man-chairs@tools.ietf.org> > > Sent: Tuesday, July 6, 2010 4:37:06 PM > > Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03 > > Hi Jari, > > Is this update fine to you along with Section 5.3.2 (Warnings for > > DNS Options Configuration)? > > > > The difference between 05-version and 06-version is located at: > > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft > > /w > > diff%20draft-ietf-6man-dns-options-bis-05_txt%20draft-ietf-6man-dns- > > op > > tions-bis-06_txt.htm > > > > If so, I will submit the version 06-ID today. > > > > Thanks. > > > > Best Regards, > > Paul > > > > -----Original Message----- > > From: Jaehoon Jeong [mailto:pjeong@Brocade.com] > > Sent: Saturday, July 03, 2010 12:33 PM > > To: Vincent Roca > > Cc: Jari Arkko; draft-ietf-6man-dns-options-bis.all@tools.ietf.org; > > secdir@mit.edu; IESG; 6man Chairs > > Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03 > > > > Hi Vincent, > > I would like to address your comments as below. > > > > The updated I-D is located in the following link: > > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft > > /d raft-ietf-6man-dns-options-bis-06.txt > > > > On Sat, Jul 3, 2010 at 11:31 AM, Jaehoon Jeong > > wrote: > > > > > > > > > -----Original Message----- > > > From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] > > > Sent: Saturday, July 03, 2010 8:04 AM > > > To: Jaehoon Jeong > > > Cc: Jari Arkko; > > > draft-ietf-6man-dns-options-bis.all@tools.ietf.org; > > > secdir@mit.edu; IESG; 6man Chairs; vincent.roca@inrialpes.fr > > > Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03 > > > > > > Dear authors, > > > > > > Thanks for your prompt reply. A few additional comments (it's my > > > role > > > ;-)) > > > > > > ** new "Security Considerations" section says: > > >> This attack > > >> is similar to Neighbor Discovery attacks that use Redirect or > > >> Neighbor Advertisement messages to redirect traffic to > > >> individual > > >> addresses to malicious parties. In general, the attacks > > >> related > > >> to > > >> RDNSS and DNSSL are similar to both Neighbor Discovery attacks > > >> and > > >> attacks against unauthenticated DHCP, as both can be used for > > >> both > > >> "wholesale" traffic redirection and more specific attacks. > > >> > > > You're right, other attacks are possible that lead to the same > > > result. ND and unauthenticated DHCP are such possibilities. > > > However, > > > IMHO this is not a sufficient reason not to RECOMMEND a security > > > solution for RA. > > > Indeed, if ND / DHCP are made robust but nothing is done for RA, > > > then the threat remains. > > > > > > So the updated text does not fully satisfies me, even if the new > > > paragraph is more clear than the old one. > > > > I reorganize the text such that the description for SEND (as a > > security solution for RA) follows the above paragraph: > > ... > > In general, the attacks related to RDNSS and DNSSL are similar to > > both Neighbor Discovery attacks and attacks against unauthenticated > > DHCP, as both can be used for both "wholesale" traffic redirection > > and more specific attacks. > > > > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used > > as a security mechanism for ND, all the ND options including the > > RDNSS and DNSSL options are automatically included in the > > signatures, so the transport for the RA options is > > integrity-protected; that is, SEND can prevent the spoofing of these > > DNS options with signatures. > > Also, SEND enables an IPv6 host to verify that the sender of an RA > > is actually a router authorized to act as a router. However, since > > any valid SEND router can still insert RDNSS and DNSSL options, SEND > > cannot verify which one is or is not authorized to send the options. > > > > > > > >>> ** Section 7: > > >>> Another point... the authors explain than network devices like > > >>> switches can be configured in such a way to disable ND/DHCP from > > >>> some ports. That's great and I agree it helps preventing > > >>> attacks. > > >>> However this is limited to wired networks. Nothing is said > > >>> concerning ND configurations in wireless networks. The situation > > >>> is rather different since any host can issue ND/DHCP traffic as > > >>> if it were a legitimate server if I understand correctly. The > > >>> document MUST include this kind of discussion. > > >>> > > >>> > > >> But this is generic issue with spoofing RAs and I am not sure it > > >> is the task of this document to specify the solutions. One > > >> solution exists in SEND (RFC 3791). > > >> > > > Once again I agree. You don't have to specify technical solutions. > > > However you need to provide a good security analysis, perhaps > > > inherited from that of the base RA document for the generic RA > > > threats, with some text describing the additional threats added by > > > the proposed extensions. And since security solutions exist > > > elsewhere (SEND), you should recommend their use. That's your > > > responsibility. > > > > In the following paragraph, we address that SEND can prevent such RA > > DNS option spoofing: > > > > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used > > as a security mechanism for ND, all the ND options including the > > RDNSS and DNSSL options are automatically included in the > > signatures, so the transport for the RA options is > > integrity-protected; that is, SEND can prevent the spoofing of these > > DNS options with signatures. > > Also, SEND enables an IPv6 host to verify that the sender of an RA > > is actually a router authorized to act as a router. However, since > > any valid SEND router can still insert RDNSS and DNSSL options, SEND > > cannot verify which one is or is not authorized to send the options. > > > > > > > >>> ** Section 7: > > >>> Yet another remark: SEND is listed as one potential solution to > > >>> add signatures in ND packets issued from servers. > > >>> I don't know SEND at all, so may be my remarks are flawed (but > > >>> in that case the text should be at least clarified). > > >>> - Shouldn't the use of SEND be RECOMMENDED as a solution to > > >>> mitigate attacks? Current document is not clear. > > >>> - Does SEND enable an authentication of the sender (the document > > >>> only mentions integrity protection)? If there's no sender > > >>> authentication, then I agree that the added value of SEND would > > >>> be limited. I'd like the authors to clarify this as well. > > >>> > > >>> > > >> The details are in RFC 3791 and its companion documents. SEND > > >> does enable a host to verify that the sender of an RA is actually > > >> a router authorized to act as a router. > > >> > > > > > > The text in your proposed I-D update does not reflect this. Can > > > you add it? Being able to authenticate the sender is as important > > > as being able to check the packet integrity. > > > > According to the comments, the checking for valid router is > > mentioned in the middle: > > > > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used > > as a security mechanism for ND, all the ND options including the > > RDNSS and DNSSL options are automatically included in the > > signatures, so the transport for the RA options is > > integrity-protected; that is, SEND can prevent the spoofing of these > > DNS options with signatures. > > Also, SEND enables an IPv6 host to verify that the sender of an RA > > is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > actually a router authorized to act as a router. However, since any > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > valid SEND router can still insert RDNSS and DNSSL options, SEND > > cannot verify which one is or is not authorized to send the options. > > > > > > > > ** I'm coming back to a comment I made earlier and that has not > > > been answered. > > > > > > In the updated I-D, section 5.3.1, I read: > > > > > > "In the case where the DNS options of RDNSS and DNSSL can be > > > obtained > > > from multiple sources, such as RA and DHCP, the IPv6 host SHOULD > > > keep > > > some DNS options from all sources. " > > > > > > I don't see (but I read very quickly so I may have missed > > > something) that secured RA/RDNSS/DNSSL messages be preferred in > > > the choice. If some RA use SEND, they must be preferred over > > > others. > > > > > > > In Section 5.3.1, the considerations on SEND is mentioned as > > follows: > > > > In the case where the DNS options of RDNSS and DNSSL can be obtained > > from multiple sources, such as RA and DHCP, the IPv6 host SHOULD > > keep some DNS options from all sources. Unless explicitly specified > > for the discovery mechanism, the exact number of addresses and > > domain names to keep is a matter of local policy and implementation > > choice. > > However, it is RECOMMENDED that at least three RDNSS addresses (or > > DNSSL domain names) can be stored from at least two different > > sources. The DNS options from Router Advertisements and DHCP SHOULD > > be stored into DNS Repository and Resolver Repository so that > > information from DHCP appears there first and therefore takes > > precedence. Thus, the DNS information from DHCP takes precedence > > over that from RA for DNS queries. On the other hand, for DNS > > ^^^^^^^^^^^^^^^^^^^^^^^^^ options announced by RA, if some RAs use > > the Secure Neighbor > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Discovery (SEND) protocol [RFC3971] for RA security, they MUST be > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > preferred over those which do not use SEND. Refer to Section 7 for > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > the detailed discussion on SEND for RA DNS options. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > I hope my comments are useful. > > > Cheers, > > > > > > Vincent > > > > > > > Thanks for your efforts on the improvement for this document. > > > > Best Regards, > > Paul _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From new-work-bounces@ietf.org Thu Jul 22 08:33:28 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A748A3A6BF3; Thu, 22 Jul 2010 08:33:28 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A2F5D3A6BD2; Thu, 22 Jul 2010 08:33:27 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100722153327.A2F5D3A6BD2@core3.amsl.com> Date: Thu, 22 Jul 2010 08:33:27 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Thu, 22 Jul 2010 12:47:18 -0700 Subject: [secdir] [New-work] WG Review: Recharter of Transparent Interconnection of Lots of Links (trill) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 15:33:28 -0000 A modified charter has been submitted for the Transparent Interconnection of Lots of Links (trill) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Thursday, July 29, 2010. Transparent Interconnection of Lots of Links (trill) ---------------------------------------------------- Current Status: Active Working Group Last updated: 2010-07-22 Chairs: Erik Nordmark Donald Eastlake 3rd Internet Area Directors: Jari Arkko Ralph Droms Internet Area Advisor: Ralph Droms Mailing List: Address: rbridge@postel.org To Subscribe: http://www.postel.org/mailman/listinfo/rbridge Archive: http://www.postel.org/pipermail/rbridge Description of Working Group The TRILL WG has specified a solution for shortest-path frame routing in multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary topologies, using an existing link-state routing protocol technology and encapsulation with a hop count. The current work of the working group is around operational and deployment support for the protocol. This includes a MIB module and other pieces needed for operations, but also additional ways to extend and optimize TRILL for the properties of the networks on which it is deployed. The WG will work on the following items: (1) A MIB module for TRILL which specifies the unique pieces needed for the protocol while reusing what is in the IS-IS MIB module and the IEEE 802.1 MIB modules for pieces that are not unique to TRILL. (2) Addition of optional support for ARP / Neighbor Discovery optimization. (3) Refinement of the TRILL Header Options feature and specification of an initial base set of options. (4) Support for RBridge campus VLAN regions, such that the same VLAN ID can have different meanings in different regions, requiring configuration only at border RBridges. (5) Write up how Operations, Administration, and Maintenance (OAM) will be handled in networks using TRILL. (6) Determine how the support the TRILL protocol provides for data centers can be improved, such as by adding support of the IEEE 802.1 "Data Center Bridging" standards. (7) Document interoperability test results of protocol implementations. Goals and Milestones: Done - Accept base protocol specification as a WG document Done - Accept problem statement and applicability as a WG work item Done - Start work with routing area WG(s) to undertake TRILL extensions Done - Accept architecture document as a WG work item Done - Accept routing protocol requirements as a WG work item Done - Choose routing protocol(s) that can meet the requirements Done - Submit problem statement and applicability to IESG for Informational RFC Done - Submit base protocol specification to IEEE/IETF expert review Done - Base protocol specification submitted to the IESG for publication as a Proposed Standard RFC Done - First draft showing what is needed for a MIB module NEW: Done - Initial WG draft on VLAN Mapping Done - Initial WG draft TRILL Header Options Jul 2010 - Initial WG draft on ARP/ND optimizations Aug 2010 - Initial WG draft on RBridge MIB module Aug 2010 - Submit TRILL Header Options to IESG for publication as Proposed Standard Aug 2010 - Submit RBridge Campus VLAN Regions to IESG for publication as Proposed Standard Oct 2010 - Submit RBridge MIB module to IESG for publication as Proposed Standard Oct 2010 - Submit TRILL ARP/ND optimizations to IESG for publication as Proposed Standard Oct 2010 - Initial WG draft for RBridge support of Data Center Bridging Oct 2010 - Initial WG draft on RBridge OAM Apr 2011 - Submit RBridge support of Data Center Bridging to IESG for publication as Proposed Standard Apr 2011 - Submit RBridge OAM to IESG for publication as Proposed Standard Jul 2011 - Re-charter or shut down the WG _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From margaretw42@gmail.com Thu Jul 22 12:42:57 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54A93A67AC; Thu, 22 Jul 2010 12:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEl4faDQpKiw; Thu, 22 Jul 2010 12:42:56 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id C08153A686C; Thu, 22 Jul 2010 12:42:56 -0700 (PDT) Received: by pzk6 with SMTP id 6so3954184pzk.31 for ; Thu, 22 Jul 2010 12:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date:cc :x-mailer; bh=fQJszsOkhA5nzdLnpAm/ZAJoJudQLPtlgjEp+j7msDc=; b=d8qCx3awc9OYztSpptfe45fCNR9/4Hs84rmQnIzoOCneb2r6aS1vbRIMGE1lrFoFoG Sa95BZLa1oyrCDBrBXq/l5udmKHgHXFxxPCswaP+oKxyV9dQe/75wYF6KcryH9VP7WiQ zN5YHijZEvNewEbk85l4YEv0AFrEDZSDzPPLo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:cc:x-mailer; b=J1m2kB9iiXuE5FGfdCyaSODB79kLmmYYp0XJ6ymKVYgvBZcOx2fX6R0ZXf8p8hZVON oU70W5jfdPQn0/wTbr8/emRGOnElOVwNQwJlJOetxqtqrhqGSI/ju8KMhGxneTon8x8y IlCZ7QLpKN+3mWuk2h1fUh7XbHg8JBwRC5tZM= Received: by 10.114.79.20 with SMTP id c20mr3826959wab.117.1279827794299; Thu, 22 Jul 2010 12:43:14 -0700 (PDT) Received: from [10.2.0.128] (68-248-62-130.ded.ameritech.net [68.248.62.130]) by mx.google.com with ESMTPS id d39sm87807888wam.16.2010.07.22.12.43.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Jul 2010 12:43:12 -0700 (PDT) Message-Id: <413FFD9E-487D-40B2-B4DD-A10F5CD00C85@gmail.com> From: Margaret Wasserman To: Internet Area , saag@ietf.org, secdir@ietf.org, ipdir@ietf.org, savi@ietf.org, csi@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Jul 2010 15:43:09 -0400 X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Thu, 22 Jul 2010 12:47:18 -0700 Cc: PaddyNallur , Dong Zhang Subject: [secdir] New Mailing List: cgasec X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 19:42:57 -0000 Hi All, We've put together a mailing list to discuss the use of Cryptographically Generated Addresses (CGAs) for security purposes across the internet. The list address is cgasec@ietf.org. To subscribe, go to: https://www.ietf.org/mailman/listinfo/cgasec. We have published a draft in this area that can be found here: https://datatracker.ietf.org/doc/draft-dong-savi-cga-header/ Abstract: This document specifies an IPv6 extension header called the Cryptographically Generated Address (CGA) Extension Header. The CGA Extension Header holds the CGA parameters associated with the source CGA of an IPv6 packet. This information can be used to validate that a particular packet was sent by the node associated with a specific CGA, enabling secure IPv6 address-based access control mechanisms. We're planning to hold a Bar BOF (the old fashioned kind, in a bar, with no presentations) in Maastricht to discuss the above draft and other possible work in this area. Please send any feedback on the above document to the cgasec@ietf.org mailing list. Please avoid cross-pointing your feedback to the full to: list on this message, unless you believe that it is pertinent to the hundreds or low thousands of people included on this message. Thank you. We will be holding an old-fashioned Bar BOF in Maastricht (in a bar, no presentations), probably on Thursday night for folks who are interested in working our proposal, or related work in this technical area. Further details about the bar BOF will be announced early next week, after I get to Maastricht and can scope out a location. There has also been some earlier work in this area by Julien Lagnier, but I do not have a current reference. Julien it is not my intention to omit your work from this discussion, so please feel free to send a pointer. Margaret From mcgrew@cisco.com Thu Jul 22 15:58:38 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580F93A6A70 for ; Thu, 22 Jul 2010 15:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.799 X-Spam-Level: X-Spam-Status: No, score=-6.799 tagged_above=-999 required=5 tests=[AWL=-3.800, BAYES_50=0.001, HTML_MESSAGE=0.001, J_BACKHAIR_11=1, J_BACKHAIR_13=1, J_BACKHAIR_23=1, J_BACKHAIR_31=1, J_BACKHAIR_34=1, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CK2bb74S-eTE for ; Thu, 22 Jul 2010 15:58:36 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id F22223A6A6F for ; Thu, 22 Jul 2010 15:58:35 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFABRqSEyrR7Hu/2dsb2JhbACBRJ4hcacjmwuCb4JHBIQAhFk Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 22 Jul 2010 22:58:53 +0000 Received: from stealth-10-32-254-212.cisco.com (stealth-10-32-254-212.cisco.com [10.32.254.212]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6MMwp14001615; Thu, 22 Jul 2010 22:58:51 GMT Message-Id: <943F9DC0-7E21-49E2-932F-6C14C09EAD79@cisco.com> From: David McGrew To: "william.polk@nist.gov Polk" , Tina TSOU In-Reply-To: <4C3BAE48.1070401@vigilsec.com> Content-Type: multipart/alternative; boundary=Apple-Mail-18-884620603 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Jul 2010 15:58:51 -0700 References: <4C3BAE48.1070401@vigilsec.com> X-Mailer: Apple Mail (2.936) Cc: Margret Salter , "Kevin M. Igoe" , secdir@ietf.org Subject: Re: [secdir] secdir review for draft-mcgrew-fundamental-ecc-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 22:58:38 -0000 --Apple-Mail-18-884620603 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Tina, thanks for your comments on the draft. On Jul 12, 2010, at 5:07 PM, Russ Housley wrote: > I did not see you as recipients on this note. Forwarding ... > > Russ > > - - - - - - - - - > > Hi, > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the =20 > IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other comments. > > Abstract > 1. First sentence: Should >are< rather be >were< ? Changed. > Introduction > 2. Introduction (p.2): I would insert the word >finite< before =20 > >fields<. Changed. > 3. Introduction (p.4): >ECDH< should be replaced by >Elliptic Curve =20= > Diffie-Hellman (ECDH) <. Changed. > Mathematical Background > 4. Mathematical Background (p.1): Should >is< rather be >are< ? The =20= > same holds in Sec.~2.2 (p.1). Changed. > 5. Sec.~2.2 (p.3): The term >g< is undefined. Hence, >g^N< should be =20= > replaced by >a^N<. The same holds for >Note that a^M is equal to g^ =20= > (M mod R)< in (p.9). Changed. > 6. Sec.~2.3 (p.2): =46rom this description, it appears to me that all = =20 > elements in Z_p can perform division operation. However, only non-=20 > zero elements, namely elements in the set > Z_p^* =3D Z_p-{0} > can perform the division operation. Moreover, all the mathematical =20 > operations over Z_p are in the sense of mod p. In addition, a prime =20= > number p is called the characteristic of a field, if 1+=85+1=3D0 (add = p =20 > times); in this case F_q contains the prime field F_p, where q=3Dp^n, =20= > n>=3D1. So I think the definition of the F_p lacks precision. I think this explanation of finite fields is appropriate for this =20 note. It is not intending to be a general introduction to finite =20 fields, but instead to provide only the background needed to =20 understand the rest of the note. The statement " When p is a prime =20 number, then the set Zp, with the addition, subtraction, =20 multiplication and division operations, is a finite field with =20 characteristic p" is correct and precise. I suggest that the section heading be changed from "Finite Fields" to =20= "The Finite Field Fp". > Elliptic Curve Groups > 7. Elliptic Curve Groups (p.1): I think the last sentence is too =20 > abstract to understand. More precisely, the elliptic curve satisfies =20= > the equations, > y^2+cy=3Dx^3+ax+b, > y^2=3Dx^3+ax^2+bx+c, > when the characteristic of the field is 2 and 3, respectively. I disagree. If the paragraph is difficult for the non-mathematician =20 to understand, I don't think adding more math will help. Besides, the =20= definitions here match [M1985] and [K1987]. > 8. Elliptic Curve Groups (p.3): The first sentence says that =20= > >when both points are the point at Infinity<. Maybe such statement =20 > is not accurate enough due to the fundamental fact that each =20 > elliptic curve abelian group has only one infinity, i.e., the =20 > identity element. I disagree that this needs to be changed; it is clear as it stands. I =20= don't see how it could be made more accurate, since inserting "equal =20 to" before "the point at infinity" would be inappropriate in a =20 definition about what it means for points to be equal. > 9. Sec.~3.1 (p.2): It seems to me that the projection space =20 > representation >x=3DX/Z mod p , y=3DY/Z mod p< is a special case of = x=3DX/=20 > Z^{c_1} mod p and y=3DY/Z^{c_2} mod p when both c_1 and c_2 are equal =20= > to 1. If so, should it be clearly explained ? The exposition in this section matches the reference, which is one of =20= the goals of the draft. > 10. Sec.~3.3.1: I would simply state the reason for the non-=20 > zero discriminant, namely, to ensure that the elliptic curve is =20 > chosen to be a non-singular one, i.e., it has no self intersections =20= > or cusps. I disagree; the discriminant is not used anywhere in the draft, and is =20= only mentioned for consistency of the elliptic curve group =20 definition. Curve parameter generation is out of scope for this =20 draft, and so the target audience has no need for the information.=09 > Elliptic Curve Diffie-Hellman (ECDH) > 11. Elliptic Curve Groups (p.1): >an arbitrary cyclic group< =20= > instead of >an arbitrary mathematical group< ? Changed; I verified that [M1983] mentions cyclic groups as well. > Elliptic Curve ElGamal Signatures > 12. Sec.~5.1 (p.1): Insert >Galois< before >field GF(2^w)<. I added "finite" instead of "Galois" since the latter term is not =20 defined in the document. > 13. Sec.~5.3 (p.2): Why not denote the generator >alpha< as =20 > >g< for consistency in this draft ? In order to closely follow the original references. > 14. Sec.~5.3.2 (4): As the symbol >*< denotes the scalar =20 > multiplication, why use such a symbol in Sec.~2.2 to represent the =20 > addition operation in a group ? Needs to be modified ? The draft uses multiplicative notation throughout for consistency with =20= early references; see S 2.2 par 2. > 15. Sec.~5.3.3 (p.1): Insert >the generator g, the group =20 > order q< before >the public key Y< in that these two parameters must =20= > know in advance before the signature verification procedure. Changed. > 16. Sec.~5.3.2 (1): Should >0s_1 in =20 > Z_q< for consistency ? The same holds for >0 in Sec.~5.4.3 (1). I assume that you mean S 5.3.3.. This change would be wrong because =20 it would mistakenly include 0. Besides, the sentence in the draft =20 matches that in the reference [FIPS186]. > 17. Sec.~5.3.2 (3): As mentioned above, the symbol >*< in the =20= > equation > >R'=3Dalpha^{u_1} * Y^{u_2}< represents the addition operation of two =20= > points on the elliptic curve; while in >u_2=3Ds_1 * s_2 mod q<, it =20 > means the scalar multiplication operation. The draft uses multiplicative notation throughout for consistency. > 18. Sec.~5.6 (p.2): In the equations >A=3Dm< and >m=3D-r*z+s*k =20= > (mod q)<, does the symbol m represent a message digest ? If so, I =20 > think m should be replaced by h(m), although the hash function is =20 > not necessary here. If not, it should be transformed to an integer =20 > since it has been defined to be a bit string in Sec.~5.2. The same =20 > holds for the equation >m*s=3D-r*s*z+k (mod q)<. S 5.6 is non-normative rationale, and the equations exactly match the =20= references. The lack of a hash function is already explained: "No =20 hash function is shown in the above equations, but as described in =20 Section 10.4, a hash function should be applied to the message prior =20 to signing in order to prevent existential forgery attacks." > Converting between integers and octet strings > 19. the title >Converting between integers and octet strings<, why =20 > not >Converting between Integers and Octet Strings< for =20 > consistency ? The same goes for other titles and subtitles. Changed. > Security Considerations > 20. Sec.~10.1 (p.3): I think it is necessary to explain the =20 > physical meaning of the cofactor and the reason that a number of =20 > attacks are possible against ECDH when the cofactor is not equal to 1. The term "cofactor" was introduced after 1994 and thus is not in the =20 normative part of the draft. I am unsure of what explanation you think =20= would be appropriate, because the definition is straightforward. I =20 disagree that detailed descriptions of the attacks are required in =20 this draft. Parameter generation is declared out of scope, cofactor=3D1 = =20 is recommended, and references are provided for the attacks =20 mentioned. The intended audience is implementers, not cryptographers =20= generating new elliptic curve groups. Kevin provided a good definition of cofactor suitable for Section 2, =20 if we can find a pre-1994 reference: in cryptographic applications, the group G typically has only a finite number of elements, and the ratio between the number of elements in G (denoted by #G) and the number of elements in the cyclic subgroup H (denoted by #H) is called the cofactor of H =20 in G, that is cofactor =3D #G/#H. Note that the cofactor is always =20 greater than or equal to 1, and the cofactor is 1 if and only if H =3D G. = A fundamental result of group theory is that the cofactor is always an integer. regards, David > > > B. R. > Tina > http://tinatsou.weebly.com/contact.html > --Apple-Mail-18-884620603 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi = Tina,

thanks for your comments on the = draft. 

On Jul 12, 2010, at 5:07 PM, Russ = Housley wrote:

I did not see you as recipients on this = note.  Forwarding ...

Russ

- - - - - = - - - -

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 = comments.

 

Abstract1. First sentence: Should >are< rather be >were< = ?

Changed.

2. Introduction (p.2): I = would insert the word >finite< before = >fields<.

Changed.

3. Introduction (p.4): = >ECDH< should be replaced by >Elliptic Curve Diffie-Hellman = (ECDH) = <.

Changed.

Mathematical = Background
4. Mathematical Background = (p.1): Should >is< rather be >are< ? The same holds in = Sec.~2.2 = (p.1).

Changed.

5. Sec.~2.2 (p.3): The term = >g< is undefined. Hence, >g^N< should be replaced by = >a^N<. The same holds for >Note that a^M is equal to g^ (M mod = R)< in = (p.9).
Changed.

6. Sec.~2.3 = (p.2):  =46rom this = description, it appears to me that all elements in Z_p can perform = division operation. However, only non-zero elements, namely elements in = the set
Z_p^* =3D Z_p-{0}
can perform the division = operation. Moreover, all the mathematical operations over Z_p are in the = sense of mod p. In addition, a prime number p is called the characteristic<= span class=3D"Apple-converted-space"> of a field, if 1+=85+1=3D= 0 (add p times); in this case F_q contains the prime field F_p, where = q=3Dp^n, n>=3D1. So I think the definition of the F_p lacks = precision.

I think this explanation of finite fields is = appropriate for this note.  It is not intending to be a general = introduction to finite fields, but instead to provide only the = background needed to understand the rest of the note.  The = statement " When p is a prime number, then the set Zp, with the = addition, subtraction, multiplication and division operations, is a = finite field with characteristic p" is correct and precise. =  

I suggest that the section heading be = changed from "Finite Fields" to "The Finite Field Fp". =  


Elliptic Curve = Groups
7. Elliptic Curve Groups (p.1): I think the = last sentence is too abstract to understand. More precisely, the = elliptic curve satisfies the = equations,
y^2+cy=3Dx^3+ax+b,
=
y^2=3Dx^3+ax^2+bx+c,
when the characteristic of the field is 2 and 3, = respectively.

I disagree.  If the paragraph is difficult for = the non-mathematician to understand, I don't think adding more math will = help.  Besides, the definitions here match [M1985] and [K1987]. =  

       8. Elliptic Curve = Groups (p.3): The first sentence says that >when both points are the = point at Infinity<. Maybe such statement is not accurate enough due = to the fundamental fact that each elliptic curve abelian group has only = one infinity, = i.e., the identity = element.
I disagree that this needs to be changed; it is clear as it = stands.  I don't see how it could be made more accurate, since = inserting "equal to" before "the point at infinity" would be = inappropriate in a definition about what it means for points to be = equal.  

       9. Sec.~3.1 (p.2): = It seems to me that the projection space representation >x=3DX/Z mod = p , y=3DY/Z mod p< is a special case of x=3DX/Z^{c_1} mod p and = y=3DY/Z^{c_2} mod p when both c_1 and c_2 = are equal to 1. If so, should it be clearly explained = ?

The exposition in this section matches the reference, which is one = of the goals of the draft.

       10. = Sec.~3.3.1: I would = simply state the reason for the non-zero discriminant, namely, to ensure = that the elliptic curve is chosen to be a non-singular one, i.e., it has = no self intersections or = cusps.

=
I disagree; the discriminant is not used anywhere in the = draft, and is only mentioned for consistency of the elliptic curve group = definition.  Curve parameter generation is out of scope for this = draft, and so the target audience has no need for the information. =

Elliptic Curve Diffie-Hellman = (ECDH)
       11. Elliptic Curve = Groups (p.1): >an arbitrary cyclic group<  instead of >an = arbitrary mathematical group< = ?

Changed; I verified that [M1983] mentions cyclic groups as well. =  

Elliptic Curve ElGamal = Signatures
       12. Sec.~5.1 (p.1): = Insert >Galois< before >field = GF(2^w)<.

I added "finite" instead of "Galois" since the latter = term is not defined in the document.  

       13. Sec.~5.3 (p.2): = Why not denote the generator >alpha< as >g< for consistency = in this draft = ?

In order to closely follow the original = references.

       14. = Sec.~5.3.2 (4): As the symbol = >*< denotes the scalar multiplication, why use such a symbol in = Sec.~2.2 to represent the addition operation in a group ? Needs to be = modified = ?

The draft uses multiplicative notation throughout for consistency = with early references; see S 2.2 par 2.

       15. = Sec.~5.3.3 (p.1): Insert >the = generator g, the group order q< before >the public key Y< in = that these two parameters must know in advance before the signature = verification = procedure.
=
Changed.  

       16. = Sec.~5.3.2 (1): Should = >0<s_1<q< be replaced by >s_1 in Z_q< for consistency ? = The same holds for >0<s_2<q< and the sentence in Sec.~5.4.3 = (1).

I assume that you mean S 5.3.3..  This change would be = wrong because it would mistakenly include 0.  Besides, the sentence = in the draft matches that in the reference = [FIPS186]. 

       17. = Sec.~5.3.2 (3): As mentioned above, = the symbol >*< in the = equation
>R'=3Dalpha^{u_1} * Y^{u_2}< represents the addition operation = of two points on the elliptic curve; while in >u_2=3Ds_1 * s_2 mod = q<, it means the scalar multiplication = operation.
=
The draft uses multiplicative notation throughout for = consistency.


       18. Sec.~5.6 (p.2): = In the equations >A=3Dm< and >m=3D-r*z+s*k (mod q)<, does = the symbol m represent a message digest ? If so, I think m should be = replaced by h(m), although the hash function is not necessary here. If = not, it should be transformed to an integer since it has been defined to = be a bit string in Sec.~5.2. The same holds for the equation = >m*s=3D-r*s*z+k (mod = q)<.
S 5.6 is non-normative rationale, and the equations exactly = match the references.  The lack of a hash function is already = explained: "No hash function is shown in the above equations, but as = described in Section 10.4, a hash function should be applied to the message prior to signing in order to prevent existential forgery = attacks." 

Converting between integers and octet = strings
19. the title >Converting between = integers and octet strings<, why not >Converting between Integers = and Octet Strings< for consistency ? The same goes for other titles = and = subtitles.
=
Changed.

       20. Sec.~10.1 (p.3): I think it is = necessary to explain the physical meaning of the cofactor and the reason that a = number of attacks are possible against ECDH when the cofactor is not = equal to = 1.
<= br>
The term "cofactor" was introduced after 1994 and thus is = not in the normative part of the draft. I am unsure of what explanation = you think would be appropriate, because the definition is = straightforward.  I disagree that detailed descriptions of the = attacks are required in this draft.  Parameter generation is = declared out of scope, cofactor=3D1 is recommended, and references are = provided for the attacks mentioned.  The intended audience is = implementers, not cryptographers generating new elliptic curve = groups.

Kevin provided a good definition of = cofactor suitable for Section 2, if we can find a pre-1994 = reference:

      in cryptographic = applications, the group G typically has only = a
      finite number of elements, = and the ratio between the number = of
      elements in G (denoted by = #G) and the number of elements in = the
      cyclic subgroup H (denoted = by #H) is called the cofactor of H in G,
    =   that is cofactor =3D #G/#H. Note that the cofactor is always = greater
      than or equal to 1, and = the cofactor is 1 if and only if H =3D G. = A
      fundamental result of group = theory is that the cofactor is = always
      an = integer.

regards,
David

 
<Attached Message = Part.txt>

= --Apple-Mail-18-884620603-- From julienl@qualcomm.com Sat Jul 24 07:40:09 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554513A6A12; Sat, 24 Jul 2010 07:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.503 X-Spam-Level: X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0t4G1qXnjEc; Sat, 24 Jul 2010 07:40:07 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 122983A6A0F; Sat, 24 Jul 2010 07:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1279982424; x=1311518424; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Margaret=20Wasserman=20,=20 Internet=20Area=0D=0A=09,=20"saag@ietf .org"=20,=20"secdir@ietf.org"=0D=0A=09,=20"ipdir@ietf.org"=20,=20" savi@ietf.org"=0D=0A=09,=20"csi@ietf.org" =20|CC:=20PaddyNallur=20,=20Dong=20Zhang=0D=0A=09 |Date:=20Sat,=2024=20Jul=202010=2007:40:20=20-0700 |Subject:=20RE:=20[secdir]=20New=20Mailing=20List:=20=20c gasec|Thread-Topic:=20[secdir]=20New=20Mailing=20List:=20 =20cgasec|Thread-Index:=20Acsp1r1t8JySvlknQ8mPfKRAwng+MwB ZshMw|Message-ID:=20|References:=20<413FFD 9E-487D-40B2-B4DD-A10F5CD00C85@gmail.com>|In-Reply-To:=20 <413FFD9E-487D-40B2-B4DD-A10F5CD00C85@gmail.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=J13ak9WLHY0D7nZRkI4NclnkdlIwFqs/Sf+QLkP6IpY=; b=aNjloy9rRbFTY7o2uzHevJ3GYGmIDrhaEuS14zFj0BxBdJ8tRp3fmGOu cHKYVdTpwgEAAQcQ5ZGysce2Sw1TcgTvLlBrP+rsazruQMKgVb4/IdfMD QtGyLelTozRxmYFD2lTJXBKgvgAfh8PiOl65ILSK0iRQ79m88654ueWrf M=; X-IronPort-AV: E=McAfee;i="5400,1158,6052"; a="48432867" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine02.qualcomm.com with ESMTP; 24 Jul 2010 07:40:24 -0700 X-IronPort-AV: E=Sophos;i="4.55,252,1278313200"; d="scan'208";a="46595949" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 24 Jul 2010 07:40:24 -0700 Received: from nasanexhc04.na.qualcomm.com (172.30.48.17) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 24 Jul 2010 07:40:26 -0700 Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.0.694.0; Sat, 24 Jul 2010 07:40:25 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Sat, 24 Jul 2010 07:40:25 -0700 From: "Laganier, Julien" To: Margaret Wasserman , Internet Area , "saag@ietf.org" , "secdir@ietf.org" , "ipdir@ietf.org" , "savi@ietf.org" , "csi@ietf.org" Date: Sat, 24 Jul 2010 07:40:20 -0700 Thread-Topic: [secdir] New Mailing List: cgasec Thread-Index: Acsp1r1t8JySvlknQ8mPfKRAwng+MwBZshMw Message-ID: References: <413FFD9E-487D-40B2-B4DD-A10F5CD00C85@gmail.com> In-Reply-To: <413FFD9E-487D-40B2-B4DD-A10F5CD00C85@gmail.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 Cc: PaddyNallur , Dong Zhang Subject: Re: [secdir] New Mailing List: cgasec X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 14:40:09 -0000 Hi Margaret, all, Margaret Wasserman wrote:=20 >=20 > Hi All, >=20 > We've put together a mailing list to discuss the use of > Cryptographically Generated Addresses (CGAs) for security purposes > across the internet. The list address is cgasec@ietf.org. To > subscribe, go to: https://www.ietf.org/mailman/listinfo/cgasec. >=20 > We have published a draft in this area that can be found here: >=20 > https://datatracker.ietf.org/doc/draft-dong-savi-cga-header/ >=20 > [...] >=20 > Please send any feedback on the above document to the cgasec@ietf.org > mailing list. Please avoid cross-pointing your feedback to the full > to: list on this message, unless you believe that it is pertinent to > the hundreds or low thousands of people included on this message. > Thank you. >=20 > We will be holding an old-fashioned Bar BOF in Maastricht (in a bar, > no presentations), probably on Thursday night for folks who are > interested in working our proposal, or related work in this technical > area. Further details about the bar BOF will be announced early next > week, after I get to Maastricht and can scope out a location. >=20 > There has also been some earlier work in this area by Julien Lagnier, > but I do not have a current reference. Julien it is not my intention > to omit your work from this discussion, so please feel free to send a > pointer. FWIW - here's a pointer: http://tools.ietf.org/html/draft-laganier-ike-ipv6-cga Abstract This document describes IKEv2 peer authentication via IPv6 Cryptographically Generated Addresses (CGA). This technique have been proposed to solve several security issues in the absence of any centralized trusted security infrastructure and without any pre- arrangements, to provide IPsec self-evident authentication mode between IPv6 nodes or security gateways. (IPsec is misspelled IPSec on the online dratf, I've corrected in the copy/= paste above :) --julien From turners@ieca.com Sat Jul 24 09:24:35 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5733A69CA for ; Sat, 24 Jul 2010 09:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.436 X-Spam-Level: X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bp0cBTLTFA2N for ; Sat, 24 Jul 2010 09:24:34 -0700 (PDT) Received: from smtp111.biz.mail.sp1.yahoo.com (smtp111.biz.mail.sp1.yahoo.com [69.147.92.224]) by core3.amsl.com (Postfix) with SMTP id E00AB3A6826 for ; Sat, 24 Jul 2010 09:24:34 -0700 (PDT) Received: (qmail 76453 invoked from network); 24 Jul 2010 16:24:54 -0000 Received: from dhcp-37f8.meeting.ietf.org (turners@130.129.55.248 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 24 Jul 2010 09:24:54 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: wXVOCNkVM1nmCTj3tz3BhPz.pwK4458eXcSV8RRl3D_Tspa tIa3KokE5koy57OGIzCq04v_2kMMc1l0kFsUhPTU1NNnfXjd5D_.AklL2YHh 811eTmys7Zh.E5jIiljHBTiJX3SQpvngIU4UjhKaiF2ixY1Ah.DGtj4mz8LJ NwwwkXEhoVG5Hi2zaextGhKILrbsQfz226W3bTKb5OVnxm0QXwYA41H4oaja raJDeiy0cAi3B2P8JaIeQvCBULrGwbJqVjNUaMpMRd0S2Iyr8ntkCveWNsfc UcIhjQvgPnynrFwKNCEp8U9U- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C4B13D4.5080507@ieca.com> Date: Sat, 24 Jul 2010 18:24:52 +0200 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Tuesday SECDIR Lunch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 16:24:35 -0000 Folks, We've reserved the MeccCafe for the traditional Tuesday Security Directorate Lunch at IETF 78, so please hold that time slot open in your personal calendars! As usual, bring your own lunch and we will discuss what's going on in the area and around the IETF. Cheers, spt From kent@bbn.com Sat Jul 24 13:44:29 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9933A6768 for ; Sat, 24 Jul 2010 13:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.282 X-Spam-Level: X-Spam-Status: No, score=-1.282 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_ATIVAN=2.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LmPYzyld1Ip for ; Sat, 24 Jul 2010 13:44:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 7EFF23A67B5 for ; Sat, 24 Jul 2010 13:44:26 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:56127 helo=[10.242.10.151]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OclaP-000Hur-HY; Sat, 24 Jul 2010 16:44:45 -0400 Mime-Version: 1.0 Message-Id: Date: Sat, 24 Jul 2010 16:44:40 -0400 To: secdir@ietf.org From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-932118212==_ma============" Cc: ginsberg@cisco.com, dward@juniper.com, stbryant@cisco.com, chopps@cisco.com Subject: [secdir] review of draft-ietf-isis-bfd-tlv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 20:44:29 -0000 --============_-932118212==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 is a very brief (8-page) document that is generally well written. It defines a TLV (an acronym not defined in the document, but I'm guessing type-length-value) value for use in IS-IS, for bidirectional forwarding detection (BFD). The abstract says that this TLV is needed because, in some scenarios, IS-IS fails to detect a forwarding plane failure based on BFD as described in ietf-bfd-generic]. Section 2 of this (the reviewed) document describes a class of scenarios in which the BFD mechanism cited above would not work properly, thus motivating the proposal contained here. The simple solution proposed here is for a router to advertise its ability to perform BFD on an interface via its IS-IS IIH (an acronym not defined in the document), hence the need to define this TLV. My biggest complaint with the document overall is that it uses several acronyms without first defining them, an easy problem to fix. The Security Considerations section is just one paragraph, which states that the addition of this feature does not adversely affect the security mechanism (sic) of IS-IS. I'm not questioning this assertion, based on reading this document, but I think a couple of additional sentences are needed here, to justify the assertion. --============_-932118212==_ma============ Content-Type: text/html; charset="us-ascii" review of draft-ietf-isis-bfd-tlv-02
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 is a very brief (8-page) document that is generally well written. It defines a TLV (an acronym not defined in the document, but I'm guessing type-length-value) value for use in IS-IS, for bidirectional forwarding detection (BFD). The abstract says that this TLV is needed because, in some scenarios, IS-IS fails to detect a forwarding plane failure based on BFD as described in ietf-bfd-generic]. Section 2 of this (the reviewed) document describes a class of scenarios in which the BFD mechanism cited above would not work properly, thus motivating the proposal contained here. The simple solution proposed here is for a router to advertise its ability to perform BFD on an interface via its IS-IS IIH (an acronym not defined in the document), hence the need to define this TLV.  My biggest complaint with the document overall is that it uses several acronyms without first defining them, an easy problem to fix.

The Security Considerations section is just one paragraph, which states that the addition of this feature does not adversely affect the security mechanism (sic) of IS-IS. I'm not questioning this assertion, based on reading this document, but I think a couple of additional sentences are needed here, to justify the assertion.
--============_-932118212==_ma============-- From hartmans@mit.edu Sun Jul 25 04:18:26 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C91D3A68B3 for ; Sun, 25 Jul 2010 04:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RC0FstJxoPru for ; Sun, 25 Jul 2010 04:18:25 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 055843A682E for ; Sun, 25 Jul 2010 04:18:24 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-23f1.meeting.ietf.org [130.129.35.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id B5AE320120; Sun, 25 Jul 2010 07:18:42 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0640A4133; Sun, 25 Jul 2010 07:18:40 -0400 (EDT) From: Sam Hartman To: Stephen Kent References: Date: Sun, 25 Jul 2010 07:18:39 -0400 In-Reply-To: (Stephen Kent's message of "Sat\, 24 Jul 2010 16\:44\:40 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: stbryant@cisco.com, ginsberg@cisco.com, chopps@cisco.com, dward@juniper.com, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-isis-bfd-tlv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 11:18:26 -0000 >>>>> "Stephen" == Stephen Kent writes: Stephen> The Security Considerations section is just one paragraph, Stephen> which states that the addition of this feature does not Stephen> adversely affect the security mechanism (sic) of IS-IS. I'm Stephen> not questioning this assertion, based on reading this Stephen> document, but I think a couple of additional sentences are Stephen> needed here, to justify the assertion. How about something like: This TLV does not adversely affect the security of IS-Is. The primary consequence of using the BFD mechanism in a case where it is not supported is incorrectly detecting a false failure of bidirectional forwarding. The primary consequence of not using BFD when BFD is supported is failure to detect situations in which bidirectional forwarding is not happening on a link. At worst, this leads to a denial of service condition. However, a party who can manipulate the contents of this TLV is already in a position to create such a denial of service by disrupting IS-IS routing. If the above paragraph is correct, I think it may go some distance to addressing Stephen's concern. However, I wonder how the authentication mechanisms of BFD interact with the authentication mechanisms of IS-IS? Is it possible to get into a situation where IS-IS is authenticated but BFD is not? If so, that should be discussed in the security considerations section. --Sam From hartmans@mit.edu Sun Jul 25 04:22:07 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37FCC3A68B9 for ; Sun, 25 Jul 2010 04:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTPUrtlCbGAQ for ; Sun, 25 Jul 2010 04:22:06 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 6A9233A682E for ; Sun, 25 Jul 2010 04:22:06 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-23f1.meeting.ietf.org [130.129.35.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4483B20437 for ; Sun, 25 Jul 2010 07:22:26 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4CA7D4133; Sun, 25 Jul 2010 07:22:24 -0400 (EDT) From: Sam Hartman To: secdir@ietf.org References: <4C4B13D4.5080507@ieca.com> Date: Sun, 25 Jul 2010 07:22:24 -0400 In-Reply-To: <4C4B13D4.5080507@ieca.com> (Sean Turner's message of "Sat, 24 Jul 2010 18:24:52 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [secdir] Tuesday SECDIR Lunch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 11:22:07 -0000 I'd appreciate reports of where to get own lunches to bring. From turners@ieca.com Sun Jul 25 04:27:38 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 850303A6880 for ; Sun, 25 Jul 2010 04:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kmuds9nNxe6f for ; Sun, 25 Jul 2010 04:27:37 -0700 (PDT) Received: from smtp112.biz.mail.mud.yahoo.com (smtp112.biz.mail.mud.yahoo.com [209.191.68.77]) by core3.amsl.com (Postfix) with SMTP id 6B23F3A681E for ; Sun, 25 Jul 2010 04:27:37 -0700 (PDT) Received: (qmail 56438 invoked from network); 25 Jul 2010 11:27:54 -0000 Received: from dhcp-26f6.meeting.ietf.org (turners@130.129.38.246 with plain) by smtp112.biz.mail.mud.yahoo.com with SMTP; 25 Jul 2010 04:27:54 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: tSJWeLQVM1nSTut.q5R4oV0na9Me8180C9eNbkcIse2mVpk bpFhxOgyDBb0x07W7qw_41hXckdK51Jz8Xku9jbG98swTivH.2GTjywO8lsM 7h0ey5Xts.MEUkuV8YH2yqGKL2Klip6wDuuGXAzZZ9.aITz7Tis9pGnjTzxP dwYvZaEu0E.urGVIMhApuvXTDMyksofi7sBTLkUTg_OtaDPFbU7Q_8XnBLoz s8vwUQk1YAUCNKLqf7wDT8x4Obr605xfR4M3TbI36pTTiotpwUJxuuzkO449 0arcbvKvBOGn9h99Sol4zrRwrJM6cmMpc6cVFlLn0LpGGJFmZmJC4 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C4C1FB8.6010403@ieca.com> Date: Sun, 25 Jul 2010 13:27:52 +0200 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <4C4B13D4.5080507@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org Subject: Re: [secdir] Tuesday SECDIR Lunch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 11:27:38 -0000 The MECC looks like it's being set up to sell lunches. We'll see if they can handle the numbers on Monday. spt Sam Hartman wrote: > I'd appreciate reports of where to get own lunches to bring. > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From scott@hyperthought.com Sun Jul 25 05:24:14 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5EC03A6912 for ; Sun, 25 Jul 2010 05:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvsmTlww5k0B for ; Sun, 25 Jul 2010 05:24:13 -0700 (PDT) Received: from smtp112.iad.emailsrvr.com (smtp112.iad.emailsrvr.com [207.97.245.112]) by core3.amsl.com (Postfix) with ESMTP id AB1493A6847 for ; Sun, 25 Jul 2010 05:24:13 -0700 (PDT) Received: from relay21.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay21.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id A7B0A1B4212; Sun, 25 Jul 2010 08:24:33 -0400 (EDT) Received: from dynamic9.wm-web.iad.mlsrvr.com (dynamic9.wm-web.iad.mlsrvr.com [192.168.2.216]) by relay21.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id A03D21B40AA; Sun, 25 Jul 2010 08:24:33 -0400 (EDT) Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic9.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 917D3320088; Sun, 25 Jul 2010 08:24:33 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Sun, 25 Jul 2010 05:24:33 -0700 (PDT) Date: Sun, 25 Jul 2010 05:24:33 -0700 (PDT) From: "Scott G. Kelly" To: secdir@ietf.org, iesg@ietf.org, draft-ietf-v6ops-ipv6-cpe-router.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1280060673.59399192@192.168.2.231> X-Mailer: webmail8 Subject: [secdir] secdir review of draft-ietf-v6ops-ipv6-cpe-router X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 12:24:14 -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=0AAs the title implies, this document discus= ses basic requirements for IPv6 customer edge routers. The comments given h= ere are limited to security only.=0A=0AThe security considerations section = begins with a paragraph stating that basic stateless egress and ingress fil= ters should be supported (lowercase "should"), and goes on to say that the = CE router should offer mechanisms to filter traffic entering the customer n= etwork, but that how these are implemented is out of scope (lowercase "shou= ld"). Then, it has the following statements:=0A=0A Security requirements:= =0A=0A S-1: The IPv6 CE router SHOULD support=0A [I-D.ietf-v6ops= -cpe-simple-security].=0A=0A S-2: The IPv6 CE router MUST support ingres= s filtering in accordance=0A with [RFC2827] (BCP 38)=0A=0AWhen I fi= rst read this, I thought the statements in the first paragraph were somewha= t weak and imprecise, as they don't use RFC2119 language. When I read draft= -ietf-v6ops-cpe-simple-security-12.txt, I thought that document gives a rel= atively thorough treatment of security considerations, but I'm not sure wha= t it means to say "The IPv6 CE router SHOULD support" it. =0A=0AWhat does t= his mean? Since the referenced ID only makes recommendations (and explicitl= y states the RFC2119 language is not binding) what does it mean to "support= " it? Must a device implement all recommendations? Must it implement only c= ertain ones? =0A=0AI think it makes sense to reference the simple security = document rather than re-writing significant sections of it here, but I also= think that this statement of security requirements should be considerably = more precise.=0A=0A--Scott=0A From kent@bbn.com Mon Jul 26 01:14:36 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B7B3A6A07 for ; Mon, 26 Jul 2010 01:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IO1GhPJXCJX5 for ; Mon, 26 Jul 2010 01:14:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 0837C3A6A53 for ; Mon, 26 Jul 2010 01:14:34 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:46598 helo=[130.129.114.216]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OdIpq-000Njl-8A; Mon, 26 Jul 2010 04:14:54 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 26 Jul 2010 04:12:16 -0400 To: "Les Ginsberg (ginsberg)" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "Stewart Bryant \(stbryant\)" , "Chris Hopps \(chopps\)" , dward@juniper.com, Sam Hartman , secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-isis-bfd-tlv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 08:14:36 -0000 At 12:55 AM -0700 7/26/10, Les Ginsberg (ginsberg) wrote: >... > >The mechanism introduced by this draft is used to determine when/if to >use BFD session state as a prerequisite to forming an IS-IS adjacency >and/or to trigger IS-IS adjacency state transitions. It does not make >any changes to the operation of BFD itself - which I think your wording >may unintentionally imply. How about: > >"The TLV defined within this document describes an addition to the IS-IS >Hello protocol. Inappropriate use of this TLV could prevent an IS-IS >adjacency from forming or lead to failure to detect bidirectional >forwarding failures - each of which is a form of denial of service. >However, a party who can >manipulate the contents of this TLV is already in a position to create >such a denial of service by disrupting IS-IS routing in other ways." > That text is much better. I think it is also worth including a sentence, as you did later in your message, noting that the use of this new TLV in the IS-IS hello exchange is independent of the use of authentication for that exchange or for BFD. Steve From hartmans@mit.edu Mon Jul 26 01:16:21 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990983A6A51 for ; Mon, 26 Jul 2010 01:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRIFVhv1pcJk for ; Mon, 26 Jul 2010 01:16:15 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 8442D3A6A1A for ; Mon, 26 Jul 2010 01:16:13 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-23f1.meeting.ietf.org [130.129.35.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id CE12920206; Mon, 26 Jul 2010 04:16:29 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 28A304133; Mon, 26 Jul 2010 04:16:29 -0400 (EDT) From: Sam Hartman To: "Les Ginsberg \(ginsberg\)" References: Date: Mon, 26 Jul 2010 04:16:29 -0400 In-Reply-To: (Les Ginsberg's message of "Mon, 26 Jul 2010 00:55:06 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: secdir@ietf.org, dward@juniper.com, "Chris Hopps \(chopps\)" , Sam Hartman , "Stewart Bryant \(stbryant\)" Subject: Re: [secdir] review of draft-ietf-isis-bfd-tlv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 08:16:21 -0000 I'm fine with your changes to my text; I think it improves and clarifies things. From william.polk@nist.gov Mon Jul 26 04:02:30 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 521D53A6B8A for ; Mon, 26 Jul 2010 04:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3U0B3qvakhwp for ; Mon, 26 Jul 2010 04:02:24 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 343583A68D4 for ; Mon, 26 Jul 2010 04:02:24 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o6QB2YXR028596 for ; Mon, 26 Jul 2010 07:02:34 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 26 Jul 2010 07:02:34 -0400 From: "Polk, William T." To: "secdir@ietf.org" Date: Mon, 26 Jul 2010 07:02:19 -0400 Thread-Topic: Finding lunch vs. ordering pizzas for secdir at IETF 78 Thread-Index: AQHLLLIEExB5DMkDOUyf7wrVsyGKTg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Subject: [secdir] Finding lunch vs. ordering pizzas for secdir at IETF 78 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 11:02:30 -0000 Folks, Sean and I have been thinking about lunch options for tomorrow's lunch. The lunch process at MECC was pretty slow today (close to 30 minutes total for me to get a burger), and there are not a lot of other options around. I checked the hotel (too slow, too expensive) and the little bar outside in the MECC (only cheese sandwiches). The MECC should be vastly improved tomorrow (see Alexa's message below), but we could also arrange to have some random pizzas delivered. (I have no idea where we would order the pizzas or what types will be available, so this is probably not an option for folks that are particular about their pizzas!) If enough folks contact me by the end of afternoon session III, I will order pizzas and folks can just contribute if they eat the pizza. Everyone would still need to pick up a drink on their own at the MECCcafe; sodas and waters would make this way too complicated. I will follow up with an email to confirm the order OR let everyone know they are on their own at the end of today's sessions. Thanks, Tim Polk ________________________________________ From: 78all-bounces@ietf.org [78all-bounces@ietf.org] On Behalf Of Alexa Morris [amorris@amsl.com] Sent: Monday, July 26, 2010 6:27 AM To: 78all@ietf.org Subject: [78all] Lunch at MECC Starting tomorrow, there will be two additional cash registers available to pay for lunch (making a total of five). The registers are being shipped in from another facility. In addition, some of the handheld credit card swipers were not working properly today; these will be repaired by tomorrow. Finally, we will be reconfiguring the space itself in order to create more room to move about as you make your lunch selection. We anticipate that this will make the process much smoother for the rest of the week. Alexa ----------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com _______________________________________________ 78all mailing list 78all@ietf.org https://www.ietf.org/mailman/listinfo/78all From william.polk@nist.gov Mon Jul 26 10:00:22 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4E23A6C31 for ; Mon, 26 Jul 2010 10:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LR+4syTAPP9E for ; Mon, 26 Jul 2010 10:00:21 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 084553A6407 for ; Mon, 26 Jul 2010 10:00:20 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (WSXGHUB2.xchange.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o6QH0TcC005467 for ; Mon, 26 Jul 2010 13:00:29 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 26 Jul 2010 13:00:14 -0400 From: "Polk, William T." To: "secdir@ietf.org" Date: Mon, 26 Jul 2010 13:00:14 -0400 Thread-Topic: important secdir lunch details! Thread-Index: AQHLLON3xHfFk0+kr0aVWpBo4UFBig== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Subject: [secdir] important secdir lunch details! X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 17:00:22 -0000 Folks, Two important data points Location: I just heard a rumor that we are moving lunch to the Paris room. I will follow up once I confirm. Food: It looks like the only option for getting food ahead of time is the pizza here at the MECC. The IETF's contract with the MECC forbids outside food, and even if we wanted to risk it, Sean and I are both in sessions before secdir. I plan to order two pizzas just for the convenience, but if anyone who previously confirmed wants to opt out please let me know ASAP. If I need to eat 72 euros worth of pizza by myself, I will be sick for a *variety* of reasons. Thanks, Tim From kent@bbn.com Tue Jul 27 01:44:00 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD8473A6BAA; Tue, 27 Jul 2010 01:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEyL6WBxr3Bw; Tue, 27 Jul 2010 01:43:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 7D8433A6BAC; Tue, 27 Jul 2010 01:43:51 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49750 helo=[130.129.114.216]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Odflj-000Cyl-Jo; Tue, 27 Jul 2010 04:44:11 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <438B2D37-5C58-4E1F-9E69-75E80D76C570@gmail.com> References: <438B2D37-5C58-4E1F-9E69-75E80D76C570@gmail.com> Date: Tue, 27 Jul 2010 04:43:44 -0400 To: Margaret Wasserman From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-931902245==_ma============" Cc: Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [secdir] [saag] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 08:44:00 -0000 --============_-931902245==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Margaret, >... >>> >>>I agree that if CGAs were to be used in ACLs they would need to be >>>static (or long-term), but this does not negate a privacy feature >>>that CGA's do not have. >> >>yes, it does, because the privacy is afforded by the host >>generating a sequence of CGAs for parallel or serial use is in >>conflict with use of a static CGA as an address space identifier >>for access control purposes. > >There may be an inherent incompatibility between access control and >anonymity, but that does not mean that the use of CGAs for access >control is mutually exclusive with their use for privacy by the same >node. I agree, in principle, but in practice I think there may serious problems. Hosts would have to support both modes of operation and offer a decent UI to enable users to choose which type of CGA they want in a given context. I worry that the latter will be hard to do well, and thus users may, in reality, be deprived of the anonymity that CGAs can offer, because hosts don't offer a UI that is manageable. >A node could have a CGA (or a set of CGAs) that it uses to access >certain resources. Those address(es) could be used in access >control lists, etc. However, the same node could still generate >CGAs or IPv6 Privacy Addresses for temporary use when >anonymity/privacy is desired. see my comment above. also, your text here assumes that privacy is the rare case, which prejudices the discussion :-). >I would argue that the use of CGAs for privacy, as you have cited >it, is under-specified. There is mention of the concept that hosts >could use CGAs for privacy, but there is no explanation of how those >addresses would be managed, how long they should live, how >application-level programs should request them, etc. IPv6 Privacy >Addresses (as defined in RFC 4941) are much better specified for >this purpose. I agree that 4941 provides a more concrete discussion of privacy for IPv6 addresses. But the discussion in section 2.4 of that RFC describes the simple notion of changing IIDs over time, and it suggests selecting the IIDs in a pseudo random fashion. CGAs meet these criteria. I think the authors of 4941 erred in dismissing the use of CGAs (in section 3.2.3). The authors of 4991 seem to assume that the public key used with CGAs is fixed, even though 3792 does not require/suggest that. Also, while I agree that the MD5-based randomization process in 4991 is faster than the analogous hash computation for 3972, I don't think the difference is significant with current processors and most, reasonable scenarios. As I noted in my message, RFC 3972 makes a number of references to privacy, so it was clearly a major consideration in the CGA design. I see CGAs as balancing the option of privacy with a need for local address use validation. The local address use validation is a good secruity practice, with minimal, adverse privacy concerns. If we say that CGAs are not to be used when privacy is desired, and if local net managers demand CGAs for local address use validation, then we have deprived users of all address privacy options. I'd not like to see that outcome. >>... > >There is also a possibility that the use of CGAs and a CGA extension >in the early packets of an exchange could be used to set-up an IPsec >SA for the remainder of the flow. In cases where a flow will >consist of more than a few packets, this would probably be a better >approach than signing all of the packets in an exchange. I agree. >... > >>Mostly, but not quite. if a host is challenged to provide a signed >>sequence of packets by a purported intermediary, how does the host >>know that the challenge is legitimate, and not just a DoS attack? > >As we discuss in the security considerations section, this is an >open issue with the specification. There are some possibilities for >how to deal with this issue -- perhaps we could require that the >requester generate it's own CGA, sign the request and include an CGA >extension header on the request? I don' think that is a viable approach for all of these cases cited in the proposal, e.g., it would require a host to be aware of the CGA of any intermediary system that might want to challenge the host. Maybe the scenarios in the proposal need to be scaled back. > Or perhaps it would be better for the requester to do some other >costly operation to make this attack as expensive for the attacker >as it would be for the target? There may be other possibilities for >how to address this issue... it is one of the things that we should >work out in the IETF before publishing this document. If the CGA challenge comes from a destination (not an intermediate system) and the host has a relationship with that destination, there probably are ways to alleviate this concern. But, if we look at scenarios like web server access, the TLS server cert model seems much more reasonable as a way of identifying the destination. Given the rising interest in issuing and publishing certs using DNSSEC, I think that model may be more appropriate for source/destination access control. We have a number of security protocols that know how to use certs, but we have had a hard time overcoming the hurdles associated with the issuance and distribution of certs in a very large scale fashion. DNSSEC provides an ideal basis for certifying the binding between a DNS name and a public key, in a fashion that does not require handing $ over to a trusted third party. Steve --============_-931902245==_ma============ Content-Type: text/html; charset="us-ascii" Re: [saag] [secdir] Interest in draft-dong-savi-cga-header
Margaret,


...

I agree that if CGAs were to be used in ACLs they would need to be static (or long-term), but this does not negate a privacy feature that CGA's do not have.

yes, it does, because the privacy is afforded by the host generating a sequence of CGAs for parallel or serial use is in conflict with use of a static CGA as an address space identifier for access control purposes.

There may be an inherent incompatibility between access control and anonymity, but that does not mean that the use of CGAs for access control is mutually exclusive with their use for privacy by the same node.

I agree, in principle, but in practice I think there may serious problems. Hosts would have to support both modes of operation and offer a decent UI to enable users to choose which type of CGA they want in a given context.  I worry that the latter will be hard to do well, and thus users may, in reality, be deprived of the anonymity that CGAs can offer, because hosts don't offer a UI that is manageable.

A node could have a CGA (or a set of CGAs) that it uses to access certain resources.  Those  address(es) could be used in access control lists, etc.  However, the same node could still generate CGAs or IPv6 Privacy Addresses for temporary use when anonymity/privacy is desired.

see my comment above. also, your text here assumes that privacy is the rare case, which prejudices the discussion :-).

I would argue that the use of CGAs for privacy, as you have cited it, is under-specified.  There is mention of the concept that hosts could use CGAs for privacy, but there is no explanation of how those addresses would be managed, how long they should live, how application-level programs should request them, etc.  IPv6 Privacy Addresses (as defined in RFC 4941) are much better specified for this purpose.

I agree that 4941 provides a more concrete discussion of privacy for IPv6 addresses. But the discussion in section 2.4 of that RFC describes the simple notion of changing IIDs over time, and it suggests selecting the IIDs in a pseudo random fashion.  CGAs meet these criteria. I think the authors of 4941 erred in dismissing the use of CGAs (in section 3.2.3). The authors of 4991 seem to assume that the public key used with CGAs is fixed, even though 3792 does not require/suggest that. Also, while I agree that the MD5-based randomization process in 4991 is faster than the analogous hash computation for 3972, I don't think the difference is significant with current processors and most, reasonable scenarios.

As I noted in my message, RFC 3972 makes a number of references to privacy, so it was clearly a major consideration in the CGA design. I see CGAs as balancing the option of privacy with a need for local address use validation. The local address use validation is a good secruity practice, with minimal, adverse privacy concerns.  If we say that CGAs are not to be used when  privacy is desired, and if local net managers demand CGAs for local address use validation, then we have deprived users of all address privacy options.  I'd not like to see that outcome.

...

There is also a possibility that the use of CGAs and a CGA extension in the early packets of an exchange could be used to set-up an IPsec SA for the remainder of the flow.  In cases where a flow will consist of more than a few packets, this would probably be a better approach than signing all of the packets in an exchange.

I agree.

...

Mostly, but not quite. if a host is challenged to provide a signed sequence of packets by a purported intermediary, how does the host know that the challenge is legitimate, and not just a DoS attack?

As we discuss in the security considerations section, this is an open issue with the specification.  There are some possibilities for how to deal with this issue -- perhaps we could require that the requester generate it's own CGA, sign the request and include an CGA extension header on the request?

I don' think that is a viable approach for all of these cases cited in the proposal, e.g.,  it would require a host to be aware of the CGA of any intermediary system that might want to challenge the host. Maybe the scenarios in the proposal need to be scaled back.

 Or perhaps it would be better for the requester to do some other costly operation to make this attack as expensive for the attacker as it would be for the target?  There may be other possibilities for how to address this issue...  it is one of the things that we should work out in the IETF before publishing this document.

If the CGA challenge comes from a destination (not an intermediate system) and the host has a relationship with that destination, there probably are ways to alleviate this concern. But, if we look at scenarios like web server access, the TLS server cert model seems much more reasonable as a way of identifying the destination.

Given the rising interest in issuing and publishing certs using DNSSEC, I think that model may be more appropriate for source/destination access control.  We have a number of security protocols that know how to use certs, but we have had a hard time overcoming the hurdles  associated with the issuance and distribution of certs in a very large scale fashion. DNSSEC provides an ideal basis for certifying the binding between a DNS name and a public key, in a fashion that does not require handing $ over to a trusted third party.

Steve
--============_-931902245==_ma============-- From ginsberg@cisco.com Mon Jul 26 00:54:48 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1D43A6A42 for ; Mon, 26 Jul 2010 00:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fw-LlUiXXhVA for ; Mon, 26 Jul 2010 00:54:47 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 5E7103A69E1 for ; Mon, 26 Jul 2010 00:54:47 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKvcTEyrR7H+/2dsb2JhbACfYHGkbIwmjWGFNgSECIcWhyk X-IronPort-AV: E=Sophos;i="4.55,260,1278288000"; d="scan'208";a="162828851" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 26 Jul 2010 07:55:08 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6Q7t804001594; Mon, 26 Jul 2010 07:55:08 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jul 2010 00:55:08 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Jul 2010 00:55:06 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] review of draft-ietf-isis-bfd-tlv-02 Thread-Index: Acsr6yTXoPmJ4yFBRTKdlaqCCt1MOAAqmRog References: From: "Les Ginsberg (ginsberg)" To: "Sam Hartman" , "Stephen Kent" X-OriginalArrivalTime: 26 Jul 2010 07:55:08.0159 (UTC) FILETIME=[DDB658F0:01CB2C97] X-Mailman-Approved-At: Tue, 27 Jul 2010 01:54:26 -0700 Cc: "Stewart Bryant \(stbryant\)" , "Chris Hopps \(chopps\)" , dward@juniper.com, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-isis-bfd-tlv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 07:54:48 -0000 Sam/Stephen - > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Sunday, July 25, 2010 4:19 AM > To: Stephen Kent > Cc: secdir@ietf.org; Les Ginsberg (ginsberg); dward@juniper.com; > Stewart Bryant (stbryant); Chris Hopps (chopps) > Subject: Re: [secdir] review of draft-ietf-isis-bfd-tlv-02 >=20 > >>>>> "Stephen" =3D=3D Stephen Kent writes: >=20 > Stephen> The Security Considerations section is just one paragraph, > Stephen> which states that the addition of this feature does not > Stephen> adversely affect the security mechanism (sic) of IS-IS. > I'm > Stephen> not questioning this assertion, based on reading this > Stephen> document, but I think a couple of additional sentences are > Stephen> needed here, to justify the assertion. >=20 >=20 > How about something like: This TLV does not adversely affect the > security of IS-Is. The primary consequence of using the BFD mechanism > in > a case where it is not supported is incorrectly detecting a false > failure of bidirectional forwarding. The primary consequence of not > using BFD when BFD is supported is failure to detect situations in > which > bidirectional forwarding is not happening on a link. At worst, this > leads to a denial of service condition. However, a party who can > manipulate the contents of this TLV is already in a position to create > such a denial of service by disrupting IS-IS routing. The mechanism introduced by this draft is used to determine when/if to use BFD session state as a prerequisite to forming an IS-IS adjacency and/or to trigger IS-IS adjacency state transitions. It does not make any changes to the operation of BFD itself - which I think your wording may unintentionally imply. How about: "The TLV defined within this document describes an addition to the IS-IS Hello protocol. Inappropriate use of this TLV could prevent an IS-IS adjacency from forming or lead to failure to detect bidirectional forwarding failures - each of which is a form of denial of service. However, a party who can manipulate the contents of this TLV is already in a position to create such a denial of service by disrupting IS-IS routing in other ways." ?? >=20 > If the above paragraph is correct, I think it may go some distance to > addressing Stephen's concern. >=20 > However, I wonder how the authentication mechanisms of BFD interact > with > the authentication mechanisms of IS-IS?=20 They do not interact. > Is it possible to get into a > situation where IS-IS is authenticated but BFD is not? If so, that > should be discussed in the security considerations section. It is possible to use BFD in conjunction w IS-IS today - and of course folks are actually doing that. The mechanism introduced here does not change that - it just allows the protocol to operate correctly when IS-IS PDUs and IP/IPv6 packets do not share fate. I don't see that we have introduced any change in the way authentication is used/not used for either IS-IS or BFD - nor have we introduced the use of BFD in conjunction w IS-IS. So I don't see that discussing the point you raise is needed. Les >=20 > --Sam From ginsberg@cisco.com Mon Jul 26 07:43:21 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C72003A6ABD for ; Mon, 26 Jul 2010 07:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.166 X-Spam-Level: X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2flHpsLN+bp for ; Mon, 26 Jul 2010 07:43:20 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8D9983A6AB5 for ; Mon, 26 Jul 2010 07:43:20 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJY7TUyrR7H+/2dsb2JhbACfZHGoA4wmjh6FNgSECIcW X-IronPort-AV: E=Sophos;i="4.55,261,1278288000"; d="scan'208";a="162973157" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 26 Jul 2010 14:43:41 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6QEhfkq005410; Mon, 26 Jul 2010 14:43:41 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 07:43:41 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Jul 2010 07:43:40 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] review of draft-ietf-isis-bfd-tlv-02 Thread-Index: AcssmqKwiivm4TsnTc2SKF0q73T+wgANdQ5Q References: From: "Les Ginsberg (ginsberg)" To: "Stephen Kent" X-OriginalArrivalTime: 26 Jul 2010 14:43:41.0514 (UTC) FILETIME=[F0CF7AA0:01CB2CD0] X-Mailman-Approved-At: Tue, 27 Jul 2010 01:54:26 -0700 Cc: "Stewart Bryant \(stbryant\)" , "Chris Hopps \(chopps\)" , dward@juniper.com, Sam Hartman , secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-isis-bfd-tlv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:43:21 -0000 > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Monday, July 26, 2010 1:12 AM > To: Les Ginsberg (ginsberg) > Cc: Sam Hartman; secdir@ietf.org; dward@juniper.com; Stewart Bryant > (stbryant); Chris Hopps (chopps) > Subject: RE: [secdir] review of draft-ietf-isis-bfd-tlv-02 >=20 > At 12:55 AM -0700 7/26/10, Les Ginsberg (ginsberg) wrote: > >... > > > >The mechanism introduced by this draft is used to determine when/if to > >use BFD session state as a prerequisite to forming an IS-IS adjacency > >and/or to trigger IS-IS adjacency state transitions. It does not make > >any changes to the operation of BFD itself - which I think your > wording > >may unintentionally imply. How about: > > > >"The TLV defined within this document describes an addition to the IS- > IS > >Hello protocol. Inappropriate use of this TLV could prevent an IS-IS > >adjacency from forming or lead to failure to detect bidirectional > >forwarding failures - each of which is a form of denial of service. > >However, a party who can > >manipulate the contents of this TLV is already in a position to create > >such a denial of service by disrupting IS-IS routing in other ways." > > >=20 > That text is much better. I think it is also worth including a > sentence, as you did later in your message, noting that the use of > this new TLV in the IS-IS hello exchange is independent of the use of > authentication for that exchange or for BFD. OK - perhaps: "The TLV defined within this document describes an addition to the IS-IS Hello protocol. Inappropriate use of this TLV could prevent an IS-IS adjacency from forming or lead to failure to detect bidirectional forwarding failures - each of which is a form of denial of service. However, a party who can manipulate the contents of this TLV is already in a position to create such a denial of service by disrupting IS-IS routing in other ways. Use of authentication by IS-IS and/or by BFD is not altered by this document." ?? Les >=20 > Steve From new-work-bounces@ietf.org Mon Jul 26 13:54:07 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA0E53A698C; Mon, 26 Jul 2010 13:54:07 -0700 (PDT) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AEB13A698F for ; Mon, 26 Jul 2010 13:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POiO+yvuS0qV for ; Mon, 26 Jul 2010 13:54:05 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id A8BD03A68B6 for ; Mon, 26 Jul 2010 13:54:05 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OdUgs-0007ky-2R; Mon, 26 Jul 2010 16:54:26 -0400 Message-Id: <6AC3B186-B6EE-4F95-B017-766D356110CD@w3.org> From: Ian Jacobs To: new-work@ietf.org Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Jul 2010 15:54:25 -0500 X-Mailer: Apple Mail (2.936) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 27 Jul 2010 01:54:27 -0700 Subject: [secdir] [New-work] Proposed W3C Charter: Web Notification Working Group (until 2010-08-23) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 20:54:08 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Rich Web Client Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Web Notification Working Group: http://www.w3.org/2010/06/notification-charter As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2010-08-23 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Philippe Le H=E9garet, Interaction Domain Lead . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2006/rwc/Activity [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Jul 27 01:36:56 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2D93A6A82; Tue, 27 Jul 2010 01:36:56 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 82AD93A6A82; Tue, 27 Jul 2010 01:36:55 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100727083655.82AD93A6A82@core3.amsl.com> Date: Tue, 27 Jul 2010 01:36:55 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 27 Jul 2010 01:54:27 -0700 Subject: [secdir] [New-work] WG Review: Port Control Protocol (pcp) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 08:36:56 -0000 A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, August 3, 2010 Port Control Protocol (pcp) --------------------------------------------- Status: Under evaluation Last updated: 2010-07-27 Chairs: TBD Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: pcp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/pcp Archive: http://www.ietf.org/mail-archive/web/pcp/current/maillist.html Description of the working group: Middleboxes such as NATs and firewalls have seen significant deployment in residential and enterprise networks for years. Applications have adapted to such environments. A first family of solutions involves some form of static configuration on the middlebox to perform port opening and/or port forwarding. Another family of solutions works indirectly, using external services to help the establishment of connections and work around the NAT. STUN (RFC 5389) and TURN (RFC 5766) are examples of such solutions. A third family of solutions include protocols that work directly with the middlebox to dynamically open up ports. Universal Plug and Play Internet Gateway Device (UPnP-IGD) and NAT Port Mapping Protocol (NAT-PMP) are examples of such solutions. IPv4 address exhaustion is now forcing ISPs to deploy carrier-grade NAT devices in their network. Those devices could operate either in addition to or instead of an existing NAT device. An example of the former case is a double NAT configuration and an example of the latter case is the application of Dual Stack Lite (DS-Lite) in a network. These deployments will break a fundamental assumption made by protocols, such UPnP or NAT-PMP, that the NAT is located on the same link as the host running the client application. As a result, such applications may break in the presence of a carrier grade NAT. The PCP working group is chartered to standardize a client/server Port Control Protocol (PCP) to enable an explicit dialog with a middlebox such as a NAT or a firewall to open up and/or forward TCP or UDP port, regardless of the location of that middlebox. A PCP client can be used by applications to directly dialog with the middlebox running a PCP server. It can also be used by a home gateways on behalf of applications. This eases the deployment of PCP in situations where applications have already changed to support the APIs necessary for communicating with UPnP-IGD or NAT-PMP. Those applications only work today when the home gateway gets a public address, but may no longer work in situations where the gateway is behind another NAT. Home gateways could use PCP to translate and relay those UPnP and NAP-PMP messages to the PCP server, thus allowing such applications to continue working as they do today. The functionality that enables the control of IPv4 middleboxes such as NAT devices or firewalls can also be useful in IPv6 context, to control IPv6 functionality in firewalls. As such, PCP will be defined for both IPv4 and IPv6. The discovery PCP servers, using classic methods such as DHCP options, is in scope for the PCP working group. The working group will also ensure that the protocol has the necessary security mechanisms. The IETF will make no changes to either NAT-PMP or UPnP-IGP protocols, and they will be used only as is. Deliverables: - PCP protocol description and terminology document - PCP service discovery document - PCP relay of UPnP document - PCP relay of NAT-PMP document Goals & Milestones - Oct 2010 First WG draft on PCP protocol description - Dec 2010 First WG draft on PCP service discovery - Feb 2011 First WG draft on UPnP relay - Feb 2011 First WG draft on NAT-PMP relay - May 2011 Send PCP protocol description to IESG for publication as Proposed Standard - May 2011 Send PCP service discovery to IESG for publication as Proposed Standard - Oct 2011 Send UPnP relay to IESG for publication as Proposed Standard - Oct 2011 Send NAT-PMP relay to IESG for publication as Proposed Standard _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From secdir-bounces@mit.edu Mon Jul 26 06:08:29 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54C2A3A6902 for ; Mon, 26 Jul 2010 06:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.97 X-Spam-Level: X-Spam-Status: No, score=-3.97 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ga0rXsz+yv8L for ; Mon, 26 Jul 2010 06:08:28 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 38D363A68B3 for ; Mon, 26 Jul 2010 06:08:28 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o6QD8mQU009655 for ; Mon, 26 Jul 2010 09:08:48 -0400 Received: from mailhub-dmz-4.mit.edu (MAILHUB-DMZ-4.MIT.EDU [18.7.62.38]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o6QD8iMA009647 for ; Mon, 26 Jul 2010 09:08:44 -0400 Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by mailhub-dmz-4.mit.edu (8.13.8/8.9.2) with ESMTP id o6QD8iYY011905 for ; Mon, 26 Jul 2010 09:08:44 -0400 X-AuditID: 1209190e-b7bbeae000000a09-47-4c4d88c1db41 Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by dmz-mailsec-scanner-3.mit.edu (Symantec Brightmail Gateway) with SMTP id 7A.6E.02569.1C88D4C4; Mon, 26 Jul 2010 09:08:17 -0400 (EDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o6QD6I5D015899; Mon, 26 Jul 2010 06:08:10 -0700 Received: from brm-exedge.brocade.com (brm-exedge.brocade.com [144.49.197.8]) by mx0b-000f0801.pphosted.com with ESMTP id q8hwmgshk-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Jul 2010 06:08:09 -0700 Received: from brm-excashub-1.corp.brocade.com (172.16.72.131) by BRM-EXEDGE-2.corp.brocade.com (172.16.72.249) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 26 Jul 2010 07:08:04 -0600 Received: from brm-exch-3.corp.brocade.com ([169.254.2.126]) by brm-excashub-1.corp.brocade.com ([172.16.72.131]) with mapi; Mon, 26 Jul 2010 07:08:08 -0600 From: Jaehoon Jeong To: Russ Housley , "iesg@ietf.org" Date: Mon, 26 Jul 2010 07:08:04 -0600 Thread-Topic: DISCUSS: draft-ietf-6man-dns-options-bis Thread-Index: AcsW4VriwT/jItJqQzGQvY6Ny1E6HwV4WDcA Message-ID: References: <20100628164527.1FAF928C0E6@core3.amsl.com> In-Reply-To: <20100628164527.1FAF928C0E6@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-26_01:2010-07-26, 2010-07-26, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1007260067 X-Brightmail-Tracker: AAAAARVGGgw= X-MIME-Autoconverted: from base64 to 8bit by pch.mit.edu id o6QD8iMA009647 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Tue, 27 Jul 2010 01:54:40 -0700 Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "ben@nostrum.com" , "secdir@mit.edu" , "IESG \(iesg@ietf.org\)" , "draft-ietf-6man-dns-options-bis@tools.ietf.org" Subject: Re: [secdir] DISCUSS: draft-ietf-6man-dns-options-bis X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 13:08:29 -0000 Dear Russ, This DNS Option Document has addressed all the issues raised by Gen-ART (Ben) and Security Directorate (Vincent) below. http://www.ietf.org/internet-drafts/draft-ietf-6man-dns-options-bis-07.txt We authors believe that you can approve this document. Thanks very much. Best Regards, Paul ============================= Paul (Jaehoon) Jeong Software Engineer, Ph.D Brocade 6000 Nathan Ln N, Plymouth, MN 55442 Phone: +1.763.268.7173 Mobile: +1.651.587.7774 Fax: +1.763.268.6800 Email: pjeong@brocade.com URI: http://www.cs.umn.edu/~jjeong/ -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Monday, June 28, 2010 11:45 AM To: iesg@ietf.org Cc: ben@nostrum.com; 6man-chairs@tools.ietf.org; draft-ietf-6man-dns-options-bis@tools.ietf.org Subject: DISCUSS: draft-ietf-6man-dns-options-bis Discuss: There has been discussion of the Gen-ART Review by Ben Campbell from 2010-06-21. There seems to be agreement on the way to resolve the concerns that were raised, but a revision has not been posted (yet). _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From william.polk@nist.gov Tue Jul 27 02:26:56 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B96593A6A9E for ; Tue, 27 Jul 2010 02:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYIaf5xeHqsX for ; Tue, 27 Jul 2010 02:26:55 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 22AA13A686B for ; Tue, 27 Jul 2010 02:26:54 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (WSXGHUB2.xchange.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o6R9R8Vb010341 for ; Tue, 27 Jul 2010 05:27:08 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 27 Jul 2010 05:26:54 -0400 From: "Polk, William T." To: "secdir@ietf.org" Date: Tue, 27 Jul 2010 05:26:52 -0400 Thread-Topic: secdir lunch is in paris room Thread-Index: AQHLLW3ZriWYfuj9aUWhgD1pKlxZ6w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Subject: [secdir] secdir lunch is in paris room X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 09:26:56 -0000 Folks, Sorry about the late confirmation, but the secdir lunch will be in the 0.5 Paris room. Tim From kent@bbn.com Tue Jul 27 03:49:41 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D040F3A6B90 for ; Tue, 27 Jul 2010 03:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-LhcLqSqnXE for ; Tue, 27 Jul 2010 03:49:41 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 066A63A6AEB for ; Tue, 27 Jul 2010 03:49:41 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:52698 helo=[130.129.114.216]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OdhjW-0001GX-Ao; Tue, 27 Jul 2010 06:50:02 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 27 Jul 2010 06:29:10 -0400 To: "Les Ginsberg (ginsberg)" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "Stewart Bryant \(stbryant\)" , "Chris Hopps \(chopps\)" , dward@juniper.com, Sam Hartman , secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-isis-bfd-tlv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 10:49:41 -0000 >... >"The TLV defined within this document describes an addition to the IS-IS >Hello protocol. Inappropriate use of this TLV could prevent an IS-IS >adjacency from forming or lead to failure to detect bidirectional >forwarding failures - each of which is a form of denial of service. >However, a party who can manipulate the contents of this TLV is already >in a position to create such a denial of service by disrupting IS-IS >routing in other ways. Use of authentication by IS-IS and/or by BFD is >not altered by this document." I'm comfortable with that text. Steve From julienl@qualcomm.com Tue Jul 27 08:22:59 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAEE73A6862; Tue, 27 Jul 2010 08:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFzH7dHiMKPQ; Tue, 27 Jul 2010 08:22:48 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id D816D3A6768; Tue, 27 Jul 2010 08:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1280244187; x=1311780187; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Stephen=20Kent=20|CC:=20Sam=20Hartma n=20,=20Margaret=20Wasserman=0D=0A =09,=20PaddyNallur=20,=0D=0A=09"saag@ietf.org"=20,=20Dong=20Zhang=20,=0D=0A=09 "secdir@ietf.org"=20|Date:=20Tue,=2027 =20Jul=202010=2008:23:06=20-0700|Subject:=20RE:=20[secdir ]=20Interest=20in=20draft-dong-savi-cga-header-03.txt=3B =0D=0A=20=20possibility=20of=20a=20five=20minute=20slot =20at=20saag?|Thread-Topic:=20[secdir]=20Interest=20in=20 draft-dong-savi-cga-header-03.txt=3B=0D=0A=20=20possibili ty=20of=20a=20five=20minute=20slot=20at=20saag? |Thread-Index:=20Acspj0CZ+SySXdOnRcaAON+nc4AYiAEDgjcg |Message-ID:=20|References:=20=20=0D =0A=20=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20e n-US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20multipart/altern ative=3B=0D=0A=09boundary=3D"_000_BF345F63074F8040B58C00A 186FCA57F1F6688540FNALASEXMB04na_"|MIME-Version:=201.0; bh=ZSpJ/zcGcQqQi6Uwh5V0t/WGfW90uPMeNazff1EHNRs=; b=mmqq8rmFJV+S4MWGiqhigrO4GQg3jWQIkD4zZRGUmYbQgwvKYvZgbjAf LrVy/cEvlmlklV3nFXGjGC/IpRwz88K6XxCuDElB/OrVwYCcMEmLmlgj4 NOaOsa8sBNrwIgRMRI3koN67lJSmu06q5eBRiMNR3NaypJdBkFSb9BD6v 4=; X-IronPort-AV: E=McAfee;i="5400,1158,6055"; a="48797070" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine02.qualcomm.com with ESMTP; 27 Jul 2010 08:23:07 -0700 X-IronPort-AV: E=Sophos;i="4.55,267,1278313200"; d="scan'208,217";a="47602859" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 27 Jul 2010 08:23:07 -0700 Received: from nasanexhc04.na.qualcomm.com (172.30.48.17) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 27 Jul 2010 08:23:09 -0700 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.0.694.0; Tue, 27 Jul 2010 08:23:09 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Tue, 27 Jul 2010 08:23:08 -0700 From: "Laganier, Julien" To: Stephen Kent Date: Tue, 27 Jul 2010 08:23:06 -0700 Thread-Topic: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? Thread-Index: Acspj0CZ+SySXdOnRcaAON+nc4AYiAEDgjcg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BF345F63074F8040B58C00A186FCA57F1F6688540FNALASEXMB04na_" MIME-Version: 1.0 Cc: Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 15:23:00 -0000 --_000_BF345F63074F8040B58C00A186FCA57F1F6688540FNALASEXMB04na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Steve, Please see some comments below, marked with [JL]. From: Stephen Kent [mailto:kent@bbn.com] Sent: Thursday, July 22, 2010 2:46 AM To: Laganier, Julien Cc: Sam Hartman; Margaret Wasserman; PaddyNallur; saag@ietf.org; Dong Zhang= ; secdir@ietf.org Subject: RE: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possib= ility of a five minute slot at saag? At 10:35 AM -0700 7/21/10, Laganier, Julien wrote: Steve, Stephen Kent wrote: > > Sam, > > Based on a quick reading, I am troubled by many aspects of this > proposal. > > CGAs were intended to afford privacy for IPv6 users, while allowing a > first-hop router to verify the binding between the host asserting the > address and the address in question. My recollection is that a form of CGA were first proposed to secure the bin= ding between a host asserting that a Mobile IPv6 home address is reachable = at a care-of address (via a MIPv6 Binding Update) and the home address in q= uestion. Section 7.3 of RFC 3792 (the original CGA RFC) says: 7.3. Privacy Considerations CGAs can give the same level of pseudonymity as the IPv6 address privacy extensions defined in RFC 3041 [RFC3041]. An IP host can generate multiple pseudo-random CGAs by executing the CGA generation algorithm of Section 4 multiple times and by using a different random or pseudo-random initial value for the modifier every time. The host should change its address periodically as in [RFC3041]. When privacy protection is needed, the (pseudo)random number generator used in address generation SHOULD be strong enough to produce unpredictable and unlinkable values. Advice on random number generation can be found in [RFC1750]. This text motivates my characterization of the privacy aspects of CGAs, wh= ich depends on the ability of a hos to use different CGAs, either serially = or in parallel. I think of the CGA mechanism as a way to enable use of var= ried address by a host, but to also enable a first hop router, to have conf= idence that an address of this sort (generated in an auto-config fashion) i= s not being hijacked by another local host. [JL] I read the above RFC 3972 text as not negating the privacy feature tha= t can be afforded by periodically regenerating an IPv6 as in RFC 3041. Thus= a CGA might or might not have privacy feature, and privacy is thus a featu= re that is orthogonal to CGAs. The central feature of a CGA is that one can= verify that host "owns" the address (own in the sense that it's the one th= at generated in the first place, i.e., it's not hijacked.) >From my perspective the key intent behind the use CGA's was the ability to= verify the binding without recourse to an infrastructure, not privacy. I also don't see how the use of CGA's would afford to an IPv6 user any bett= er privacy than another IPv6 address given that it is uniquely bound to a l= ong (1024+ bits) public key. I think the text above, and the cited text in RFC 3041 explains the rationa= le for privacy assertions re CGAs. [JL] Understood. > The proposal to use CGAs in ACLs seems to negate the privacy feature, > because it would (I assume) call for the CGAs to be static (for ease > of ACL management). I agree that if CGAs were to be used in ACLs they would need to be static (= or long-term), but this does not negate a privacy feature that CGA's do not= have. yes, it does, because the privacy is afforded by the host generating a sequ= ence of CGAs for parallel or serial use is in conflict with use of a static= CGA as an address space identifier for access control purposes. [JL] I think we agree but differ on how we're expressing it. I'd say that t= he use of static addresses in ACLs is in conflict with the privacy afforded= by being able to periodically regenerate an address, as per 3041. > The proposal says that "any host along the path" can engage in an > exchange to cause the subject host to verify itself as the "owner" of > the address. this is a very big deviation from the much more limited, > local SeND context. As above, CGA use is not limited to a local context such as SEND. In partic= ular, the use of CGA's for Mobile IPv6 security is in a _global_ context. I admit that I was not thinking about CGAs in the mobile IP context; RFC 39= 72 does refer to mobile nodes, but does not say much in that regard. RFC 45= 81, which updated 3972, never mentions mobile nodes. [JL] The use of CGA in the mobile IP context was documented later, in RFC 4= 866 "Enhanced Route Optimization for Mobile IPv6". > The proposal also calls for the sender to generate the signature on > the payload of the packet, ala IPsec in Transport mode. The document > cites RFC 3971 (the SeND) spec, which calls for sig generation is a > very different context, i.e., NDP packets in the SeND exchange. > > This proposal includes an example (from the wireless context) > suggesting that the sig is to be generated for every packet sent by a > host, a requirement that would place a substantial burden on a host. > IPsec rejected solutions of this sort for performance reasons. If there were to be only one intermediary on-path node going to verify that= the packets were generated by the CGA owner, it would be possible to execu= te a key exchange protocol bound to the CGAs of the sending host and the ve= rifying node, and use symmetric keying material derived from that exchange = to afford integrity protection to every packet at a cost comparable to that= of IPsec providing integrity protection. yes, one could do what you suggest above, but that would be duplicating IPs= ec (ESP-NULL) functionality, which I hope would be frowned upon :-). [JL] Well that could be all done based on IPsec, as you note below. > Conversely, if only an initial packet exchange, involves the signed > packet from the host, the secruity offered is much lower, making it > vulnerable to MITM attacks. As above, an initial packet exchange could be used to derive symmetric keys= bound to the CGA's of the parties involved. and IPsec would be a good idea here too :-). [JL] Agree > Also note that SeND requires a trust anchor to be shared between the > host and its local router. This is a reasonable assumption for that > local context, but it less viable in a more general source/destination > context that may extend outside a local space, as many of the offered > examples do. The SEND trust anchor is used by hosts to verify a router certificates chai= n. The router public key being certified is used to sign the router adverti= sement messages of the router discovery function of ND. In contrast, hosts uses uncertified public keys that are used to generate C= GA's and sign neighbor solicitations and advertisement messages of the addr= ess resolution function of ND. Thus the SEND requirement of hosts and router sharing a trust anchor is ent= irely orthogonal to the use and generation of CGA's. Mostly, but not quite. if a host is challenged to provide a signed sequence= of packets by a purported intermediary, how does the host know that the ch= allenge is legitimate, and not just a DoS attack? [JL] if there's execution of a key establishment protocol based on the publ= ic keys bound to the CGAs, the opportunity for a DoS attack is reduced and = more in line with what's been done in the context of BTNS. [JL] All of that being said, I agree that the requirement to use static CGA= s is a bad thing. That requirement could be removed if the ACLs were based = on the public keys generating the CGAs, rather than the CGAs themselves. Bu= t if that were the case, coupled with the use of a key establishment protoc= ol, then it becomes dubious what is the additional value provided by CGAs a= s IPsec seems to afford the required security service: access control, inte= grity protection. --julien --_000_BF345F63074F8040B58C00A186FCA57F1F6688540FNALASEXMB04na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [secdir] Interest in draft-dong-savi-cga-header-03.txt

Hi Steve,

 

Please see some comments below, marked with [JL].=

 

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Thursday, July 22, 2010 2:46 AM
To: Laganier, Julien
Cc: Sam Hartman; Margaret Wasserman; PaddyNallur; saag@ietf.org; Don= g Zhang; secdir@ietf.org
Subject: RE: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag?

 

At 10:35 AM -0700 7/21/10, Laganier, Julien wrote:

Steve,

Stephen Kent wrote:
>
> Sam,
>
> Based on a quick reading, I am troubled by many aspects of this
> proposal.
>
> CGAs were intended to afford privacy for IPv6 users, while allowing a<= br> > first-hop router to verify the binding between the host asserting the<= br> > address and the address in question.

My recollection is that a form of CGA were first proposed to secure the bin= ding between a host asserting that a Mobile IPv6 home address is reachable at a care-of address (via a MIPv6 Binding Update) and the home address in questi= on.


Section 7.3 of RFC 3792 (the original CGA RFC) says:

 

7.3.  Privacy Considerations

   CGAs can give the same level of pseudonymity as the IPv6 addre= ss
   privacy extensions defined in RFC 3041 [RFC3041].&nb= sp; An IP host can
   generate multiple pseudo-random CGAs by executing the CGA generation
   algorithm of Section 4= multiple times and by using a different random
   or pseudo-random initial value for the modifier every time.&nb= sp; The host
   should change its address periodically as in [RFC3041].&nb= sp; When privacy
   protection is needed, the (pseudo)random number generator used= in
   address generation SHOULD be strong enough to produce unpredictable
   and unlinkable values.  Advice on random number generatio= n can be

   found in [RFC1750].

This text  motivates my characterization of the p= rivacy aspects of CGAs, which depends on the ability of a hos to use different CGA= s, either serially or in parallel.  I think of the CGA mechanism as a way= to enable use of varried address by a host, but to also enable a first hop rou= ter, to have confidence that an address of this sort (generated in an auto-confi= g fashion) is not being hijacked by another local host.

 =

[JL] I read the above RFC 3972 text as not negating the priv= acy feature that can be afforded by periodically regenerating an IPv6 as in RFC 3041. Thus a CGA might or might not have privacy feature, and privacy is th= us a feature that is orthogonal to CGAs. The central feature of a CGA is that on= e can verify that host “owns” the address (own in the sense that = it’s the one that generated in the first place, i.e., it’s not hijacked.)<= o:p>

>From my perspective the key intent behind the use = CGA's was the ability to verify the binding without recourse to an infrastructure= , not privacy.

I also don't see how the use of CGA's would afford to = an IPv6 user any better privacy than another IPv6 address given that it is uniquely bound to a long (1024+ bits) public key.

 

I think the text above, and the cited text in RFC 3041= explains the rationale for privacy assertions re CGAs.

 =

[JL] Understood.

 
> The proposal to use CGAs in ACLs seems to negate the privacy feature,<= br> > because it would (I assume) call for the CGAs to be static (for ease > of ACL management).

I agree that if CGAs were to be used in ACLs they would need to be static (= or long-term), but this does not negate a privacy feature that CGA's do not ha= ve.

 

yes, it does, because the privacy is afforded by the h= ost generating a sequence of CGAs for parallel or serial use is in conflict wit= h use of a static CGA as an address space identifier for access control purpo= ses.

 =

[JL] I think we agree but differ on how we’re expressi= ng it. I’d say that the use of static addresses in ACLs is in conflict with = the privacy afforded by being able to periodically regenerate an address, as pe= r 3041.

 
> The proposal says that "any host along the path" can engage = in an
> exchange to cause the subject host to verify itself as the "owner" of
> the address. this is a very big deviation from the much more limited,<= br> > local SeND context.

As above, CGA use is not limited to a local context such as SEND. In particular, the use of CGA's for Mobile IPv6 security is in a _global_ cont= ext.

 

I admit that I was not thinking about CGAs in the mobi= le IP context; RFC 3972 does refer to mobile nodes, but does not say much in that regard. RFC 4581, which updated 3972, never mentions mobile nodes.

 =

[JL] The use of CGA in the mobile IP context was documented later, in RFC 4866 “Enhanced Route Optimization for Mobile IPv6”= ;.

 > The proposal also calls for the sender to g= enerate the signature on
> the payload of the packet, ala IPsec in Transport mode.  The docu= ment
> cites RFC 3971 (the SeND) spec, which calls for sig generation is a > very different context, i.e., NDP packets in the SeND exchange.
>
> This proposal includes an example (from the wireless context)

> suggesting that the sig is to be generated for ev= ery packet sent by a
> host, a requirement that would place a substantial burden on a host. > IPsec rejected solutions of this sort for performance reasons.

If there were to be only one intermediary on-path node= going to verify that the packets were generated by the CGA owner, it would be possible to execute a key exchange protocol bound to the CGAs of the sendin= g host and the verifying node, and use symmetric keying material derived from that exchange to afford integrity protection to every packet at a cost comparable to that of IPsec providing integrity protection.

 

yes, one could do what you suggest above, but that wou= ld be duplicating IPsec (ESP-NULL) functionality, which I hope would be frowned u= pon :-).

 =

[JL] Well that could be all done based on IPsec, as you note= below.

 > Conversely, if only an initial packet excha= nge, involves the signed
> packet from the host, the secruity offered is much lower, making it > vulnerable to MITM attacks.

As above, an initial packet exchange could be used to derive symmetric keys bound to the CGA's of the parties involved.

 

and IPsec would be a good idea here too :-).

 =

[JL] Agree


> Also note that SeND requires a trust anchor to be shared between the > host and its local router. This is a reasonable assumption for that > local context, but it less viable in a more general source/destination=
> context that may extend outside a local space, as many of the offered<= br> > examples do.

The SEND trust anchor is used by hosts to verify a router certificates chai= n. The router public key being certified is used to sign the router advertisement messages of the router discovery function of ND.

In contrast, hosts uses uncertified public keys that are used to generate C= GA's and sign neighbor solicitations and advertisement messages of the address resolution function of ND. 

Thus the SEND requirement of hosts and router sharing = a trust anchor is entirely orthogonal to the use and generation of CGA's.

 

Mostly, but not quite. if a host is challenged to prov= ide a signed sequence of packets by a purported intermediary, how does the host k= now that the challenge is legitimate, and not just a DoS attack?

 

[JL] if there’s execution of a key establishment proto= col based on the public keys bound to the CGAs, the opportunity for a DoS attac= k is reduced and more in line with what’s been done in the context of BTNS= .

 

[JL] All of that being said, I agree that the requirement to= use static CGAs is a bad thing. That requirement could be removed if the ACLs w= ere based on the public keys generating the CGAs, rather than the CGAs themselv= es. But if that were the case, coupled with the use of a key establishment protocol, then it becomes dubious what is the additional value provided by = CGAs as IPsec seems to afford the required security service: access control, integrity protection.

 

--julien

 

 

--_000_BF345F63074F8040B58C00A186FCA57F1F6688540FNALASEXMB04na_-- From margaretw42@gmail.com Tue Jul 27 02:36:18 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A02FA3A6A55; Tue, 27 Jul 2010 02:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJzw00mMKnMR; Tue, 27 Jul 2010 02:36:16 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 489283A67E5; Tue, 27 Jul 2010 02:36:15 -0700 (PDT) Received: by ewy22 with SMTP id 22so1301773ewy.31 for ; Tue, 27 Jul 2010 02:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=yUUhfgIW/XCUHlV5R0zii8XdsUG/G1wbdhyUUXnDoi4=; b=VuEFvKGXnVCiTWu5TtlPhsEZvQM3X4REFOL6ySpO3dqdq1bJgoONylzJ4wP5uhBsfO 2KyxuL+/pnTma4bBC8LX7D1X3W8dXb1fsNa2OQFYdO4Ni6Pd338rBv2g3UPHHj0fdipx R7PWDnE/JhNZ1/In9YohQ70ZfZ086DhSzh+eQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=CIWwbxq8LOJTsl30DyDKBXulPpSoZklLNZiERAuLucBp6Lgk/91j16D9T9n19HavIY hhKBcswCh2C8E7CVXEMIFtUL57jjhDUubNH4gNxIXotMCIU9zQ7E0jkSnuWPZ4kc2hFe jF4yrSB4F8SO4d5lKxZCHbiyP+0W/7/UKcvps= Received: by 10.213.45.194 with SMTP id g2mr4440373ebf.0.1280223396269; Tue, 27 Jul 2010 02:36:36 -0700 (PDT) Received: from dhcp-716e.meeting.ietf.org (dhcp-716e.meeting.ietf.org [130.129.113.110]) by mx.google.com with ESMTPS id a48sm7248730eei.19.2010.07.27.02.36.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Jul 2010 02:36:35 -0700 (PDT) Message-Id: <821DAA3A-8F9E-4C16-9894-A7425362E135@gmail.com> From: Margaret Wasserman To: Stephen Kent In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Jul 2010 11:36:15 +0200 References: <438B2D37-5C58-4E1F-9E69-75E80D76C570@gmail.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Wed, 28 Jul 2010 08:02:02 -0700 Cc: Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [secdir] [saag] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 09:36:18 -0000 Hi Steve, Thanks for your additional feedback! I am finding this discussion very useful. On Jul 27, 2010, at 10:43 AM, Stephen Kent wrote: >> There may be an inherent incompatibility between access control and >> anonymity, but that does not mean that the use of CGAs for access >> control is mutually exclusive with their use for privacy by the >> same node. > > I agree, in principle, but in practice I think there may serious > problems. Hosts would have to support both modes of operation and > offer a decent UI to enable users to choose which type of CGA they > want in a given context. I worry that the latter will be hard to do > well, and thus users may, in reality, be deprived of the anonymity > that CGAs can offer, because hosts don't offer a UI that is > manageable. In the IETF privacy address work (so far) this is not so much a matter of having a UI (accessed by users) as having an API where applications that want temporary/privacy addresses can select that option for a specific application (as a socket option, for example). Applications that don't request privacy addresses don't get them. Generating ones addresses as CGAs doesn't really change this picture... If an application does not specify a privacy socket option, it could use a static CGA, while applications that do request privacy could use CGAs that are generated for a particular session or a given time period. > >> A node could have a CGA (or a set of CGAs) that it uses to access >> certain resources. Those address(es) could be used in access >> control lists, etc. However, the same node could still generate >> CGAs or IPv6 Privacy Addresses for temporary use when anonymity/ >> privacy is desired. > > see my comment above. also, your text here assumes that privacy is > the rare case, which prejudices the discussion :-). Actually, I think that privacy addresses should be the common case for outgoing client/server applications (e.g. web browsers). However, I believe that systems will continue to have static addresses (which may be static CGAs) if they need to run servers that can be reached at a particular address, if they are using referrals that should remain valid over a longer period of time, or if they are using applications where the source IP address is used as part of an access control system or any other mechanism that uses the source IP address to identify the source of the traffic for any reason. > > I agree that 4941 provides a more concrete discussion of privacy for > IPv6 addresses. But the discussion in section 2.4 of that RFC > describes the simple notion of changing IIDs over time, and it > suggests selecting the IIDs in a pseudo random fashion. CGAs meet > these criteria. I think the authors of 4941 erred in dismissing the > use of CGAs (in section 3.2.3). The authors of 4991 seem to assume > that the public key used with CGAs is fixed, even though 3792 does > not require/suggest that. Also, while I agree that the MD5-based > randomization process in 4991 is faster than the analogous hash > computation for 3972, I don't think the difference is significant > with current processors and most, reasonable scenarios. I agree with you that RFC 4991 could use some improvements in this area. If we do decide to charter a separate cgasec WG, I think it would make sense to include an update to this section of RFC 4991 in a charter for that group. Otherwise, it could potentially be done in an existing WG, such as 6man or intarea. > As I noted in my message, RFC 3972 makes a number of references to > privacy, so it was clearly a major consideration in the CGA design. > I see CGAs as balancing the option of privacy with a need for local > address use validation. The local address use validation is a good > secruity practice, with minimal, adverse privacy concerns. If we > say that CGAs are not to be used when privacy is desired, and if > local net managers demand CGAs for local address use validation, > then we have deprived users of all address privacy options. I'd not > like to see that outcome. I have not proposed that we disallow CGAs for privacy purposes, and I agree that we shouldn't do that. I don't believe, however, that using static CGAs for secure access control (where identifying the source is explicitly desired) is incompatible with using other CGAs for privacy (for applications where privacy is desired) on the same node. I think this would work quite well within the existing APIs that we have designed for privacy addresses. >> There is also a possibility that the use of CGAs and a CGA >> extension in the early packets of an exchange could be used to set- >> up an IPsec SA for the remainder of the flow. In cases where a >> flow will consist of more than a few packets, this would probably >> be a better approach than signing all of the packets in an exchange. > > I agree. There is also the possibility (that a few other people have raised with me this week) that we could design an IKEv2 SPI type (I apologize if that isn't quite the right terminology) that contains a CGA and CGA parameters, and that information could be used to set-up an IPsec SA. I am not sure if a transition to IPsec is the best choice for very short flows, though, such as the syslog or SNMP trap/inform use cases in the draft. I would be interested in your opinion about the trade- offs involved. I am not, personally, focusing on the exact details of our specific proposal at this point. I am interested in discussing how/if CGAs are a suitable mechanism to do one or both of the following things: 1) Produce viable security mechanisms that are simpler to configure than existing solutions. In many cases, this may only involve minor extensions or tweaks to existing mechanisms (e.g. the new IKE SPI type described above). 2) Offer a practical alternative to the insecure Access Control Lists (ACLs) that are still in wide use today. Part of being a practical alternative (that will actually get deployed) is that configuring the new solution cannot require considerably more work or expertise than configuring an insecure ACL. Do those seem like reasonable goals to you? Do you think there is some potential that we could accomplish these things using CGAs? >>> Mostly, but not quite. if a host is challenged to provide a signed >>> sequence of packets by a purported intermediary, how does the host >>> know that the challenge is legitimate, and not just a DoS attack? >> >> As we discuss in the security considerations section, this is an >> open issue with the specification. There are some possibilities >> for how to deal with this issue -- perhaps we could require that >> the requester generate it's own CGA, sign the request and include >> an CGA extension header on the request? > > I don' think that is a viable approach for all of these cases cited > in the proposal, e.g., it would require a host to be aware of the > CGA of any intermediary system that might want to challenge the > host. Maybe the scenarios in the proposal need to be scaled back. I'm not sure which use cases would need to be scaled back in this case and why. Could you explain a bit more? > >> Or perhaps it would be better for the requester to do some other >> costly operation to make this attack as expensive for the attacker >> as it would be for the target? There may be other possibilities >> for how to address this issue... it is one of the things that we >> should work out in the IETF before publishing this document. > If the CGA challenge comes from a destination (not an intermediate > system) and the host has a relationship with that destination, there > probably are ways to alleviate this concern. But, if we look at > scenarios like web server access, the TLS server cert model seems > much more reasonable as a way of identifying the destination. I am not creative/imaginative enough to believe that CGA access control will replace TLS! :-) > > Given the rising interest in issuing and publishing certs using > DNSSEC, I think that model may be more appropriate for source/ > destination access control. We have a number of security protocols > that know how to use certs, but we have had a hard time overcoming > the hurdles associated with the issuance and distribution of certs > in a very large scale fashion. DNSSEC provides an ideal basis for > certifying the binding between a DNS name and a public key, in a > fashion that does not require handing $ over to a trusted third party. CGAs have similar properties in this regard. They don't require configuring certificates on end nodes, and they don't require sending anyone any money. I share your preferences in this area. :-) Using DNSSEC to resolve this problem is an interesting idea... Is there a draft, paper or other published document that describes how to do this? Or could you flesh it out a bit? I would be interested in understanding this approach better, so that I could understand the trade-offs between these two approaches. Margaret From kent@bbn.com Thu Jul 29 00:53:51 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8DC73A69AD; Thu, 29 Jul 2010 00:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEUKR26L4U6F; Thu, 29 Jul 2010 00:53:50 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 4E0743A699D; Thu, 29 Jul 2010 00:53:50 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:39281 helo=[130.129.114.216]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OeNwS-0004U9-P3; Thu, 29 Jul 2010 03:54:13 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <821DAA3A-8F9E-4C16-9894-A7425362E135@gmail.com> References: <438B2D37-5C58-4E1F-9E69-75E80D76C570@gmail.com> <821DAA3A-8F9E-4C16-9894-A7425362E135@gmail.com> Date: Thu, 29 Jul 2010 03:40:35 -0400 To: Margaret Wasserman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [secdir] [saag] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 07:53:52 -0000 At 11:36 AM +0200 7/27/10, Margaret Wasserman wrote: >Hi Steve, >>,,, > >In the IETF privacy address work (so far) this is not so much a >matter of having a UI (accessed by users) as having an API where >applications that want temporary/privacy addresses can select that >option for a specific application (as a socket option, for example). >Applications that don't request privacy addresses don't get them. Thanks; I didn't know what the model was. I do see possible problems with this model. It's somewhat reminiscent of the model we had in mind for how to use the TOS field in IP, back in the late 70's and early 80's. That didn't work because apps generally didn't make API calls to invoke TOS, and didn't offer a UI to enable users to sya TOS they thought they needed, ... >Generating ones addresses as CGAs doesn't really change this >picture... If an application does not specify a privacy socket >option, it could use a static CGA, while applications that do >request privacy could use CGAs that are generated for a particular >session or a given time period. Again, I agree in principle, but I worry that in practice the default will be static CGAs with no real user controls to invoke privacy features. > >>... > >Actually, I think that privacy addresses should be the common case >for outgoing client/server applications (e.g. web browsers). that's an interesting case, which may illustrate why this strikes me as a hard problem. Folks visit a range of web sites, some of which require user auth (for access control), and others that do not. If CGAs were to be used for access control, users might if confusing managing switching between static and dynamic CGAs depending on the sites being visited. >However, I believe that systems will continue to have static >addresses (which may be static CGAs) if they need to run servers >that can be reached at a particular address, if they are using >referrals that should remain valid over a longer period of time, or >if they are using applications where the source IP address is used >as part of an access control system or any other mechanism that uses >the source IP address to identify the source of the traffic for any >reason. I've been focusing on the user side of this issue. Servers need static DNS names, irrespective of whether their addresses are static or dynamic (with dynamic DNS). But, I agree that most servers (not use by phishers ans spammers) don't need addresses that vary for privacy purposes. >... >I agree with you that RFC 4991 could use some improvements in this >area. If we do decide to charter a separate cgasec WG, I think it >would make sense to include an update to this section of RFC 4991 in >a charter for that group. Otherwise, it could potentially be done >in an existing WG, such as 6man or intarea. Sure. >>... > >I have not proposed that we disallow CGAs for privacy purposes, and >I agree that we shouldn't do that. I don't believe, however, that >using static CGAs for secure access control (where identifying the >source is explicitly desired) is incompatible with using other CGAs >for privacy (for applications where privacy is desired) on the same >node. I think this would work quite well within the existing APIs >that we have designed for privacy addresses. My concern is that, in advocating use of CGAs for access control, we will effectively kill CGA use for privacy, for the reasons cited above. I don't mean to suggest that you are trying to preclude use of CGAs for privacy; I just see this as a likely, unintended side-efect. >>... > >There is also the possibility (that a few other people have raised >with me this week) that we could design an IKEv2 SPI type (I >apologize if that isn't quite the right terminology) that contains a >CGA and CGA parameters, and that information could be used to set-up >an IPsec SA. Not the right terminology, but let's not focus on that. I saw that Julien published an I-D that seems to have this flavor, although I have not read it. >I am not sure if a transition to IPsec is the best choice for very >short flows, though, such as the syslog or SNMP trap/inform use >cases in the draft. I would be interested in your opinion about the >trade-offs involved. Maybe. But one can establish an SA and reuse it over time, to amortize the SA establishment overhead. So, it depends. >I am not, personally, focusing on the exact details of our specific >proposal at this point. I am interested in discussing how/if CGAs >are a suitable mechanism to do one or both of the following things: > >1) Produce viable security mechanisms that are simpler to configure >than existing solutions. In many cases, this may only involve minor >extensions or tweaks to existing mechanisms (e.g. the new IKE SPI >type described above). > >2) Offer a practical alternative to the insecure Access Control >Lists (ACLs) that are still in wide use today. Part of being a >practical alternative (that will actually get deployed) is that >configuring the new solution cannot require considerably more work >or expertise than configuring an insecure ACL. > >Do those seem like reasonable goals to you? Do you think there is >some potential that we could accomplish these things using CGAs? I agree that address-based ACLs are insecure, and it would be nice to have better alternatives. Whether CGAs are a good choice for this depends on the the context in which the ACL is being used, since the context determines what alternatives are viable. For IPsec, we'll have to sees the detail of the proposal. We have seen a lot of interest in using the DNS, now that DNESEC is being more widely deployed, as a way to ease the configuration burden for secruity protocols like TLS and IPsec. So CGAs are not the only game in town, in this context. >>... > >I'm not sure which use cases would need to be scaled back in this >case and why. Could you explain a bit more? Sorry if I was not clear. I think that having an intermediate node challenge a host may be problematic. The host might not have a way to know the ID of an intermediate node, which creates the sort of DoS concern I cited. In contrast, a host can be expected to know the ID of the destination that it is attempting to reach, making these two cases potentially very different. >... >I am not creative/imaginative enough to believe that CGA access >control will replace TLS! :-) agreed. >>... > >CGAs have similar properties in this regard. They don't require >configuring certificates on end nodes, and they don't require >sending anyone any money. I share your preferences in this area. :-) good. >Using DNSSEC to resolve this problem is an interesting idea... Is >there a draft, paper or other published document that describes how >to do this? Or could you flesh it out a bit? I would be interested >in understanding this approach better, so that I could understand >the trade-offs between these two approaches. There was a bar BoF this week. We'll see what comes from that. Steve From kent@bbn.com Thu Jul 29 00:53:53 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95DB23A69C2; Thu, 29 Jul 2010 00:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijIKILZk3yrf; Thu, 29 Jul 2010 00:53:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 536C13A69AD; Thu, 29 Jul 2010 00:53:52 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:39281 helo=[130.129.114.216]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OeNwU-0004U9-8S; Thu, 29 Jul 2010 03:54:14 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 29 Jul 2010 03:53:34 -0400 To: "Laganier, Julien" From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-931732443==_ma============" Cc: Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [secdir] [saag] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 07:53:53 -0000 --============_-931732443==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >... > >[JL] I read the above RFC 3972 text as not negating the privacy >feature that can be afforded by periodically regenerating an IPv6 as >in RFC 3041. Thus a CGA might or might not have privacy feature, and >privacy is thus a feature that is orthogonal to CGAs. The central >feature of a CGA is that one can verify that host "owns" the address >(own in the sense that it's the one that generated in the first >place, i.e., it's not hijacked.) I agree that the primary motivation for CGAs arose in the SeND context, and that privacy is an independent feature. But, the context in which CGAs were intended to provide an ability to establish a binding to an IPv6 address was local. When one moves beyond this local context, and one advocates having more distant nodes challenge a host, this creates privacy questions. >... > >yes, it does, because the privacy is afforded by the host generating >a sequence of CGAs for parallel or serial use is in conflict with >use of a static CGA as an address space identifier for access >control purposes. > >[JL] I think we agree but differ on how we're expressing it. I'd say >that the use of static addresses in ACLs is in conflict with the >privacy afforded by being able to periodically regenerate an >address, as per 3041. Agreed. >I admit that I was not thinking about CGAs in the mobile IP context; >RFC 3972 does refer to mobile nodes, but does not say much in that >regard. RFC 4581, which updated 3972, never mentions mobile nodes. > >[JL] The use of CGA in the mobile IP context was documented later, >in RFC 4866 "Enhanced Route Optimization for Mobile IPv6". OK. >.... > >yes, one could do what you suggest above, but that would be >duplicating IPsec (ESP-NULL) functionality, which I hope would be >frowned upon :-). > >[JL] Well that could be all done based on IPsec, as you note below. Glad to see that we agree on this point. But, note that IKE specifically passes credentials (e.g., certs) only after establishing an encrypted channel. This was done to protect the user's asserted ID. Thus, if one uses a CGA as an ID (i.e., and input to an access control decision) with IPsec, one is undermining that privacy (traffic analysis countermeasure) feature of IPsec. >... > > >Mostly, but not quite. if a host is challenged to provide a signed >sequence of packets by a purported intermediary, how does the host >know that the challenge is legitimate, and not just a DoS attack? > >[JL] if there's execution of a key establishment protocol based on >the public keys bound to the CGAs, the opportunity for a DoS attack >is reduced and more in line with what's been done in the context of >BTNS. I'll have to think about that. >[JL] All of that being said, I agree that the requirement to use >static CGAs is a bad thing. That requirement could be removed if the >ACLs were based on the public keys generating the CGAs, rather than >the CGAs themselves. But if that were the case, coupled with the use >of a key establishment protocol, then it becomes dubious what is the >additional value provided by CGAs as IPsec seems to afford the >required security service: access control, integrity protection. I think I agree with your observation, which seems to undercut the "CGAs as inputs to ACLs" argument :-). Steve --============_-931732443==_ma============ Content-Type: text/html; charset="us-ascii" Re: [saag] [secdir] Interest in draft-dong-savi-cga-header
...
 
[JL] I read the above RFC 3972 text as not negating the privacy feature that can be afforded by periodically regenerating an IPv6 as in RFC 3041. Thus a CGA might or might not have privacy feature, and privacy is thus a feature that is orthogonal to CGAs. The central feature of a CGA is that one can verify that host "owns" the address (own in the sense that it's the one that generated in the first place, i.e., it's not hijacked.)

I agree that the primary motivation for CGAs arose in the SeND context, and that privacy is an independent feature. But, the context in which CGAs were intended to provide an ability to establish a binding to an IPv6 address was local. When one moves beyond this local context, and one advocates having more distant nodes challenge a host, this creates privacy questions.
 
...

 
yes, it does, because the privacy is afforded by the host generating a sequence of CGAs for parallel or serial use is in conflict with use of a static CGA as an address space identifier for access control purposes.
 
[JL] I think we agree but differ on how we're expressing it. I'd say that the use of static addresses in ACLs is in conflict with the privacy afforded by being able to periodically regenerate an address, as per 3041.

Agreed.

I admit that I was not thinking about CGAs in the mobile IP context; RFC 3972 does refer to mobile nodes, but does not say much in that regard. RFC 4581, which updated 3972, never mentions mobile nodes.
 
[JL] The use of CGA in the mobile IP context was documented later, in RFC 4866 "Enhanced Route Optimization for Mobile IPv6".

OK.
....
 
yes, one could do what you suggest above, but that would be duplicating IPsec (ESP-NULL) functionality, which I hope would be frowned upon :-).
 
[JL] Well that could be all done based on IPsec, as you note below.

Glad to see that we agree on this point. But, note that IKE specifically passes credentials (e.g., certs) only after establishing an encrypted channel. This was done to protect the user's asserted ID. Thus, if one uses a CGA as an ID (i.e., and input to an access control decision) with IPsec, one is undermining that privacy (traffic analysis countermeasure) feature of IPsec.

...

 
Mostly, but not quite. if a host is challenged to provide a signed sequence of packets by a purported intermediary, how does the host know that the challenge is legitimate, and not just a DoS attack?
 
[JL] if there's execution of a key establishment protocol based on the public keys bound to the CGAs, the opportunity for a DoS attack is reduced and more in line with what's been done in the context of BTNS.

I'll have to think about that.

[JL] All of that being said, I agree that the requirement to use static CGAs is a bad thing. That requirement could be removed if the ACLs were based on the public keys generating the CGAs, rather than the CGAs themselves. But if that were the case, coupled with the use of a key establishment protocol, then it becomes dubious what is the additional value provided by CGAs as IPsec seems to afford the required security service: access control, integrity protection.
 
I think I agree with your observation, which seems to undercut the "CGAs as inputs to ACLs" argument :-).

Steve
--============_-931732443==_ma============-- From hartmans@mit.edu Thu Jul 29 01:13:56 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B716F3A6A33; Thu, 29 Jul 2010 01:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wMlxfI8cygA; Thu, 29 Jul 2010 01:13:51 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 90C413A6990; Thu, 29 Jul 2010 01:13:51 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-23f1.meeting.ietf.org [130.129.35.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id DFDA620393; Thu, 29 Jul 2010 04:14:14 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F0FC44133; Thu, 29 Jul 2010 04:14:13 -0400 (EDT) From: Sam Hartman To: Stephen Kent References: Date: Thu, 29 Jul 2010 04:14:13 -0400 In-Reply-To: (Stephen Kent's message of "Thu\, 29 Jul 2010 03\:53\:34 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Laganier, Julien" , Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [secdir] [saag] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 08:13:56 -0000 >>>>> "Stephen" == Stephen Kent writes: Stephen> I agree that the primary motivation for CGAs arose in the Stephen> SeND context, and that privacy is an independent Stephen> feature. But, the context in which CGAs were intended to Stephen> provide an ability to establish a binding to an IPv6 Stephen> address was local. When one moves beyond this local Stephen> context, and one advocates having more distant nodes Stephen> challenge a host, this creates privacy questions. I think we've been looking at CGAs that have non-local scope for a while. Section 7.4 of RFC 3972 seems to anticipate CGAs used with other protocols. It's my understanding that shim6 supports both HBAs and CGAs for non-local contexts. I also believe the MIP6 context for CGA use is non-local. From rbarnes@bbn.com Thu Jul 29 01:28:20 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5893E28C1C5; Thu, 29 Jul 2010 01:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pi6eI-9GfBFS; Thu, 29 Jul 2010 01:28:19 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 5C1D93A63C9; Thu, 29 Jul 2010 01:28:17 -0700 (PDT) Received: from [128.89.253.91] (port=49262 helo=dhcp-22e1.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OeOTj-0004iB-Le; Thu, 29 Jul 2010 04:28:35 -0400 Message-Id: <20C6D044-08B8-4956-910A-D22C70819933@bbn.com> From: "Richard L. Barnes" To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Jul 2010 10:28:34 +0200 References: X-Mailer: Apple Mail (2.936) Cc: Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman Subject: Re: [secdir] [saag] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 08:28:20 -0000 The thing I'm struggling with here is what value a CGA provides over a bare public key. The use of a CGA as a source address doesn't prove anything except that the entity that generated it had access to a given public key, which is nothing special. If you're going to get any security benefit, you either need 1. Out-of-band knowledge that SEND was applied in the relevant subnet, or 2. Some interaction that proves ownership of the private key In the second case, you might as well just use existing protocols for proving ownership of a key (IPsec, TLS); the first case is just a special case of the second, where the entity applying access control has a special relationship with the layer-2 network (kind of fragile). Either way, what you end up doing is validating that the entity holds a given private key, at which point the source address has nothing to do with the security of communications. tl;dr: CGAs don't have any security benefit without another protocol. What's the use case? --Richard On Jul 29, 2010, at 10:14 AM, Sam Hartman wrote: >>>>>> "Stephen" == Stephen Kent writes: > > Stephen> I agree that the primary motivation for CGAs arose in the > Stephen> SeND context, and that privacy is an independent > Stephen> feature. But, the context in which CGAs were intended to > Stephen> provide an ability to establish a binding to an IPv6 > Stephen> address was local. When one moves beyond this local > Stephen> context, and one advocates having more distant nodes > Stephen> challenge a host, this creates privacy questions. > > I think we've been looking at CGAs that have non-local scope for a > while. Section 7.4 of RFC 3972 seems to anticipate CGAs used with > other > protocols. It's my understanding that shim6 supports both HBAs and > CGAs > for non-local contexts. I also believe the MIP6 context for CGA use > is > non-local. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From rgm-sec@htt-consult.com Thu Jul 29 05:04:10 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C112A3A69EB; Thu, 29 Jul 2010 05:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEnrMh02xS5p; Thu, 29 Jul 2010 05:04:09 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 7E04E3A69A2; Thu, 29 Jul 2010 05:04:09 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 7FB4D68B25; Thu, 29 Jul 2010 11:55:22 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSaOg4VCZEas; Thu, 29 Jul 2010 07:55:12 -0400 (EDT) Received: from nc2400.htt-consult.com (dhcp-60fb.meeting.ietf.org [130.129.96.251]) (Authenticated sender: rgm-sec@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 4BCBE68B24; Thu, 29 Jul 2010 07:55:11 -0400 (EDT) Message-ID: <4C516E42.9080103@htt-consult.com> Date: Thu, 29 Jul 2010 14:04:18 +0200 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Richard L. Barnes" References: <20C6D044-08B8-4956-910A-D22C70819933@bbn.com> In-Reply-To: <20C6D044-08B8-4956-910A-D22C70819933@bbn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 29 Jul 2010 05:48:16 -0700 Cc: Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [secdir] [saag] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 12:04:10 -0000 On 07/29/2010 10:28 AM, Richard L. Barnes wrote: > The thing I'm struggling with here is what value a CGA provides over a > bare public key. My understanding MAY be incomplete, but... It looks like CGA generation binds the prefix to the key, thus there is a trust that the prefix has not been altered. I don't do that in HIT generation. Don't know if I should change HIT generation or not. I would need to look at the IPR around CGAs. > The use of a CGA as a source address doesn't prove anything except > that the entity that generated it had access to a given public key, > which is nothing special. If you're going to get any security benefit, > you either need > > 1. Out-of-band knowledge that SEND was applied in the relevant subnet, or > 2. Some interaction that proves ownership of the private key > > In the second case, you might as well just use existing protocols for > proving ownership of a key (IPsec, TLS); the first case is just a > special case of the second, where the entity applying access control > has a special relationship with the layer-2 network (kind of fragile). > > Either way, what you end up doing is validating that the entity holds > a given private key, at which point the source address has nothing to > do with the security of communications. > > tl;dr: CGAs don't have any security benefit without another protocol. > What's the use case? > > --Richard > > > > > On Jul 29, 2010, at 10:14 AM, Sam Hartman wrote: > >>>>>>> "Stephen" == Stephen Kent writes: >> >> Stephen> I agree that the primary motivation for CGAs arose in the >> Stephen> SeND context, and that privacy is an independent >> Stephen> feature. But, the context in which CGAs were intended to >> Stephen> provide an ability to establish a binding to an IPv6 >> Stephen> address was local. When one moves beyond this local >> Stephen> context, and one advocates having more distant nodes >> Stephen> challenge a host, this creates privacy questions. >> >> I think we've been looking at CGAs that have non-local scope for a >> while. Section 7.4 of RFC 3972 seems to anticipate CGAs used with other >> protocols. It's my understanding that shim6 supports both HBAs and CGAs >> for non-local contexts. I also believe the MIP6 context for CGA use is >> non-local. >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From jason_livingood@cable.comcast.com Thu Jul 29 06:35:55 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD2013A6A03; Thu, 29 Jul 2010 06:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.452 X-Spam-Level: * X-Spam-Status: No, score=1.452 tagged_above=-999 required=5 tests=[AWL=1.120, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acqY46nu115s; Thu, 29 Jul 2010 06:35:50 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 98BEE3A67EF; Thu, 29 Jul 2010 06:35:46 -0700 (PDT) Received: from ([147.191.124.12]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.5144736; Thu, 29 Jul 2010 07:40:45 -0600 Received: from PAOAKEXCSMTP01.cable.comcast.com (10.52.116.30) by copdcexhub01.cable.comcast.com (147.191.124.12) with Microsoft SMTP Server id 14.0.702.0; Thu, 29 Jul 2010 07:36:08 -0600 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Jul 2010 09:35:52 -0400 Received: from 92.65.30.74 ([92.65.30.74]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server legacywebmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 Jul 2010 13:35:51 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Thu, 29 Jul 2010 09:35:50 -0400 From: Jason Livingood To: Tero Kivinen , , Message-ID: Thread-Topic: Review of draft-livingood-woundy-congestion-mgmt-05 Thread-Index: AcsvIvU8GKpLrhORL0+RRWggSw/W5g== In-Reply-To: <19526.56446.871198.214543@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jul 2010 13:35:52.0037 (UTC) FILETIME=[F673D150:01CB2F22] X-Mailman-Approved-At: Thu, 29 Jul 2010 08:06:57 -0700 Cc: Rich Woundy Subject: Re: [secdir] Review of draft-livingood-woundy-congestion-mgmt-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 13:35:55 -0000 Tero -- Tero - Thanks for the review and feedback. All of this is now fixed in draft-livingood-woundy-congestion-mgmt-06, which has been uploaded today and is now available at http://www.ietf.org/id/draft-livingood-woundy-congestion-mgmt-06.txt. I've made specific replies inline below, if you are interested, to confirm and show the changes. Thank you, Jason On 7/21/10 7:39 AM, "Tero Kivinen" wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document describes the congestion management system used by the > comcast. As such it does not describe any specific protocol, just the > architecture and management algorithms to manage congestion. The > security considerations section says > > ---------------------------------------------------------------------- > 12. Security Considerations > > It is important that an ISP secure access to the Congestion > Management Servers and the QoS Servers, as well as QoS signaling to > the CMTSes, so that unauthorized users and/or hosts cannot make > unauthorized changes to QoS settings in the network. It is also > important to secure access to the Statistics Collection Server since > this contains ISP-proprietary traffic data. > ---------------------------------------------------------------------- > > and as such it seems to list the most obvious security threats i.e. > the actual protocols run between the different nodes and that those > protocols needs to be secured, altought I would not consider > protecting the ISP-proprietary traffic data as the most important > reason why statistics collection server access needs to be secured. > The privacy issues (i.e from that statistics data it might be possible > to find out who is making connections to where) and ability to protect > against feeding false statistics information is more important than > protecting ISP-proprietary traffic data. That is a very good point and was an oversight on my part. I have revised the section as follows at the bottom of this email. I have also explained in there what the IPDR record stores, which is just bytes sent and bytes received, over a given interval of time. Thus there is not source/destination data, etc. > There is no description what happens to the statistics data after the > inspection interval, i.e. whether it is stored for long time or > whether it is immediately deleted. Getting access to statistics data > later might allow all kind of traffic analysis etc and the document > does not describe on what granularity the actual statistics are > collected so the traffic analysis done afterwards might offer quite > lot information. It should be enough to collect only per "cable modem" > statistics, i.e. remove actual TCP flow or connection information from > the statistics (not sure if that is done or not), and for the > congestion management reasons it should be enough to keep only the > last n minutes worth of statistics. This is correct and is fact what IPDR data is restricted to collecting (in the stats collection server). Here's what I now have. Please do advise if you wish additional changes or clarifications and I will make them ASAP. Security Considerations: It is important that an ISP secure access to the Congestion Management Servers and the QoS Servers, as well as QoS signaling to the CMTSes, so that unauthorized users and/or hosts cannot make unauthorized changes to QoS settings in the network. It is also important to secure access to the Statistics Collection Server since this contains IPDR-based byte transfer data which considered private by end users on an individual basis. In addition this data is considered ISP-proprietary traffic data on an aggregate basis. Access to the Statistics Collection Server should also be secured so that false usage statistics cannot be fed into the system. It is important to note that IPDR data contain a count of bytes sent and bytes received, by cable modem MAC address, over a given interval of time. This data does not contain things such as the source and/or destination Internet address of that data, nor does it contain the protocols used, ports used, etc. From turners@ieca.com Fri Jul 30 05:05:36 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09FC83A6969 for ; Fri, 30 Jul 2010 05:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhLc3Vzg7qUx for ; Fri, 30 Jul 2010 05:05:34 -0700 (PDT) Received: from smtp114.biz.mail.mud.yahoo.com (smtp114.biz.mail.mud.yahoo.com [209.191.68.79]) by core3.amsl.com (Postfix) with SMTP id 76F503A6964 for ; Fri, 30 Jul 2010 05:05:34 -0700 (PDT) Received: (qmail 72654 invoked from network); 30 Jul 2010 12:05:55 -0000 Received: from dhcp-26f6.meeting.ietf.org (turners@130.129.38.246 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 30 Jul 2010 05:05:55 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: W05nGGgVM1lYYl4KV0_nfybTZpfptL4H9g3Pynnd1bkCigy xnevXG7n5wnQvXtpivAf3p5QVFDjevogq2gAb4s31Gga.PSLDXyy07uVOjSh Zn64s3a3SBy3Egn.TGwSMefRfEI9wp3wTOrrWnHCyGZm91UtZHnL2upxD0Zg bAMY2J3EJ8oPWxhaSTzx5obk5VyQHl7WyZI0A83be.OKYQk5gEb3WOJACWFU 3DjlZbMIGgGGyEzJV18M0l4ErfiEV3FxWZgSw_R7pD.4H5d4I714Fo8OkMtp VZvOOtHOQdJSZ_874GrShJ80- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C52C021.8060305@ieca.com> Date: Fri, 30 Jul 2010 14:05:53 +0200 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Resolving Errata on RFC 4226 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 12:05:36 -0000 Does anybody know the authors of RFC 4226: HOTP: An HMAC-Based One-Time Password Algorithm? There are seven errata on it that Tim and I need to resolve and I've been unsuccessful in contacting them via email. spt From weiler@watson.org Fri Jul 30 05:40:40 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1384C3A6892 for ; Fri, 30 Jul 2010 05:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[AWL=0.897, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iS39+iOdvdCo for ; Fri, 30 Jul 2010 05:40:39 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 11CFA3A67FA for ; Fri, 30 Jul 2010 05:40:38 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id o6UCf12n005700; Fri, 30 Jul 2010 08:41:01 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id o6UCf1ZZ005697; Fri, 30 Jul 2010 08:41:01 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 30 Jul 2010 08:41:01 -0400 (EDT) From: Samuel Weiler To: Sean Turner In-Reply-To: <4C52C021.8060305@ieca.com> Message-ID: References: <4C52C021.8060305@ieca.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 30 Jul 2010 08:41:02 -0400 (EDT) Cc: secdir@ietf.org Subject: Re: [secdir] Resolving Errata on RFC 4226 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 12:40:40 -0000 On Fri, 30 Jul 2010, Sean Turner wrote: > Does anybody know the authors of RFC 4226: HOTP: An HMAC-Based One-Time > Password Algorithm? There are seven errata on it that Tim and I need to > resolve and I've been unsuccessful in contacting them via email. To make it easier: David M'Raihi (primary contact for sending comments and questions) VeriSign, Inc. Mihir Bellare University of California at San Diego Frank Hoornaert VASCO Data Security, Inc. David Naccache Gemplus Innovation Ohad Ranen Aladdin Knowledge Systems Ltd. From weiler@watson.org Fri Jul 30 06:05:25 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9CE3A6985 for ; Fri, 30 Jul 2010 06:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHYTV8o7wQFs for ; Fri, 30 Jul 2010 06:05:24 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 89C413A69A0 for ; Fri, 30 Jul 2010 06:05:24 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id o6UD5n8G009713 for ; Fri, 30 Jul 2010 09:05:49 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id o6UD5n5d009710 for ; Fri, 30 Jul 2010 09:05:49 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 30 Jul 2010 09:05:49 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 30 Jul 2010 09:05:49 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 13:05:26 -0000 Magnus Nystrom is next in the rotation. I'll be on holiday during the next week; contact the ADs with anything urgent. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview The assignment email format has changed to show last call end dates for all docs, even those scheduled for telechat. Special requests won't have one, nor will docs for which as LC has been requested but not yet issued. Some new assignments have a LC end date in the immediate future; that's an artifact of my not having sent new assignments in the last week. -- Sam For telechat 2010-08-12 Reviewer LC end Draft Rob Austein T 2010-07-12 draft-ietf-forces-applicability-09 Alan DeKok T 2010-07-12 draft-ietf-forces-implementation-report-02 Shawn Emery T 2010-07-14 draft-ietf-ippm-twamp-reflect-octets-07 Tobias Gondrom T 2010-08-04 draft-davis-u-langtag-ext-03 Sandy Murphy T 2010-07-30 draft-ietf-softwire-ds-lite-tunnel-option-03 Last calls and special requests: Reviewer LC end Draft Stephen Farrell - draft-baker-v6ops-greynet-04 Phillip Hallam-Baker 2010-07-23 draft-ietf-geopriv-arch-02 Love Hornquist-Astrand 2010-07-23 draft-ietf-pkix-ocspagility-08 Jeffrey Hutzelman 2010-07-23 draft-ietf-pkix-ta-mgmt-reqs-05 Julien Laganier - draft-ietf-nsis-nslp-auth-05 Barry Leiba 2010-08-12 draft-saintandre-tls-server-id-check-08 Chris Lonvick 2010-08-05 draft-ietf-netmod-arch-07 David McGrew - draft-ietf-ecrit-framework-11 David McGrew 2010-08-05 draft-ietf-pce-manageability-requirements-10 Catherine Meadows - draft-ietf-tcpm-tcp-lcd-02 Russ Mundy 2010-08-05 draft-ietf-v6ops-isp-scenarios-00 Chris Newman 2010-08-23 draft-azinger-additional-private-ipv4-space-issues-04 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Brian Weis 2010-07-16 draft-daboo-srv-caldav-05 Nico Williams 2010-07-16 draft-turner-suiteb-cmc-03 Larry Zhu 2010-08-12 draft-thaler-v6ops-teredo-extensions-07 Larry Zhu - draft-ietf-sip-domain-certs-07 Glen Zorn 2010-07-26 draft-cakulev-mikey-ibake-01