From pgut001@cs.auckland.ac.nz Thu Mar 6 00:38:15 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m265cEpW027642 for ; Thu, 6 Mar 2008 00:38:15 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m265c360012830 for ; Thu, 6 Mar 2008 00:38:03 -0500 (EST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by mit.edu (Spam Firewall) with ESMTP id 00D917E7152 for ; Thu, 6 Mar 2008 00:38:01 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 01C9F9C693; Thu, 6 Mar 2008 18:38:00 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBfO28U-kvwx; Thu, 6 Mar 2008 18:37:59 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 5D4019C68A; Thu, 6 Mar 2008 18:37:58 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 0221419EC0B8; Thu, 6 Mar 2008 18:37:58 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JX8nl-0005nH-Rl; Thu, 06 Mar 2008 18:37:57 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, rja@extremenetworks.com, SChokhani@cygnacom.com In-Reply-To: Message-Id: Sender: pgut001 Date: Thu, 06 Mar 2008 18:37:57 +1300 X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 05:38:15 -0000 "Santosh Chokhani" writes: >I do not think this is a forum for negotiations. Absolutely, that's why I pointed out that I wasn't taking it as a price quote, more to make a point. >But, we will be happy to do FIPS testing for your product for Level 1 for >quoted price. > >As to algorithms, all FIPS approved algorithms need to be tested. And there's the rub, it's not just handing over $30K and getting back a coloured certificate, you need to get the algorithms certified, prepare a ton of paperwork, spend a considerable amount of time on this, and that's where the $100K all-up figure comes from. If I could simply hand over $30K and the source code *with no further effort or expense on my behalf* I'd jump at the chance. Just to show that I'm not trying to pick on Cygnacom here I'll make this an open offer to anyone: If I can hand you $30K and a copy of my source code and you can get me a FIPS 140 cert for it without me incurring any additional effort or expense, please get in touch. >Have you yourself participated in a FIPS evaluation or have you looked at the >NIST FIPS 140-2 DTR and FIPS 140-2 IG (i.e. Implementation Guidance) >available on the Web? Probably about half a dozen directly (+/- one or two, I haven't kept an exact tally), and been involved indirectly in about a dozen more via discussions with (and listening to complaining about :-) others going through the process. (Again, YMMV, I haven't kept an exact tally on the latter, and in some cases it was nothing more than "what did you guys do to get past ...?", and sympathising with them over problems). Peter. From ben@links.org Thu Mar 6 04:43:45 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m269hfQ4010831 for ; Thu, 6 Mar 2008 04:43:41 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m269hTKh019524 for ; Thu, 6 Mar 2008 04:43:29 -0500 (EST) Received: from mail.links.org (mail.links.org [217.155.92.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 7BC2BFDF416 for ; Thu, 6 Mar 2008 04:43:05 -0500 (EST) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id C480233C1C; Thu, 6 Mar 2008 09:42:42 +0000 (GMT) Message-ID: <47CFBC99.3000608@links.org> Date: Thu, 06 Mar 2008 09:42:49 +0000 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, rja@extremenetworks.com, mcgrew@cisco.com Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 09:43:45 -0000 Peter Gutmann wrote: > mcgrew writes: > >> Winston Churchill said that democracy is the worst form of government, except >> for all of the others. I think that the same is true for the FIPS-140 >> cryptomodule validation process ;-) > > I think it's more a case of the Politician's Fallacy: > > 1. Something must be done. > 2. This is something. > 3. This must be done. > > It'd be interesting to see a study of the effectiveness in terms of finding > security and interop problems of: > > A. A FIPS 140 eval. > > B. Running the code through Fortify/Coverity/whatever and completing a crypto > exchange with a peer (TLS, S/MIME, PGP, whatever the underlying crypto is > that's being used). > > in particular in terms of return for effort-involved. Having done both of these, I can give you an impromptu answer, and also comment on some other themes I've seen on this thread. The background here is I did most of the initial work for the FIPS-140 eval of OpenSSL. I also have access to Coverity runs over OpenSSL. There's no doubt that Coverity gives far more return on effort. It actually found problems. FIPS-140 did not (though it did create some, see below). Coverity took only a few days of investment. FIPS-140 took months (and years of elapsed time). Other themes... Silly modes: FIPS-140 doesn't introduce silly modes that are available to client s/w, but it does introduce some really quite complex silliness for the tests, involving repeated encryption of a block, extracting some of the output and using it to create new keys and data for more repeated encryptions. Getting those right was really very painful - and, as far as I can see, no more useful than standard test vectors. Fixed input to PRNGs: someone observed that this is worrisome from a security point of view. The fact that OpenSSL got certified and yet had a huge security hole because it accidentally left the PRNG seeded from the self-test supports this concern (http://openssl.org/news/secadv_20071129.txt). Weak PRNGs: no-one mentioned this, I don't think, but one of the things that bugged me most was having to replace OpenSSL's PRNG with a much weaker one, as required by FIPS-140. Enforced security holes: again, not mentioned, but one of the problems with PRNGs under Unix is that after a fork, both copies will produce the same randomness. OpenSSL protects against this by detecting a fork and mixing in different stuff in the two processes. I replicated this behaviour for FIPS-140 and was forced to remove it. The result is that if you use FIPS-140 mode and you fork, if you don't reseed the PRNG yourself, you have made a big mistake. Cost: Peter Gutmann points out that the total cost of an eval vastly exceeds the cost of the testing lab. He's right. There's a huge amount of paperwork and pointless code to write. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From SChokhani@cygnacom.com Thu Mar 6 07:26:57 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m26CQuC0027798 for ; Thu, 6 Mar 2008 07:26:56 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m26CQmYi000046 for ; Thu, 6 Mar 2008 07:26:48 -0500 (EST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id 2AF64FFDE10 for ; Thu, 6 Mar 2008 07:26:25 -0500 (EST) Received: (qmail 5619 invoked from network); 6 Mar 2008 12:18:31 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 06 Mar 2008 12:18:31 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 6 Mar 2008 12:18:31 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 6 Mar 2008 07:26:24 -0500 Message-ID: in-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Ach/TD54DSqCiVDLSG+vCOidUOjT/wAOMVEA References: From: "Santosh Chokhani" To: "pgut001" , X-Spam-Score: 0.30 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m26CQuC0027798 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 12:26:57 -0000 Most of the standards are based on the assumption that you have some software development processes in place and thus will have documentation on the architecture and design of the product and not just the source code. One would think that you would also done some testing based on the knowledge of the design, interfaces and source code. -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz] Sent: Thursday, March 06, 2008 12:38 AM To: pgut001@cs.auckland.ac.nz; rja@extremenetworks.com; Santosh Chokhani Cc: saag@mit.edu Subject: RE: [saag] Algorithms/modes requested by users/customers "Santosh Chokhani" writes: >I do not think this is a forum for negotiations. Absolutely, that's why I pointed out that I wasn't taking it as a price quote, more to make a point. >But, we will be happy to do FIPS testing for your product for Level 1 for >quoted price. > >As to algorithms, all FIPS approved algorithms need to be tested. And there's the rub, it's not just handing over $30K and getting back a coloured certificate, you need to get the algorithms certified, prepare a ton of paperwork, spend a considerable amount of time on this, and that's where the $100K all-up figure comes from. If I could simply hand over $30K and the source code *with no further effort or expense on my behalf* I'd jump at the chance. Just to show that I'm not trying to pick on Cygnacom here I'll make this an open offer to anyone: If I can hand you $30K and a copy of my source code and you can get me a FIPS 140 cert for it without me incurring any additional effort or expense, please get in touch. >Have you yourself participated in a FIPS evaluation or have you looked at the >NIST FIPS 140-2 DTR and FIPS 140-2 IG (i.e. Implementation Guidance) >available on the Web? Probably about half a dozen directly (+/- one or two, I haven't kept an exact tally), and been involved indirectly in about a dozen more via discussions with (and listening to complaining about :-) others going through the process. (Again, YMMV, I haven't kept an exact tally on the latter, and in some cases it was nothing more than "what did you guys do to get past ...?", and sympathising with them over problems). Peter. From SChokhani@cygnacom.com Thu Mar 6 09:16:14 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m26EGAxS020310 for ; Thu, 6 Mar 2008 09:16:10 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m26EFvZk016572 for ; Thu, 6 Mar 2008 09:15:58 -0500 (EST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id DBD46D22525 for ; Thu, 6 Mar 2008 09:15:26 -0500 (EST) Received: (qmail 6324 invoked from network); 6 Mar 2008 14:07:32 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 06 Mar 2008 14:07:32 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 6 Mar 2008 14:07:31 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 6 Mar 2008 09:15:24 -0500 Message-ID: in-reply-to: <47CFBC99.3000608@links.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Ach/b+RUBDjQzHyhRzG3UZKk+fm1NQAI1zpQ References: <47CFBC99.3000608@links.org> From: "Santosh Chokhani" To: "Ben Laurie" , "Peter Gutmann" X-Spam-Score: 0.14 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m26EGAxS020310 Cc: saag@mit.edu, rja@extremenetworks.com, mcgrew@cisco.com Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 14:16:15 -0000 Ben, 1. In terms of Coverity, it complements what FIPS does. Coverity is a good tool for looking at code complexity and possible soft spots. Note that FIPS scrutiny is not very deep. It does not even perform full functional or interface testing. It is more akin to demonstration testing at EAL 2 for Common Criteria. For Common Criteria, for vulnerability analysis and testing, we do recommend that the developers use automated tools for static code analysis and test coverage analysis. 2. On the PRNG, I see FIPS having some cogent requirements. The basic requirements are that the entropy of the seed by commensurate with the entropy for the key being generated and the seed be pseudo randomized. I have myself worked with the developer to successfully obtain NIST approval when the PRNG algorithm has varied from FIPS approved methods. 3. I do not know what happened in your case. A wild stab is that may be the you were going for level 1 only for the operating environment also and multi-threading was not permitted. That is not an excuse. I do not know enough to suggest how U would handle this. 4. As to extra code, I do not know what you are specifically concerned with. I have for about 8-9 years unsuccessfully advocated to NIST to do away with self-tests. They were meaningful in old days of truly hardware crypto. Now, most hardware crypto is on some generic processor, and POST for the processor are sufficient as opposed to crypto specific tests. -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Ben Laurie Sent: Thursday, March 06, 2008 4:43 AM To: Peter Gutmann Cc: saag@mit.edu; rja@extremenetworks.com; mcgrew@cisco.com Subject: Re: [saag] Algorithms/modes requested by users/customers Peter Gutmann wrote: > mcgrew writes: > >> Winston Churchill said that democracy is the worst form of government, except >> for all of the others. I think that the same is true for the FIPS-140 >> cryptomodule validation process ;-) > > I think it's more a case of the Politician's Fallacy: > > 1. Something must be done. > 2. This is something. > 3. This must be done. > > It'd be interesting to see a study of the effectiveness in terms of finding > security and interop problems of: > > A. A FIPS 140 eval. > > B. Running the code through Fortify/Coverity/whatever and completing a crypto > exchange with a peer (TLS, S/MIME, PGP, whatever the underlying crypto is > that's being used). > > in particular in terms of return for effort-involved. Having done both of these, I can give you an impromptu answer, and also comment on some other themes I've seen on this thread. The background here is I did most of the initial work for the FIPS-140 eval of OpenSSL. I also have access to Coverity runs over OpenSSL. There's no doubt that Coverity gives far more return on effort. It actually found problems. FIPS-140 did not (though it did create some, see below). Coverity took only a few days of investment. FIPS-140 took months (and years of elapsed time). Other themes... Silly modes: FIPS-140 doesn't introduce silly modes that are available to client s/w, but it does introduce some really quite complex silliness for the tests, involving repeated encryption of a block, extracting some of the output and using it to create new keys and data for more repeated encryptions. Getting those right was really very painful - and, as far as I can see, no more useful than standard test vectors. Fixed input to PRNGs: someone observed that this is worrisome from a security point of view. The fact that OpenSSL got certified and yet had a huge security hole because it accidentally left the PRNG seeded from the self-test supports this concern (http://openssl.org/news/secadv_20071129.txt). Weak PRNGs: no-one mentioned this, I don't think, but one of the things that bugged me most was having to replace OpenSSL's PRNG with a much weaker one, as required by FIPS-140. Enforced security holes: again, not mentioned, but one of the problems with PRNGs under Unix is that after a fork, both copies will produce the same randomness. OpenSSL protects against this by detecting a fork and mixing in different stuff in the two processes. I replicated this behaviour for FIPS-140 and was forced to remove it. The result is that if you use FIPS-140 mode and you fork, if you don't reseed the PRNG yourself, you have made a big mistake. Cost: Peter Gutmann points out that the total cost of an eval vastly exceeds the cost of the testing lab. He's right. There's a huge amount of paperwork and pointless code to write. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff _______________________________________________ saag mailing list saag@mit.edu http://mailman.mit.edu/mailman/listinfo/saag From ravi.gami@ennovatetech.com Thu Mar 6 07:56:55 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m26CuomK006388 for ; Thu, 6 Mar 2008 07:56:55 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m26Cuhw2004766 for ; Thu, 6 Mar 2008 07:56:43 -0500 (EST) Received: from ahmedabad.einfochips.com (india.einfochips.com [203.88.139.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 2490CE11DB8 for ; Thu, 6 Mar 2008 07:56:21 -0500 (EST) Received: (qmail 1418 invoked by uid 118); 6 Mar 2008 12:52:09 -0000 Received: from 10.101.1.136 by ahm (envelope-from , uid 112) with qmail-scanner-1.25st (clamdscan: 0.91.2/6143. spamassassin: 3.1.7-deb. altermime: ???. perlscan: 1.25st. Clear:RC:1(10.101.1.136):. Processed in 0.019263 secs); 06 Mar 2008 12:52:09 -0000 Received: from unknown (HELO Ravi) (ravi.gami@ennovatetech.com@[10.101.1.136]) (envelope-sender ) by ahmedabad.einfochips.com (qmail-ldap-1.03) with SMTP for ; 6 Mar 2008 12:52:09 -0000 Message-ID: <001001c87f89$78a53840$8801650a@Ravi> From: "Gami Ravi" To: Date: Thu, 6 Mar 2008 18:26:18 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C87FB7.921F80E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 5.51 X-Spam-Level: ***** (5.51) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Thu, 06 Mar 2008 10:12:29 -0500 Subject: [saag] How security is maintained by IANA X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 12:56:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C87FB7.921F80E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I want to register multicast IP address.I want to know that once i = register multicast IP address can any other use that IP to send data on = that IP? How security is implemented for that ? Thanks & Regards, Ravi Gami. -- eInfochips Business Disclaimer: This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose,distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated.Nothing contained in this message shall be construed as an offer or acceptance of any offer by eInfochips Limited and/or eInfochips Inc(“eInfochips”) unless sent with that express intent and with due authority of eInfochips.EInfochips has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ------=_NextPart_000_000D_01C87FB7.921F80E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
    I want to register = multicast IP=20 address.I want to know that once i register multicast IP address can any = other=20 use that IP to send data on that IP? How security is implemented for = that=20 ?
 
 
Thanks & Regards,
Ravi Gami.

-- 
eInfochips Business Disclaimer:
 
This message may contain confidential, proprietary or legally Privileged
information. In case you are not the original intended Recipient of the
message, you must not, directly or indirectly, use, Disclose,distribute,
print, or copy any part of this message and you are requested to delete
it and inform the sender. Any views expressed in this message are those
of the individual sender unless otherwise stated.Nothing contained in
this message shall be construed as an offer or acceptance of any offer
by eInfochips Limited and/or eInfochips Inc(“eInfochips”) unless sent
with that express intent and with due authority of eInfochips.EInfochips
has taken enough precautions to prevent the spread of viruses. However
the company accepts no liability for any damage caused by any virus
transmitted by this email.

------=_NextPart_000_000D_01C87FB7.921F80E0-- From ekr@networkresonance.com Mon Mar 10 19:33:41 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2ANXfIl026578 for ; Mon, 10 Mar 2008 19:33:41 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2ANXS0M022779 for ; Mon, 10 Mar 2008 19:33:29 -0400 (EDT) Received: from kilo.rtfm.com (unknown [130.129.87.199]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id D4B3E77EE71 for ; Mon, 10 Mar 2008 19:33:04 -0400 (EDT) Received: from dhcp-1679.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 47E9B1AA4C7; Mon, 10 Mar 2008 19:33:04 -0400 (EDT) Date: Mon, 10 Mar 2008 19:33:04 -0400 From: Eric Rescorla To: tcpm@ietf.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080310233304.47E9B1AA4C7@kilo.rtfm.com> X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: [saag] Comments on draft-ietf-tcpm-tcp-auth-opt-00 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2008 23:33:41 -0000 I started writing comments on this and after I'd spent about 2 hours writing background material, I decided to cram it into an I-D. Until it appears on the I-D directory, you can find it at: https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tcp-auth-arch.txt Anyway, review follows: $Id: draft-ietf-tcpm-tcp-auth-opt-00-rev.txt,v 1.2 2008/03/10 23:11:21 ekr Exp $ GENERAL COMMENTS I'm not convinced it's necessary to have a new key for each connection. This is primarily useful to prevent inter-connection cut-and-paste attacks, and it's not clear how serious those are. I think it's particularly problematic to levy this requirement without providing some mechanism for arranging that, since that basically implies having some automatic mechanism for establishing fresh per-connection keys, which doesn't currently exist. That makes this mechanism distinctly less useful than RFC 2385. I don't think this API, specification of the TSAD, etc., is particularly helpful. IPsec needed the concept of an association database because packets corresponding to multiple associations got similar treatment. However, TCP has an explicit notion of connection so it would be far more convenient to simply refer to keys as tied to connections, and then have a set of rules for mapping which connections get which keys. Even if some TSAD-type abstraction is useful, I don't think it's appropriate to define things like the size of each parameter in the TSAD as opposed to on the wire, or to describe the default values of various parameters as in S 3. For instance: iii. Key length. A byte indicating the length of the connection key in bytes. Those are internal implementation issues. Certainly, I might want to use a native int in my implementation. Why should this document tell me otherwise? TECHNICAL COMMENTS S 1.1. I don't see a lot of value in pre-specifying two MAC algorithms as MTI. There's no reason to believe one isn't plenty, as used in other protocols. S 2.2. This thing with the key-id being present if the MAC is odd, but absent if it's even strikes me as being overly clever. Let's just burn an octet on key-id and leave it at that. S 3. >> At least one direction (inbound/outbound) SHOULD have a non-NONE MAC in practice, but this MUST NOT be strictly required by an implementation. 1. This seems like a bad idea. It's very hard to analyze the security properties of a connection when only one side is protected. To take one case that is obviously bad, if you're worried about DoS attacks and you use TCP-AO, then forging packets in either direction can bring it down. I would reverse this and require MACs in both directions. 2. Even if we stipulate that this might be an OK idea, it's not appropriate to require implementations to support it. S 4.1. >> New TSAD entries MUST be checked against a table of previously used TSAD entries, and key reuse MUST be prohibited. Huh? So, I have to keep a list of every TSAD entry ever and check against the table. Seems better to just to do this by construction. S 4.3. >> TCP segments with TCP-AO but not matching TSAD entries MUST be silently accepted; this is required for equivalent function with TCPs not implementing TCP-AO. I don't see this. Can you explain? >> Silent discard events SHOULD be signaled to the user as a warning, and silent accept events MAY be signaled to the user as a warning. I don't really understand what a warning means here? syslog? S 5. Implementations are encouraged to keep keys in a suitably private area. Users of TCP-AO are encouraged to use different keys for inbound and outbound MACs on a given TCP connection. Some discussion of why different keys are good or bad would help here. As far as I can tell, reflection attacks aren't an issue as long as the host/port quartet is incuded in the header. S 5.1. o Number of bytes to be sent/received (two bytes); this is used on the send side to trigger bytecount-based KeyID changes, and on the receive side only for statistics or length-sensitive KeyID selection. Please explain the cryptographic rationale for why you would want to do bytecount based key changes. S 9. TCP-AO does not expose the MAC algorithm used to authenticate a particular connection; that information is kept in the TSAD at the endpoints, and is not indicated in the header. This seems to be of extremely marginal security benefit. There are likely to be <5 algorithms in use. So, searching all of them increases the effective key size by <3 bits. EDITORIAL COMMENTS S 1. there have been escalating attacks on the algorithm itself [Be05] [Bu06]. TCP MD5 also lacks both key management and algorithm These citations should be to the original papers, not the summaries (not that I mind you citing Steve's and my paper...) o S 2.2. Figure 2 is kind of hard to read since the length of the kind field is 16 bits, but kinds are 8 bits, rigth? S 3. Note that the connection key is not included here; we expect that the MAC algorithm will indicate how to use the key, e.g., as HMACs do in s/HMACs do/HMAC does/ TCP-AO by default includes the TCP options because these options are intended to be end-to-end and some are required for proper TCP operation (e.g., SACK, timestamp, large windows). Middleboxes that I dpn't understand what "by default" means here. This needs to be configured on both sides, right? So, this is just a UI issue. S 5. the default case. Segments carry only enough context to identify the security association [RFC4301][RFC4306]. In TCP-AO, this context is I'm not sure what security association means here. You're not using IKE, right? S 9. TCP-AO does not expose the MAC algorithm used to authenticate a particular connection; that information is kept in the TSAD at the endpoints, and is not indicated in the header. I may not be enough of a TCP wonk, but what's a connection ID? -Ekr From touch@ISI.EDU Mon Mar 10 21:31:36 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2B1VaWF005482 for ; Mon, 10 Mar 2008 21:31:36 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2B1VNYY010731 for ; Mon, 10 Mar 2008 21:31:24 -0400 (EDT) X-ASG-Whitelist: Client Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 9D1C8752794 for ; Mon, 10 Mar 2008 21:31:23 -0400 (EDT) Received: from [127.0.0.1] ([63.133.180.130]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m2B1UlLU015902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Mar 2008 18:30:50 -0700 (PDT) Message-ID: <47D5E09A.5000803@isi.edu> Date: Mon, 10 Mar 2008 18:30:02 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eric Rescorla , IETF Security Area WG , tcpm@ietf.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig591A580DD43B812CE3076EB4" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] discussion of draft-rescorla-tcp-auth-arch-00.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 01:31:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig591A580DD43B812CE3076EB4 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Eric, Again, thanks for the detailed comments. Discussion below... This too should be useful to discuss further in TCPM. Joe > Network Working Group E. Rescorl= a > Internet-Draft RTFM, Inc= =2E > Intended status: Informational March 09, 200= 8 > Expires: September 10, 2008 >=20 >=20 > Notes on TCP Authentication Architectures > draft-rescorla-tcp-auth-arch-00.txt =2E.. > 1. Introduction =2E.. > Note that there is currently two documents > [I-D.ietf-tcpm-tcp-auth-opt] [I-D.bellovin-tcpsec] that discuss > additional requirements, but it's not clear to me that these > requirements have consensus or in fact are correct. The documents were presented at the last IETF, where we solicited=20 comments on those requirements. The requirements were presented as=20 having the consensus of the TCP-AO design team only at that time. =2E.. > 3. Keys and Associations >=20 > Probably the most important architectural question is the > relationship of keys to associations. As indicated above, TCP MD5 > uses a single static key for all associations. This key is > configured in a pairwise fashion. By contrast, conventional channel= > security protocols such as TLS [RFC4346] or IPsec [RFC4301] establis= h > a fresh set of keying material for each association. The proposed > TCP Authentication Option [I-D.ietf-tcpm-tcp-auth-opt] also requires= > (though does not arrange for) a fresh key for each association. TCP-AO is identical to IPsec [i.e., 4301] in that regard; neither=20 arranges for keys, and both rely on a separate protocol to do so, in the = sense that IPsec relies on IKE. > >> New TSAD entries MUST be checked against a table of previously= > used TSAD entries, and key reuse MUST be prohibited. >=20 > There are two good (and one not so good) reasons why it's desirable > to have mechanisms for changing keys: Changing keys is not related to the above key reuse issue AFAICT. Key changes are to reduce the amount of material signed under a single=20 key, to reduce the utility of signed packets to a cryptoanalyst. Key reuse is critical to preventing replay attacks within a connection=20 ID (src IP, dst IP, src port, dst port, aka socket pair). It is useful=20 to avoid keying different ports or even different hosts with the same=20 key, but only in a general sense (i.e., to again reduce the amount of=20 material signed with a single key). > o To arrange for different cryptographic keying material to be used= > for each connection, thus preventing cut-and-paste attacks betwee= n > connections. (Good) Those don't seem relevant; the ports change, so the signatures would chan= ge. > o To allow rekeying in case of key compromise. (Good) Rekeying of a connection is not necessarily related to rekeying an=20 endpoint. Connection key compromise is not something we're designing to=20 address per se. > o To limit the amount of plaintext/MAC pairs available to the > attacker (Not-so-good) Is that the 'amount of keyed material' kind of stuff above? That was=20 given by Bellovin as an issue with TCP-MD5. > In TCP, cut-and-paste attacks are also possible within a connection > due to sequence number rollover. This can be fixed, however, by > extending the sequence numbers virtually, as done with ESP/AH. We definitely do not want to tie the keying directly to the sequence=20 space for a variety of reasons (we listed some, I believe); this is done = indirectly by bytecounts or packet counts to trigger key changes. > 4. Credentials Interface >=20 > As described at the beginning of this document, essentially all the > currently deployed systems use a single pre-configured pairwise > shared key. This key is directly configured on the router interface= =2E > For instance, here's the example from Cisco's IOS manuals [REF: htt= p > ://www.cisco.com/en/US/docs/ios/12_0/np1/configuration/guide/ > 1cbgp.html#wp5978] >=20 > router bgp 109 neighbor 145.2.2.2 password v61ne0qkel33& >=20 > It's extremely desirable to be able to retain the existing > interfaces. Any solution which requires a significant change to > those interfaces and especially to the interaction model creates a > substantial additional burden on operators, which creates a major > barrier to deployment. That would be allowed if the key management system used a single master=20 endpoint key, and derived connection keys from that key. I.e., if this=20 is critical to BGP, then BGP will require TCP-AO and a specific key=20 management protocol. Again, this isn't different from saying "IPsec with = IKE" at the IP layer, except that we are intending that TCP-AO and its=20 key management system are simpler to implement (partly because they're=20 specific to a single transport protocol). > 5. Handshake and Capabilities Discovery >=20 > The ability to automatically discover a peer's capabilitiies is a > common feature of modern cryptographic protocols. \ Like IPsec, we rely on the key management protocol to perform this. This = is not a part of TCP-AO as a result. > 6. Potential Architectures >=20 > This section describes a number of potential architectures for key > management for TCP. I'll skip them here, excepting ones that affect TCP-AO: > 6.2.1. Internal Key Management Protocol >=20 > The traditional approach to this problem would be to build a KMP int= o > TCP. This would presumably entail designing a new crypto protocol > (no small job) which is then carried in a TCP option. TCP option space is already consumed by a number of commonly used=20 options, and we want to retain space for additional options where=20 possible. Space is most limited in the SYN packet, which is where the=20 initial key exchange would occur. Because there isn't enough TCP option space for this sort of solution,=20 we excluded it as a possibility. =2E.. > 6.2.3. Layered KMP >=20 > Another way to provide a separate KMP is to bind it more tightly to > the transport protocol by running it over (or next to, as in DTLS- > SRTP [I-D.ietf-avt-dtls-srtp]) the transport protocol. At the time > that the association is created, the application initiating the > association also initiates a KMP exchange over (next to) the > transport protocol. When the KMP terminates, it outputs keying and > parameter information and imposes them on the association. In the > case of TLS over TCP, this would look something like: >=20 > TCP Client TCP Server > ---------- ---------- > TCP SYN -------------------------------------> > <---------------------------------- TCP SYN/ACK > TCP ACK -------------------------------------> > <--------- TLS Handshake (over TCP) ------> > Keys to TCP Keys to TCP= > App data (protected with TCP integrity) -----> > <----- App data (protected with TCP integrity) This fails to protect the SYN exchange, which we consider a requirement. = It also changes state from non-keyed to keyed; it would be very=20 difficult to introduce that sort of stateful change inside the TCP=20 protocol in ways that affect the data stream, since no other options=20 have that kind of effect (i.e., of affecting all data after some point). --- --------------enig591A580DD43B812CE3076EB4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH1eCaE5f5cImnZrsRAtqKAKCkOpSWIcSR0yqtvqyNSEeif5nIPACgl5// grdeJWN5biUgovCo/MKyD00= =7rmx -----END PGP SIGNATURE----- --------------enig591A580DD43B812CE3076EB4-- From touch@ISI.EDU Mon Mar 10 21:31:40 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2B1VeYd005498 for ; Mon, 10 Mar 2008 21:31:40 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2B1VRTh010768 for ; Mon, 10 Mar 2008 21:31:27 -0400 (EDT) X-ASG-Whitelist: Client Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id B472EE2965F for ; Mon, 10 Mar 2008 21:31:26 -0400 (EDT) Received: from [127.0.0.1] ([63.133.180.130]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m2B1UdSR015862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Mar 2008 18:30:42 -0700 (PDT) Message-ID: <47D5E090.9010608@isi.edu> Date: Mon, 10 Mar 2008 18:29:52 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eric Rescorla References: <20080310233304.47E9B1AA4C7@kilo.rtfm.com> In-Reply-To: <20080310233304.47E9B1AA4C7@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE118A070FCD485B77E83166F" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, tcpm@ietf.org Subject: Re: [saag] [tcpm] Comments on draft-ietf-tcpm-tcp-auth-opt-00 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 01:31:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE118A070FCD485B77E83166F Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Eric, Thanks for the detailed comments. Some responses based on the text below. I'll comment on the ID separately... Also, I would expect that most of these issues would be useful to=20 discuss further in TCPM if you're available. Otherwise, we could meet=20 separately... Joe Eric Rescorla wrote: > I started writing comments on this and after I'd spent about=20 > 2 hours writing background material, I decided to cram it=20 > into an I-D. Until it appears on the I-D directory, you > can find it at: >=20 > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tcp-auth= -arch.txt >=20 > Anyway, review follows: >=20 > $Id: draft-ietf-tcpm-tcp-auth-opt-00-rev.txt,v 1.2 2008/03/10 23:11:21 = ekr Exp $ >=20 > GENERAL COMMENTS > I'm not convinced it's necessary to have a new key for each > connection. This is primarily useful to prevent inter-connection > cut-and-paste attacks, and it's not clear how serious those > are.=20 It's there primarily to prevent packets from an old version of a=20 connection from being used on a new connection, i.e., replay attacks=20 between a connection and its successor using the same port pair. I.e., IMO it's a MUST within a port pair for some period of time (the=20 cache check), and a SHOULD (for general security reasons) between port=20 pairs. The SHOULD can be dropped if (IMO) SAAG doesn't consider reusing=20 keys for different datasets an issue. > I think it's particularly problematic to levy this > requirement without providing some mechanism for arranging > that, since that basically implies having some automatic > mechanism for establishing fresh per-connection keys, which > doesn't currently exist. That makes this mechanism distinctly > less useful than RFC 2385. It does imply that for systems that re-establish connections frequently=20 either a a fresh key generation system is available, or a fairly long=20 list is preloaded. > I don't think this API, specification of the TSAD, etc., is > particularly helpful. IPsec needed the concept of an association > database because packets corresponding to multiple associations > got similar treatment. However, TCP has an explicit notion > of connection so it would be far more convenient to simply > refer to keys as tied to connections, and then have a set > of rules for mapping which connections get which keys. That's exactly what the TSAD is (or at least is supposed to be). It=20 might be useful to discuss this offline to figure out what the=20 disconnect is... > Even if some TSAD-type abstraction is useful, I don't think > it's appropriate to define things like the size of each > parameter in the TSAD as opposed to on the wire,=20 The TSAD API needs to be specified in detail because the key management=20 solution needs to rely on that information. > or to > describe the default values of various parameters as in > S 3. For instance: > > iii. Key length. A byte indicating the length of the=20 > connection key in bytes. =20 >=20 > Those are internal implementation issues. Certainly, I might > want to use a native int in my implementation. Why should > this document tell me otherwise? Again, it's to allow another party - the key management solution - to=20 load the TSAD. > TECHNICAL COMMENTS > S 1.1. > I don't see a lot of value in pre-specifying two MAC algorithms > as MTI. There's no reason to believe one isn't plenty, as used > in other protocols. >=20 > S 2.2. > This thing with the key-id being present if the MAC is odd, > but absent if it's even strikes me as being overly clever. > Let's just burn an octet on key-id and leave it at that. That would be discussed in TCPM further. The primary utility is for=20 short connections where the key isn't expected to need to rollover, and=20 where TCP option bytes are in extreme scarcity, esp. because single byte = can end up adding 4 overall, due to alignment issues. If that's not useful, we can decide to make the key-id always present. > S 3. > >> At least one direction (inbound/outbound) SHOULD have= =20 > a non-NONE MAC in practice, but this MUST NOT be strictl= y=20 > required by an implementation. =20 >=20 > 1. This seems like a bad idea. It's very hard to analyze the security > properties of a connection when only one side is protected. To take > one case that is obviously bad, if you're worried about DoS attacks > and you use TCP-AO, then forging packets in either direction can > bring it down. I would reverse this and require MACs in both directions= =2E For BGP, this is important. For servers, it's not necessarily feasible - = clients may authenticate the server, but the converse may not=20 necessarily be true. Yes, this allows attacks in one direction to=20 succeed, but it also isn't clear that both directions are equally=20 vulnerable, is it? > 2. Even if we stipulate that this might be an OK idea, it's not > appropriate to require implementations to support it. I'm not sure I understand this; if we say that connections MAY have=20 unidirectional auth, then it seems like the implementation MUST support=20 that capability. > S 4.1. > >> New TSAD entries MUST be checked against a table of previously=20 > used TSAD entries, and key reuse MUST be prohibited.=20 >=20 > Huh? So, I have to keep a list of every TSAD entry ever and check > against the table. Seems better to just to do this by construction. I'm not sure what "by construction" means, but that's certainly better=20 if possible. Can you suggest text or explain this off-line? > S 4.3. > >> TCP segments with TCP-AO but not matching TSAD entries MUST be=20 > silently accepted; this is required for equivalent function with TCP= s=20 > not implementing TCP-AO. =20 >=20 > I don't see this. Can you explain? TCP-AO is just a signature. If you don't have enough information to=20 invalidate the signature, you don't have enough reason to drop a segment.= The expected use case is that an endsystem will authenticate only a=20 subset of its connections; for those connections, it would install keys=20 - even if random ones - to "lock" those ports down. It's simpler to do=20 that than to lock everything by default and open things up explictly,=20 IMO, but we can default in either direction if necessary. Consider the case of a system that does not implement TCP-AO. TCP=20 ignores options it doesn't understand, so the connection will work fine. = Now you install TCP-AO, but don't load any keys. The intent is that an=20 un-keyed connection is the same as TCP without TCP-AO. > >> Silent discard events SHOULD be signaled to the user as a warning= ,=20 > and silent accept events MAY be signaled to the user as a warning.=20 >=20 > I don't really understand what a warning means here? syslog? That's one way. Others accumulate the info in a variable that apps can=20 check, e.g., via the socket interface. > S 5. > Implementations are encouraged to keep keys in a suitably private=20 > area. Users of TCP-AO are encouraged to use different keys for=20 > inbound and outbound MACs on a given TCP connection.=20 >=20 > Some discussion of why different keys are good or bad would help > here. As far as I can tell, reflection attacks aren't an issue > as long as the host/port quartet is incuded in the header. Sure. The goal is the general one of avoiding rekeying symmetric data=20 with the same key. It's not based on a specific kind of attack. > S 5.1. > o Number of bytes to be sent/received (two bytes); this is used on = > the send side to trigger bytecount-based KeyID changes, and on th= e=20 > receive side only for statistics or length-sensitive KeyID=20 > selection.=20 >=20 > Please explain the cryptographic rationale for why you would want to > do bytecount based key changes. That part of the API is strawman; we expect to need to count either=20 messages or bytes or both. If message counts are more useful, then we=20 can change to that. > S 9. > TCP-AO does not expose the MAC algorithm used to authenticate a=20 > particular connection; that information is kept in the TSAD at the=20 > endpoints, and is not indicated in the header.=20 >=20 > This seems to be of extremely marginal security benefit. There > are likely to be <5 algorithms in use. So, searching all of them > increases the effective key size by <3 bits.=20 The other reason to not include it is space; it's not needed, since it's = effectively bound to the active key anyway. > EDITORIAL COMMENTS Fixed separately.... Joe --------------enigE118A070FCD485B77E83166F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH1eCQE5f5cImnZrsRAllHAKDo/WvgfbrU52AMgJ5ohFwOINKvYgCg5x0u EHY8Tv0u6qWefoMybdZ95wk= =1QMC -----END PGP SIGNATURE----- --------------enigE118A070FCD485B77E83166F-- From ekr@networkresonance.com Tue Mar 11 07:52:49 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2BBqmVf025552 for ; Tue, 11 Mar 2008 07:52:48 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2BBqdEw000811 for ; Tue, 11 Mar 2008 07:52:39 -0400 (EDT) Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 9C138E2F407 for ; Tue, 11 Mar 2008 07:52:18 -0400 (EDT) Received: from dhcp-1679.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id A85891AB2B9; Tue, 11 Mar 2008 07:52:20 -0400 (EDT) Date: Tue, 11 Mar 2008 07:52:20 -0400 From: Eric Rescorla To: Joe Touch In-Reply-To: <47D5E09A.5000803@isi.edu> References: <47D5E09A.5000803@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080311115220.A85891AB2B9@kilo.rtfm.com> X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: IETF Security Area WG , tcpm@ietf.org Subject: Re: [saag] discussion of draft-rescorla-tcp-auth-arch-00.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 11:52:49 -0000 At Mon, 10 Mar 2008 18:30:02 -0700, Joe Touch wrote: > > Network Working Group E. Rescorla > > Internet-Draft RTFM, Inc. > > Intended status: Informational March 09, 2008 > > Expires: September 10, 2008 > > > > > > Notes on TCP Authentication Architectures > > draft-rescorla-tcp-auth-arch-00.txt > ... > > 1. Introduction > ... > > Note that there is currently two documents > > [I-D.ietf-tcpm-tcp-auth-opt] [I-D.bellovin-tcpsec] that discuss > > additional requirements, but it's not clear to me that these > > requirements have consensus or in fact are correct. > > The documents were presented at the last IETF, where we solicited > comments on those requirements. The requirements were presented as > having the consensus of the TCP-AO design team only at that time. Sure. I was just trying to say that I wasn't taken them as a given for the purposes of this document. > > 3. Keys and Associations > > > > Probably the most important architectural question is the > > relationship of keys to associations. As indicated above, TCP MD5 > > uses a single static key for all associations. This key is > > configured in a pairwise fashion. By contrast, conventional channel > > security protocols such as TLS [RFC4346] or IPsec [RFC4301] establish > > a fresh set of keying material for each association. The proposed > > TCP Authentication Option [I-D.ietf-tcpm-tcp-auth-opt] also requires > > (though does not arrange for) a fresh key for each association. > > TCP-AO is identical to IPsec [i.e., 4301] in that regard; neither > arranges for keys, and both rely on a separate protocol to do so, in the > sense that IPsec relies on IKE. It's similar to IPsec but not identical, in that IPsec's notion of an association spans multiple TCP connections. > > >> New TSAD entries MUST be checked against a table of previously > > used TSAD entries, and key reuse MUST be prohibited. > > > > There are two good (and one not so good) reasons why it's desirable > > to have mechanisms for changing keys: > > Changing keys is not related to the above key reuse issue AFAICT. Well, part of my point in this section is to distinguish these cases in which one might or might not wish to use different keys at different times. > Key changes are to reduce the amount of material signed under a single > key, to reduce the utility of signed packets to a cryptoanalyst. As I indicate in S 3.3, while this is certainly crypto lore for symmetric ciphers, I am unaware of any evidence that having large (but practical) numbers of plaintext/ciphertext pairs is of any significant value in attacking modern algorithms. > Key reuse is critical to preventing replay attacks within a connection > ID (src IP, dst IP, src port, dst port, aka socket pair). It is useful > to avoid keying different ports or even different hosts with the same > key, but only in a general sense (i.e., to again reduce the amount of > material signed with a single key). I'm not sure which issue you're referring to here by "within a socket pair". - With a single connection. - Between connections which happen to share parameters by coincidence. As I indicate in S 3.1, there's no replay issue in the first case except for TCP sequence number rollover, which can be fixed by using extended sequence numbers. The relevant issue is the second case, again discussed in S 3.1, but it's not clear to me how important this actually is. > > o To arrange for different cryptographic keying material to be used > > for each connection, thus preventing cut-and-paste attacks between > > connections. (Good) > > Those don't seem relevant; the ports change, so the signatures would change. Yes, I'm talking about the second of the two issues above. > > o To limit the amount of plaintext/MAC pairs available to the > > attacker (Not-so-good) > > Is that the 'amount of keyed material' kind of stuff above? That was > given by Bellovin as an issue with TCP-MD5. Yes, presumably. As I say, I'm unaware of any cryptographic issue here. > > In TCP, cut-and-paste attacks are also possible within a connection > > due to sequence number rollover. This can be fixed, however, by > > extending the sequence numbers virtually, as done with ESP/AH. > > We definitely do not want to tie the keying directly to the sequence > space for a variety of reasons (we listed some, I believe); this is done > indirectly by bytecounts or packet counts to trigger key changes. The only mention of sequence number in your draft is in S 9: Value (ICV). In TCP-AO, the socket pair performs most of the function of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay attacks, isn't needed due to TCP's Sequence Number, which is used to reorder received segments. Unfortunately, it is not useful to validate TCP's Sequence Number before performing a TCP-AO authentication calculation, because many out-of-window segments still cause TCP protocol actions (e.g., ACK retransmission) [RFC793]. It is similarly not useful to add a separate Sequence Number field to the TCP-AO option, because doing so could cause a change in TCP's behavior even when segments are valid. But this is not what I'm talking about. I'm merely talking about using the ISNs as a diversifier for the per-connection key. Could you elaborate more on issues with this. > > 6.2.1. Internal Key Management Protocol > > > > The traditional approach to this problem would be to build a KMP into > > TCP. This would presumably entail designing a new crypto protocol > > (no small job) which is then carried in a TCP option. > > TCP option space is already consumed by a number of commonly used > options, and we want to retain space for additional options where > possible. Space is most limited in the SYN packet, which is where the > initial key exchange would occur. > > Because there isn't enough TCP option space for this sort of solution, > we excluded it as a possibility. I tend to agree that this is not that attractive an alternative. > > 6.2.3. Layered KMP > > > > Another way to provide a separate KMP is to bind it more tightly to > > the transport protocol by running it over (or next to, as in DTLS- > > SRTP [I-D.ietf-avt-dtls-srtp]) the transport protocol. At the time > > that the association is created, the application initiating the > > association also initiates a KMP exchange over (next to) the > > transport protocol. When the KMP terminates, it outputs keying and > > parameter information and imposes them on the association. In the > > case of TLS over TCP, this would look something like: > > > > TCP Client TCP Server > > ---------- ---------- > > TCP SYN -------------------------------------> > > <---------------------------------- TCP SYN/ACK > > TCP ACK -------------------------------------> > > <--------- TLS Handshake (over TCP) ------> > > Keys to TCP Keys to TCP > > App data (protected with TCP integrity) -----> > > <----- App data (protected with TCP integrity) > > This fails to protect the SYN exchange, which we consider a requirement. I certainly agree that it does not protect the SYN. I noted it as the second major disadvantage. As for whether this is a requirement, I think that's deserving of some discussion. > It also changes state from non-keyed to keyed; it would be very > difficult to introduce that sort of stateful change inside the TCP > protocol in ways that affect the data stream, since no other options > have that kind of effect (i.e., of affecting all data after some point). I'm no expert on TCP options and I'm certainly prepared to believe that no other options have this effect, but I'm not sure I see the issue here as to why this is a problem. The sides can simply place the option in the segment keyed with some null key and algorithm (e.g., all zero MAC) and then start processing when the key is set. As I recall, a similar algorithm is used in SCTP-AUTH. -Ekr From ekr@networkresonance.com Tue Mar 11 07:54:27 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2BBsRDl026403 for ; Tue, 11 Mar 2008 07:54:27 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2BBsI1N004420 for ; Tue, 11 Mar 2008 07:54:18 -0400 (EDT) Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 9812C1008D01 for ; Tue, 11 Mar 2008 07:53:54 -0400 (EDT) Received: from dhcp-1679.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 17B5F1AB2D2; Tue, 11 Mar 2008 07:53:57 -0400 (EDT) Date: Tue, 11 Mar 2008 07:53:57 -0400 From: Eric Rescorla To: Joe Touch In-Reply-To: <47D5E090.9010608@isi.edu> References: <20080310233304.47E9B1AA4C7@kilo.rtfm.com> <47D5E090.9010608@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080311115357.17B5F1AB2D2@kilo.rtfm.com> X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, tcpm@ietf.org Subject: Re: [saag] [tcpm] Comments on draft-ietf-tcpm-tcp-auth-opt-00 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 11:54:28 -0000 At Mon, 10 Mar 2008 18:29:52 -0700, Joe Touch wrote: > Also, I would expect that most of these issues would be useful to > discuss further in TCPM if you're available. Otherwise, we could meet > separately... I do plan to try to attend TCPM. > > GENERAL COMMENTS > > I'm not convinced it's necessary to have a new key for each > > connection. This is primarily useful to prevent inter-connection > > cut-and-paste attacks, and it's not clear how serious those > > are. > > It's there primarily to prevent packets from an old version of a > connection from being used on a new connection, i.e., replay attacks > between a connection and its successor using the same port pair. Right, that's what I mean by "inter-connection cut and paste attacks". I'd like to see some analysis of how serious they are. > > I think it's particularly problematic to levy this > > requirement without providing some mechanism for arranging > > that, since that basically implies having some automatic > > mechanism for establishing fresh per-connection keys, which > > doesn't currently exist. That makes this mechanism distinctly > > less useful than RFC 2385. > > It does imply that for systems that re-establish connections frequently > either a a fresh key generation system is available, or a fairly long > list is preloaded. Right, so absent the definition of such a mechanism, this is less useful than 2385. > > I don't think this API, specification of the TSAD, etc., is > > particularly helpful. IPsec needed the concept of an association > > database because packets corresponding to multiple associations > > got similar treatment. However, TCP has an explicit notion > > of connection so it would be far more convenient to simply > > refer to keys as tied to connections, and then have a set > > of rules for mapping which connections get which keys. > > That's exactly what the TSAD is (or at least is supposed to be). It > might be useful to discuss this offline to figure out what the > disconnect is... Perhaps. I think expressing it as a database isn't particularly helpful. There are structures associated with the connection and it's most useful (IMO) to think of this data as attached to them, just as (for instance) the current window or sequence number is. > > Even if some TSAD-type abstraction is useful, I don't think > > it's appropriate to define things like the size of each > > parameter in the TSAD as opposed to on the wire, > > The TSAD API needs to be specified in detail because the key management > solution needs to rely on that information. > > > or to > > describe the default values of various parameters as in > > S 3. For instance: > > > > iii. Key length. A byte indicating the length of the > > connection key in bytes. > > > > Those are internal implementation issues. Certainly, I might > > want to use a native int in my implementation. Why should > > this document tell me otherwise? > > Again, it's to allow another party - the key management solution - to > load the TSAD. I really don't see this. The other party presumably has some set of API calls/IPC/whatever, that it talks to. It's not our job to specify the interface between those to, other than the contents of the elements. > > S 3. > > >> At least one direction (inbound/outbound) SHOULD have > > a non-NONE MAC in practice, but this MUST NOT be strictly > > required by an implementation. > > > > 1. This seems like a bad idea. It's very hard to analyze the security > > properties of a connection when only one side is protected. To take > > one case that is obviously bad, if you're worried about DoS attacks > > and you use TCP-AO, then forging packets in either direction can > > bring it down. I would reverse this and require MACs in both directions. > > For BGP, this is important. For servers, it's not necessarily feasible - > clients may authenticate the server, but the converse may not > necessarily be true. I don't see why it's not feasible. They share a key, so there's no reason not to have mutual auth. > Yes, this allows attacks in one direction to > succeed, but it also isn't clear that both directions are equally > vulnerable, is it? I don't see this. The relevant attack here is to bring down the connection. An RST in either direction will accomplish that. Thus, ISTM that packets need to be authenticated in both directions. > > 2. Even if we stipulate that this might be an OK idea, it's not > > appropriate to require implementations to support it. > > I'm not sure I understand this; if we say that connections MAY have > unidirectional auth, then it seems like the implementation MUST support > that capability. I don't see that that's true. For instance, TLS stacks MAY support RC4, but we don't require them to support RC4. > > S 4.1. > > >> New TSAD entries MUST be checked against a table of previously > > used TSAD entries, and key reuse MUST be prohibited. > > > > Huh? So, I have to keep a list of every TSAD entry ever and check > > against the table. Seems better to just to do this by construction. > > I'm not sure what "by construction" means, but that's certainly better > if possible. Can you suggest text or explain this off-line? I mean that if you randomly generate keys for the TSAD with an appropriate algorithm then there is no reasonable chance that there will be a collision. > > S 5.1. > > o Number of bytes to be sent/received (two bytes); this is used on > > the send side to trigger bytecount-based KeyID changes, and on the > > receive side only for statistics or length-sensitive KeyID > > selection. > > > > Please explain the cryptographic rationale for why you would want to > > do bytecount based key changes. > > That part of the API is strawman; we expect to need to count either > messages or bytes or both. If message counts are more useful, then we > can change to that. I don't see that you need to count either. > > S 9. > > TCP-AO does not expose the MAC algorithm used to authenticate a > > particular connection; that information is kept in the TSAD at the > > endpoints, and is not indicated in the header. > > > > This seems to be of extremely marginal security benefit. There > > are likely to be <5 algorithms in use. So, searching all of them > > increases the effective key size by <3 bits. > > The other reason to not include it is space; it's not needed, since it's > effectively bound to the active key anyway. That's totally reasonable. I'm not saying it has to be included, just that I don't see not including it as a significant security benefit. -Ekr From touch@ISI.EDU Tue Mar 11 08:23:02 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2BCN0Zc024513 for ; Tue, 11 Mar 2008 08:23:00 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2BCMpp8007542 for ; Tue, 11 Mar 2008 08:22:51 -0400 (EDT) X-ASG-Whitelist: Client Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 66A9076787B for ; Tue, 11 Mar 2008 08:22:51 -0400 (EDT) Received: from [127.0.0.1] ([63.133.180.130]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m2BCISgC014611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Mar 2008 05:18:29 -0700 (PDT) Message-ID: <47D6784B.3030107@isi.edu> Date: Tue, 11 Mar 2008 05:17:15 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eric Rescorla References: <47D5E09A.5000803@isi.edu> <20080311115220.A85891AB2B9@kilo.rtfm.com> In-Reply-To: <20080311115220.A85891AB2B9@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEB93B1C241DC34622A0B2F1D" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: IETF Security Area WG , tcpm@ietf.org Subject: Re: [saag] discussion of draft-rescorla-tcp-auth-arch-00.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 12:23:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEB93B1C241DC34622A0B2F1D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote: =2E.. >>> 3. Keys and Associations >>> >>> Probably the most important architectural question is the >>> relationship of keys to associations. As indicated above, TCP MD5= >>> uses a single static key for all associations. This key is >>> configured in a pairwise fashion. By contrast, conventional chann= el >>> security protocols such as TLS [RFC4346] or IPsec [RFC4301] establ= ish >>> a fresh set of keying material for each association. The proposed= >>> TCP Authentication Option [I-D.ietf-tcpm-tcp-auth-opt] also requir= es >>> (though does not arrange for) a fresh key for each association. >> >> TCP-AO is identical to IPsec [i.e., 4301] in that regard; neither=20 >> arranges for keys, and both rely on a separate protocol to do so, in t= he=20 >> sense that IPsec relies on IKE. >=20 > It's similar to IPsec but not identical, in that IPsec's notion of an > association spans multiple TCP connections. There are numerous differences, however, regarding the statement "does=20 not arrange for) a fresh key for each association", they are identical IM= O. >>> >> New TSAD entries MUST be checked against a table of previous= ly >>> used TSAD entries, and key reuse MUST be prohibited. >>> >>> There are two good (and one not so good) reasons why it's desirabl= e >>> to have mechanisms for changing keys: >> >> Changing keys is not related to the above key reuse issue AFAICT. >=20 > Well, part of my point in this section is to distinguish these > cases in which one might or might not wish to use different > keys at different times. Agreed. Unless your doc is intended to be longer term, it's not an issue.= >> Key changes are to reduce the amount of material signed under a single= =20 >> key, to reduce the utility of signed packets to a cryptoanalyst. >=20 > As I indicate in S 3.3, while this is certainly crypto lore for > symmetric ciphers, I am unaware of any evidence that having > large (but practical) numbers of plaintext/ciphertext pairs=20 > is of any significant value in attacking modern algorithms. That lore is expressed in RFC3562,and implied in RFC4107 in the phrase=20 "short term" key. We'd be glad to be advised otherwise; if so, then: - we could note that the key-ID would be used only for deliberate key changes, e.g., due to compromise, or to avoid a key rollover replay attack note: this is also why we need a byte/segment counter; when it hits 2^32, we MUST change keys or there is a clear replay attack - we could ignore the reuse of keys across different connections within the same machine, though we'd still want to avoid reuse within a connection ID due to replay attacks >> Key reuse is critical to preventing replay attacks within a connection= =20 >> ID (src IP, dst IP, src port, dst port, aka socket pair). It is useful= =20 >> to avoid keying different ports or even different hosts with the same = >> key, but only in a general sense (i.e., to again reduce the amount of = >> material signed with a single key). >=20 > I'm not sure which issue you're referring to here by "within a socket > pair". It's defined in RFC793 as [srcIP, dstIP, srcport, dstport]; it defines a = TCP connection, and noted as such in sec 3 of the tcp-auth I-D. > - With a single connection. > - Between connections which happen to share parameters by coincidence. >=20 > As I indicate in S 3.1, there's no replay issue in the first case > except for TCP sequence number rollover, which can be fixed by > using extended sequence numbers.=20 TCP does not have extended sequence numbers. Adding that=20 cross-connection information, and including it in every tcp-opt header,=20 was explored but is decided against for numerous reasons. > The relevant issue is the > second case, again discussed in S 3.1, but it's not clear to > me how important this actually is. That's why we believe it's sufficient to address this at the TSAD,=20 requiring keys to change when connections end and new ones start with=20 the same port numbers. That can be accomplished in various ways, e.g., by= : - forcing a TSAD key change - keeping a cache of previous TSAD keys for that connection etc. The first one above might be sufficient - and simple to implement - if=20 this is not a severe concern. =2E.. >>> In TCP, cut-and-paste attacks are also possible within a connectio= n >>> due to sequence number rollover. This can be fixed, however, by >>> extending the sequence numbers virtually, as done with ESP/AH. >> >> We definitely do not want to tie the keying directly to the sequence=20 >> space for a variety of reasons (we listed some, I believe); this is do= ne=20 >> indirectly by bytecounts or packet counts to trigger key changes. >=20 > The only mention of sequence number in your draft is in S 9: >=20 > Value (ICV). In TCP-AO, the socket pair performs most of the functio= n=20 > of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay=20 > attacks, isn't needed due to TCP's Sequence Number, which is used to= =20 > reorder received segments. Unfortunately, it is not useful to=20 > validate TCP's Sequence Number before performing a TCP-AO=20 > authentication calculation, because many out-of-window segments stil= l=20 > cause TCP protocol actions (e.g., ACK retransmission) [RFC793]. It i= s=20 > similarly not useful to add a separate Sequence Number field to the = > TCP-AO option, because doing so could cause a change in TCP's=20 > behavior even when segments are valid.=20 Thanks for rechecking; we can add text to capture our previous thoughts=20 on this, though, as you note below, that's not important here. > But this is not what I'm talking about. I'm merely talking about > using the ISNs as a diversifier for the per-connection key. > Could you elaborate more on issues with this. Are you suggesting instead to retain the ISN for a connection and use it = in the crypto alg? TCP doesn't currently require any specific entropy in = the ISN change; if it's sufficient that it change, this might be a way=20 to achieve the lack of key reuse. >>> 6.2.3. Layered KMP >>> >>> Another way to provide a separate KMP is to bind it more tightly t= o >>> the transport protocol by running it over (or next to, as in DTLS-= >>> SRTP [I-D.ietf-avt-dtls-srtp]) the transport protocol. At the tim= e >>> that the association is created, the application initiating the >>> association also initiates a KMP exchange over (next to) the >>> transport protocol. When the KMP terminates, it outputs keying an= d >>> parameter information and imposes them on the association. In the= >>> case of TLS over TCP, this would look something like: >>> >>> TCP Client TCP Server >>> ---------- ---------- >>> TCP SYN -------------------------------------> >>> <---------------------------------- TCP SYN/ACK >>> TCP ACK -------------------------------------> >>> <--------- TLS Handshake (over TCP) ------> >>> Keys to TCP Keys to T= CP >>> App data (protected with TCP integrity) -----> >>> <----- App data (protected with TCP integrity) >> This fails to protect the SYN exchange, which we consider a requiremen= t.=20 >=20 > I certainly agree that it does not protect the SYN. I noted it as > the second major disadvantage. As for whether this is a requirement, > I think that's deserving of some discussion. >=20 >=20 >> It also changes state from non-keyed to keyed; it would be very=20 >> difficult to introduce that sort of stateful change inside the TCP=20 >> protocol in ways that affect the data stream, since no other options=20 >> have that kind of effect (i.e., of affecting all data after some point= ). >=20 > I'm no expert on TCP options and I'm certainly prepared to believe > that no other options have this effect, but I'm not sure I see > the issue here as to why this is a problem. The sides can simply > place the option in the segment keyed with some null key and > algorithm (e.g., all zero MAC) and then start processing when > the key is set. As I recall, a similar algorithm is used in > SCTP-AUTH. We'll raise that today at TCPM, but I expect that all state associated=20 with a TCP connection will continue to be negotiated solely at SYN time. = Agreed that this is not the case for other stateful protocols. Joe --------------enigEB93B1C241DC34622A0B2F1D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH1nhLE5f5cImnZrsRAkkXAJ98fO1wHOTR360hYZnpo/jPRBK2hACdG6Zu 2zkgm++bPMHUvTpFcYKJFC8= =l86h -----END PGP SIGNATURE----- --------------enigEB93B1C241DC34622A0B2F1D-- From Manuel.A.Offenberg@seagate.com Tue Mar 11 08:31:39 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2BCVdhN028070 for ; Tue, 11 Mar 2008 08:31:39 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2BCVUht029446 for ; Tue, 11 Mar 2008 08:31:30 -0400 (EDT) Received: from pps0.sv-ext.mailhost.seagate.com (pps0.sv-ext.mailhost.seagate.com [192.55.4.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 389CC7722A5 for ; Tue, 11 Mar 2008 08:30:57 -0400 (EDT) Received: from sv-gw1.notes.seagate.com (sv-gw1.stsj.seagate.com [10.5.132.29]) by pps0.sv-ext.mailhost.seagate.com (8.13.7/8.13.7) with ESMTP id m2BCUuVA030142 for ; Tue, 11 Mar 2008 05:30:56 -0700 From: Manuel.A.Offenberg@seagate.com To: saag@mit.edu Message-ID: Date: Tue, 11 Mar 2008 04:30:51 -0800 X-MIMETrack: Serialize by Router on SV-GW1/Seagate Internet(Release 7.0.1 HF29|March 07, 2006) at 03/11/2008 04:30:56 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Proofpoint-FWRule: outbound2 X-Spam-Score: 0.55 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Manuel A Offenberg/Seagate is out of office X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 12:31:39 -0000 I will be out of the office starting 03/10/2008 and will not return until 03/13/2008. May have intermittent access to email. For emergencies, please contact me on my cell (415) 235 8917 or Jim Dykes at (720) 684-2601. Kind regards, Manuel Offenberg From touch@ISI.EDU Tue Mar 11 08:34:30 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2BCYUvt029446 for ; Tue, 11 Mar 2008 08:34:30 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2BCYKcw026395 for ; Tue, 11 Mar 2008 08:34:20 -0400 (EDT) X-ASG-Whitelist: Client Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id D4B8AD28B71 for ; Tue, 11 Mar 2008 08:34:19 -0400 (EDT) Received: from [127.0.0.1] ([63.133.180.130]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m2BCX2xm019868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Mar 2008 05:33:04 -0700 (PDT) Message-ID: <47D67BCD.7030508@isi.edu> Date: Tue, 11 Mar 2008 05:32:13 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eric Rescorla References: <20080310233304.47E9B1AA4C7@kilo.rtfm.com> <47D5E090.9010608@isi.edu> <20080311115357.17B5F1AB2D2@kilo.rtfm.com> In-Reply-To: <20080311115357.17B5F1AB2D2@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE5DDAAD1A38E1B3593A26CDE" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, tcpm@ietf.org Subject: Re: [saag] [tcpm] Comments on draft-ietf-tcpm-tcp-auth-opt-00 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 12:34:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE5DDAAD1A38E1B3593A26CDE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Eric, Eric Rescorla wrote: =2E.. >>> GENERAL COMMENTS >>> I'm not convinced it's necessary to have a new key for each >>> connection. This is primarily useful to prevent inter-connection >>> cut-and-paste attacks, and it's not clear how serious those >>> are.=20 >> It's there primarily to prevent packets from an old version of a=20 >> connection from being used on a new connection, i.e., replay attacks=20 >> between a connection and its successor using the same port pair. >=20 > Right, that's what I mean by "inter-connection cut and paste attacks". > I'd like to see some analysis of how serious they are.=20 They would be obvious opportunities for on-path attackers. As per my=20 other reply this AM, using the ISN in the hash might avoid this issue=20 entirely. >>> I think it's particularly problematic to levy this >>> requirement without providing some mechanism for arranging >>> that, since that basically implies having some automatic >>> mechanism for establishing fresh per-connection keys, which >>> doesn't currently exist. That makes this mechanism distinctly >>> less useful than RFC 2385. >> >> It does imply that for systems that re-establish connections frequentl= y=20 >> either a a fresh key generation system is available, or a fairly long = >> list is preloaded. >=20 > Right, so absent the definition of such a mechanism, this is less > useful than 2385. Absolutely. We agree that an auto key mechanism is critical; we feel=20 that, like IPsec, it's not integral. >>> I don't think this API, specification of the TSAD, etc., is >>> particularly helpful. IPsec needed the concept of an association >>> database because packets corresponding to multiple associations >>> got similar treatment. However, TCP has an explicit notion >>> of connection so it would be far more convenient to simply >>> refer to keys as tied to connections, and then have a set >>> of rules for mapping which connections get which keys. >> That's exactly what the TSAD is (or at least is supposed to be). It=20 >> might be useful to discuss this offline to figure out what the=20 >> disconnect is... >=20 > Perhaps. I think expressing it as a database isn't particularly > helpful. There are structures associated with the connection > and it's most useful (IMO) to think of this data as attached > to them, just as (for instance) the current window or sequence > number is. Agreed, and that information is deliberately not accessible. Expression=20 of the info as a dbase is equivalent to how TCP describes a "control=20 block". The important issue is the info in each entry, and the index by=20 which they're differentiated. >>> Even if some TSAD-type abstraction is useful, I don't think >>> it's appropriate to define things like the size of each >>> parameter in the TSAD as opposed to on the wire,=20 >> >> The TSAD API needs to be specified in detail because the key managemen= t=20 >> solution needs to rely on that information. >> >>> or to >>> describe the default values of various parameters as in >>> S 3. For instance: >>> >>> iii. Key length. A byte indicating the length of the=20 >>> connection key in bytes. =20 >>> >>> Those are internal implementation issues. Certainly, I might >>> want to use a native int in my implementation. Why should >>> this document tell me otherwise? >> >> Again, it's to allow another party - the key management solution - to = >> load the TSAD. >=20 > I really don't see this. The other party presumably has some set of > API calls/IPC/whatever, that it talks to. It's not our job to > specify the interface between those to, other than the contents > of the elements.=20 That's basically all we do - contents, order, and size of each element=20 in each direction. >>> S 3. >>> >> At least one direction (inbound/outbound) SHOULD ha= ve=20 >>> a non-NONE MAC in practice, but this MUST NOT be stric= tly=20 >>> required by an implementation. =20 >>> >>> 1. This seems like a bad idea. It's very hard to analyze the security= >>> properties of a connection when only one side is protected. To take >>> one case that is obviously bad, if you're worried about DoS attacks >>> and you use TCP-AO, then forging packets in either direction can >>> bring it down. I would reverse this and require MACs in both directio= ns. >> >> For BGP, this is important. For servers, it's not necessarily feasible= -=20 >> clients may authenticate the server, but the converse may not=20 >> necessarily be true. >=20 > I don't see why it's not feasible. They share a key, so there's > no reason not to have mutual auth. There are cases I can think of - akin to well-known CAs used by web=20 browsers used over wireless channels (see below). >> Yes, this allows attacks in one direction to=20 >> succeed, but it also isn't clear that both directions are equally=20 >> vulnerable, is it? >=20 > I don't see this. The relevant attack here is to bring down the > connection. An RST in either direction will accomplish that. The question is whether a RST in either direction is as easy to inject.=20 There are media with dedicated uplinks and shared downlinks for which=20 this is the case, e.g., some wireless nets. Note that this is all just my playing devils' advocate about whether=20 this is needed; if we agree that we should always require bidirectional=20 auth, then it's a trivial patch to the doc to do so. >>> 2. Even if we stipulate that this might be an OK idea, it's not >>> appropriate to require implementations to support it. >> >> I'm not sure I understand this; if we say that connections MAY have=20 >> unidirectional auth, then it seems like the implementation MUST suppor= t=20 >> that capability. >=20 > I don't see that that's true. For instance, TLS stacks MAY support > RC4, but we don't require them to support RC4. I understand now. I am thinking of this as a required feature; again, if = the TCPM WG and/or SAAG thinks this is either MUST NOT or MAY, then it's = an easy change. >>> S 4.1. >>> >> New TSAD entries MUST be checked against a table of previously = >>> used TSAD entries, and key reuse MUST be prohibited.=20 >>> >>> Huh? So, I have to keep a list of every TSAD entry ever and check >>> against the table. Seems better to just to do this by construction. >> >> I'm not sure what "by construction" means, but that's certainly better= =20 >> if possible. Can you suggest text or explain this off-line? >=20 > I mean that if you randomly generate keys for the TSAD with an > appropriate algorithm then there is no reasonable chance that there > will be a collision. That requires the TSAD only ever be loaded by an automatic key manager,=20 AND that only one such manager ever exist. We don't want to require=20 either for all implementations, thus the TSAD must enforce whatever is=20 needed in this regard. Again, the other email of this AM might suggest a simpler way out using=20 ISNs in the hash. >>> S 5.1. >>> o Number of bytes to be sent/received (two bytes); this is used o= n=20 >>> the send side to trigger bytecount-based KeyID changes, and on = the=20 >>> receive side only for statistics or length-sensitive KeyID=20 >>> selection.=20 >>> >>> Please explain the cryptographic rationale for why you would want to >>> do bytecount based key changes. >> >> That part of the API is strawman; we expect to need to count either=20 >> messages or bytes or both. If message counts are more useful, then we = >> can change to that. >=20 > I don't see that you need to count either.=20 I recalled this; it's for sequence number rollover. There are TCP=20 connections that send more than 2^32 bytes. We MUST rollover keys when=20 that happens, and we do not want to tie the key system to internal TCP=20 state. >>> S 9. >>> TCP-AO does not expose the MAC algorithm used to authenticate a=20 >>> particular connection; that information is kept in the TSAD at the= =20 >>> endpoints, and is not indicated in the header.=20 >>> >>> This seems to be of extremely marginal security benefit. There >>> are likely to be <5 algorithms in use. So, searching all of them >>> increases the effective key size by <3 bits.=20 >> >> The other reason to not include it is space; it's not needed, since it= 's=20 >> effectively bound to the active key anyway. >=20 > That's totally reasonable. I'm not saying it has to be included, just t= hat > I don't see not including it as a significant security benefit. It's not significant, agreed. We might omit that from the doc as a=20 result if others agree. Joe --------------enigE5DDAAD1A38E1B3593A26CDE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH1nvNE5f5cImnZrsRAk5+AKC4hRqj2XfVL3fyN31jfyXQjVHClACfe1Rz uYoJ/WXm39+osLvdfq4fozA= =FjWK -----END PGP SIGNATURE----- --------------enigE5DDAAD1A38E1B3593A26CDE-- From ekr@networkresonance.com Tue Mar 11 08:39:04 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2BCd3PZ031405 for ; Tue, 11 Mar 2008 08:39:03 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2BCcsBl014124 for ; Tue, 11 Mar 2008 08:38:54 -0400 (EDT) Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id A47607D9BB1 for ; Tue, 11 Mar 2008 08:38:52 -0400 (EDT) Received: from dhcp-1679.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 9CF841AB60F; Tue, 11 Mar 2008 08:38:51 -0400 (EDT) Date: Tue, 11 Mar 2008 08:38:51 -0400 From: Eric Rescorla To: Joe Touch In-Reply-To: <47D6784B.3030107@isi.edu> References: <47D5E09A.5000803@isi.edu> <20080311115220.A85891AB2B9@kilo.rtfm.com> <47D6784B.3030107@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080311123851.9CF841AB60F@kilo.rtfm.com> X-Spam-Score: 3.635 X-Spam-Level: *** (3.635) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: IETF Security Area WG , tcpm@ietf.org Subject: Re: [saag] discussion of draft-rescorla-tcp-auth-arch-00.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 12:39:04 -0000 At Tue, 11 Mar 2008 05:17:15 -0700, Joe Touch wrote: > Eric Rescorla wrote: > >> Key changes are to reduce the amount of material signed under a single > >> key, to reduce the utility of signed packets to a cryptoanalyst. > > > > As I indicate in S 3.3, while this is certainly crypto lore for > > symmetric ciphers, I am unaware of any evidence that having > > large (but practical) numbers of plaintext/ciphertext pairs > > is of any significant value in attacking modern algorithms. > > That lore is expressed in RFC3562,and implied in RFC4107 in the phrase > "short term" key. We'd be glad to be advised otherwise; if so, then: > > - we could note that the key-ID would be used only for > deliberate key changes, e.g., due to compromise, or to > avoid a key rollover replay attack > > note: this is also why we need a byte/segment > counter; when it hits 2^32, we MUST change > keys or there is a clear replay attack As I stated in my original document, this is not correct. You simply treat the sequence number as 64 bits long with only the low order 32-bits represented on the wire, but include the entire sequence number in the MAC. The relevant technique is described in RFC 4304. > > - With a single connection. > > - Between connections which happen to share parameters by coincidence. > > > > As I indicate in S 3.1, there's no replay issue in the first case > > except for TCP sequence number rollover, which can be fixed by > > using extended sequence numbers. > > TCP does not have extended sequence numbers. Adding that > cross-connection information, and including it in every tcp-opt header, > was explored but is decided against for numerous reasons. As noted above, this is not included on the wire. > > The relevant issue is the > > second case, again discussed in S 3.1, but it's not clear to > > me how important this actually is. > > That's why we believe it's sufficient to address this at the TSAD, > requiring keys to change when connections end and new ones start with > the same port numbers. That can be accomplished in various ways, e.g., by: > - forcing a TSAD key change > - keeping a cache of previous TSAD keys for that connection > etc. > > The first one above might be sufficient - and simple to implement - if > this is not a severe concern. Well, you're assuming that it's something we need to do at all. Given that it comes at some cost, I think it should be discussed first. > > But this is not what I'm talking about. I'm merely talking about > > using the ISNs as a diversifier for the per-connection key. > > Could you elaborate more on issues with this. > > Are you suggesting instead to retain the ISN for a connection and use it > in the crypto alg? See S 6.1.2. K_connection = HMAC(K_static, ISN_client || ISN_server) -Ekr From ekr@networkresonance.com Tue Mar 11 08:47:02 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2BCl230002681 for ; Tue, 11 Mar 2008 08:47:02 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2BCkq3p017976 for ; Tue, 11 Mar 2008 08:46:52 -0400 (EDT) Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 5A1EEE3B9BC for ; Tue, 11 Mar 2008 08:46:32 -0400 (EDT) Received: from dhcp-1679.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id AFB0C1AB68D; Tue, 11 Mar 2008 08:46:31 -0400 (EDT) Date: Tue, 11 Mar 2008 08:46:31 -0400 From: Eric Rescorla To: Joe Touch In-Reply-To: <47D67BCD.7030508@isi.edu> References: <20080310233304.47E9B1AA4C7@kilo.rtfm.com> <47D5E090.9010608@isi.edu> <20080311115357.17B5F1AB2D2@kilo.rtfm.com> <47D67BCD.7030508@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080311124631.AFB0C1AB68D@kilo.rtfm.com> X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, tcpm@ietf.org Subject: Re: [saag] [tcpm] Comments on draft-ietf-tcpm-tcp-auth-opt-00 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 12:47:02 -0000 Information is getting spread over two threads here, so I will be repeating myself a bit. At Tue, 11 Mar 2008 05:32:13 -0700, Joe Touch wrote: > >>> I don't think this API, specification of the TSAD, etc., is > >>> particularly helpful. IPsec needed the concept of an association > >>> database because packets corresponding to multiple associations > >>> got similar treatment. However, TCP has an explicit notion > >>> of connection so it would be far more convenient to simply > >>> refer to keys as tied to connections, and then have a set > >>> of rules for mapping which connections get which keys. > >> That's exactly what the TSAD is (or at least is supposed to be). It > >> might be useful to discuss this offline to figure out what the > >> disconnect is... > > > > Perhaps. I think expressing it as a database isn't particularly > > helpful. There are structures associated with the connection > > and it's most useful (IMO) to think of this data as attached > > to them, just as (for instance) the current window or sequence > > number is. > > Agreed, and that information is deliberately not accessible. Expression > of the info as a dbase is equivalent to how TCP describes a "control > block". The important issue is the info in each entry, and the index by > which they're differentiated. I think we're going to have to disagree on this one. > > I really don't see this. The other party presumably has some set of > > API calls/IPC/whatever, that it talks to. It's not our job to > > specify the interface between those to, other than the contents > > of the elements. > > That's basically all we do - contents, order, and size of each element > in each direction. Well "contents" != "contents, order, and size" and I haven't heard a clear demonstration that "order and size" are required". > > I don't see why it's not feasible. They share a key, so there's > > no reason not to have mutual auth. > > There are cases I can think of - akin to well-known CAs used by web > browsers used over wireless channels (see below). Well, I think any case in which you have public key is fundamentally different: shared keys imply an opportunity for utual authentication. > >>> >> New TSAD entries MUST be checked against a table of previously > >>> used TSAD entries, and key reuse MUST be prohibited. > >>> > >>> Huh? So, I have to keep a list of every TSAD entry ever and check > >>> against the table. Seems better to just to do this by construction. > >> > >> I'm not sure what "by construction" means, but that's certainly better > >> if possible. Can you suggest text or explain this off-line? > > > > I mean that if you randomly generate keys for the TSAD with an > > appropriate algorithm then there is no reasonable chance that there > > will be a collision. > > That requires the TSAD only ever be loaded by an automatic key manager, > AND that only one such manager ever exist. We don't want to require > either for all implementations, thus the TSAD must enforce whatever is > needed in this regard. No, I don't agree with this. Rather, implementors must ensure that they don't duplicate entry. If they have two management processes, they need to somehow coordinate (or use independent algorithms). That does not mean that the TSAD needs to verify that. Note that verifying it means retaining records of every key. That seems impractical. > >>> S 5.1. > >>> o Number of bytes to be sent/received (two bytes); this is used on > >>> the send side to trigger bytecount-based KeyID changes, and on the > >>> receive side only for statistics or length-sensitive KeyID > >>> selection. > >>> > >>> Please explain the cryptographic rationale for why you would want to > >>> do bytecount based key changes. > >> > >> That part of the API is strawman; we expect to need to count either > >> messages or bytes or both. If message counts are more useful, then we > >> can change to that. > > > > I don't see that you need to count either. > > I recalled this; it's for sequence number rollover. There are TCP > connections that send more than 2^32 bytes. We MUST rollover keys when > that happens, and we do not want to tie the key system to internal TCP > state. See my previous note for how to do this without rollover using ESNs. -Ekr From leiba@watson.ibm.com Tue Mar 11 11:14:35 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2BFEZmw001129 for ; Tue, 11 Mar 2008 11:14:35 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2BFEJvk007136 for ; Tue, 11 Mar 2008 11:14:21 -0400 (EDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 6C674782126 for ; Tue, 11 Mar 2008 11:04:09 -0400 (EDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m2BF48eu030180 for ; Tue, 11 Mar 2008 11:04:08 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m2BF3rD3234324 for ; Tue, 11 Mar 2008 11:03:54 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m2BF3rXr020650 for ; Tue, 11 Mar 2008 11:03:53 -0400 Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m2BF3rdX020640 for ; Tue, 11 Mar 2008 11:03:53 -0400 Received: from wecm-9-67-175-178.wecm.ibm.com ([9.67.175.178]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1205247832.2941; Tue, 11 Mar 2008 10:03:53 -0400 Date: Tue, 11 Mar 2008 11:03:52 -0400 From: Barry Leiba To: saag@mit.edu Message-ID: <1C0560A379B9B2B7ED1EA22A@Uranus.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] IETF 71: DKIM working group summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 15:14:35 -0000 [Sorry; I mis-posted this to secdir; reposting to saag.] IETF 71 DKIM meeting summary The DKIM working group met on Monday, 10 March 2008, from 1740-1950 in the Franklin 5 room. The main goal of the meeting was to discuss and close issues on the Author Signing Policy document and move toward WGLC on that document. The meeting opened with a review of the informational documents, "DKIM Service Overview"[1] and "DKIM Service Deployment"[2]. The former is mostly done, but for some editorial comments. WGLC on the content started at the close of the meeting, and will end on 24 March. The latter is still under development. The authors solicited reviews and contributions from those developing software for DKIM, deploying it, or operating mail systems with it. Ellen Siegel, who works for an email marketing company, had comments about the timing of the documents, and the importance of having some early advice on the deployment of signing practices. Tony Hansen met with a few people after the meeting. The bulk of the meeting was then spent going through the open issues on the signing practices document, now called "Author Signing Practices"[3] ("Author" replacing "Sender", and there was some discussion on the name, with one WG chair preferring "From Domain", shortened to "FroDo"). Jim Fenton discussed the history of the recent changes (which involved a significant restructuring of the document, a restructuring that resolved a number of issues), and then divided the open issues into three groups, roughly "easy", "medium", and "hard" -- more specifically, "We should close these," "These might be ready to close," and "These probably need more discussion." The result of the issue run-through and discussion related to the latest (-03) draft was that, pending confirmation on the mailing list, we can close all but two of the "easy" issues, all but two of the "medium" ones, and all but one of the "hard" issues (but see below). Most of the "hard" discussion was on issue 1519, user vs domain granularity of signing practices. Consensus was to leave it at domain granularity only, leaving any extension to user granularity for a protocol extension. We'll leave this issue open for two weeks, to allow further discussion. Some issues remaining open: 1519 - user vs domain granularity of signing practices 1535 - clarify need for domain existence check in the decision tree (step 2) 1543 - remove [FWS]; there's a significant move to keep it, just for consistency with the base spec 1547 - require existence of MX records; leave open awaiting follow-up from Peter Koch 1550 - the name of the document (remains open *briefly*); there's still disagreement on "Author" In addition, Phill Hallam-Baker agreed to review the security considerations and add any appropriate text about security threats. Peter Koch will post a message to the list about his concerns about DNS queries (which may open a new issue). And we will open a new issue to replace 1520, which will address only the *name* of the "Discardable" feature -- there's significant dislike of the name, but it's not clear that we'll find a better one. This issue will be open for two weeks only, to avoid having it turn into an interminable discussion. --- [1] Slides at http://www3.ietf.org/proceedings/08mar/slides/dkim-1.pdf Document at http://tools.ietf.org/html/draft-ietf-dkim-overview [2] Slides at http://www3.ietf.org/proceedings/08mar/slides/dkim-2.pdf Document at http://tools.ietf.org/html/draft-ietf-dkim-deployment [3] Slides at http://www3.ietf.org/proceedings/08mar/slides/dkim-0.pdf Document at http://tools.ietf.org/html/draft-ietf-dkim-ssp -- Barry Leiba, DKIM working group chair (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam From tim.polk@nist.gov Wed Mar 12 08:30:52 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2CCUqXU008211 for ; Wed, 12 Mar 2008 08:30:52 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2CCUf8m012096 for ; Wed, 12 Mar 2008 08:30:42 -0400 (EDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 4E246E2F352 for ; Wed, 12 Mar 2008 08:30:21 -0400 (EDT) Received: from [129.6.222.23] ([129.6.222.23]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m2CCUEG4025151; Wed, 12 Mar 2008 08:30:15 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tim Polk Date: Wed, 12 Mar 2008 08:30:14 -0400 To: saag@mit.edu X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] reminder:kmart bof X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 12:30:52 -0000 Folks, Just wanted to remind everyone that we will be continuing our discussions from the Vancouver SAAG in the KMART BOF today from 1 - 3 PM. I hope to se you all there! Thanks, Tim Polk From ekr@networkresonance.com Wed Mar 12 09:09:00 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2CD90N4023945 for ; Wed, 12 Mar 2008 09:09:00 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2CD8oNS001045 for ; Wed, 12 Mar 2008 09:08:50 -0400 (EDT) Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 97A41E30603 for ; Wed, 12 Mar 2008 09:08:29 -0400 (EDT) Received: from dhcp-11ec.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 773171AEFB0 for ; Wed, 12 Mar 2008 09:08:29 -0400 (EDT) Date: Wed, 12 Mar 2008 09:08:29 -0400 From: Eric Rescorla To: saag@mit.edu User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080312130829.773171AEFB0@kilo.rtfm.com> X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Summary of TLS WG X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 13:09:00 -0000 $Id$ TLS met Monday at 1520-1420 for an hour. Don Eastlake presented RFC 4366-bis, which is the separate draft for TLS extensions. This is mostly editorial but there are two technical issues about certificate URL hashing. The general consensus was (1) to mandate the hash and (2) deal with hash agility by defining a new code point if we need to. Pasi Eronen presented the DES/IDEA cipher suite document, which breaks those cipher suites out of the main TLS draft. There was discussion about what kind of disclaimer to use and general consensus that in future we need to put clear applicability statements on cipher suites. Pascal Urien presented ECDHE_PSK, a new WG item. This hasn't had enough review to advance yet. We commissioned two reviews. Eric Rescorla presented plans for DTLS 1.1. The intention is simply to rev the version to align with TLS 1.2 and fix ambiguities in the original spec. There was substantial support for adopting this as a WG item--needs to be confirmed on list. Kato Akihiro presented Camellia cipher suites with SHA-256. Camellia is already in TLS, but with SHA-1. -Ekr From ekr@networkresonance.com Wed Mar 12 09:27:05 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2CDR5ED031550 for ; Wed, 12 Mar 2008 09:27:05 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2CDQuQc029001 for ; Wed, 12 Mar 2008 09:26:56 -0400 (EDT) Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 2F618E32472 for ; Wed, 12 Mar 2008 09:26:31 -0400 (EDT) Received: from dhcp-11ec.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 4569A1AF112; Wed, 12 Mar 2008 09:26:30 -0400 (EDT) Date: Wed, 12 Mar 2008 09:26:30 -0400 From: Eric Rescorla To: Lakshminath Dondeti In-Reply-To: <47D7D9AB.2060005@qualcomm.com> References: <20080312130829.773171AEFB0@kilo.rtfm.com> <47D7D9AB.2060005@qualcomm.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080312132630.4569A1AF112@kilo.rtfm.com> X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Summary of TLS WG X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 13:27:05 -0000 At Wed, 12 Mar 2008 06:24:59 -0700, Lakshminath Dondeti wrote: > > > > On 3/12/2008 6:08 AM, Eric Rescorla wrote: > > $Id$ > > > > TLS met Monday at 1520-1420 for an hour. > > > > Ekr, > > I know you speak fast, but didn't realize it was fast enough for time > travel. > > This is a great achievement! I was there at the meeting, but failed to > notice clocks turning back in time. I was not wearing a watch at that > time; perhaps that was why. Well, it's a Schrodinger's cat thing. If you had been looking at your watch, then it wouldn't have happened. -Ekr From ldondeti@qualcomm.com Wed Mar 12 09:39:03 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2CDd3MA004016 for ; Wed, 12 Mar 2008 09:39:03 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2CDcqU1023505 for ; Wed, 12 Mar 2008 09:38:53 -0400 (EDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id C1FB878A9D9 for ; Wed, 12 Mar 2008 09:25:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1205328320; x=1236864320; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<47D7D9AB.2060005@qualcomm.com>|Date:=20We d,=2012=20Mar=202008=2006:24:59=20-0700|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.12=20(Windows/20080213)|MIME-Version:=201 .0|To:=20Eric=20Rescorla=20|CC: =20saag@mit.edu|Subject:=20Re:=20[saag]=20Summary=20of=20 TLS=20WG|References:=20<20080312130829.773171AEFB0@kilo.r tfm.com>|In-Reply-To:=20<20080312130829.773171AEFB0@kilo. rtfm.com>|Content-Type:=20text/plain=3B=20charset=3DISO-8 859-15=3B=20format=3Dflowed|Content-Transfer-Encoding:=20 7bit|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5249" =3B=20a=3D"1056052"; bh=UwSKyv60net1tnlZXKxNn3EqjRDDuSvgVyuestEwCNI=; b=OHbQfM1yWRCJWBMnqInraCccFjpu9/UoTlYySffZjGJ8wMBWMhsFTGlq 0VTb85uR7QCMClXCsfX55pTjrckgyvmlAmt8YWYyM0Gj1YiE85A6H9pkj jfkO8kmqpu29ZUKnYC9WD0mnbFiXvKQ8gJjlQ4TtLUw/FIpu2545I/tlN s=; X-IronPort-AV: E=McAfee;i="5200,2160,5249"; a="1056052" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Mar 2008 06:24:59 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2CDP1ju004130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Mar 2008 06:25:02 -0700 Received: from [10.50.72.188] (qconnect-10-50-72-188.qualcomm.com [10.50.72.188]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2CDOxTK009395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Mar 2008 06:25:00 -0700 (PDT) Message-ID: <47D7D9AB.2060005@qualcomm.com> Date: Wed, 12 Mar 2008 06:24:59 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eric Rescorla References: <20080312130829.773171AEFB0@kilo.rtfm.com> In-Reply-To: <20080312130829.773171AEFB0@kilo.rtfm.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Summary of TLS WG X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 13:39:03 -0000 On 3/12/2008 6:08 AM, Eric Rescorla wrote: > $Id$ > > TLS met Monday at 1520-1420 for an hour. > Ekr, I know you speak fast, but didn't realize it was fast enough for time travel. This is a great achievement! I was there at the meeting, but failed to notice clocks turning back in time. I was not wearing a watch at that time; perhaps that was why. :) regards, Lakshminath From shanna@juniper.net Wed Mar 12 13:30:41 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2CHUd1W004342 for ; Wed, 12 Mar 2008 13:30:41 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2CHUTTs026480 for ; Wed, 12 Mar 2008 13:30:29 -0400 (EDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 58945799E6F for ; Wed, 12 Mar 2008 13:30:08 -0400 (EDT) Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Wed, 12 Mar 2008 10:28:34 PDT Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Mar 2008 10:29:50 -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" Date: Wed, 12 Mar 2008 13:29:21 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 71 NEA WG summary Thread-Index: AciEZpuoeg7JgsfETEyZkkHI8rGOcg== From: "Stephen Hanna" To: X-OriginalArrivalTime: 12 Mar 2008 17:29:50.0344 (UTC) FILETIME=[ACF6B880:01C88466] X-Spam-Score: 3.5 X-Spam-Level: *** (3.5) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m2CHUd1W004342 Subject: [saag] IETF 71 NEA WG summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 17:30:41 -0000 The Network Endpoint Assessment (NEA) WG met at IETF 71 on Tuesday, March 11, 2008 from 9 AM to 11:30 AM EDT. We reviewed changes made in draft-ietf-nea-requirements-06.txt in response to IESG COMMENTs and DISCUSSes. No issues were identified with those changes. They will be reviewed further on the NEA WG email list. The bulk of the meeting was spent reviewing the PB-TNC, PA-TNC, and PA-TNC Security proposals. These were the only responses to our request for protocol proposals that meet the NEA requirements. After a good discussion of the proposals, a consensus check showed a clear consensus in the room to accept PB-TNC and PA-TNC as WG drafts. For PA-TNC Security, the consensus was to defer action for now. These decisions will be confirmed on the NEA WG email list. A new set of NEA WG milestones was reviewed. These have previously been reviewed on the WG list and are almost identical to the version reviewed at IETF 70. No concerns have been raised so they will be submitted. From tim.polk@nist.gov Wed Mar 12 17:20:30 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2CLKUgn016486 for ; Wed, 12 Mar 2008 17:20:30 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2CLKLAQ028762 for ; Wed, 12 Mar 2008 17:20:22 -0400 (EDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id D984A80BD4F for ; Wed, 12 Mar 2008 17:20:08 -0400 (EDT) Received: from [129.6.222.92] ([129.6.222.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m2CLJvq9007936; Wed, 12 Mar 2008 17:20:00 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3EBD71AC-EC1B-4D48-8011-B63D28C84072@nist.gov> Content-Transfer-Encoding: 7bit From: Tim Polk Date: Wed, 12 Mar 2008 17:19:03 -0400 To: saag@mit.edu X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] call for wg co-chair nominations: emu; tls; and msec X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 21:20:30 -0000 Pasi and I would appreciate nominations for co-chair positions for three working groups within the Security Area. The positions are co- chair for emu, tls, and msec. The emu working group has been operating with a single chair, Joe Salowey, for a long time now. Emu is currently considering significant charter revisions, and this prospective new work could increase the workload beyond that appropriate for a single chair. The tls working group has been co-chaired by Eric Rescorla and Pasi Eronen. As part of AD transition, we have decided that Pasi should become the responsible AD for tls, creating the second vacancy. The msec working group has been co-chaired by Lakshminath Dondeti and Ran Canetti. Ran no longer has the time and is stepping down, so msec will be needing a new chair as well. If you would like to be considered for one of these position, or wish to nominate someone else, please contact Pasi or me directly. From Shawn.Emery@Sun.COM Wed Mar 12 15:46:43 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2CJkhoI001514 for ; Wed, 12 Mar 2008 15:46:43 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2CJkYrg007711 for ; Wed, 12 Mar 2008 15:46:34 -0400 (EDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mit.edu (Spam Firewall) with ESMTP id AE38B79699F for ; Wed, 12 Mar 2008 15:46:12 -0400 (EDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2CJkC5F019121 for ; Wed, 12 Mar 2008 19:46:12 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXM00L01U9PEV00@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM) for saag@mit.edu; Wed, 12 Mar 2008 13:46:12 -0600 (MDT) Received: from dhcp-15a7.ietf71.ietf.org ([129.150.66.199]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXM00JMSUWOVNB0@mail-amer.sun.com>; Wed, 12 Mar 2008 13:46:01 -0600 (MDT) Date: Wed, 12 Mar 2008 13:42:55 -0600 From: "Shawn M. Emery" Sender: Shawn.Emery@Sun.COM To: saag@mit.edu Message-id: <47D8323F.5070405@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) X-Spam-Score: 0.001 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Wed, 12 Mar 2008 17:20:54 -0400 Cc: Alexey Melnikov Subject: [saag] IETF 71 Kitten Working Group Summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 19:46:43 -0000 The kitten-wg met Tuesday, 3/11/08, during the last afternoon session. Co-chairs: Alexey Melnikov and Shawn Emery The goals of the meeting were to go over the active working items and Milestones. Important developments included both domain-based drafts: draft-ietf-kitten-gssapi-domain-based-names draft-ietf-kitten-gssapi-krb5-domain-based-names clearing DISCUSS issues and are now in the RFC editor's queue. IANA extension draft: draft-ietf-kitten-gssapi-extensions-iana-02 has made progress, but still needs more guidance for IANA. One solution provided would be to create an appendix with examples from existing mechanisms. Editor will make these changes and we have volunteer reviewers before WGLC. The channel-bindings clarification draft: draft-ietf-kitten-gssapi-channel-bindings-03 is close to starting WGLC after normative reference update to RFC5056. Currently needs Introduction and IANA Considerations sections before submitting. New editor has volunteered to take over naming extensions ID: draft-ietf-kitten-gssapi-naming-exts-02 which needs the most work compared to the other drafts in the WG. We have decided to spread out the work load by submitting WGLC on the Java bindings draft: draft-ietf-kitten-rfc2853bis-03. after the IANA, channel bindings, and the naming extensions draft. Milestones have been pushed out. Co-chairs will update with the new time lines shortly. Shawn and Alexey. -- From Pasi.Eronen@nokia.com Thu Mar 13 10:53:06 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2DEr5fB020597 for ; Thu, 13 Mar 2008 10:53:06 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2DEqxqX016688 for ; Thu, 13 Mar 2008 10:52:59 -0400 (EDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 3CAE3E37306 for ; Thu, 13 Mar 2008 10:52:37 -0400 (EDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m2DEqSrg005817; Thu, 13 Mar 2008 16:52:34 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 16:51:51 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 16:51:51 +0200 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" Date: Thu, 13 Mar 2008 16:51:50 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB7218393D@vaebe104.NOE.Nokia.com> In-Reply-To: <3EBD71AC-EC1B-4D48-8011-B63D28C84072@nist.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] call for wg co-chair nominations: emu; tls; and msec Thread-Index: AciEh9uhYu+OYImUReKgrcEm6s7ZiwAkW1QA References: <3EBD71AC-EC1B-4D48-8011-B63D28C84072@nist.gov> From: To: , X-OriginalArrivalTime: 13 Mar 2008 14:51:51.0766 (UTC) FILETIME=[C5B43F60:01C88519] X-Nokia-AV: Clean X-Spam-Score: 0.69 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m2DEr5fB020597 Subject: Re: [saag] call for wg co-chair nominations: emu; tls; and msec X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 14:53:08 -0000 I'd like to add that we're also open to considering new blood; i.e., someone who hasn't been a WG chair before. If you know someone you think would be interested, drop us a note. Best regards, Pasi > -----Original Message----- > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On > Behalf Of ext Tim Polk > Sent: 12 March, 2008 23:19 > To: saag@mit.edu > Subject: [saag] call for wg co-chair nominations: emu; tls; and msec > > > Pasi and I would appreciate nominations for co-chair positions for > three working groups within the Security Area. The > positions are co- > chair for emu, tls, and msec. > > The emu working group has been operating with a single chair, Joe > Salowey, for a long time now. Emu is currently considering > significant charter revisions, and this prospective new work could > increase the workload beyond that appropriate for a single chair. > > The tls working group has been co-chaired by Eric Rescorla and Pasi > Eronen. As part of AD transition, we have decided that Pasi should > become the responsible AD for tls, creating the second vacancy. > > The msec working group has been co-chaired by Lakshminath > Dondeti and > Ran Canetti. Ran no longer has the time and is stepping down, so > msec will be needing a new chair as well. > > If you would like to be considered for one of these position, > or wish > to nominate someone else, please contact Pasi or me directly. > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > From kent@bbn.com Thu Mar 13 11:27:20 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2DFRKn7002322 for ; Thu, 13 Mar 2008 11:27:20 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2DFRABv000837 for ; Thu, 13 Mar 2008 11:27:10 -0400 (EDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by mit.edu (Spam Firewall) with ESMTP id 4EA20101B6BC for ; Thu, 13 Mar 2008 11:26:48 -0400 (EDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.16.169]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JZpKS-0002in-52 for saag@mit.edu; Thu, 13 Mar 2008 11:26:48 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 13 Mar 2008 11:27:00 -0400 To: saag@mit.edu From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 2.29 X-Spam-Level: ** (2.29) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] (no subject) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 15:27:20 -0000 PKIX met once for 2.5 hours on Monday, 3.10.08, with about 60 attendees. Four PKIX documents have received IESG approval since the last IETF meeting (3 of these were approved this week): 3280bis and the CMC trio. There were five presentations on WG items, and five on related items. Two existing PKIX RFCs (3279 and 4055), to align with our newly adopted approach to representing public key algorithms with parameters, are undergoing minor revisions and should be completed soon. The effort to update PKIX specs to use the 1998/2002 version of ASN.1 is progressing. Jim Schaad described the merits of one of the new constructs in this version of ASN.1, objects. The trust anchor management effort was the topic of two presentations. The first reviewed the current version of the problem statement I-D, and noted the plan to abandon this document and transition much of the text into a requirements statement I-D. Questions were raised on the list about about the relationship between the TAM data structures and SCVP, so the speaker presented an analysis of the two. Although there is an overlap, there are enough differences to suggest that it makes sense to continue development of the TAM data structures without trying to adopt the SCVP structure in toto. The second presentation described a directory-based approach to TA management, and compared it to the request/response protocol approach that has been put forth so far. Both approaches can benefit from a common data structure model, but each approach offers somewhat different functionality. The PKI Resource Query Protocol (PRQP) was briefed for a third time. This protocol is slated to be an experimental RFC. and was accepted as a WG item (with that stipulation) as the result of a straw poll conducted in December. It may be close to a WG last call. A discussion of the use of wildcards in DSN names in certs concluded with an agreement that this topic is adequately addressed in 3280bis; processing semantics beyond what 3280bis describes are best handled in the WGs responsible for the secruity protocols that allow use of this convention. There was a second presentation on a proposed extension to allow a cert to carry pointers to other certs that have been issued to the same subject. Additional text in the I-D is needed to clarify some issues raised during Q&A, before the WG can decide if it wants to adopt this as a new work item. There was a presentation on a model for issuing Traceable Anonymous Certificates (TACs). The model is compatible with the PKIX/X.509 cert format and with PKIX cert request protocols. Validation of a TAC is also compatible with PKIX standards. The motivation for TACs is to allow issuance of (EE) certs that contain a Subject name that does not disclose the real name of the Subject, but which can be traced to the real user if needed, e.g., in case of abuse by the user. The speaker requested feedback from PKIX members and solicited a co-author for the document. Scott Rea (Dartmouth) made a very brief appeal for assistance from IETF PKI experts. His work is exploring how to improve the usability of PKIs by "ordinary" users. The final presentation was on a proposed extension to represent subject clearance (of processing authorization, for devices) information in PK certs (vs. attribute certs). The format is one already defined for attribute certs by ITU-T (and thus is in RFC 3281), and is is used in SMIME ESS (RFC 3851). Adpproval for adoption of this as a WG item will be pursued on the list. From tlyu@MIT.EDU Thu Mar 13 12:28:46 2008 Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2DGSiD7002557 for ; Thu, 13 Mar 2008 12:28:46 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2DGSh2U003651 for ; Thu, 13 Mar 2008 12:28:43 -0400 (EDT) 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 m2DGSg8j022620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Mar 2008 12:28:43 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id m2DGSgHr001326; Thu, 13 Mar 2008 12:28:42 -0400 (EDT) To: saag@MIT.EDU From: Tom Yu Date: Thu, 13 Mar 2008 12:28:42 -0400 Message-ID: Lines: 52 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Subject: [saag] IETF71 SASL WG summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 16:28:46 -0000 Simple Authentication And Security Layer (SASL) IETF71, Philadelphia, PA Tuesday, March 11, 2008 at 13:00-15:00 ====================================== Chairs: Tom Yu Kurt Zeilenga ==================== Thanks to Cyrus Daboo for scribing. IESG discussion on recharter proposal results in a desire to have additional details on the requirements for the DIGEST-MD5 successor. Some text was proposed on mailing list; we will work on a shorter summary for the actual charter text and send the longer version for additional explanation to the IESG if needed. Block digest-to-historic behind SCRAM? Various strategies proposed, including putting a normative reference to SCRAM. We decide that we will ask Pasi what works best for him in terms of document workflow. Tangential discussion about moving http-digest to historic; conclude that the question is not for this working group to decide. Is SCRAM what we have consensus on for the DIGEST-MD5 successor? Eventually Simon Josefsson, Chris Newman, and Alexey Melnikov agree to merge Simon's doc with SCRAM. They will also produce a comparison of Simon's doc and SCRAM. Block GS2 behind SCRAM? Simon wants to wait until it's in rfc editor queue. Alexey would rather at least one additional GS2 mech prior to implementing GS2. We want to avoid yet another previously-general mechanism family that only supports GSS-API/Kerberos. Postpone decision until IETF72 (Dublin). Frank Ellerman made a WGLC comment on digest-to-historic, detailing the http-digest incompatibility with DIGEST-MD5. Alexey will respond to Frank's comment re digest-to-historic by the end of the week. Kurt to coordinate interop testing in dublin ACTION ITEMS: Alexey will respond to Frank's comment on digest-to-historic by the end of the week. Simon, Alexey, Chris will produce a merged document for DIGEST-MD5 successor by May 1st, including a comparison of Simon's mech and SCRAM. From clancy@ltsnet.net Thu Mar 13 13:16:15 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2DHGFEf027777 for ; Thu, 13 Mar 2008 13:16:15 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2DHG3wS014477 for ; Thu, 13 Mar 2008 13:16:03 -0400 (EDT) Received: from bacon.cs.umd.edu (server-nat-2.cs.umd.edu [128.8.127.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id E89F7E29D90 for ; Thu, 13 Mar 2008 13:15:39 -0400 (EDT) Received: from [127.0.0.1] (dhcp-108d.ietf71.ietf.org [130.129.16.141]) (authenticated bits=0) by bacon.cs.umd.edu (8.13.1/8.12.5) with ESMTP id m2DHFXR1007813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Mar 2008 13:15:34 -0400 Message-ID: <47D96130.80003@ltsnet.net> Date: Thu, 13 Mar 2008 13:15:28 -0400 From: Charles Clancy User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: saag@mit.edu Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.399, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.00, BAYES_00 -2.60) X-CSD-MailScanner-From: clancy@ltsnet.net X-Spam-Status: No X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] HOKEY WG Summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 17:16:15 -0000 HOKEY met Wednesday morning. Most of the discussion related to the HOKEY key management draft, which describes how to distribute EAP session keys to various network entities. Discussion resulted in consensus and a specific plan for how to move the document forward within the working group. Specifically, the proposal involves simplifying the protocol to a single RT between the key recipient and the home AAA server, and relying on AAA security rather than implementing our own. Document status: HOKEY Re-authentication Problem Statement draft-ietf-hokey-key-mgm RFC Editor's Queue EAP Reauthentication Extensions (ERX) draft-ietf-hokey-erx IESG Evaluation EMSK Keying Hierarchy draft-ietf-hokey-emsk-hierarchy IETF Last Call HOKEY Key Management draft-ietf-hokey-key-mgm Still under construction Pre-authentication Problem Statement draft-ietf-hokey-preauth-ps WGLC to start soon -- Dr. Charles Clancy www.ltsnet.net/~clancy Senior Researcher, Laboratory for Telecommunications Sciences From jsalowey@cisco.com Thu Mar 13 13:23:21 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2DHNL1Q030803 for ; Thu, 13 Mar 2008 13:23:21 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2DHN94j027580 for ; Thu, 13 Mar 2008 13:23:10 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 4E058E47867 for ; Thu, 13 Mar 2008 13:22:49 -0400 (EDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 13 Mar 2008 10:22:48 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m2DHMmhx018266 for ; Thu, 13 Mar 2008 10:22:48 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m2DHMX5s029439 for ; Thu, 13 Mar 2008 17:22:48 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 10:22:38 -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" Date: Thu, 13 Mar 2008 10:23:24 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EMU Working group summary Thread-Index: AciFLvF/FGAGDxcCQ9GxkNbm5C2Gjw== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 13 Mar 2008 17:22:38.0800 (UTC) FILETIME=[D6281500:01C8852E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=486; t=1205428968; x=1206292968; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20EMU=20Working=20group=20summary |Sender:=20; bh=GduGQ9r+JQqrgrbiRNvqcjIDXR6hmv0PGUCs+a1US48=; b=azhMJ2EROyihqvAoyQl8qa4QAxrJXB9KYyI29+5U1lIyf/L1x4K/OAgttQ qpx/kPgkI2sxt54oDbKRAzteu0yBX3zpmcLucqDxrddYcmiIBzmbN6OoMuiz QeMrsAgnCy; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m2DHNL1Q030803 Subject: [saag] EMU Working group summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 17:23:22 -0000 EAP Method Update (EMU) working group met Thursday morning. Discussion primarily focused on revising the charter to include tunnel method and the definition of EAP Channel Bindings. Next steps are finalizing the charter and requirements for the tunnel method. We also had a presentation on a secure password only method (draft-harkins-emu-eap-pwd-01). There was some interest in this type of method, but the working group was not ready to take this work on at this time. From jhutz@cmu.edu Thu Mar 13 13:38:01 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2DHc1wJ005555 for ; Thu, 13 Mar 2008 13:38:01 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2DHbpAn027839 for ; Thu, 13 Mar 2008 13:37:51 -0400 (EDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id AB447D164CB for ; Thu, 13 Mar 2008 13:37:30 -0400 (EDT) Received: from dhcp-162c.ietf71.ietf.org (dhcp-162c.ietf71.ietf.org [130.129.22.44]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m2DHbSnZ007810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 13:37:29 -0400 (EDT) Date: Thu, 13 Mar 2008 13:37:28 -0400 From: Jeffrey Hutzelman To: ietf-krb-wg@anl.gov, saag@mit.edu Message-ID: X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Kerberos WG IETF71 meeting summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 17:38:02 -0000 This is a SUMMARY of the Kerberos WG meeting held this week in Philadelphia as part of the 71st IETF meeting. Full minutes will be posted on a later date. -- Jeff Kerberos Working Group - IETF 71 meeting summary ACTION ITEMS: * Nicolas Williams - send an updated version of set-change password * Chairs - finish review and writeup of cross-realm problem statement * Larry Zhu - prepare an example for naming of how unintended access could be granted if authentication succeedes with an unsupported well-known name. * Chairs - ask folks commenting that the data model might be incomplete to come up with specific examples of things that are missing. * Larry Zhu, Shawn Emery, others - examine the data model with respect to their specific implementations. DECISIONS (to be validated): * The data model document should not cover operations. * OTP perhaps does not need a mandatory-to-implement mechanism SESSION SUMMARY: We reviewed the status of several documents that are working their way through the queue, and discussed several documents which have recently concluded IETF or Working Group Last Call. The set-change password document is waiting for an updated version which the author didn't quite get in before the meeting, and then it will go to Tim and the IESG. We reviewed the status of several documents that are working their way through the queue. The set-change password document is waiting for an updated version which the author didn't quite get in before the meeting, and then it will go to Tim and the IESG. The cross-realm problem statement document finished WG last call some time ago, and has been waiting for the chairs to finish their review and writeup. We also discussed several documents which have recently concluded IETF or Working Group Last Call. The PKINIT ECC document has received no notable comments in IETF LC, and hopefully will move along smoothly. There were some comments in a security directorate review of naming, which will be addressed in an upcoming revision. The data model document just finished WGLC. Leif will do some updates to reflect comments received. Sam Hartman reviewed recent updates to the Preauth Framework document, Gareth Richards went over some open issues related to the OTP document. There was discussion as to whether it was necessary to have a particular mandatory-to-implement OTP mechanism; the conclusion in the room seemed to be that it was not. Gareth also described an issue relating to the need to come up with OTP algorithm identifiers: apparently keyprov has the same problem, and a joint solution may be appropriate. The chairs would like to see the group consider possible directions and next steps now that the cross-realm problem statement document is done. This could include rechartering to pick up new work to address one or more of the problems described there. To that end, Kamada Ken'ichi gave a presentation on the Client-Friendly Cross Realm work he's been doing. We will continue to consider where to go next, and possibly have another presentation in Dublin. Interested parties should contact the chairs and/or bring up their proposals on the mailing list. There was a discussion relating to the intended status of the STARTTLS document. Before we send this document to the IESG, the chairs would like to see us come to conclusion on whether it should be Informational or Standards Track. Tim is investigating whether there is precedent for possible actions when the technical aspects of a document are complete and it is blocked only on intended status. At the open mic, Shoichi Sakane mentioned a proposal he is bringing to the dhc working group to create a DHCPv6 option for identifying a KDC. From ldondeti@qualcomm.com Thu Mar 13 13:42:15 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2DHgFRW008136 for ; Thu, 13 Mar 2008 13:42:15 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2DHg37T009734 for ; Thu, 13 Mar 2008 13:42:04 -0400 (EDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id A4D4D1014CE4 for ; Thu, 13 Mar 2008 13:41:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1205430102; x=1236966102; h=message-id:date:from:user-agent:mime-version:to:cc: subject:content-type:content-transfer-encoding: x-ironport-av; z=Message-ID:=20<47D9673E.9040602@qualcomm.com>|Date:=20Th u,=2013=20Mar=202008=2010:41:18=20-0700|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.12=20(Windows/20080213)|MIME-Version:=201 .0|To:=20saag@mit.edu|CC:=20msec@ietf.org|Subject:=20MSEC =20summary|Content-Type:=20text/plain=3B=20charset=3DISO- 8859-15=3B=20format=3Dflowed|Content-Transfer-Encoding: =207bit|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5251 "=3B=20a=3D"1086028"; bh=Z3QoEOtDW+iqT6uOReW+eGK8zmhheugNfpXelJ9jvDk=; b=CUcQSLH+XDkshb7mwbXxyF8YdPqvewT/P4UkrIWgm/qHgjH/BbXVN1Qr AE6WK8HP+ZsvVoZTbOlUHvPXlIYLPW8+a6GjdiOrb8fvWJaPTFn5zVefe G7v+WA3NBirE+tJFoT6FwYW6ogizm+XNI4ohHSiir7y16oHgHT24IZO3z o=; X-IronPort-AV: E=McAfee;i="5200,2160,5251"; a="1086028" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Mar 2008 10:41:21 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2DHfKNl002426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Mar 2008 10:41:21 -0700 Received: from [10.50.68.106] (qconnect-10-50-68-106.qualcomm.com [10.50.68.106]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2DHfIUS030336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Mar 2008 10:41:19 -0700 Message-ID: <47D9673E.9040602@qualcomm.com> Date: Thu, 13 Mar 2008 10:41:18 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: saag@mit.edu Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: msec@ietf.org Subject: [saag] MSEC summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 17:42:15 -0000 We spent 1 hour on Wednesday discussing new work items. There are requirements related to a signaling protocol (RSVP) and routing protocols (e.g., OSPF, NLS) which point to the need for group key management protocols. There are indications that the work needs to happen in MSEC; although there is caution from the TSV ADs that the requirements do not imply that a particular protocol can be adopted as a MSEC work item. The direction would have been to extend GDOI to satisfy these requirements. As it stands now, we see no urgency for that work to happen. It appears that may be a longer term goal and so we agreed to proceed with the current GDOI extensions work (unrelated to the new requirements, and related to hash algorithm agility and other minor changes based on implementation experience). The authors are advised to continue the work as individual work. Next, Dan Wing presented his SRTP key transport work which works over DTLS. MSEC has a work item on group keying for SRTP, GDOI-SRTP. Sheela Rowles compared to the two approaches and after some discussion the conclusion was to pursue optimization of GDOI-SRTP for large groups and DTLS-SRTP-Key transport for small groups. As a side note, Dan was asked to study if there are indeed difficulties in using the TLS-based solution for large groups. TESLA-for-alc-norm is ready for WGLC. There was also a presentation on extending MIKEY to support mode negotiation. regards, Lakshminath From Donald.Eastlake@motorola.com Thu Mar 13 13:45:29 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2DHjTN7010626 for ; Thu, 13 Mar 2008 13:45:29 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2DHjJPI019226 for ; Thu, 13 Mar 2008 13:45:19 -0400 (EDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by mit.edu (Spam Firewall) with SMTP id D8E7478CAEA for ; Thu, 13 Mar 2008 13:44:57 -0400 (EDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1205430295!1770263!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 27695 invoked from network); 13 Mar 2008 17:44:56 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-5.tower-128.messagelabs.com with SMTP; 13 Mar 2008 17:44:56 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m2DHitTI009833 for ; Thu, 13 Mar 2008 10:44:55 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id m2DHiswg025924 for ; Thu, 13 Mar 2008 12:44:54 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id m2DHiqiU025907 for ; Thu, 13 Mar 2008 12:44:53 -0500 (CDT) 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" Date: Thu, 13 Mar 2008 13:44:50 -0400 Message-ID: <3870C46029D1F945B1472F170D2D979003997154@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Report on the KMART BoF Thread-Index: AciFMe/TotFQ9H5/Qui3h3vz9wiV2w== From: "Eastlake III Donald-LDE008" To: X-CFilter-Loop: Reflected X-Spam-Score: 3.7 X-Spam-Level: *** (3.7) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m2DHjTN7010626 Subject: [saag] Report on the KMART BoF X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 17:45:30 -0000 The Key MAnagement for RouTing protocols (KMART) BOF was Wednesday afternoon. It's primary goal was to improve mutual understanding between the Routing and Security Areas on the operational and protocol realities of routing security, threats against routing security, and what automated key management is and can do for you. It succeeded and seemed to presage improved cooperation between the areas. A number of excellent presentations were made on requirements, existing routing security problems and a history of attacks, operational characteristics of BGP, and key management. The BoF was well attended and the Routing and Security ADs were there. Some ISP people came to the mike and told us what problems they felt were the most pressing to solve. A list of four problems with link state routing was presented, with no disagreement, in which it was thought that the first three were reasonably soluble and the fourth more problematic: (1) weak algorithms, (2) poor key rollover / lack of key IDs, (3) lack of replay protection, and (4) multicast security. There was a desire for the Security Area to revisit RFC 3365 with respect to the routing protocol environment and for the Routing Area to pursue completion of some of the authentication work in the pipeline with renewed vigor. The TCP Authentication Option which is proceeding in parallel was cited several times. Donald (co-chair with Acee Lindem) ==================================================== Donald E. Eastlake 3rd +1-508-786-7554 (work) Motorola Laboratories 111 Locke Drive Marlborough, MA 01752 USA Donald.Eastlake@motorola.com From pekkas@netcore.fi Thu Mar 13 18:38:38 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2DMccmJ025349 for ; Thu, 13 Mar 2008 18:38:38 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2DMcV2U023464 for ; Thu, 13 Mar 2008 18:38:31 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 8C682E49AAD for ; Thu, 13 Mar 2008 18:38:10 -0400 (EDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m2DMc6KE007228; Fri, 14 Mar 2008 00:38:06 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m2DMc6Rq007225; Fri, 14 Mar 2008 00:38:06 +0200 Date: Fri, 14 Mar 2008 00:38:06 +0200 (EET) From: Pekka Savola To: Eastlake III Donald-LDE008 In-Reply-To: <3870C46029D1F945B1472F170D2D979003997154@de01exm64.ds.mot.com> Message-ID: References: <3870C46029D1F945B1472F170D2D979003997154@de01exm64.ds.mot.com> User-Agent: Alpine 1.00 (LRH 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Status: Clean X-Spam-Status: No, score=-3.7 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on otso.netcore.fi X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Report on the KMART BoF X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 22:38:39 -0000 On Thu, 13 Mar 2008, Eastlake III Donald-LDE008 wrote: > There was a desire for the Security > Area to revisit RFC 3365 with respect to the routing protocol > environment and for the Routing Area to pursue completion of > some of the authentication work in the pipeline with renewed > vigor. The TCP Authentication Option which is proceeding in > parallel was cited several times. I thought Dave Ward was referrng to RFC 4107 (BCP 107) on automatic key management requirements. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From Donald.Eastlake@motorola.com Fri Mar 14 00:44:01 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2E4i182006349 for ; Fri, 14 Mar 2008 00:44:01 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2E4hnFi017332 for ; Fri, 14 Mar 2008 00:43:50 -0400 (EDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by mit.edu (Spam Firewall) with SMTP id 54517E451B6 for ; Fri, 14 Mar 2008 00:43:29 -0400 (EDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1205469807!813074!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12364 invoked from network); 14 Mar 2008 04:43:28 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 14 Mar 2008 04:43:28 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m2E4hRds023965 for ; Thu, 13 Mar 2008 21:43:27 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id m2E4hR0v003302 for ; Thu, 13 Mar 2008 23:43:27 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id m2E4hQx1003298 for ; Thu, 13 Mar 2008 23:43:26 -0500 (CDT) 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" Date: Fri, 14 Mar 2008 00:43:24 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790039CFE5D@de01exm64.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Report on the KMART BoF Thread-Index: AciFWvoU+p0v8tT9SFCeIimULVbNOwAMqsHw References: <3870C46029D1F945B1472F170D2D979003997154@de01exm64.ds.mot.com> From: "Eastlake III Donald-LDE008" To: "Pekka Savola" X-CFilter-Loop: Reflected X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m2E4i182006349 Cc: saag@mit.edu Subject: Re: [saag] Report on the KMART BoF X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2008 04:44:01 -0000 You're correct. Consider "3365" replaced by "4107" in my message. Sorry, Donald -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Thursday, March 13, 2008 6:38 PM To: Eastlake III Donald-LDE008 Cc: saag@mit.edu Subject: Re: [saag] Report on the KMART BoF On Thu, 13 Mar 2008, Eastlake III Donald-LDE008 wrote: > There was a desire for the Security > Area to revisit RFC 3365 with respect to the routing protocol > environment and for the Routing Area to pursue completion of > some of the authentication work in the pipeline with renewed > vigor. The TCP Authentication Option which is proceeding in > parallel was cited several times. I thought Dave Ward was referrng to RFC 4107 (BCP 107) on automatic key management requirements. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From Nicolas.Williams@sun.com Fri Mar 14 03:50:43 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2E7ohRR002898 for ; Fri, 14 Mar 2008 03:50:43 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2E7oX8M016943 for ; Fri, 14 Mar 2008 03:50:33 -0400 (EDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 0E7D2E246AE for ; Fri, 14 Mar 2008 03:50:12 -0400 (EDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2E7oBLH023182 for ; Fri, 14 Mar 2008 07:50:11 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m2E7oBip051648 for ; Fri, 14 Mar 2008 01:50:11 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2E7oBcM013153 for ; Fri, 14 Mar 2008 02:50:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2E7oBGI013152 for saag@mit.edu; Fri, 14 Mar 2008 02:50:11 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 14 Mar 2008 02:50:11 -0500 From: Nicolas Williams To: saag@mit.edu Message-ID: <20080314075010.GC986@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Thank you, Sam X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2008 07:50:43 -0000 Sam, First, I want to thank you for all your work as AD these past three years, to say nothing of your friendship for the past six. At today's SAAG meeting I was slightly confused by one of your slides, the one where you labelled BTNS IPsec interfaces work and channel bindings "successes." My first reaction was "but we're not done!" But as a hall conversation following SAAG showed me, we have indeed succeeded in some key respects: many now understand channel binding and its value and seek to apply it, and many understand that IPsec requires APIs, and simple APIs mind you, to be truly useful for end-to-end security. And then I think about how hard it was just to get the BTNS WG spun up. And I recall that you first suggested channel binding to IPsec as the solution for the NFS w/ RDDP security XOR performance issues, way back in March 2003, five years ago, almost to the day, at Connectathon '03. Now we're almost done with the relevant specs. No, we're not yet done with running code, but we'll get there too. Therefore I'm no longer confused, I believe you're correct, those have been successes, both, in merely getting started, and in getting them to be taken seriously. And I must say, none of that would have happened without your help for the past five years. But for my temporary confusion I would have stood up and said all this at the mic. Thank you so very much. I wish you all the best in your new endeavours, and look forward to seeing you again. Nico -- From housley@vigilsec.com Thu Mar 20 17:06:15 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2KL6EqC026683 for ; Thu, 20 Mar 2008 17:06:14 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2KL64Fw007008 for ; Thu, 20 Mar 2008 17:06:04 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by mit.edu (Spam Firewall) with SMTP id 79663E39EF0 for ; Thu, 20 Mar 2008 17:05:43 -0400 (EDT) Received: (qmail 16774 invoked by uid 0); 20 Mar 2008 21:05:36 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 20 Mar 2008 21:05:36 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Mar 2008 16:30:16 -0400 To: saag@mit.edu From: Russ Housley In-Reply-To: <1205980033.23519.6.camel@localhost> References: <1205980033.23519.6.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20080320210543.79663E39EF0@mit.edu> X-Spam-Score: 0.84 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Fwd: Proposed W3C Charter: XML Security Working Group (until 2008-05-02) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 21:06:16 -0000 What, if anything, does this mean for the XMLDSig work that was done in the IETF? At 10:27 PM 3/19/2008, Ian B. Jacobs wrote: >Hello, > >Today W3C Advisory Committee Representatives received a Proposal >to revise the Security Activity [0] (see the W3C Process >Document description of Activity Proposals [1]). This proposal >includes a draft charter for the XML Security Working Group: > http://www.w3.org/2008/02/xmlsec-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 2008-05-02 on the >proposed charter. Please send comments to >public-new-work-comments@w3.org, which has a public archive: > http://lists.w3.org/Archives/Public/public-new-work-comments/ > >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 Thomas Roessler, Security Activity Lead . > >Thank you, > >Ian Jacobs, Head of W3C Communications > >[0] http://www.w3.org/Security/ >[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 From tlr+bounce@w3.org Fri Mar 21 09:40:40 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2LDee43032628 for ; Fri, 21 Mar 2008 09:40:40 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2LDeV7B005675 for ; Fri, 21 Mar 2008 09:40:31 -0400 (EDT) Received: from homer.w3.org (ssh.w3.org [128.30.52.60]) by mit.edu (Spam Firewall) with ESMTP id 25430E6167C for ; Fri, 21 Mar 2008 09:40:09 -0400 (EDT) Received: from iCoaster.does-not-exist.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 709CA4F2A5; Fri, 21 Mar 2008 09:40:09 -0400 (EDT) Received: from tlr by iCoaster.does-not-exist.org with local (Exim 4.66) (envelope-from ) id JY31YW-001MMG-PZ; Fri, 21 Mar 2008 14:40:08 +0100 Date: Fri, 21 Mar 2008 14:40:08 +0100 From: Thomas Roessler To: Russ Housley Message-ID: <20080321134008.GZ577@iCoaster.does-not-exist.org> References: <1205980033.23519.6.camel@localhost> <20080320210543.79663E39EF0@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080320210543.79663E39EF0@mit.edu> User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Fwd: Proposed W3C Charter: XML Security Working Group (until 2008-05-02) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2008 13:40:41 -0000 On 2008-03-20 16:30:16 -0400, Russ Housley wrote: > What, if anything, does this mean for the XMLDSig work that was > done in the IETF? It mostly means that there seemed to be critical mass for sorting out some referencing and transform model related issues at the W3C workshop last September, and that the community seems to agree that the current canonicalization model is really due for an overhaul. http://www.w3.org/2007/xmlsec/ws/report.html That workshop was announced on the saag list and at the Security Area meeting in Chicago; in fact, we deliberately aligned the position paper deadline so people could write and submit some *after* that meeting. I don't think many actually made use of that possibility. The workshop report was announced on saag in October. Note that the charter calls out close coordination with the IETF as an explicit requirement: The XML Signature specification was produced in a joint effort between W3C and the IETF. It is expected that the XML Security Working Group will liaise closely with the IETF Security and Application Areas in developing its deliverables. That said, if there are IETF participants who are specifically interested in this work and can't go the usual way through member companies, or if there are specific comments about the charter, please drop me a line. Regards, -- Thomas Roessler, W3C +33-4-89063488 > At 10:27 PM 3/19/2008, Ian B. Jacobs wrote: > > >Hello, > > > >Today W3C Advisory Committee Representatives received a Proposal > >to revise the Security Activity [0] (see the W3C Process > >Document description of Activity Proposals [1]). This proposal > >includes a draft charter for the XML Security Working Group: > > http://www.w3.org/2008/02/xmlsec-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 2008-05-02 on the > >proposed charter. Please send comments to > >public-new-work-comments@w3.org, which has a public archive: > > http://lists.w3.org/Archives/Public/public-new-work-comments/ > > > >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 Thomas Roessler, Security Activity Lead . > > > >Thank you, > > > >Ian Jacobs, Head of W3C Communications > > > >[0] http://www.w3.org/Security/ > >[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 > > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > From Donald.Eastlake@motorola.com Fri Mar 28 09:10:32 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2SDAVFR024153 for ; Fri, 28 Mar 2008 09:10:31 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2SDAONW022191 for ; Fri, 28 Mar 2008 09:10:24 -0400 (EDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by mit.edu (Spam Firewall) with SMTP id 2FB72850FF9 for ; Fri, 28 Mar 2008 09:10:22 -0400 (EDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1206709821!3262344!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 29524 invoked from network); 28 Mar 2008 13:10:21 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-5.tower-128.messagelabs.com with SMTP; 28 Mar 2008 13:10:21 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m2SDAKiN003738 for ; Fri, 28 Mar 2008 06:10:20 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id m2SDAJGb027692 for ; Fri, 28 Mar 2008 08:10:20 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id m2SDAINq027674 for ; Fri, 28 Mar 2008 08:10:19 -0500 (CDT) 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" Date: Fri, 28 Mar 2008 09:10:16 -0400 Message-ID: <3870C46029D1F945B1472F170D2D979003A56F7C@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: KMART Minutes Uploaded Thread-Index: AciQ1RDVps99zuVdR/K2UPWkmbMQFQ== From: "Eastlake III Donald-LDE008" To: , X-CFilter-Loop: Reflected X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m2SDAVFR024153 Subject: [saag] KMART Minutes Uploaded X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2008 13:10:32 -0000 Hi, Minutes have been uploaded to the IETF-71 Meeting Materials page for the KMART BoF. Thanks, Donald & Acee ==================================================== Donald E. Eastlake 3rd Motorola Laboratories 111 Locke Drive Marlborough, MA 01752 USA From max.rythmos@yahoo.com Sun Mar 30 06:37:23 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2UAbMOA015664 for ; Sun, 30 Mar 2008 06:37:23 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2UAbAZC025157 for ; Sun, 30 Mar 2008 06:37:10 -0400 (EDT) Received: from web32906.mail.mud.yahoo.com (web32906.mail.mud.yahoo.com [209.191.69.83]) by mit.edu (Spam Firewall) with SMTP id 787AAD88276 for ; Sun, 30 Mar 2008 06:36:46 -0400 (EDT) Received: (qmail 72974 invoked by uid 60001); 30 Mar 2008 10:36:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=ZDANjgCFKoxRN3rmR34ROwDXeEbeDodTWIuk4k7wBTR5HXDbq8OPfhbklctaFqcZcutMOfnTLWjBgfaJ4wvLkgs0MJWGhj2o/QjNOmoV/fjKiA2L8Y+JOxda2Qy6sNY9PsrCDYoJWB8xLl2j8XY3776K1YzxoPI4or/4h78pfA4=; X-YMail-OSG: AnpJYKMVM1kVWhcPY1q8N6sCbms0ipgkK1SuVtMuzYJQ14t.LcRFFxnRGxBoKV6ZnmCDksoxC4mscw8KzJvNtFiKywAhIcZxw.eG9xqlsj8F1HkWmGegswx8qEf7oQ-- Received: from [80.126.106.22] by web32906.mail.mud.yahoo.com via HTTP; Sun, 30 Mar 2008 03:36:45 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Sun, 30 Mar 2008 03:36:45 -0700 (PDT) From: MARZIO VENEMAN To: saag@mit.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1503521000-1206873405=:72963" Message-ID: <594504.72963.qm@web32906.mail.mud.yahoo.com> X-Spam-Score: 0.14 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Fw: Earth Science webliography and utmost recommended social network USA (facebook - myspace) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2008 10:37:23 -0000 --0-1503521000-1206873405=:72963 Content-Type: text/plain; charset=us-ascii Rythmomachy is a member of GotoMy.com and is inviting you to join our new community site! Rythmomachy Says: WELCOM Join GotoMy.com and you will instantly be connected to the community of the future. Click here to visit my profile! http://rythmomachy.gotomy.com What is GotoMy.com? ========================== Is the online community web site of the future. GotoMy.com offers every member an affilaite system that lets them get a % of every ad they see, and every ad their friends see. Click here for more information! http://www.gotomy.com/affiliate/?memberid=804&tarid=Rythmomachy Join today and get! >> Your own custom profile >> create your own photo albums >> upload unlimited number of photos >> Easily created skins >> Edit your layout >> Stay connected with te community >> Write and recieve comments with friends >> Create unlimited blogs >> Join a club, or create your own >> And Much More... Get started today! http://www.gotomy.com/affiliate/?memberid=Rythmomachy You received this email because someone who knows you sent you an invitation to join them on GotoMy.com If you feel this is spam please contact us at admin@GotoMy.com Thank you ______________________ http://lists.tldp.org/ ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ --0-1503521000-1206873405=:72963 Content-Type: text/html; charset=us-ascii
Rythmomachy is a member of GotoMy.com and is inviting you to join our new community site!
                                            
                                            Rythmomachy Says:
                                           
                                            WELCOM
                                           
                                            Join GotoMy.com and you will instantly be connected to the community of the future.
                                           
                                            Click here to visit my profile!
                                            http://rythmomachy.gotomy.com
                                           
                                            What is GotoMy.com?
                                            ==========================
                                            Is the online community web site of the future.
                                            GotoMy.com offers every member an affilaite system that lets them
                                            get a % of every ad they see, and every ad their friends see.
                                           
                                            Click here for more information!
                                            http://www.gotomy.com/affiliate/?memberid=804&tarid=Rythmomachy 
                                            
                                            Join today and get!
                                            >> Your own custom profile
                                            >> create your own photo albums
                                            >> upload unlimited number of photos
                                            >> Easily created skins
                                            >> Edit your layout
                                            >> Stay connected with te community
                                            >> Write and recieve comments with friends
                                            >> Create unlimited blogs
                                            >> Join a club, or create your own
                                            >> And Much More...
                                           
                                            Get started today!
                                            http://www.gotomy.com/affiliate/?memberid=Rythmomachy 
                                            
                                            You received this email because someone who knows you
                                            sent you an invitation to join them on GotoMy.com

                                            If you feel this is spam please contact us at admin@GotoMy.com
                                            Thank you
     


______________________
http://lists.tldp.org/


Looking for last minute shopping deals? Find them fast with Yahoo! Search. --0-1503521000-1206873405=:72963--